>the work

The funnel started with parallel readers mapping the prototype against the shipped specs, and they surfaced something I had not seen, which is that the prototype quietly bundled three separate initiatives. The highest-leverage human decision of the entire project was the scope gate right there, where I deleted roughly two epics of accidental scope before any code existed. From there we reconciled 122 requirement candidates against the shipped catalogs, which turned up 19 conflicts that were all resolved and 6 product questions I had to rule on myself, and then we authored 114 requirements with permanent, immutable IDs, all before a single line of implementation.

Then the spec was minted into 45 thin, vertical, end-to-end slices wired together by blocked-by edges. Once that graph existed, readiness was something the loop could compute, so it derived the ready set directly from Linear and nobody hand-ordered the work. Laid out by build depth the columns of the graph are waves, and every slice in a column became buildable the moment the wave before it merged. The tall columns are exactly where two lanes ran in parallel, and the critical path set the floor on how fast any of this could go.

Every lane ran the same nine-step spine: pre-flight, sync real data, implement with a file-domain-isolated strike team, verify against the running app, multi-lens review, fix every finding, iterate until clean, capture learnings, and honor the autonomy dial. I tiered verification to risk rather than to whatever was convenient, so the drain lead re-ran every gate personally, read every diff, drove the live app through browser automation, and queried the database directly for ground truth on the write paths. We finished with 111 of 111 end-to-end scenarios green. The defects had already been caught upstream in each lane's own QA loop, so by the time we reached the final gate it was really acting as confirmation.

The human budget for all 45 tickets came to eight decisions: a scope gate, a reversal blessing, six product rulings, the ticket-mint authorization, the drain gate, pacing, and a set of mid-build product questions that I recorded for a PM rather than letting an agent decide them. Every one of the roughly 92 PRs was approved and merged by a human after the artifact-level gates. I am happy to give agents autonomy over execution, and I keep the judgment calls with people.

Two pipelines share one engine, and the triage front door in front of them accepts the work in whatever form it arrives — a prototype, a Figma file, a ticket, a meeting transcript, a freeform prompt. Small work runs a single lane to a PR, and big features go through the spec-decomposition funnel and end in an epic drain. Whether a lane is running solo or as part of a drain, it runs the same spine: real-data sync, a test-case ledger gate, a file-domain-isolated strike team with a QA loop, live verification against the running app, multi-lens read-only review, fix-every-finding iteration, and learnings capture before ship.

The newest stage sits between triage and planning, and it came out of a retrospective. A 75-ticket epic had drained clean, every lane green, and then QA reopened 37% of its tickets after merge. When I traced the findings, 22 of the 43 attributable ones sat in coverage categories that QA's own derivation rules name and that my pre-PR verification had never named, and about half of everything QA found was a spec gap or a ruling rather than a code defect. The tickets had carried no test cases, so verify had been executing its own guesses. So I split QA's ticket-testing skill in two and pulled the derivation half left of the build. It reads the ticket with every comment and attachment, runs a 17-area requirement analysis, and derives cases under a shared rules file whose version is pinned into every ledger, so the pre-build and post-merge derivations cannot drift apart. Rules generate scenarios and only spec rows may supply expected outcomes, so a rule with no governing row becomes a typed spec-gap line with a proposed value, two rows that disagree become a conflict line that is never buildable as-is, and every one of those lines needs a human disposition before an implementer may start. Each case gets a content-hashed ID so a refresh keeps the unchanged ones, a substrate tag that says whether a unit run, an API call, a real browser, or a human can prove it, and a dependency list so a superseded spec row invalidates the cases that leaned on it. The ledger is then executed by the implementer's QA teammate, by verify in a real browser, and finally by QA after merge, all from the same list, which is posted once as a single comment on the ticket. As the acceptance test I re-ran the derivation blind on seven reopened tickets with their inputs frozen to pre-build state, and it reproduced the later QA finding on all seven. The re-open rate since has been about 15%.

Before anything executes, the plan has to survive an argument. The debate engine runs a 5-lens reviewer panel covering correctness, coverage, consistency, exhaustiveness, and test-case coverage, and each reviewer traces the requirement through the codebase before it is allowed to read the plan. Then an author agent validates every blocker against real code. All of this is deterministic workflow code with severity gates, round caps, token reserves, and a formal dispute-escalation path, and when the disagreement is genuine that path hands it to the human rather than resolving it automatically.

Everything runs under budgets and stop conditions: spawn caps, a 3-strike rule keyed on root-cause tags rather than raw failure counts, broken-baseline hard stops, and an operator-owned-decision rule that stops the loop and hands back whenever a genuine product call comes up. Subagents never return prose. Every fan-out is schema-validated so that orchestration is always consuming typed data.

The far end now reaches production. I wrote the deploy stage by encoding what I had improvised by hand during one release night: a live-state pre-flight that caught a missing database default-privileges grant, a pipeline watch that turned a base-image CVE failure into a dependency-bump PR within minutes, and an unprompted filtered log watch while the team tested. The command reads live production state first and builds a go/no-go card from it. It computes the last green run from stage results, because a non-gating post-deploy test stage makes every run read as failed, lists the pending migrations in dependency order, checks the grants, and requires a rollback answer with a named database-restore owner before the card can go green. On a green card it queues the backend pipeline and then the frontend one, and a named human approves the pipeline gate every time, because the agent has no approve path at all. Every red stage is classified against a fixed playbook, and the ledger write lands before any action. Verification compares each workload's revision, image tag, traffic split, migration head, grants, and cache headers against expected text written into the release ledger ahead of time, so no row can pass by construction, and an unreadable check is recorded as blocked rather than failed, which means a tunnel outage can neither open the pointer bump nor print the rollback commands. Then a soak reads the error logs every ten minutes, subtracts a noise list and everything already seen, and turns every new signature into a row for a human to look at. The release ledger itself is a self-contained HTML page committed to git with append-only events and no server behind it, and the close-out tags the release on the ledger's own merge commit.

Prompt engineering is converging across teams, and as far as I could tell nobody was harvesting the parts that travel. So I surveyed a brownfield team's suite, roughly 6,800 lines with 21 slash commands and 5 subagent templates, and I read it the way you would read another engineer's library, asking what is generalizable and what is load-bearing on their particular context.

Five patterns travelled: risk-driven mode selection, file-domain isolation between subagents, task-log files as durable phase contracts, active-fixer review agents, and frontmatter-registered subagents. I adopted all five into a different team's greenfield suite, and then I wrote a teammate-facing report so that other AI engineers could pilot the same patterns without having to redo the archaeology themselves.