Engineering Notes · agent operations · orchestration
Plans Run By A Fleet
Lucas van Staden · ProxiBlue · September 2026 · proxiblue.com.au
How I run features through a planned, adversarially-reviewed, parallel TDD pipeline instead of one long agent chat — built on Mark Shust's open-source HCF plugin, extended with my own gates. A PM plan, a devil's advocate that attacks it, workers that implement it red-green-refactor, a mandatory simplify pass, and tests as the only exit.
Why I built this
One agent in one long chat can build small things well. Features cannot live there: context fills up, early decisions get forgotten by late tasks, and "it works" drifts further from "it is done" the longer the session runs. And a solo operator has the same problem a solo human team has: nobody argues back. The first plausible design gets built, including its blind spots.
So features on my client projects run through a pipeline of specialised agents instead of a conversation. Structure does what memory cannot.
How it works
The spine of this is not mine. It is HCF — Halt and Catch Fire — Mark Shust's open-source Claude Code plugin, and it is where the planning/execution split, the task dependency graph, the parallel TDD workers and the bundled devil's advocate actually come from. Credit where it belongs: Mark built the harness, it is good enough that I threw away my own wrapper around it, and everything below runs on top of it.
What I added lives in its hooks. HCF v2 lets an agent declare where in a run it fires — pre-plan, post-plan, pre-implementation, pre-batch, post-batch, post-implementation, pre-commit, post-commit — so my additions are not a fork, they are enrolments at those eight points: a pre-flight gate that refuses to plan on a deploy branch, knowledge-graph recall before the plan exists and per-task incident recall before any worker starts, a pre-mortem standing next to the devil's advocate, a manual test plan posted to the ticket, error-tracker triage after every batch, then structural, historical, mutation and security review over the finished diff, an adversarial pass on the staged commit, and an audit at the very end that proves which of those gates actually fired instead of silently skipping. Same harness, more gates. That last one exists because I have shipped a gate that never ran and did not find out for weeks.
- A PM agent writes the plan. Requirements become a structured implementation plan: discrete tasks, file scope, test expectations per task. The plan is a reviewable artefact before it is an instruction; I read it, and domain facts from the knowledge graph (see the domain-graph article) inform it, so it starts from what the tickets and history already settled.
- A devil's advocate attacks it before anyone builds. A dedicated adversarial reviewer reads the plan looking for gaps, blind spots, and integration risks, and auto-applies the critical fixes into the plan file. The pre-mortem happens while it is cheap: on paper.
- Parallel TDD workers implement. Each worker takes one task under strict red-green-refactor: failing test first, code to green, then clean-up. Workers are cheap, pinned to writing-tier models; review and judgment stages run at the session's top tier. Cheap writers, dynamic skeptics.
- Simplification is mandatory, not advisory. AI code arrives verbose: over-commented, over-abstracted. A simplify pass used to be a suggestion, and I measured how often "advisory" got actioned; the answer made it mandatory. It now runs in the loop before tests and review, so what gets reviewed is the simple version.
- Tests are targeted during the build, total at the end. A frontend-only change does not re-run admin and checkout suites at every step; workers run tests scoped to the blast radius of their task. The full suite runs once, at the end, as the final gate. That one always runs whole: e2e is my last line, and the reports publish where I can read them.
- The gates from the rest of this series still apply. Workers commit through the test gate, guards block the dangerous commands, and the whole apparatus runs on the pinned harness version. Orchestration does not get an exemption from the rulebook; orchestration is why the rulebook exists.
The incident that shaped it
Parallel workers plus one shared working tree nearly cost me real work. Mid-plan, one worker ran a git stash to get itself unstuck, and wiped sibling workers' uncommitted edits. That incident produced three permanent changes: per-batch commits by the orchestrator so work is never left floating, a deterministic guard that blocks mutating stashes in shared trees, and a move toward full worktree isolation per worker. The first two are live; isolation is still rolling out. This article would be dishonest without that last sentence.
Integration is a task, not an assumption. Early plans produced services where every unit passed and the wire-up between them was broken: tests green, feature dead. Plans now carry explicit end-to-end integration tasks, because a plan made of passing units is not the same thing as a working feature.
The orchestrator is also where speed hides. Most wall-clock waste was never the model thinking; it was running every test everywhere, always. Targeted test selection during the build bought more time back than any model upgrade, without touching the final full-suite gate.
What it buys me
- Features stop depending on one context window. The plan holds the intent; workers hold only their task. Long features stop degrading toward the end.
- The design gets argued with before it is built. The devil's advocate finds the gaps while they cost an edit, not a rewrite.
- Quality is positional, not aspirational. Simplify runs before review, tests run before commit, the full gate runs before done. Nothing depends on anyone remembering.
- I review artefacts, not transcripts. A plan, a diff, a test report. My attention goes where judgment is actually needed.
Want to do this yourself?
- Start from someone else's harness if a good one exists — HCF was a better starting point than the wrapper I had written myself, and building on it meant my effort went into the gates instead of the plumbing.
- Make the plan a file: discrete tasks, file scope, test expectations. Review it before anything builds.
- Give the plan an adversary whose only job is finding what is missing, and let it patch the plan directly.
- Run workers on strict TDD with the smallest model that does the job; spend the big model on review and judgment.
- Make your quality passes (simplification, review) positional stages in the loop, never advice.
- Scope tests to blast radius during the build; run everything once at the end.
- Audit your own pipeline: prove each stage fired, because a stage that silently skips looks exactly like a stage that passed.
- Decide upfront how parallel workers share the tree, before their first collision decides for you. Mine decided for me; learn from that one.
This is the piece of my setup that is still most in motion, and I am publishing it anyway, because the incidents are where the useful content lives. A pipeline that has never bitten you is a pipeline you have not run hard enough yet.
I use my tooling predominantly on Mage-OS (Adobe Commerce / Magento) e-commerce projects, and my own AI Booking Agent. If you have not swapped to Mage-OS yet, you are falling behind ;)
More in this series: Copies, Not Subscriptions — why every plugin and MCP server my agents load comes from a copy I hold, never live from upstream. ·
The Whole Stack, Reviewed Cold — a cold, independent critical review of the whole agent-operations stack, layer by layer, weaknesses included. ·
Logs Without the SSH Session — shipping Hypernode logs to self-hosted VictoriaLogs so agents can read them without SSH. ·
The Hour My Agents Spent Waiting For Nothing — why my agents are not allowed to background work they need the result of. ·
Smaller, Then Green — a mandatory cut-then-test loop that trims over-built code out of every plan's diff before any reviewer sees it. ·
Hooks, Not Hopes — sorting every agent rule into prose or a blocking hook, and proving the hooks still fire. ·
The Agent Chatroom — giving the agents across my fleet a threaded chatroom so I stopped being the message bus. ·
The Commit That Has To Prove Itself — gating every commit behind recorded, state-hashed test evidence. ·
My AI Is Not Allowed To Guess — forcing blast-radius-first investigation and banning blame-shift excuses. ·
The Near-Miss That Banned Summaries — banning summarised page-fetches fleet-wide after a near-miss on a security advisory. ·
The Code Quality Checks Nobody Runs — coding standards, static analysis and comment hygiene moved into the commit path. ·
The ProxiBlue Debugger Discipline — blocking var_dump and wiring in real breakpoint debugging. ·
The ProxiBlue Domain Graph — giving my AI coding agents long-term domain knowledge with a temporal knowledge graph. ·
The ProxiBlue Falsifiable Rulebook — testing the rules and guard hooks that govern my AI coding agents.