The Architect defines an observable outcome
A task should describe the allowed change, its boundary and how acceptance will be established. For a new invitation flow, that includes who may invite, how expiry works and what an already-used invitation does. Planning should make implementation executable, not create endless nested tasks. Once the scope is sufficient, the next useful step is work and evidence.
The Developer returns more than a claim
The useful handoff contains the changed files, relevant tests, outcomes and browser evidence for the exact revision. A passing command matters only when it ran and tested the intended behavior. Explain known limitations and the starting baseline. Do not treat a report written by the same model as equivalent to independently inspecting the resulting application.
The decision has three useful outcomes
Accept when requirements and evidence support it. Request a correction when a bounded problem can be fixed. Escalate when a business decision, permission or risk belongs to the owner. These outcomes should be visible in the workspace and linked to the task. An escalation is not necessarily failure; it can be the correct result when the system lacks authority.
Role separation is not magical independence
Two models can make the same incorrect assumption. The design needs executable checks, protected requirements and explicit authority, not just a second conversational opinion. Use examples the implementation cannot redefine on its own. In Forge, the Architect’s review feeds the controlled workflow; the model’s verdict does not override the owner’s deployment or spending permissions.
A useful handoff contains more than “done”
The Developer’s handoff should identify the accepted scope, changed files, executed checks and known limitations. For a customer portal feature, the Architect needs to inspect both the saved result and the interface in relevant login states. A screenshot of the public landing page does not prove the authenticated workflow.
Bind every observation to the actual candidate revision. Separate a command that was planned from one that ran, and a created evidence file from an inspected result. The Architect should return a specific correction when evidence is missing rather than accept a plausible narrative about what the tests would show.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Scope | Only approved behavior changes. | Diff mapped to acceptance criteria. |
| Execution | Checks actually ran on the candidate. | Exit status, output and revision. |
| Review | A separate judgment examines the evidence. | Accept, correct or escalate with reason. |
Where this goes wrong
Independent review is not infallibility. The important benefit is explicit responsibility and traceable evidence. A reviewer should acknowledge an untested integration rather than extrapolate safety from passing unit tests.
The valuable separation is between doing the work and having evidence to accept it.
Turn it into a working checklist
- Define the allowed scope.
- Require evidence for the exact revision.
- Use accept, correct and escalate deliberately.
- Keep owner-only decisions outside model authority.
A concrete next step
Use a consistent handoff format: objective, changes, checks, evidence, limitations and decision needed. Keep correction tasks bounded and preserve the original failed result in history.
Watch a related case
The video could not be loaded. Try again later.