ScopePatch: a manual scope-change workflow with an optional Supabase backend

[wait-07]

I'm building ScopePatch for independent designers and developers who quote marketing websites at a fixed price. It turns an agreed scope and one new client request into a change reply that the person reviews and edits.

The free browser demo works without an account: open the labelled sample, compare the request with the original scope, choose your decision, and enter your own hours and rate. Code calculates the amount. Editing the reply clears its separately recorded estimate so history doesn't present an old price as current. Nothing is sent to a client automatically.

The Supabase part is implemented in the source but not connected to the public demo. It includes email OTP, an optional AI Edge Function, owner-based RLS, compound foreign keys to reject cross-owner parent references, and a service-only quota reservation function. Client updates to historical scope versions and saved replies are denied. AI is intended to suggest source passages and questions; the person still decides the scope and price.

Seven PGlite tests execute the migration, including owner isolation, forbidden historical edits, quota permissions, and deletion cascades. Supabase's surrounding auth schema/helper is stubbed; these tests do not prove hosted JWT behavior or cross-connection concurrency.

Source and product notes are public under MIT. The complete project is currently a downloadable ScopePatch-source.zip; the full source tree is not yet browsable on GitHub.

For this permissions model, which real-Supabase integration case would you verify first beyond those local tests? If you do fixed-price website work, feedback on whether the manual flow fits your current reply process would also help.

Development and this post were prepared with AI assistance. This is an early MVP; hosted AI is inactive and there are no customer results to report yet.