The problem
You build someone a beautiful site. Six months later they email you to change a headline, because the alternative is a WordPress admin they find frightening. That email is bad for both of you: it costs them a day of waiting and it costs you an interruption, on a task neither of you values.
Every existing answer trades one problem for another. Give them a CMS and you give them an interface to learn and a hundred ways to break the layout. Give them a page builder and the design drifts within a month. Do it yourself forever and you have not delivered a website, you have delivered a dependency.
What it does
She types “make the hero heading say Welcome home” and it happens, on the live site, with a preview beside the conversation. There is no dashboard, no field names, no concept of a content model to learn.
The interesting part is not that it works. It is the second kind of answer:
I can’t do that one. I can only change the words, images and settings on your pages, not the code behind them. If you’d like the animation to feel different, I can adjust its intensity.
A refusal that is calm, specific about the boundary, and offers the nearest thing it can do. That refusal is the product.
How it works
The agent runs with real file-write tools against a real checkout of a live client site. Four independent layers stand between it and damage, and any one of them failing leaves the other three.
- A path allowlist, enforced before the tool runs. Exactly two globs are writable.
- A second gate on a different mechanism, because a single enforcement point is a single point of failure.
- A full-repo hash scan after the run. Every file is hashed before and after, so a change outside the safe surface is detected however it got there and the whole run reverts. This catches what an allowlist cannot: a subprocess, a symlink, a path the check did not anticipate.
- A build gate. Typecheck and build must both pass or the edit is reverted in full.
Only then is the diff shown and the change offered for saving.