PROJECT
LOCK AND REGENERATE
Scope:
Solo project — research, design, build, deploy. One day.
Next.js, TypeScript, deployed on Vercel.
Github: https://github.com/anuragkalra/lock-and-regenerate
Prompt-editing is a bad control surface. To fix one part of a generated result, you throw the whole thing away and re-roll blind. This is a planner where you edit the artifact instead: lock the slots that work, regenerate, and only the unlocked ones change.
Tested in Google Docs suggesting mode with a six-paragraph itinerary.
1
Change marks sit on the text
2
Docs diffs the edit, not the content
Two failures, and they point the same direction.
Docs marks change on the text itself — the insertion stacks above the struck-through original, the paragraph grows from two lines to three, and every untouched paragraph below it moves.
And it diffs at the granularity of the edit, not the content. Select all, paste a revision where two of six paragraphs are byte-identical, and all six are struck through and re-inserted. Content that never changed is marked as changed.
Which is the same failure the whole project is about: select-all-and-paste is a blind re-roll performed by hand. You throw away what you wanted to keep because the tool has no way to know you wanted to keep it.
So the slot is the diff unit, change is marked on the container rather than the text, and card height is fixed at 92px. The last one isn’t styling — it’s what makes “locked slots don’t move” true by construction instead of by discipline.
Lock two slots and regenerate. Then try blind re-roll.
What this doesn’t handle yet
Times are fixed. Making them editable introduces real constraint propagation — move dinner to 15:00 and everything around it has to renegotiate — which is a harder problem than locking and a separate project.
Slot content can’t be edited inline. Free text breaks fixed height, and fixed height is what enforces the core constraint.
The demo runs on hardcoded options, not a live model. The generation isn’t the contribution; the interaction is.