One build request in, a supervised multi-stage build out

Long builds done by unattended agents went wrong in repeatable ways. I wanted to ask for a build and have that complexity handled automatically. The design came from a written record of two weeks of failures. Builds went for the wrong target because decisions were copied into briefs and went stale. About three builds in four had no review at all. A gate keyed on a file fired the moment the file appeared, while the run was still writing.

Research and adversarial review became stages rather than prompt paragraphs, and each review writes findings to a file the next stage must answer point by point. "Done" is treated as a claim the supervisor checks, not a fact.

A request becomes discovery, research rounds each followed by an adversarial review, a plan, build stages, ship and a final review, all queued at once. An unclear request is sized medium, because the record's commonest fault was a job sized too small. Discovery writes the target from the repo itself, and every build happens on its own branch in its own worktree.

A supervisor, called every minute, is the only writer of gate files. It passes a stage only when the output is fresh, ends with a completion marker, the stage report exists, the last message does not read as waiting and a fast finish explains itself. Build and ship must also record a passing test verdict. A failed check re-queues the stage with a note saying what was missing, at most twice. A refusal or a logged-out session stalls the pipeline with one notification.

Every stage brief carries the same labelled guards, among them authority (only ship may merge, deploy or push) and full tests before any merge. A selftest fails if any label is missing from any brief. I can add a note mid-build, and every unpassed stage must answer it by its id. Steps only a person can do reach me when the plan passes, not at ship.

A review on 30 Sep found the supervisor passed stages on "I finished" alone and did not read test verdicts. Each fix got its own selftest check. Every stage already passed in the live pipelines still passed under the new rules. Build stages ran through it overnight into 1 Oct.

A status check run inside a sandbox read live runs as dead, and the supervisor started second attempts into worktrees still in use. The fix counts a run as dead only on a positive reading and takes one lock per worktree. The waiting-message test only catches phrasings seen so far, so the completion marker remains the real guard.