The “70% wall” is our name for a familiar moment, not a measured percentage. The app has a dashboard, settings, a responsive menu and a convincing screenshot. A client asks for one small change. The agent improves the project list and removes the only way to reopen a completed proof. The new screenshot is prettier. The person who approved a proof yesterday now has a support problem. The missing piece was a description of what already worked.
Consider a client who signs in, opens the Atlas project, approves a proof and reloads the page. Four actions, one expectation: the proof should still show as approved. An agent seeing only the project card might rebuild it with local component state. The first click works and the screenshot looks right. A reload loses the approval. The repair passed the test that the agent had in mind. Nobody gave it the test that mattered to the client.
Make a map you can replay
Start with one task, one actor and one object. “A client reviews the latest Atlas proof and sees the decision after a reload” is enough. It tells you where to begin, what data matters, which interaction to try and how to distinguish a temporary change from a saved one. Save the route and the initial state. If the proof has already been approved in your browser, reset the fictional record before recording the baseline.
Include an alternate path that reaches the same object. The client might enter through a search result or a direct link. You do not need to map every page in the product. You need to know which neighboring behavior the proposed edit can damage. If the project card and search results share a component, editing its link can break both. If they use separate implementations, fix the reported surface first and record the second one as a separate decision.
A useful baseline fits in a few lines: search Atlas, open the proof, approve, reload, observe Approved. Add what you actually saw. If the original app already forgets the decision, label that a baseline failure. Do not tell the next agent to preserve a defect, and do not let it claim credit for repairing something it never checked. A baseline gives both sides room to make an honest statement about the change.
Tell the agent what stays true
The request “modernize the project list” leaves every visible choice open. A more useful brief is: “Bring proofs awaiting review above finished projects. Keep the project URLs, search behavior and saved approvals. Use the existing status field. Verify the Atlas flow before and after.” This still gives the agent design freedom. It prevents it from solving a hierarchy problem by inventing a new data model.
Write protected behavior in terms a browser can observe. “Preserve state management” is vague. “After approving and reloading, the same proof shows Approved” is testable even if the internal implementation changes. Add a negative case: approving an Atlas proof must not approve another project's proof. That catches accidental reuse of a single boolean for the whole list. It also protects the user from a failure that no screenshot of one card could reveal.
Keep a short list of boundaries in the repository. If billing migrations, live email or account permissions are outside a visual change, say so. If the agent discovers that the requested behavior genuinely requires a backend change, it should show the gap. A fake success toast would make the demo look smooth while leaving the action broken. The right handoff might be a verified visual improvement and one clearly identified service requirement.
Inspect data boundaries, not just components
A recurring regression starts with a convenient rewrite. An agent changes an invoice filter, duplicates the fixture data and renders the redesign from the copy. The screenshot looks right for October; choosing September still shows October totals. Search for the source of truth before editing. Find the function or query that supplies both the table and the summary. Verify that they use the same selected month after the change.
The Tallybook demo has a useful boundary case: September combined with the overdue filter produces no matching rows. “No invoices” would imply the studio has none, while “No overdue invoices in September” tells the truth. Clearing the filter should reveal the existing September records. Test the sequence in that order rather than jumping straight to a populated table. A summary that updates correctly can coexist with an empty state that strands the customer.
Think about stale network replies in the same way. Suppose a customer searches for Atlas, quickly changes the query, then receives the first response last. Which result should stay on screen? You do not have to build an elaborate simulation for a static demo, but a real client with asynchronous requests deserves this check. Write what you verified locally and what needs a service test. A mock response proves routing logic, not provider availability.
Keep the patch small enough to understand
Compare the diff against the brief after the first useful change. If the agent modified a global card component to fix one project route, list the other consumers. A login form that shares the card's padding might now overflow at phone width. Decide whether the rule was wrong globally or whether this route needed a local composition. A smaller change is valuable because you can see its consequences, not because line counts are a measure of quality.
Review deleted code with particular care. Removing a visually hidden label can shorten a file and break the accessible name of an input. Replacing a link with a styled container can preserve the screenshot and lose keyboard activation, opening in a new tab and copied URLs. Ask the agent to use the browser as a customer would: tab to the item, open it, go back, and confirm the search still means what it meant before.
Do not force every fix through the same test suite. For a copy change on one static page, reading the rendered text and checking the link may be sufficient. For a shared approval control, replay the saved-state sequence and the neighboring search flow. For a change in a billing service, use a disposable test account and inspect the recorded event. Match the cost of the check to the cost of being wrong.
Review without reading the proposed conclusion first
A person who wrote the fix knows exactly where to click. A reviewer should begin with the original task and baseline. Give them the URL, fixture and acceptance condition before the implementer's summary. Let them attempt the sequence on their own. When they fail, capture the exact transition. “I cannot approve the proof after reopening the deep link” is a report someone can reproduce. “The design feels off” may be true, but it is harder to assign.
Look at desktop and phone widths with real text. Keep an eye on the second action, because some regressions appear only after the first success. Save twice, change a filter twice, reopen a dialog after closing it with Escape. The first attempt can be correct by accident if a component starts with convenient defaults. Repetition tells you whether the implementation returns to a usable state.
Leave the next session an honest starting point
A handoff should name the changed surface, the checks run, the outcome and anything not tested. “Atlas approval survived reload in a fresh browser; expired sessions were not tested” gives the next person two useful facts. “Everything works” gives them neither. Link to the changed component or the screenshot when doing so saves someone a search. Avoid turning the handoff into a second undocumented product specification.
Keep the unfinished work small and visible. If you discovered that an old archived proof has no recovery action, record its route, fixture and consequence in the backlog. It can be valuable without belonging to today's patch. A release decision should distinguish that issue from a critical regression in the flow you just changed. Say what would make you hold the release and what evidence would let you proceed.
Give the repair a stopping rule. In the current /fix workflow a change earns another render at both widths and another grade on the same task. If a decision becomes harder or a previously working interaction breaks, keep the evidence and restore that round where safe. Three rounds is a cap, even if one grade is still C. This prevents a promising screenshot from hiding a broken approval.
In the real-repo trial for print exchange feed, the plain agent won in both orders. The two votes were 2 and 3 on a seven-point scale oriented toward the kit, with four neutral. The protected action is checked separately: a reader must be able to save a print and find it on their profile.
Use the free audit to start the next pass. Record what works, name what should improve and try the same task after the edit. Keep the screenshots as evidence of appearance and the browser sequence as evidence of behavior. Both belong in the review when the team decides whether the change is ready.