Persistent file panel
Protection stays visible; the panel takes canvas space.
For the Figma Make product team
Later Make prompts can change completed details, forcing rechecks and repair.
Independent proposal · not a Figma featureThe proposed change
I explored an enforced scope that asks before changing files a builder protects.01 / User signals
Three public comments, not frequency data.
02 / Work process
Three AI-generated treatments informed by a Figma-published Make interface.
Protection stays visible; the panel takes canvas space.
Scope is explicit for each prompt; setup repeats.
Only protected-file exceptions pause; normal edits proceed.
03 / Decision
Selected concept C · protected-change checkpoint
A keeps protection visible but uses editor space. B gives each prompt an explicit scope but repeats setup and creates chances to forget a file. C still requires builders to mark files protected first. Then normal edits proceed; only protected-file touches pause, name affected paths, and offer retry or one-run approval. C is our strongest starting hypothesis for balancing control and speed, not a user-tested winner. A may prove better if builders need constant visibility into protected files.
Boundary: Files remain readable. At apply, check writes, renames and deletes; one-run approval expires.
Limit: Shared CSS, parents and dependencies can still change the rendered screen.
Make has templates, guidelines, plan mode, review and rollback; Bolt documents locks.
Business hypothesis: fewer repair cycles may improve completion and paid retention, though reduced repair prompting could initially lower credit spend. Measure customer value and margin.
This local example makes no AI request and changes no real files. A mixed patch blocks atomically; approval applies once.
Choose a request and preview the patch.
Every touched path must be in the editable scope.