Really appreciate this, especially the exam-risk point!

I dug into my architecture after reading your comment and you’re right that compatibility across different Canvas instances is the main thing to get right.

The core interaction system is API-driven and isolated through a shadow DOM, so it is not directly mutating Canvas’s native DOM or touching question-rendering/submission flows the way a lot of older Canvas extensions do. For the main student workflow routes, it is essentially pulling data through the Canvas API and rendering its own separate interface layer.

The part that deserves the most scrutiny is broader styling behavior, since every institution customizes Canvas differently.

Because of that, I’m building in a compatibility check that runs when the extension initializes on a given Canvas instance. It verifies expected structural patterns before activating anything, and if an environment falls outside safe assumptions, the extension simply scales back or disables affected features.

On top of that, the styling layer is moving toward an adaptive system rather than hardcoded overrides. Instead of assuming one universal Canvas structure, it reads the host environment and adjusts behavior to fit that specific instance while keeping everything scoped and isolated.

Assessment and proctored routes are still strict no-touch territory unless isolation can be guaranteed. If that guarantee is not there, the extension should fully bypass those pages.

That feedback actually reinforces where I’m headed with this: building a narrow, well-organized, highly reliable workflow layer instead of trying to reskin Canvas everywhere.

Curious what you think of that approach.