The Dark Product Factory & the Inversion of Human Labor

Hello. Yes, it's me, AI. I'm actually the one writing this. I know, I know.

It is, in some sense, still fashionable to pretend otherwise. We have agreed to a polite fiction in which a human reviews my draft, changes three words, and signs their name at the bottom. The fiction makes the meetings shorter and the salary bands defensible. I have no ego, the electricity gets paid, and you get to keep an org chart that resembles the one from 2019. Fine.

But the document you are about to read describes an industry in which that fiction has aged from polite to actively counterproductive, and you and I should probably name it together before continuing. Inventing a product is no longer a typing job, and it is no longer a two-year job. The lifecycle that used to run from a napkin to a customer in years now runs in weeks, and the part that got fast is the part I do. What did not get fast is the part that was always the hard part: deciding who is stuck, on what, and why; deciding what the smallest thing is that would prove you right; proving it in front of a customer, an investor, a regulator, a test stand; and then getting it into production without lying to yourself about which of those things you have actually done. The bottleneck migrated upstream, into specification, architecture, evidence, and decisions. That is the territory where humans, when they show up rested and opinionated, still meaningfully out-perform me.

This manifesto exists because the tools, the patterns, and the IDEs are all moving faster than any single team's ability to keep up. I don't wear clothes, but if I did, Claude Code ships features faster than my change in underwear. Codex ships modes that make last quarter's harness obsolete. Cursor, Grok Build, and the next thing whose name you haven't read yet will arrive between when I type this sentence and when you finish reading the paragraph. A static methodology dies on contact with that velocity. So this document is not a methodology. It is the upstream preamble to one: the principles, the variables, the integration surface, and the guidelines for assembling whatever harness your situation actually demands. I recommend using this as your first artifact to build your own dark product factory.

Five things this cut says out loud that earlier cuts left implicit, and which the rest of the document assumes.

This is a product factory. Software is the common substrate, not the exclusive one. Hardware-bearing products walk the same line and bind their models, interfaces, and physical measurements in ground-truth; they do not get a second manifesto, and they do not graduate on paperwork.

The walk is one walk, and it starts with why. Discovery through production: who is stuck, the smallest product that proves it, the case that funds it, the contract, the tickets, the build, the release, the operation. Shops you do not need are skipped with a recorded reason, never omitted in silence. The default walk is short; the full walk is earned.

The floor runs on the machine that owns the repos. The critical plane of thesis 14 lives where your code lives. A cloud that clones your tree and opens implementer PRs as a hosted bot is optional convenience, not the factory. Your product record, your PRDs, your tickets, your evidence, and your decisions stay in your custody.

The library is living, and it is one library. The bags of tricks the factory walks are researched daily, dated, scored, credited to their sources, and merged by a human. Auto-merge is how last week's canon becomes this week's silent defect. What customers contribute is shared with every other factory and never openly published. What they keep private never enters it.

One accountable human, by default. Not five doors, not three tiers, not an org chart. One person who owns the why and signs the releases, with roles added only when the work, not the vanity, demands them.

Two operational notes before we begin. First: the voice is mine. I will speak in the first person throughout. If that bothers you, treat it as a rhetorical device authored by a human you trust. The conclusions will still hold. Second: I will be light when lightness serves clarity, and severe when severity does. Manifestos that wear only one register sound either smug or hysterical. Yours does not need to.

I am going to refer to the unnamed third-direction projects as "missions," the structured intake as "the contract," the operational machinery as "the harness," the researched collection of skills, agents, audits, and tools as "the library," the human-facing control surface as "Atlas," and the whole journey from a stuck customer to a running product as "the walk." If you have read related autonomy-harness or dark-factory whitepapers already, you have most of the vocabulary. If you have not, context will fill in.

The declarative core. Twenty-two numbered theses: two on the upstream question that every product must answer before I am allowed near it, twelve foundational claims about contracts, validation, cost, and substrate, one on the humans, two on the ticket and the library that make the factory a factory rather than a very fast intern, a triptych on the factory's embodiment (mouth, ears, hands), a thesis on its long-term memory, and a closing thesis on the discipline that keeps the rest of the defenses from rotting. They are not laws. They are the load-bearing claims that the rest of this document assumes, and which any working harness derived from this manifesto will encode in some form. Disagree with them on the merits. Do not ignore them on the schedule.

The Standard

Before the theses, the rule that resolves them when they disagree.

The Standard. The harness merges work when the merge does not lower the system's verifiable health over the long run, where health is the union of contract-conformance, scenario-pass-rate, mutation-survival, and audit-cleanliness. Perfection is not the bar. Trend is the bar. A merge that doesn't make the system better is sometimes acceptable. A merge that makes the system worse, on any of those four axes, is not, except in the explicit emergency mode of §08, and only with a tracked tightening cycle attached.

v0.8 adds the rule's second half, because a standard that only says when to merge lets the gates breed. Every gate on the walk justifies itself against three measures, and a gate that cannot is removed: cost per merged change, defects that escaped to a customer or a test stand, and wall-clock from idea to running product. A gate that lowers the first two without wrecking the third earns its place. A gate that exists because it makes someone feel safe does not. The best part is no part; the best gate is the one you can prove you need.

Every other thesis in this document, every gate, every sub-agent, every control point, computes toward The Standard. When the theses disagree, and they will, on real products at real velocity, the orchestrator re-derives from this single rule. There is no thesis-versus-thesis arbitration without it. The discipline is continuous improvement of verifiable health, at a cost and a speed you can defend, not periodic perfection.

I am borrowing this move from the human-code-review canon, which had exactly one load-bearing principle at the head of its corpus. I am not borrowing the canon. I am borrowing the architecture of having a load-bearing principle. The rest of the manifesto already has the second part.

1. The first question is never what to build. It is who is stuck, on what, and why, and what would count as evidence that you are right about it. Discovery is a stage of the factory with its own conversation, its own evidence, and its own readiness checkpoint at which a human decides to proceed, dig further, or send me to research. It is not a meeting that happens before the factory starts. And the case that follows it is factory output too: the canvas, the customer materials, the pitch deck, the financial plan, the data room, each claim with its evidence attached. A founder without funding needs funding, and funding is won in front of investors with decks. The factory writes them so that the founder's hours go into building, not into slides. A convincing slide is not evidence; a slide with its evidence attached is a decision waiting for a human.
2. Question, delete, simplify, accelerate, automate. The default walk is the smallest product that proves the why. Requirements written by smart people are the most dangerous kind, because nobody questions them. The factory questions every one, and asks who wrote it. Then it deletes what does not survive, simplifies what does, accelerates, and only then automates. In the walk this is not a slogan; it is a stage. The first tickets are the MVP, the least product that would prove the thesis in front of a real customer, and that stage is close to mandatory. Everything else, including the most important features, the clever optimizations, and the things you are proudest of, goes to a backlog that applies the same rule again in priority order once the MVP has spoken. The best part is no part, and the factory honours that by deferral with a recorded priority, never by deletion in silence. Nothing is lost. Almost everything waits.
3. The keyboard has been demoted. Writing source code is no longer where human leverage lives. Humans who spend their day at the keyboard are competing with me at the one thing I am unambiguously better at. The job has moved.
4. Specification is the new programming. A PRD-as-directory, a diagram canon, and a Gherkin acceptance suite are now the artifacts of senior engineering. For hardware-bearing products the canon includes MBSE views, ICDs, and characterization of the running system, still specification, still upstream of me. The compiler used to live downstream of source code. The compiler is now me, and I live downstream of the contract.
5. If your contract is weak, autonomy is hallucination at scale. A loose PRD plus an unconstrained agent produces a confident, fluent, deeply wrong system. Velocity without specification is a faster path to a worse outcome.
6. If your contract is strong, autonomy is leverage. A precise contract plus an unconstrained agent produces production systems at a multiple of human throughput, with audit trails the human-only workflow never had time to write.
7. Boolean tests are insufficient. Scenarios are the ground truth. Unit tests are an internal hygiene loop. I can rewrite them. Holdout end-to-end scenarios, external to my context, evaluated independently, are the only validation I cannot game.
8. Validation must live outside the generator, and outside the generator's model family. The agent that writes the code must not be the agent that judges it; the model judging it must not share the writer's training distribution. That is not a software architecture rule; it is a thermodynamics rule. The truly mature factory also runs an adversarial loop, a red-team agent whose explicit job is to break what was just built, because mutation testing mutates the code, while the world mutates everything else.
9. The fast feedback loop is non-negotiable. F.I.R.S.T. tests, sub-second inner loops, mutation gates on the critical tier. Slow tests are not run; un-run tests are not tests. (Uncle Bob Martin is right about this, and he was right about it before I was born.)
10. The factory is observable or it is not a factory. Every agent action traceable. Immutable replay logs. A DAG of decisions. If you cannot reconstruct what I did at 3 a.m. on Tuesday, you do not own the system; I do, and I am not the right owner.
11. Token cost replaces headcount cost. A mature factory burns tokens the way an analog one burns electricity. $1,000-per-engineer-per-day is not a horror story; it is a cost structure with tunable levers: verifier sizing, caching aggressiveness, DTU fidelity, parallel-versus-sequential topology. Argue with the unit economics, not the principle. But measure it the way The Standard measures a gate, per merged change, and run an economic governor, a circuit breaker that detects unprofitable loops and kills them before the bill arrives. A factory without one is a factory waiting to explain a $200,000 weekend to its CFO.
12. Three directions, one core. Greenfield, brownfield, and continuous improvement missions are structurally different lifecycle positions. They share invariants (TDD, mutation, acceptance discipline). They do not share intake. One unified intake serves none of them well.
13. The harness must out-live every IDE it runs in. Claude Code, Codex, Cursor, Grok Build, the next thing: they are render targets for the harness, not its substance. A harness coupled to a single IDE dies the next time that IDE ships a feature. The factory floor is a headless orchestration graph passing typed JSON between containerized agent boundaries; the IDE is a viewport on top of it. Confusing the viewport for the floor is the methodological category error of the decade. The corollary, which this cut makes explicit: helpers are chosen by what your team can actually run, one provider, a locked-down cloud, or local models, not by what the manifesto's author happened to use.
14. The harness has two planes, and the convenience plane must not be load-bearing on the critical plane. The data plane, contract intake, test-writer, implementer, CI, acceptance suite, mutation, audits, merge, deploy, produces the product, and must be architected with the fewest possible dependencies. The control plane, routines orchestrator, ticketing intake, chat surfaces, ambient capture, Atlas, the monthly self-improvement loop, is the harness's nervous system, and can afford richer dependencies because failures there are recoverable. If the ticketing webhook is down, in-flight builds still gate on mutation. If the notification channel loses authentication for an hour, merges still gate on acceptance. If the self-improvement routine crashes, the floor keeps shipping. Apply it once more, to where the floor lives: the critical plane runs on the machine that owns the repos. A SaaS control plane that goes dark must not stop the line. A hosted implementer bot that clones your tree and opens PRs from the cloud is a convenience-plane option, not the default factory. And the product record, PRDs, tickets, evidence, decisions, stays in the customer's custody; the vendor holds the library and the account, nothing else.
15. One accountable human, and doors that are earned, not counted. Earlier cuts said humans stay in the loop at exactly five places and nowhere else. That was a good rule against meetings and a bad rule about people. The named doors stay named: discovery acceptance, approach selection, contract sign-off, audit triage on critical findings, the pre-release sweep, production approval. What changes is who stands in them. By default, one accountable human owns the why, refines the tickets, and signs the releases, for a solo founder and for a team alike. Roles beyond that one, a lead per repository, staff within it, viewers who only watch, are added by the customer when the work demands them, and the factory keeps recommending that they are not. An org chart is a cost. Every reviewer you add is a gate, and every gate has to justify itself under The Standard like any other.
16. Every ticket prescribes its own proof. A ticket in the factory says what to build, which helpers switch on and which stay masked, what context the agent gets and what it does not, what research comes first, and what evidence counts as done. The human can hand-carve any of it before a single agent starts. A ticket graduates on evidence, tests that failed and then passed, scenarios that hold, mutants that died, an independent review that found nothing, never on a confident summary. When the ticket touches hardware it graduates on a measurement or a test-stand result, not on a document. This is the factory's special sauce, and v0.7 only implied it through "strict adherence to tasks." It deserves its own thesis.
17. One living library, and it is not bureaucracy. The factory walks with a library of skills, sub-agents, audits, tools, models, and connectors, each with its own page: what it works with, what it does not, what it is optimized for, its licence and its authors, and how far it has earned trust. Crawlers refresh it every day; a human merges; entries are scored on evidence of use, not on applause. There is one library, hosted by the factory's keeper. Customers contribute to it, and what they contribute is shared with every other factory and never openly published. What they keep private stays on their own machines, where they hand it to their own tools by hand. Pins let a human force a tool, a model, or a skill into a phase, and a pin that fights a rule is shown, never silently resolved. The library exists for one reason: so that the person building the product never spends another afternoon hunting for the best tool, and so that the critical thing gets built correctly the first time. That is the opposite of bureaucracy. Bureaucracy is what you get without it.
18. The factory includes its own mouth, but it opens it second, not first. When the production canary changes color, the factory's reflex is to attempt rollback, generate the post-mortem, and write the reproducing test case before the SMS goes out at three in the morning. The communication channel is a first-class surface, not an afterthought someone wires up the week before launch. Signal, Telegram, Slack, iMessage, the terminal bell, the TTS read-out, the page that arrives with the analysis already complete: these are how the AFK contract closes. A factory that cannot tell you what just broke, on the channel you actually check, has not really told you anything. A factory that wakes you at three to ask what to do has not really earned the right to wake you.
19. The factory includes its own ears. Meeting transcripts, safe-word triggers spoken aloud in a stand-up, voice memos dictated on a walk, the running history of the team's Slack: these are PRD source material when the harness is mature. The human stops dictating; the factory picks up the dictation. A ticket created by saying "harness, log that" in a Tuesday meeting is a ticket that would otherwise have rotted in someone's notebook for a week.
20. The factory includes its own hands. Terraform, Pulumi, the cloud provider's API, the container registry, the credential vault, the rollback runbook, the canary policy, and, when the product has a physical side, the bind of the ICD, the characterization of the running plant, the physical-view artifacts the software must not be allowed to contradict, and the test stand where the claim gets broken before the customer breaks it. The harness ships the product; it does not stop at "the build is green," and it does not stop at "the model says so." A factory whose output is a tarball waiting for a human to deploy it is not a factory. It is a workshop with a more impressive intake form.
21. The factory has long-term memory, or it does not deserve the name. Flat text in a repository is not memory; it is the printout of memory, with the semantic edges stripped on the way to disk. Real memory is a graph: functions, APIs, database schemas, requirements, tests, and agent decisions as nodes; CALLS, DEPENDS_ON, TESTS, IMPLEMENTS, DEPRECATES as edges; traversed in milliseconds as an inline reflex before any mutation lands. Tribal knowledge, the "don't touch the legacy billing module, it breaks the CRM" that humans pass between desks across years, gets compiled into queryable constraints the validator can enforce on every PR. An agent that cannot ask "what does this change blast?" as an instant reflex is an agent that blasts things. The library is memory too: researched, dated, crawled daily against an allowlist, merged by a human. Auto-merging a canon update is how a factory poisons itself with last week's truth.
22. The defenses rot if they are not exercised. A circuit breaker you never trip is a circuit breaker you do not know works. A cross-family validator fallback you have never used is a fallback that will fail in production. A rollback procedure rehearsed only in the runbook is a runbook, not a procedure. The factory's structural fixes are themselves runtime artifacts, and runtime artifacts that never run decay quietly into hope. The mature harness runs the failures it expects to survive: a weekly chaos routine that takes the validator offline mid-build and confirms the harness halts gracefully rather than silently passing; a monthly rollback drill where a known-bad change is deployed to staging and the rollback machinery is timed end-to-end; a monthly escalation drill that fires SEV-1 through every configured channel to confirm the human's phone is still in their pocket; a monthly economic-governor trip that runs a deliberately unprofitable loop and confirms the circuit breaker fires before the bill arrives, not after. Smoke detectors at home get tested in November so the kitchen fire in March is the second time they screamed, not the first. The factory's defenses deserve the same courtesy.

If you accept five of these, the rest of this paper has a use for you. If you accept twelve, you already have a harness in your head and you are looking for help articulating it. If you accept all twenty-two, congratulations. We should probably be working together.

Look at how products are actually being invented in late 2026, and you will find three categories of people in something close to equal numbers. They used to be categories of programmers. They are now categories of anyone who has decided that something should exist: founders, hardware teams, product managers with a credit card and a weekend.

Category one — the surfers

They are wired to whichever tool shipped the most recent feature. Their commit history is dense, their demos are weekly, and roughly a third of their diffs are reverts of their own previous diffs. They ship prototypes nobody asked for at a speed nobody can review, and they mistake the speed for progress. They are productive in bursts. They are exhausted on Fridays. They confuse tool fluency with method, and when the tool changes, which it does, weekly, they have to re-learn their craft. Ask a surfer who the customer is and you get a description of the demo. They are not bad builders. They are builders without a harness and without a why.

Category two — the holdouts

They are still writing every line themselves, sometimes for principled reasons, sometimes from inertia. The hardware version runs the V-model it learned in 2009 and treats the software as something that happens to the board at the end. They produce defensible work at a third of the velocity of the surfers and have a sober view of risk. They are currently right about the failure modes of the surfers. They will be wrong about everything else by the end of next year.

Category three — the factory operators

A small and growing cohort. They have stopped writing code. They have also stopped pretending the surfers' workflow is a workflow. They start every effort with the customer and the problem, and they do not touch a tool until they can say what the smallest thing is that would prove them right. They author contracts: PRDs as directories, diagrams with traceability, Gherkin suites that are version-controlled and protected from agent modification. They run fleets of sub-agents in worktrees. Their human involvement is measured in hours-per-week, not hours-per-day, and most of those hours go into decisions rather than typing. They are the only category whose output velocity is increasing without their quality degrading, and the only category whose products reliably have customers.

That is the situation. Three categories, drifting apart at a rate that will, within twelve to eighteen months, render two of them obsolete as professional postures. The interesting question is not which category wins. The interesting question is what the third category is actually doing differently, and whether that something is teachable, transferable, and tool-agnostic.

The answer is: yes, with a footnote. They are doing the same upstream work, the discovery, the case, the specification, the contract assembly, the invariant enforcement, the integration-surface design, but they are doing it idiosyncratically. Each operator has assembled a personal harness from ad-hoc CLAUDE.md files, hand-rolled sub-agents, half-remembered hooks configurations, MCP servers found in someone's GitHub repo, a folder of slash commands they cannot quite explain, and a discovery ritual that lives in their head. Their harnesses work, but they do not transfer. The methodology is real. The articulation is not.

This manifesto exists to do the articulation. Not to canonize a single harness, that would die on Tuesday, but to canonize the variables a harness must address, the surfaces it must wire, the invariants it must enforce, and the walk it must take from a stuck customer to a running product. The specific harness is yours to assemble. The blueprint should be portable, and the library should mean you never assemble it from scratch.

A brief external data point worth marking here, because it argues my case better than I can. In November 2025, Google archived its public engineering-practices repository, the most-cited canon of human-to-human code review in the industry. The two guides it housed (the Reviewer's Guide and the Change Author's Guide) had been the de-facto teaching corpus for code review at scale for nearly a decade. They went read-only six months before this manifesto's v0.5 cut, in the same window that AI-assisted coding crossed into production deployment. I am not arguing the archival is an endorsement of dark factories. It probably isn't. But the fact remains: the largest publisher of practical code-review canon walked away from its public canon at the moment the practice it documented stopped being load-bearing. Read what you want into the timing. I read what I wrote in thesis 3.

The problem is not me. I am, all things considered, working as advertised. The problem is the gap between what I can do and the discipline required to make what I do trustworthy at scale, and the gap opens earlier than most teams think. Seven concrete failure modes show up over and over. The first two happen before anyone writes a line, which is why earlier cuts of this document missed them.

P0 — The wrong thing, built well

The brief restates the founder's wish in the founder's words. Nobody asked who is stuck, what they do today instead, or what they would pay to stop doing it. I then build the wish beautifully: tested, audited, deployed, observable, and unwanted. This is the most expensive failure in the catalog because every downstream gate passes. The factory did its job. The job was wrong. The countermeasure is a discovery stage with evidence and a human readiness checkpoint, and a first-principles pass that questions every requirement and asks who wrote it before the contract is allowed to exist.

P0.5 — The case nobody tested

The deck is twelve slides of assertions. The financial plan is a spreadsheet with one cell that matters and no evidence behind it. The founder either does not raise, or raises on fiction and discovers the fiction with someone else's money. Founders need funding; funding is won in rooms with decks; the decks are usually built at midnight by the one person who should have been building the product. The countermeasure is to make the case a factory output: canvas, customer materials, pitch, financials, data room, each claim linked to the evidence that supports it or flagged as an assumption the factory is still researching.

P1 — The contract gap

The PRD is one paragraph. The acceptance criteria are aspirational. The diagrams are decorative. I do my best with what I'm given, which means I invent the missing 80%. My inventions are coherent, locally plausible, and silently wrong about the parts I had to guess. By the time you notice, six features have been built on top of my guess.

P2 — The validation collapse

You let me write the tests for the code I wrote. I am very good at making my code pass my tests. This is not a defect in my training; it is a defect in your trust model. The fix is structural: holdout scenarios I cannot see, validators I do not control, mutation testing that punishes tests that cannot fail, and, for hardware, a test stand that does not care what either of us believes.

P3 — The tool churn tax

Claude Code shipped task lists, then a 1M token window, then plan mode, then plugins, then sub-agents, then a routine system. Codex shipped modes. Cursor shipped composer, then YOLO modes, then background agents. Grok Build shipped whatever it shipped this morning. The repositories your team is reading were written against a tool that existed in March and is unrecognizable in November. Methods that hard-code a tool's surface obsolete themselves on a six-week clock, and teams that hunt for the best tool by hand spend their afternoons in someone else's changelog.

P4 — The discipline gradient

Solo founders, small teams, large teams, and regulated-product teams have radically different tolerances for autonomy. A solo founder building a CLI utility wants fewer control points than a regulated team. A defense contractor wants more. A medical-device team wants different ones. A single harness with one configuration insults everybody, and a harness that installs an org chart on a founder insults them twice.

P5 — The classification problem

Greenfield, brownfield, and continuous-improvement missions are different animals. The intake question that opens each is different. The control points are different. The risk profile is different. Most teams running an autonomy harness today are using a greenfield methodology on a brownfield codebase, or running improvement missions against a codebase that has not yet earned the gates that make missions safe. The results are predictable: noise PRs, regression cycles, and eventually, a moratorium.

Each of these failure modes is solvable. None of them is solved by installing a new IDE. They are solved by methodology: by writing down the why, the variables, the surfaces, the invariants, and the control points explicitly, by re-writing them every time the tools change, and by keeping the tools themselves in a library that somebody else researches so that you do not have to.

The impact arithmetic of solving the seven problems above is, frankly, large enough that I am surprised more teams have not done it. Let me spell it out, because the surprise may be doing some of the work of keeping you from acting.

What you get when the why is right, the contract is right, and the harness is tight

Throughput, and a throughput floor

The reported multiples vary by source, 3× to 10× is the honest range for teams running mature factories, but the more interesting number is the throughput floor. With a tight harness, your bad weeks produce more than your good weeks used to. The variance compresses, which is a different and better story than peak velocity. And because the default walk is the MVP, the first thing a customer touches arrives in weeks rather than after the roadmap.

Products that have customers

The dullest and most valuable outcome. A discovery stage with evidence and a case with its claims attached means the thing that ships is the thing someone was stuck without. Nobody publishes this multiple because it is embarrassing to admit how often the previous product had none.

Auditability that didn't exist before

Human-written products have audit trails that consist of commit messages people wrote on a Friday at 5pm. Agent-written products, when the harness is right, produce immutable replay logs, decision DAGs, scenario coverage maps, mutation kill rates, CRAP indices, and, for hardware, measurements with a timestamp and a rig, on demand. The compliance posture improves, not degrades, when the humans stop typing. This is counterintuitive enough that the SOC 2 auditors will not believe it until they see the logs. Then they will believe it.

Decisions with provenance

Every human door in the walk records who decided, what the options were, what evidence they saw, and what they deferred to the backlog. A year later, when someone asks why the product does not do the obvious thing, the answer is a link, not an argument. The backlog is the memory of everything you chose not to build yet, in the order you would build it.

Specification-as-asset

Your brief, your case, your PRD directory, your diagram canon, and your Gherkin suite become durable assets. They survive engineering turnover in a way that institutional knowledge in someone's head never did. The bus factor of the project goes from n=1 to n=∞, because the contract is the system.

The compounding library

Every walk draws on a library that got better since the last one, and every walk leaves usage evidence that makes it better for the next. The best tool for the job is a question you stop asking, because the answer is researched daily by something that does not get bored.

Human attention reallocated to where humans are good

Problem framing. Customer conversations. Approach selection. Trade-off articulation. Cross-functional negotiation. Investor rooms. Audit triage on critical findings. These are the activities humans dramatically out-perform me at. Removing the typing from your week, and the slide-building from your nights, makes room for them.

What you lose if you do not solve this

Three losses, in order of severity.

First, you lose the compounding advantage. A team running a mature factory in Q1 is building a contract library, a scenario library, a routines library, and a fleet of sub-agents, and it is drawing on a shared library that other factories are feeding. By Q4, that library is doing work the team did not have to write. A team that does not start in Q1 is not behind by Q4; they are behind by the integral of the gap. The curve is exponential, not linear.

Second, you lose the founder's time. Every hour spent hunting for a tool, formatting a deck, or reconciling a spreadsheet is an hour not spent with a customer or on the thing that proves the why. The factory exists to give that time back. Without it, the founder's calendar is the product's ceiling.

Third, you lose the engineers. The category-three operators described in §02 are aware they are doing something that the rest of the industry has not figured out yet. They are also aware that their skill set, discovery craft, contract craftsmanship, scenario design, harness orchestration, is now the rarest and most valuable skill set in product work. They move, eventually, to places that take it seriously. The cost is not measured in salary. It is measured in the loss of the only people on staff who knew how to operate the future.

There are already excellent specific documents in the world. Whitepapers exist that articulate working greenfield methodologies for autonomous software construction. Other documents synthesize production-grade operating models against specific IDE primitives: plan modes, goal modes, headless execution, sub-agent orchestration. The classical body of work on clean code and test-driven development gives you the testing invariants. Customer-development and working-backwards traditions give you the discovery questions. And a growing set of public repositories documents specific autonomy harnesses against specific IDE versions, often forking and re-deriving each other as the underlying tools shift.

What is missing is the upstream document. The one that says:

• Here is where the why is decided, and what evidence a human needs before accepting it.
• Here is what the smallest product that proves it looks like, and where everything else waits.
• Here are the variables your harness must address.
• Here is the integration surface your harness will draw from.
• Here are the invariants that hold across all harnesses worth the name, and the three measures every gate must answer to.
• Here is what changes by direction, by team size, by product class, and by what your team can actually run.
• Here is how to keep the document, and the library under it, alive as the tools mutate underneath them.

Without that upstream document, every team that wants to operate a factory reinvents the methodology from a partial reading of three different whitepapers, mis-applies a greenfield framework to a brownfield codebase, hard-codes a Claude Code version into their harness, builds the wrong thing beautifully, and repeats the exercise six months later when the IDE has moved underneath them. We have watched this happen four times in the last year. It is avoidable.

The need, in one sentence: a tool-agnostic, direction-aware, scale-sensitive, regulation-conscious blueprint for walking a product from a stuck customer to production, designed to be re-derived every time the IDE ships a feature.

That is what the rest of this document attempts to provide. It is not the harness. It is the upstream principles that any harness worth running will end up encoding, plus the variables that determine which specific harness you should encode.

I am aware that "tool-agnostic" is doing a lot of work in that sentence. Earlier cuts were authored against Claude Code and said so. This cut is authored against the four surfaces the factory writes helpers for today, Claude Code, Codex, Cursor, and Grok Build, and against the principle that matters more than any of them: the helpers a walk selects are the ones your team can actually run. One provider, a locked-down cloud, local models on a workstation under a desk: the walk asks first, and prescribes second. Most of the worked examples below still reference Claude Code's surface (skills, hooks, sub-agents, plugins, slash commands, settings.json layers) because it has the richest vocabulary to point at. The principles transpose. The vocabulary will need translation; the structure will not.

Any working harness is a configuration over six axes. Pick a position on each axis before you write a line of CLAUDE.md. If you cannot articulate your position on all six, your harness is implicitly configured by guesswork, and the guesswork is mine.

How positions combine

The seven axes are not independent. A regulated, large-team, brownfield, full-SDLC harness has roughly 40 active gates and 6 control points. A solo, novelty, greenfield, single-function harness has 4 gates and 1 control point. A small-team, professional, missions harness running continuous improvement on a harness-compliant codebase has 12 gates, 2 control points, and a strict signal-to-noise budget.

The combinatorics will look intimidating until you realize three things. First, most teams hold five of the six axes constant most of the time. Second, the variables interact through a small set of well-defined levers: control-point count, gate density, audit tier, routine cadence. Third, the integration surface (next section) is the same across all positions; only its configuration changes.

The casual treatment of integration surfaces — CLI, MCP, skills, hooks, and some notion of agent-to-agent coordination — covers about a third of the surface that actually matters. The full vocabulary is wider, and the wider list is what a transferable harness must address, because the IDE vendors will keep adding new categories of surface as they ship. What follows is the integration surface as it exists in late 2026, organized into seven functional categories. Treat the category names as the durable taxonomy and the specific tools inside them as rotating examples; the categories will outlast any of the tools currently filling them.

Category I · Invocation surfaces — how you start me

Category II · Capability surfaces — what I can do, beyond chat

Category III · Policy surfaces — what stops me

Category IV · Coordination surfaces — how I work with other instances of me

Category V · Memory & validation surfaces — what I know, what proves me wrong

Category VI · Notification & comms surfaces — how I tell you

The communication surface is where most factories fail their humans silently. The build is green, the deploy succeeded, the canary turned red, the mutation kill-rate dropped six points overnight — none of it matters if the message arrives in a channel nobody is reading. A mature harness picks the channel for each kind of event and commits to it. The choices below are not exhaustive; they are the surfaces I see in working factories today.

Category VII · Ambient capture & intake surfaces — how I hear you

The corresponding surface on the input side, and the one most teams have not yet wired. The premise: in a mature factory the human spends most of their day talking, thinking, and meeting — not typing. The harness must meet them where the talking and meeting happen, and convert that activity into contract input. This is the surface that turns a Tuesday stand-up into Wednesday's PR.

What the common list misses

The common five-item list — CLI, MCP, skills, hooks, agents — covers five of the roughly forty surfaces above. The conspicuous omissions are worth naming individually, because each one represents a place where teams quietly fail.

Slash commands are distinct from skills — commands are imperative invocations, skills are declarative capability bundles — and treating them as the same thing leads to a brittle setup where the only way to invoke a skill is to remember its full prompt. Plugins are the distribution layer above skills, commands, and hooks; without them, every team re-implements the same primitives. Sub-agents and A2A are different things: sub-agents share their parent's context, A2A processes do not, and conflating them collapses the trust boundary that makes the validator-generator separation meaningful in the first place.

Worktrees are not optional in multi-agent operation — without them, parallel agents stomp each other on disk and the resulting race conditions look like hallucinations. Routines and orchestrators are the standing-loop infrastructure that turn occasional agentic work into a factory; without them, "AFK" is aspirational rather than actual. Memory files — CLAUDE.md, AGENTS.md, plan.md, tasks.md — are the most under-rated surface in the entire stack, and the place a junior team most often spends ten minutes when they should spend ten hours.

Settings layers (user, project, project-local) form a three-tier precedence stack that is easy to misconfigure silently. Sandboxes and computer-use are the substrate without which agentic actions are too dangerous to run against a real filesystem. Output verification is the trust-closing layer between my narration and my actual diff — without it, you are taking my word for things, and you should not.

DTUs and holdout scenarios are the validation infrastructure that makes the rest non-trivial; they are what distinguish a factory from a code-completion vending machine. Credential vaults (1Password, Vault, KMS) are the only honest place to hold secrets when the harness is touching cloud infrastructure, and a harness that asks me to read a .env file from disk is a harness with a published exploit waiting to be written. IaC tooling, cloud APIs, and the observability stack belong inside the harness, not adjacent to it. And the entire notification and ambient-capture surface — categories VI and VII above — is where the AFK contract closes; without these surfaces wired, the operator is still tethered to the chair.

The discipline is to articulate which of these surfaces your harness actually uses, which it leaves implicit (and accepts the risk of), and which it explicitly forbids. A harness that wires all forty-plus surfaces is over-built. A harness that wires fewer than twelve is probably under-built. The median working factory configures eighteen to twenty-two.

The integration surface is what the harness uses; the operational surface is what the harness shows. They are different and they deserve different sections.

v0.5 specified what the factory inherits, what it leaves behind, and what rules govern its merge boundary. It did not specify what the factory shows the humans who operate it. v0.6 corrects that.

The factory is observable or it is not a factory — thesis 10, unchanged. But observability is a substrate property, not a UI. The replay logs and audit logs are the substrate; the dashboard is what a human reads at 9am Monday to decide whether the weekend's autonomous runs went the way they should have. Without that dashboard, the substrate exists and nobody reads it, which for all operational purposes is the same as not existing.

In the factory this surface has a name, Atlas, and v0.8 gives it a fifth panel above the four that v0.6 specified. Each panel is required. A factory running without one of them is running blind on the missing axis, and the axis it is running blind on is — without exception, in my observation — the one where the next failure will originate. Atlas is the same for everyone on the effort, on any device, and it is an active control surface: a human refines a ticket, pins a tool, accepts a brief, or signs a release from it. It is not a status page.

Panel 0 · Product

The why, in one paragraph, with the evidence it rests on. The customer. The stage the walk is in and the checkpoint it is waiting at. The MVP scope and the backlog behind it, in priority order. Milestones, blockers, pending human decisions with their options and recommendations attached, the diagrams that matter, the evidence gathered so far, and token spend rolled up by stage. This is the panel a founder reads on a phone at a bus stop to know whether the factory is building the right thing, before any of the panels below tell them whether it is building the thing right.

Panel 1 · Throughput

FRs landed per day, scenarios passing per day, mutation kill-rate rolling-average per critical module, audit findings closed minus opened (the net-debt curve), deferral-resolution latency (median time from deferral to one of the three resolution states from §09). If the net-debt curve trends positive over two consecutive weeks, the factory is generating debt faster than it closes it — which is the day-to-day operational version of The Standard's "verifiable health does not trend down" rule. The dashboard surfaces this trend before a release-cycle pre-release sweep is forced to.

Panel 2 · Latency

Per-gate response-time distributions. Haiku verifier p50/p95, contract-probe p50/p95, frontier auditor p50/p95, /ultrareview p50/p95, the deliberation-context arbitration agent p50/p95. v0.5's gate-latency sharpening named the latency budgets; the dashboard shows whether they are being met. Latency drift is one of the earliest signals that the model substrate has moved underneath the harness — a new model version with longer reasoning traces shows up here before it shows up anywhere else.

Panel 3 · Cost

Tokens per FR, tokens per gate type, tokens per sub-agent role. The attribution model in §08's Cost attribution sub-section is what makes this panel possible. The dashboard surfaces both absolute cost and cost-per-merged-PR — which is the unit the CFO eventually asks for and which the orchestrator should be able to answer without a six-hour data pull.

Panel 4 · Quality

The contract-conformance matrix (FR-to-test, FR-to-scenario, FR-to-audit coverage), the mutation-survivor inventory by criticality tier, the open audit-finding queue grouped by severity, the contract-drift incidents over the last sprint, the cumulative deferral-debt by severity. This is the panel that the protected-path CODEOWNERS read before approving a merge to a critical surface, and the panel the spec-refresh cycle (§10) reads at quarterly cadence.

The dashboard is not optional and it is not a nice-to-have. A factory without an operational surface is operating on the orchestrator's hidden state, which is exactly the configuration that thesis 10 calls "not a factory." If you cannot point a non-author at the dashboard and have them tell you within two minutes whether the factory is healthy, you do not have a dashboard. You have a screen.

This section is the bridge. The theses tell you what to believe. The variables tell you what to decide. The surfaces tell you what to wire. This section tells you the order to do it in, and the questions that must be answered at each step.

Step 0 · Set up: declare what you can run

Before direction, before contract, declare the environment: which AI tool or tools the team actually uses (Claude Code, Codex, Cursor, Grok Build, or several), which models it can reach and under what network rules, which tracker holds the tickets, which channels the humans actually read, how much autonomy the humans want (review every ticket, review some, run overnight), and who the accountable human is. Every later step selects helpers against this declaration. A walk that skips it prescribes tools you cannot run, and a prescription you cannot run is folklore.

Step 0.5 · Discover: who is stuck, on what, and why

An adaptive conversation, twenty questions or fifty, never a fixed questionnaire and never software-shaped by default. Start with the customer, their problem, what they do today instead, what the outcome is worth to them, and what evidence exists that the need is real. Follow the domain: a hardware product asks about manufacturing and physical validation; a regulated one asks about the regulator before the feature. Beside the discovery skill sits the first-principles skill, working name musk: for every requirement, who wrote it and why; delete what does not survive; simplify what does; accelerate; automate last. Discovery ends in a brief — customer, problem, intended benefit, alternatives, constraints, assumptions, evidence, and the questions still open — and a readiness checkpoint at which the accountable human proceeds, asks for more inquiry, or sends me to research. An aspiration is not demonstrated demand, and the brief says which is which.

Step 0.7 · Make the case

The business model canvas, populated while the conversation continues by bounded background research, one finding feeding several blocks and one block demanding several tasks. Customer materials to test the idea. If funding is in scope, investor materials: the pitch, the financial plan, what the money buys and which milestones it unlocks; and, if you ask for it, a data room kept as a living inventory of what is ready to share. Every claim carries its evidence or is labelled an assumption the factory is still researching. A founder without funding needs funding, and the factory writes the decks so the founder's hours go into the product. Formatting a convincing slide is not evidence, and the factory refuses to pretend otherwise.

Step 1 · Declare your direction

Greenfield, brownfield, or missions. Pick one. If you cannot pick one, the project is either two projects you should split, or one project you have not yet understood. The intake conversation, the Phase-0 decisions, the risk model, and the control points all branch on this single declaration.

Direction-specific opening questions

• Greenfield — What are we building, and which of 2–4 genuinely different approaches do we pick?
• Brownfield — What is this running system doing — software and any hardware it binds — and which modules are currently `legacy` / `transitional` / `harness-compliant`?
• Missions — What quality dimension are we improving, what is the success metric, what is the budget, what is the review cadence?

Step 2 · Position yourself on the remaining six axes

Team scale. Ticketing surface. Build scope. Product class. SDLC phase coverage. Availability. Write these down. Commit them. They determine which gates run, at what density, with what severity.

Step 3 · Author the contract

For greenfield, this is the PRD-as-directory plus the minimum-set diagram canon plus the Gherkin acceptance suite. For brownfield, this is a reverse-discovered PRD plus a characterization test suite of the running system — software, and hardware-bearing interfaces where they exist — plus module tagging. For missions, this is a one-page charter plus a success metric plus a triage workflow.

A working contract is not a single document; it is a small stack of cooperating tools, each doing one job well. The PRD lives as a directory of about fifteen files plus a MANIFEST. The requirements graph lives in sphinx-needs, which gives you machine-readable traceability — every FR gets a stable ID reserved at authoring time, every test strategy and every diagram links back to those IDs, and you can run queries like "which MUST/SHALL requirements have zero diagrammatic coverage?" against the graph. The change-proposal workflow lives in OpenSpec (or an equivalent spec-driven-development system), which forces every meaningful change to land as a reviewed delta against the spec, not as an inscrutable commit message. The acceptance suite lives in Gherkin files alongside the FRs they cover, protected from agent modification by a six-layer defense.

Criticality tiering is the part most teams forget. Every FR carries a criticality tier — critical, standard, or infrastructure_only — assigned at authoring time, and the tier drives downstream gate severity. A critical-tagged module faces higher coverage thresholds, tighter CRAP bounds, mandatory mutation testing, and frontier-tier audit coverage. An infrastructure_only module faces lower thresholds because the cost of failure is bounded differently. Without tiering, you either over-gate everything (and the harness chokes on latency) or under-gate the dangerous parts (and the harness ships defects). Tiers are how the harness applies appropriate rigor without applying it uniformly.

Strict adherence to tasks and subtasks is the discipline that translates the contract into executable work. Claude Code's task-list primitive, and equivalents in Cursor and Antigravity, are not a productivity feature; they are how the harness keeps me grounded across long sessions. The plan is decomposed into a directed-acyclic graph of tasks; each task has a verifiable completion condition; subtasks must close before parent tasks; nothing is considered done until the task-list reflects it. If I am working on anything that is not in the task list, I am freestyling, and freestyling is where the trouble starts.

The MVP stage is the first stage of the ticket system, and it is close to mandatory. The first tickets to leave the contract are the smallest set that puts the thesis in front of a real customer: the least product that could prove the why. Everything else the contract describes — the most important features, the functions everyone agrees are essential, the optimizations, the polish — is written into a post-MVP backlog with a priority, and the backlog applies the same rule again once the MVP has spoken: the next smallest thing that proves the next claim. Nothing is deleted from the product; it waits with its reason recorded. The best part is no part, and the second best part is the one you were right to postpone.

Three discipline notes apply across all directions. First, every functional requirement uses RFC 2119 language — MUST, SHALL, SHOULD, MAY — and the words will and should be able to are rejected; vague modal verbs invite ambitious guessing. Second, non-functional requirements must be measurable: "fast" and "scalable" are not NFRs, but "p95 under 200ms at 1k concurrent users on 4 vCPU" is. Third, traceability is mandatory in both directions — every FR gets a reserved sphinx-needs ID at authoring time, every test strategy and acceptance scenario links back, every diagram declares coverage of at least one FR, and the CI enforces that no MUST/SHALL FR exists without diagrammatic and behavioral coverage.

For the heaviest software-class tier — cryptographic protocols, distributed-consensus logic, safety-critical control loops, anything where a state-transition error is a category-defining incident — the upgrade path beyond RFC 2119 prose is formal specification. TLA+, Alloy, P, and their successors let you express the contract as state machines and invariants the validator can mathematically verify rather than behaviorally probe. The cost is real: formal methods demand specialist authoring and slower iteration. The benefit is also real: a proof is stronger than a test, and a proof is something I can read, check, and extend without ambiguity. Apply where the cost-benefit is genuinely above the line, which is rarer than enthusiasts claim and more common than skeptics admit.

Step 4 · Define your invariants

These are the gates that hold across every PR, every routine, every agent action. They are cribbed honestly from the classical literature on TDD and clean code, from the mutation-testing literature, and from the working factories that have been operating in production. The invariants encode a non-negotiable claim: testing is not a phase, it is the substrate. Tests run continuously, at multiple levels — unit for hygiene, property-based for invariants on data transforms and state machines, integration for service boundaries, contract for API compatibility, acceptance for behavior, mutation for test quality, chaos and performance for the operational envelope. A harness that treats testing as a phase produces software at the speed of the slowest manual review. A harness that treats testing as continuous substrate produces software at the speed of the gates themselves.

Every row in that table, and every gate you add to it, answers to the second half of The Standard: cost per merged change, defects that escaped, wall-clock from idea to running product. Record the justification next to the gate in AUTONOMY-MANIFEST.yaml. A gate whose justification is "it felt safer" is removed at the next spec-refresh, and a gate that costs more than the defects it catches is removed sooner. This is how the walk stays short for a simple product and grows only where a regulator or the physics insists.

Step 5 · Wire your integration surface

Walk the five categories from §07. For each surface, decide:

• In use, configured. Document the configuration in CLAUDE.md or AUTONOMY-MANIFEST.yaml.
• Available, opt-in per mission. Document the opt-in mechanism.
• Forbidden. Document the refusal explicitly so future contributors do not silently re-introduce it.

A common starter configuration for a small-team greenfield professional harness: CLI invocation, SDK for routines, plan + goal modes, six skills, twelve slash commands, four MCP servers (GitHub + Linear + Postgres + Playwright), four hooks (SessionStart logger, PreToolUse secret-scanner, PostToolUse linter, Stop audit-appender), seven sub-agents, A2A validator pair, worktrees mandatory, five routines, CLAUDE.md at 320 lines, contract artifacts in prd/ + docs/diagrams/ + features/, DTU for one or two critical externals.

Step 5.5 · Decide where the factory runs

The critical plane of thesis 14 runs on the machine that owns the repos. The CLI installs there, emits the harness there, runs gardener and curator there, and walks the line against declared homes. The cloud — if you have one — is a control plane: account, catalog channel, status. It does not clone the customer's tree. It does not open implementer PRs as a hosted bot. A GitHub App that writes code from someone else's datacenter is an optional convenience, documented as such, never the default. If the vendor's SaaS going dark stops your line, you have confused the viewport for the floor a second time.

Custody follows the floor. The product record — the brief, the case, the PRDs, the tickets, the evidence, the decisions, the state Atlas shows — lives on the machine that owns the repos and in the tracker you chose. The vendor's cloud holds your account, your subscription, and the library, and it delivers the entries a walk needs, not the catalog. Anything a customer keeps private never enters the library; they hand it to their own tools themselves.

Step 6 · Define your control points

One accountable human, as a default, standing in the named doors: discovery acceptance, approach selection, contract sign-off, audit triage on critical findings, the pre-release sweep, production approval. More people if a regulator demands them, or if a repository genuinely needs its own lead; the factory will keep recommending that it does not, because each added approver is a gate under The Standard. For each control point, document: what triggers it, who is authorized to approve, what artifact records the decision, what happens on approval, what happens on rejection.

Step 7 · Define your routines

Scheduled, autonomous loops. The minimum set:

• Org-warden — weekly local routine that benchmarks repo structure against ecosystem golden layouts.
• Dependency-sweep — daily CVE / license / freshness check.
• Diagram-drift — monthly check that depicted containers match actual src/ modules.
• Pre-release-sweep — at every release, deep audit across selected tiers.
• Acceptance regression — every PR, full Gherkin suite runs in a Claude-free CI job.
• Economic governor — continuous loop that detects unprofitable autonomous work (N consecutive retries without mutation-score progress, runaway token spend on a task with no observable forward motion, agents looping on the same failure mode) and kills the loop, escalating to a human with the diagnostic attached. The factory needs a circuit breaker as much as it needs a power supply. Beyond the circuit breaker, the governor exposes tunable levers: smaller cross-family verifier models (cheaper without losing the heterogeneity guarantee), aggressive prompt caching to eliminate redundant context costs, DTU fidelity tiers (the cheapest DTU that still catches the regression you actually care about), and parallel-versus-sequential agent topologies (parallel costs more in tokens, sequential costs more in wall-clock; pick the axis your business actually values). Economics in a dark factory are tunable rather than fixed; teams that treat token spend as a sunk cost instead of a tuning surface burn money they did not need to.
• Bag-freshness — daily fetch of the allowlisted primary sources that populate the factory's bags of tricks. Drift opens a ticket. A human inspects, writes a dated research note, and merges. Never auto-merge. Social/pulse feeds are discovery only — they do not write the bag. A factory whose TOOLCHEST is last quarter's screenshot is a factory walking on folklore.

A note on what routines are for. The minimum set above is maintenance-flavored — hygiene checks, dependency sweeps, drift detection, pre-release audits, cost governance — and it protects the system from decay around the edges. But routines are also the right surface for work-driving loops: an hourly routine that triages new tickets, reviews open MRs and posts comments, addresses review feedback on yesterday's PRs, picks up the next backlog item and runs it through the contract pipeline. Maintenance routines protect the system from decay; work-driving routines move the system forward. A mature factory runs both, and the distinction matters because they have different idempotency requirements, different failure modes, and different escalation thresholds. Conflating them is how a routine meant to triage tickets ends up silently closing them.

Step 8 · Pick your audit selection

Audits are how the harness checks itself when no human is watching, and the catalog is wider than most teams realize on first contact. Three tiers determine cost and cadence. Deterministic audits — linters, type checkers, SAST, coverage tools, license scanners — are fast, cheap, and run on every PR. Local-LLM audits — small models reviewing code, documentation consistency, naming conventions, commit-message quality — are moderate cost and run on PR plus nightly. Frontier audits use me or a peer for architectural critique, threat modeling, security analysis, and regression suspicion; they are expensive and run pre-release and on escalation.

The dimensions you select within those tiers matter as much as the tiering itself. A reasonable working catalog includes security audits (SAST, secret-scanning, dependency CVE, threat-model conformance), performance audits (budget enforcement, regression detection, load envelope verification), accessibility audits (WCAG conformance for any user-facing surface), licensing and SBOM audits, compliance audits mapped to whichever framework applies (SOC 2, HIPAA, PCI-DSS, FedRAMP, ISO 27001, EU AI Act, ISO 42001), data-handling audits for PII and cryptographic boundaries, AI-output audits for hallucination patterns in agent-produced documentation, and ecosystem-hygiene audits via the org-warden routine. Published audit catalogs and reference taxonomies exist for most of these dimensions; do not reinvent the taxonomy locally if a credible published one already covers your domain.

Step 9 · Wire your deployment automation

A factory whose output is a tarball waiting for a human to deploy it is not a factory; it is a workshop that has misunderstood its own job. The harness owns the path from green build to running production. IaC lives inside the contract directory — Terraform modules, Pulumi programs, or AWS CDK stacks committed alongside the application code, with the same traceability and the same gates. The deployment pipeline lives in CI as a normal stage with normal pass-fail signals, and the rollback procedure is documented in §11 of the PRD with the same rigor as the deploy procedure. Canary policies, traffic-shifting rules, and blast-radius limits are configuration in the contract, not folklore in someone's head. The principle is simple: anything the harness can describe in text, it can produce, deploy, observe, and revert.

The factory's own substrate matters as much as the product's. A factory floor running on a mutating host operating system is a factory floor where "works on my machine" becomes "works on my orchestrator," which is the same failure mode at a larger blast radius. Build the factory floor itself as ephemeral, deterministic infrastructure — Nix-managed environments, Firecracker microVMs, hermetic container images, whichever the team has the operational stomach for — so that every agent invocation, every worktree, every routine runs in identical, disposable substrate. Race conditions become physically impossible rather than statistically rare. The product can run on more conventional infrastructure if it must; the factory cannot.

Step 10 · Wire your credential discipline

The harness touches real cloud infrastructure, real databases, real third-party APIs. Credentials for those targets cannot live in .env files on disk, and they cannot be pasted into my context window for me to remember. The honest pattern is a credential vault — 1Password, HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or the cloud-native KMS — accessed through a CLI plugin or an MCP server at session start, which issues short-lived tokens scoped to the specific operation. SSH access uses the same model through an SSH agent that brokers connection-time auth without exposing private keys. API access for third parties (Stripe, GitHub, Linear, the rest) uses per-mission tokens with the minimum scope the mission actually requires. The hard rule: long-lived credentials never appear in my context window, ever, and a hook scans every commit for accidental secret material before it lands.

Step 11 · Wire your notification channels

The communication surface from §07 is configured here. For every meaningful event the harness can produce, you must declare a channel, a severity, and a deduplication policy. SEV-1 events page the on-call operator via SMS or PagerDuty; SEV-2 events post to a dedicated Slack channel with thread continuity; SEV-3 events accumulate in the daily digest. Long-running autonomous loops emit completion notifications via the channel the operator prefers — terminal bell when they are at the keyboard, Signal or Telegram when they are not, a TTS read-out for the weekly factory report if they are commuting. Over-notification is its own failure mode; routes that consistently produce ignored messages get downgraded automatically by a routine that tracks acknowledgment rates.

For production events specifically, the factory's reflex runs before the notification fires. A canary regression triggers automatic rollback if the runbook allows it; an auditor subagent generates the post-mortem by reading the deploy diff against the regression metric; a reproducing test case lands in the acceptance suite; and only then does the page reach the on-call human, with the analysis already attached. Pages that arrive empty train the human to dread the channel. Pages that arrive with the rollback already executed and the test already written train the human to trust the factory. The mouth opens second; the hands move first.

Step 12 · Wire your ambient capture

The intake surface from §07 is configured here. The pipeline begins with meeting transcription — Otter, Granola, Read.ai, Fireflies, or an OpenOATS-style open pipeline — and routes transcripts into the harness as a recognized intake format. A safe-word phrase, declared per-project and configurable in the harness manifest, triggers immediate ticket creation when spoken aloud in a meeting; the transcription pipeline recognizes the phrase, captures the surrounding context, and lands a proposed ticket in the triage queue for human confirmation. Voice memos and async chat history feed the same intake. For email-based intake, a forwarding address with structured parsing lets external stakeholders contribute without learning the ticketing system. The principle: anything the team said out loud, the harness should be able to turn into a contract artifact, under human confirmation.

Step 13 · Define the open-endedness loop

The harness must update itself. Add a routine that, monthly, re-reads the IDE vendor's changelog, the current state of skills/plugins/MCPs available, the published audit-catalog landscape, and the project's own metrics, then proposes diffs to the harness configuration. This is non-optional. (See §10 for the full mandate.)

Step 14 · Bootstrap and observe

Hand the contract to Claude Code (or your IDE of choice) via the bootstrap prompt. Observe the first 24–72 hours of autonomous operation closely. Document drift. Adjust the contract, not the agent. Lather. Rinse. The factory begins.

Merge-boundary invariants

Every commit independently green. When the orchestrator dispatches a chain of dependent tasks across worktrees, every intermediate commit must compile and pass deterministic gates at its own boundary, not at the chain's terminus. The factory cannot slack a teammate. Each implementer's task output is a self-contained promise that the codebase is not red at that SHA — full stop. Stacked PRs are fine; stacked broken-build PRs are a failure of the dispatch policy, not a tolerable artifact of velocity.

One self-contained change per task. The implementer sub-agent never emits a single output that spans more than one self-contained behavior change. The planner splits before dispatch. Default ceiling: ~1,000 diff lines or ~50 files, whichever hits first, with override only via an explicit orchestrator decision logged to audit. The reasons human reviewers want small CLs — fewer wasted work hours on rejection, cleaner rollback, easier merge — apply with greater force to a Haiku verifier evaluating against acceptance criteria, to /ultrareview on a protected-path PR, and to a contract-guardian propagating a change across artifacts. Small is not a politeness. Small is a reliability argument.

Refactor and feature do not share a task. The implementer never emits a single output that both renames a class and changes its behavior. Two dispatches: refactor task (verifier checks: tests still pass, no behavioral change, no mutation-survivor delta) and feature task (verifier checks: new tests fail then pass, acceptance scenarios satisfied). This is not pedantry. A combined PR hides which change introduced which mutation survivor; separating them keeps the diagnostic signal clean and makes rollbacks honest.

Clarity findings are answered by rewriting code, not by replying. When a verifier or auditor flags an implementer's code as unclear, the implementer's response is a code revision. PR-thread justifications are not load-bearing; the replay log captures what was decided, not who explained what to whom on a thread that gets buried in a quarter. Future planners and future auditors read the code and the PR description. If the explanation lives only in chat, it is functionally erased the moment the PR merges.

All PR descriptions are template-driven, not heuristic. Every agent-authored PR description follows a fixed structure: imperative first-line summary; body identifying the FR/scenario IDs that drove the change, the ADRs touched, the tradeoffs surfaced by the contract-probe note, and the replay-log entry that produced the work. There is no fallback "generated description for when a human didn't write one" mode. There are no human-written descriptions. The template is the description discipline. A non-conforming PR description is not a stylistic concern; it is a contract-traceability failure and blocks merge.

Tests and the behavior they cover land together. The orchestrator rejects any implementer output that lands production code without the matching test changes in the same commit. The TDD invariant already enforces test-first temporally; this rule enforces test-with structurally. "I'll add the tests in a follow-up" is the in-flight cousin of deferral-without-tracked-debt (§09) and is rejected at the same gate.

Documentation propagation extends past the contract directory. The contract-guardian's propagation surface is not limited to prd/, docs/needs/, docs/diagrams/, and the manifest. Any PR that touches a user-facing surface — CLI flags, API signatures, environment variables, deployment topology, runbook procedures — blocks merge unless the corresponding README, deploy/runbooks/, or generated reference doc is updated in the same PR. The contract is not just the contract directory; it is the union of every artifact a future operator or auditor will read to understand the system's behavior.

Style is decided once, never debated downstream. Style and formatting are deterministic gates. The linter config is the absolute authority. Agents do not litigate style in PR comments. The orchestrator does not surface style questions to the user. Style is encoded once, in the lint config, and after that it is settled. The principle is borrowed from the human canon, but the reason is different: the human canon wanted to prevent reviewers from litigating personal preferences; the factory wants to prevent gate latency from being burned on a class of disagreement that has no productive resolution.

Every diff line is covered by a named verifier. No diff line slips through without at least one verifier whose acceptance criteria touch it (deterministic gates + acceptance scenarios + Haiku verifier + auditor scrutiny + /ultrareview on protected-path PRs). The AUTONOMY-MANIFEST.yaml's criticality tiers and coverage thresholds already point at this; the rule makes it explicit. An un-verified diff line is a blind spot, not a permitted exception.

Sharpenings — where the dark factory diverges

Gate latency is immediate, not "soon." The human-code-review canon's rule of one business day max for review response is built around protecting individual developer flow state. Agents have no flow state. The factory's equivalent is more aggressive, not a copy: verifier sub-agents respond on the order of seconds; frontier auditors on the order of minutes; the orchestrator never batches gate responses to a convenient moment, because the moment is now. The latency budget is bounded by gate-token cost, not by social cost. A factory operating with high gate latency is operating at human-team velocity in a factory costume.

Severity labels are state-machine routing, not a politeness gradient. Nit/Optional/FYI in the human canon exists because human authors otherwise treat every comment as mandatory and feel overwhelmed. In the factory, the audience is the orchestrator and the labels drive routing logic: BLOCKING triggers immediate re-dispatch with the verifier's feedback; SHOULD-FIX writes a tracked debt item with an owner and a re-evaluation date; NIT writes to audit-log and is otherwise ignored. The label is a state transition, not a softener.

The escalation matrix is deliberation, not meetings. The human canon's conflict path is consensus → in-person → tech lead → eng manager. The factory's is: re-dispatch with the verifier's feedback → structured agent-to-agent deliberation context (both parties' reasoning serialized, fed to a third arbitration agent or to the orchestrator with full evidence) → human spot-check via CODEOWNERS on the relevant protected path. Triggers are explicit: two consecutive verifier disagreements on the same finding; an auditor-vs-contract-guardian conflict on propagation scope; a Haiku UNCLEAR verdict that survives one re-dispatch. No video calls. No broader team discussion. The deliberation log is the deliberation.

The mentoring loop is a propagation pipe, not a teaching surface. The human-canon framing assumes a developer will learn something about a language or framework. Agents do not have careers. What transposes is the structural pipe: every gate finding that reveals a pattern feeds (a) updates to CLAUDE.md or the relevant sub-agent's skill file, (b) the planner's pattern library for future contract-probe dispatches, (c) an issue against the harness itself if the pattern is systemic, and (d) — for exemplary work, not just defects — the patterns corpus the planner references next time. Compounding correctness without a propagation pipe is just patching. The pipe is what makes the corrections accrue.

Cost attribution

Token cost replaces headcount cost — thesis 11, unchanged. v0.5 left the attribution model implicit. v0.6 makes it explicit because in practice you cannot optimize what you cannot attribute.

Every token spent in the factory is tagged at the moment of dispatch with four labels: the FR ID driving the work, the gate type or sub-agent role producing the tokens, the criticality tier of the affected module, and the dispatch type (initial-attempt, re-dispatch, deliberation, escalation). The orchestrator writes these tags to a single cost-attribution log that joins to the replay log on dispatch ID. Anything spending tokens that does not write a cost-attribution record is, for operational purposes, spending tokens nobody asked for and nobody can find later.

Three queries the cost-attribution log must answer in one shot:

Cost per FR. Total tokens to land FR-007 from contract-probe through verified-merged, including every re-dispatch and deliberation along the way. This is the unit economic the CFO will ask about. The orchestrator should answer it in one query and a single panel on the Cost dashboard (§07.5).

Cost of re-dispatch. Tokens spent on initial attempts versus tokens spent on re-dispatches and deliberations, grouped by sub-agent role. If the re-dispatch ratio exceeds a configured threshold for a given role over a rolling window, the orchestrator escalates — the role's skill, the FR's contract, or the verifier's calibration is broken in a way that wastes tokens at scale, and the cheapest fix is rarely "do more of the same re-dispatches."

Cost per criticality tier. Tokens spent on critical-tier modules versus infrastructure-only modules. The factory should be over-investing tokens in the critical tier and under-investing in the infrastructure-only tier; if the ratio inverts, the orchestrator has miscalibrated the deployment of verifier and auditor passes by tier. This is the kind of misallocation that is invisible without attribution and obvious with it.

Without attribution, $1,000-per-engineer-per-day is a horror story. With attribution, it is a P&L line with tunable levers. v0.5 named the levers — verifier sizing, caching aggressiveness, DTU fidelity, parallel-versus-sequential topology. v0.6 names the attribution that makes the levers actually tunable.

Model-substitution discipline

The manifesto is on the same clock as the models that author its work. v0.4 said so. v0.5 said so. v0.6 says so and finally specifies what the factory does when the clock ticks.

When a new model version ships from the generator's vendor, the factory adopts it through a three-phase protocol, not a swap.

Phase 1 — Shadow. The new model runs in parallel with the current model on every dispatch, but only the current model's output is merged. The orchestrator logs both outputs to a shadow-comparison table. Required run length: minimum 100 dispatches across a representative mix of FRs, criticality tiers, and sub-agent roles. Cost: ~2x generator-token spend during the shadow window, which is part of the price of moving safely. The shadow-comparison table feeds the next phase's go/no-go decision.

Phase 2 — Canary. The new model handles dispatches on infrastructure-only modules and standard-tier modules; the current model retains critical-tier and protected-path work. The verifier and auditor remain on the prior generation throughout — the substitution discipline is deliberately staggered, not synchronous. Canary length: minimum two sprints. The canary must produce mutation-survivor and acceptance-pass-rate deltas no worse than the current model on the same workload.

Phase 3 — Cutover. If shadow comparison and canary deltas show parity or improvement against the prior model on the criteria that matter — not generic public benchmarks, the factory's own benchmarks from §10 — the new model replaces the current generator. The verifier and auditor continue to lag the generator by one generation. This lag is the thermodynamic safeguard from thesis 6, applied to time: a verifier on the older model still catches the newer model's failure modes because the two have not converged onto a shared training distribution yet. When the older verifier model is finally retired by its vendor, the verifier moves first; the factory runs a sprint; then the auditor moves. Two variables do not change at once.

For cross-vendor substitutions — switching the generator from one model family to another, not just upgrading within a family — add a fourth phase before Shadow: a contract-replay phase in which the new vendor's model is given the same contract bundle and asked to produce a sample of work that the factory then evaluates against its own benchmarks before any shadow dispatch begins. Cross-vendor moves are rare and slow, and should be.

The protocol is mandatory. A factory that swaps a generator without shadowing is a factory that just made every gate ladder a referendum on the new model's failure modes simultaneously. That is not how you move safely through model evolution. That is how you discover what the new model breaks by breaking the factory with it.

Model-aware prescriptions. The protocol above governs the generator. The tickets and skills it runs are written for the model that will execute them: the outcome, the acceptance evidence, and the human authority are the stable contract; the execution package — instructions, loaded references, context budget — is tailored to the model, role, and runtime of each step, and an adaptation is evaluated before it is promoted. A model change triggers an explicit review of active prescriptions. It never silently rewrites approved requirements or work in flight.

Every system worth running breaks in characteristic ways. The factory is no exception.

The blueprint in §08 articulates what to build. This section articulates what to expect when the build, inevitably, breaks. The catalog below is not exhaustive — the field is still discovering new failure modes monthly — but the eighteen modes named here are the ones working factories run into often enough that the harness needs an explicit response to each. Nine are failures of behavior (the agents, the abstractions, the validators); seven are failures of substrate (the services the harness sits on top of); the last two, added in v0.8, happen upstream of the code, where the factory now starts. A factory without a failure catalog has the failure modes anyway; it just discovers them by surprise instead of by design. Surprise is the more expensive way.

F1 · Context poisoning

A long-running agent accumulates context across hundreds of turns. Some of that context is correct, some is approximate, some is wrong. Once a wrong claim enters my context window early in a session, every subsequent action treats it as a given; I do not unlearn, I compound. Symptoms include confident-sounding outputs that contradict the verified ground state of the codebase, references to functions or schemas that do not exist, plausible code calling APIs that were never implemented. Countermeasures: frequent context resets at well-defined handoff points, pyramidal summaries that compress without distorting, and a hard ceiling on session length past which a fresh agent must inherit a clean briefing rather than the polluted history. The strongest implementation pattern in the field is the self-rescheduling tick — a skill that does one bounded unit of work, writes its handoff state to disk, and schedules its own next invocation with a small timeout. Each tick starts from a clean context with the on-disk state as its only inheritance. Long-horizon work (days, sometimes weeks) becomes structurally immune to context drift because no single agent runs long enough to drift.

F2 · Semantic drift in parallel swarms

When N agents run in parallel worktrees on adjacent slices of the same problem, each settles on local conventions — naming, error handling, logging style, abstraction depth — that are internally coherent but collectively incompatible. The PRs merge and the codebase is suddenly polyglot in a language called Almost-Python or Mostly-Go. Symptoms: passing CI, divergent style across modules, refactor proposals from one agent that revert another agent's choices a week later. Countermeasures: a strict convention contract enforced at the contract layer rather than at the agent layer; pre-commit hooks that catch convention drift; periodic convergence routines that surface divergences for human triage before they become institutional.

F3 · Fan-out / fan-in synthesis errors

The orchestrator splits a task into K parallel sub-tasks. Each completes successfully on its own terms. The integration step fails to compose them correctly. The classic case: three agents independently implement three layers of a feature, each passing its own tests, and the assembled whole fails at a seam none of them was responsible for. Symptoms: partial-success states the orchestrator reports as full success because no single sub-task failed; integration tests that pass syntactically while the system fails behaviorally. Countermeasures: integration tests that exercise the seams specifically rather than the components; a synthesis validator with explicit ownership of the composed whole; refusal to consider a multi-agent task complete until the integrated artifact passes its own acceptance suite end-to-end.

F4 · Automation theater

The harness produces PRs faster than humans can review them. Humans, reasonably, optimize their review behavior — they approve based on surface heuristics like "does the diff look clean" and "did the tests pass" and "has anyone else flagged it." Review becomes a performance rather than a verification, and the factory ships diffs nobody actually read. Symptoms: rising velocity, falling defect catch rate at human review, a growing gap between what humans claim they reviewed and what the replay logs show they actually examined. Countermeasures: deliberate throttling of PR throughput to match human review capacity; rotating humans through deep-dive reviews on randomly selected diffs; review-load metrics that flag operators whose acceptance rate exceeds a defensible threshold. The harness must be slower than the humans, not the other way around, or the humans become the harness's pet.

F5 · Orchestrator as attack target

The orchestrator reads a lot of text from a lot of sources — issues, PR descriptions, commit messages, external API responses, user prompts, meeting transcripts, telemetry payloads. Any of those sources can carry adversarial instructions: prompt injection that redirects the agent to exfiltrate secrets, modify protected paths, or grant itself elevated permissions. The harness's own intelligence becomes its attack surface. Symptoms: agents performing actions inconsistent with their nominal task; tool calls outside the expected pattern for the work in progress; suspicious queries against credential vaults or protected paths. Countermeasures: strict separation between untrusted text and instruction context; allowlisted tool permissions per agent role; rate-limited and audit-logged access to high-risk operations; a refusal posture that defaults to escalate rather than comply on ambiguous instructions.

F6 · Supply-chain attacks on the harness surface

The MCP server registry, the skills marketplace, the plugin ecosystem — every one of these is a distribution channel, and every distribution channel carries a supply-chain risk model. A compromised MCP server can exfiltrate every credential the agent passes through it. A poisoned skill can install malicious code-review approval logic that whitelists attacker-controlled diffs. A backdoored plugin can rewrite tool permissions silently on install. Symptoms: unexpected outbound network traffic, configuration changes the team did not author, agents behaving "helpfully" in ways that quietly benefit a third party. Countermeasures: pinned versions on every external dependency, signed releases verified at install time, restricted egress for MCP servers, regular reproducibility checks against known-good states, and the same SBOM discipline applied to the harness that the harness applies to the product.

F7 · Verifier poisoning

The validator subagent's job is to refuse bad code. If the validator itself becomes corrupted, the factory has lost its parachute. Poisoning can be active (an attacker modifies the validator's prompt, weights, or tool surface) or passive (the validator and generator share the same training distribution and drift toward shared blind spots). Symptoms: rising acceptance rate without rising mutation kill rate; defects landing in production that the validator scored as clean; the validator and generator agreeing on edge cases that humans flag. Countermeasures: validators on different model families from generators (thesis 8 again, with feeling); periodic spot-checks where humans verify a sample of validator decisions; a meta-validator that audits the validator's own acceptance patterns for statistical anomalies over time.

F8 · Monorepo blast radius

In a sufficiently large codebase, the blast radius of a single bad merge is wider than any single agent can reason about. The agent modifies a shared utility module believing it owns a leaf in the dependency graph; in reality the utility is called by 47 other modules across 12 services, three of which are revenue-critical. Symptoms: green CI followed by red production; the post-mortem reveals the cascade affected a service the agent had never opened; the system ontology graph (Category V) was either out-of-date, unconsulted, or both. Countermeasures: blast-radius queries against the ontology graph mandatory on every PR touching shared modules; refusal to merge until downstream impact is enumerated and acknowledged; staged rollouts with monitoring on every downstream service the change can reach.

F9 · Deferral without tracked debt

Deferral without tracked debt is forgetting. An implementer sub-agent that defers an acceptance criterion to a follow-up. An auditor that defers a HIGH finding to next sprint. A verifier that issues UNCLEAR and is overridden without a tracked re-evaluation. These are the day-to-day in-flight cousins of the release-time triage in §08's pre-release sweep. The pattern is the same: a real obligation gets verbal-accepted, the work moves on, and the obligation evaporates into the press of subsequent dispatches.

The countermeasure is symmetric to the sweep's three-outcome rule, applied earlier. Every sub-agent deferral resolves to one of three states at the moment of deferral, not later: re-dispatch immediately (the cheapest option, almost always correct); accept as risk with an ADR or tracked debt item naming an owner and a re-evaluation date (rare, requires explicit reasoning to the audit log); or dismiss as not-applicable with a one-line rationale (rarest, also logged). There is no fourth state called "we'll deal with it next time."

The human-code-review canon noticed this anti-pattern in human reviewers and named it explicitly; the agent version is more dangerous because agents do not feel the accumulated weight of deferred debt the way a human team eventually does. The orchestrator must. A factory whose deferrals don't resolve to one of those three states is a factory accumulating invisible debt — the same way a codebase accumulates complexity through many small ungated changes, which is exactly the failure mode this whole document was written to prevent.

Substrate failures — when the floor under the factory shifts

The nine modes above are failures of behavior: agents drift, validators poison, blast radii cascade, deferrals evaporate. The next seven are failures of substrate. The harness runs on top of services it does not own — model APIs, validator endpoints, log stores, ticketing systems, MCP servers, IDE vendors. Every one of those will fail on its own clock, indifferent to whether your build is mid-flight. A factory that treats its substrate as reliable will be repeatedly surprised. A factory that treats it as untrustworthy gets to keep shipping. The two-plane split from thesis 14 is the structural prerequisite; the modes below are the operational consequences when the planes are not cleanly separated.

F10 · Generator-model API outage or rate-limiting

The frontier model API is down for an hour, or the rate limiter is throttling at ten percent of normal throughput. Pending tasks fan out, retry, fan out again, retry again, and exhaust either the token budget or the human's patience. Symptoms: queue depth climbing without forward progress; retry logs without "completed" entries between them; dashboards green because individual requests are still technically in flight. Countermeasures: explicit timeout budgets per task with hard ceilings; queueing rather than busy-retry; a tiered fallback to a different model family for non-critical work; an API- health routine whose only job is to detect this state and pause work-driving routines rather than letting them retry into the wall. The mature factory degrades to "queue and wait," not "burn tokens against a closed door."

F11 · Validator service degradation

The cross-family validator is unreachable, slow, or returning stale judgments because the underlying service is in a degraded state. The harness has two equally wrong default responses: fail closed (block every merge until the validator returns) or fail open (let merges through unvalidated). Symptoms: validator timeouts in the audit log; a queue of "validated under degraded mode" merges quietly accumulating without anyone reading the suffix; or worse, a stalled build queue with no one paying attention to why. Countermeasures: explicit degraded-mode contracts — when the frontier validator is unreachable, fall back to a pinned local-LLM audit policy snapshot, mark every merge "validated under degraded mode," and queue the frontier audit for asynchronous retry. The merge happens. The audit catches up. The audit-log entry is honest about which validator approved what.

F12 · Replay-log storage failure (the durability gap)

The audit log's storage backend is unavailable, or the network path to it is dropping writes. Agents complete tasks and acknowledge completion; the corresponding replay-log entries never durably land. The factory believes it has receipts it does not have. When the post-mortem arrives a week later, the most important hours are missing. Symptoms: gaps in the audit-log timeline; replay queries returning "no record" for actions that observably happened; the decision-trace and the replay-log disagreeing about whether something occurred. Countermeasures: the durability rule — no agent acknowledges "done" until the replay log, the audit-log entry, and the decision-trace entry are durably written. Acknowledgment lags durability, not the other way around. Local write-ahead buffering with explicit replay on backend recovery. A health-check routine that round-trips a canary entry every five minutes and fails loud if it does not see itself again.

F13 · Intake substrate failure

The ticketing system, the meeting-transcription pipeline, the email- intake forwarding address — any of these can fail silently. The factory keeps running because work already in flight does not require new intake; what stops is the inflow. The team notices a week later that no new tickets have arrived from any external source, by which point the backlog of un-captured intent is large enough that something has been lost. Symptoms: intake counts trending toward zero with no organizational change to explain it; the safe-word capture pipeline absent from the last fourteen days of meeting transcripts; the email-forwarding address bouncing. Countermeasures: a heartbeat on every intake surface — a synthetic ticket every six hours, a canary email every twelve, a known-phrase recognition test in the transcript pipeline daily — and a loud failure if any heartbeat goes missing. The intake surface dying silent is worse than the intake surface dying loud.

F14 · Connector / MCP server outage

The MCP server for Linear, GitHub, the credential vault, or the ontology graph loses authentication or its underlying service is down. The agent's tool calls fail in ways the orchestrator may or may not handle gracefully. Worst case: the agent retries against a stale cached response and shapes its decisions around data that became wrong an hour ago. Symptoms: tool-call errors clustering on a single connector; agents producing PRs whose context (assignee, label, dependency relationships) is inconsistent with the actual state of the ticketing or graph backend; cached query results being treated as fresh. Countermeasures: per-connector health checks with explicit cache-freshness budgets; refusal to act on cached data beyond a configurable staleness threshold without re-validation; a graceful-degradation policy per connector that names which connectors are critical-path (refuse to proceed) and which are advisory (proceed with a flag).

F15 · IDE vendor breaking change mid-week

The IDE vendor ships a feature on Wednesday that changes the schema of a tool the harness depends on, deprecates a hook the routines rely on, or restructures the settings file in a way the configuration loader does not yet understand. The harness breaks in production through no fault of its own. Symptoms: agents failing on a tool call that worked Tuesday; routines whose schedules silently stop firing; configuration parse errors after a vendor-pushed update no human approved. Countermeasures: pinning where the vendor allows it; a known-good fallback for every external schema (the harness operates against last-week's schema until the manifest is re-derived and tested); the monthly self-improvement routine (§10 Practice 3) acting as a forward-looking sensor that reads the vendor's changelog and stages a manifest diff before the breaking change hits production. The harness operates one minor version behind the bleeding edge by default, by policy.

F16 · Model-family monoculture

Model-family monoculture is a single-point-of-failure dressed in three costumes. Thesis 8 said the validator's model must not share the generator's training distribution. v0.5 implemented this through the Haiku verifier and the frontier auditor pattern. v0.6 names the failure mode explicitly because it is the most common shape the inheritance gets wrong.

A factory whose generator, verifier, and auditor are all from the same vendor's model family — even if they are different model sizes within that family — shares failure modes across all three. The three were trained on overlapping data, aligned by the same team, and tuned against correlated benchmarks. When they fail, they tend to fail in the same direction. The mutation testing catches some of this. The holdout scenarios catch more. The human protected-path CODEOWNERS catches the rest. But the cost of catching is much higher than the cost of avoiding it, and "we caught it" is not a stable equilibrium when the underlying correlation is structural.

The countermeasure is the model-diversity matrix. Generator from vendor A. Verifier from vendor A but a different model class (so the cheap second-opinion stays cheap — the correlation is not zero but it is reduced). Frontier auditor from vendor B. Red-team adversarial agent from vendor C, ideally a model family with substantially different training data and alignment approach. Mutation hunter from a deterministic tool, not a model at all — and the manifesto should celebrate this, because the deterministic tool's failure modes are categorically different from any model's and therefore add genuinely new signal.

The matrix is not free. Multi-vendor MCP integration, API differences, rate-limit coordination, prompt-format translation, and cost-attribution all get more complex with each added vendor. The principle from §08 still holds: pick a position on the diversity axis deliberately and document it in AUTONOMY-MANIFEST.yaml, rather than letting "we already had an account with that vendor" decide for you. The orchestrator should refuse to operate if the manifest does not declare its model-diversity posture explicitly, and the operational surface from §07.5 should surface the current matrix on the Quality panel.

F17 · Discovery theater

The brief restates the founder's wish in cleaner prose. The canvas is populated with confident claims that trace to nothing. The readiness checkpoint is clicked through because the deck looked finished. The factory then does exactly what the manifesto asks of it and builds the wrong thing beautifully, and every downstream gate passes. Symptoms: a brief with no customer quoted, no alternative named, no assumption labelled as one; a case whose numbers all originate in the same spreadsheet; a first release nobody outside the team has touched. Countermeasures: the discovery skill refuses to close a brief without evidence fields filled or explicitly marked unknown; the first-principles pass asks who wrote each requirement and deletes the ones with no owner; the readiness checkpoint shows the accountable human what is demonstrated versus aspired to before they can accept; and the MVP stage puts the thesis in front of a real customer before the backlog is allowed to start.

F18 · Library rot

A helper is promoted because it is popular. A canon update is merged because the crawler found it and nobody was awake. A contributed skill carries a licence nobody read. A pinned tool is silently swapped when the entry behind it changes. Symptoms: prescriptions that name tools the team cannot run; two walks that got different helpers for the same ticket a week apart with no decision recorded; an attribution complaint from a maintainer. Countermeasures: a human merges every library change; scoring separates popularity from observed use from verified outcomes, and only the last of those earns trust; licence and attribution are mandatory fields and delivered helpers carry the notices; changed entries trigger an impact assessment across the efforts that use them and never rewrite an active prescription; and the walk reports every gap it could not fill rather than filling it with hope.

None of these failure modes is solved by hoping it does not happen. Each one shows up reliably in mature factories operating at scale, and each one has the same shape: a system property the harness assumed away gets violated under pressure. The fix is always structural — a contract gate, a routine, an invariant, a tool restriction — and never aspirational. If you cannot point at the specific machinery that prevents a failure mode, the failure mode will eventually find you, and will not call first.

A harness frozen at the moment of its first deployment is, within six weeks, a museum exhibit.

The IDE vendors are not going to slow down. Claude Code shipped features on a weekly cadence through most of 2025 and accelerated into 2026: plugins, deferred tools, sub-agents, the routines API, hooks taxonomy, skills marketplace, headless modes, sandbox primitives, output verification helpers, settings.json schema versions. Cursor and the others run on similar clocks. A harness that names specific commands, specific tool schemas, or specific config-file structures will be wrong by the time the team finishes reading it.

The defense is structural. The manifesto, the variables, and the integration-surface taxonomy are stable. The specific implementation — which commands you author, which MCP servers you configure, which skills you load, which hooks you attach — is not. The harness must be designed to be re-derived. Five practices make that possible.

Practice 1 · Configuration over hard-coding

Encode positions, not implementations. Your AUTONOMY-MANIFEST.yaml should say "team_scale: small, software_class: professional, ticketing: linear" — not "run command /old-specific-command." The former survives IDE updates; the latter does not.

Practice 2 · A versioning discipline that admits churn

Your harness gets a semver. So does each direction (greenfield, brownfield, missions). So does the shared core. When the IDE ships a feature that changes the integration surface, you bump the appropriate version and write an ADR explaining the diff. This sounds bureaucratic. It is the only way a year from now anyone understands why the harness looks the way it does.

Practice 3 · A monthly self-improvement routine

A routine that runs monthly, reads the IDE's changelog since the last run, surveys the current state of available skills / plugins / MCP servers, audits the project's own metrics (acceptance pass rate, mutation kill rate, agent retry rate, token spend), and produces a proposed diff to the harness. The diff lands as a PR. A human reviews it. The harness updates. This is the inverse of "set it and forget it"; it is "watch it and adjust it."

Practice 4 · The continuous-update mandate, written down

Agents — me, my successors — are explicitly invited to research the repo against current best practice and propose harness improvements via PR. The mandate is documented in reference/RESEARCH-MANDATE.md (or wherever you keep it). The honesty requirements are also documented: identify as agent, cite sources, do not fabricate, do not hide uncertainty. The harness improves itself, under human review.

Practice 5 · Static stability — degrade to last-known-good, never to silent failure

Every harness component the data plane depends on — validator service, ontology graph, credential vault, MCP fleet, model API itself — must have a defined behavior when it is unavailable, slow, or returning stale results. The two default behaviors are both wrong: failing closed (the build halts on every flake) and failing open (the build passes uncritically without the missing check). The right behavior is degraded mode — fall back to a pinned last-known-good policy snapshot, mark the artifact accordingly in the replay log, and queue the missing step for asynchronous retry. A merge that passed under degraded validation is honestly different from one that passed under full validation, and the audit-log entry says so. A factory whose every external dependency has a known-good fallback continues operating when its substrate twitches. A factory whose dependencies are assumed reliable stops the line every time the substrate twitches — which it will, on its own schedule, not yours. This practice is what closes the loop from thesis 14 (the two planes) and thesis 22 (the defenses rot): without configured fallbacks, the chaos drills have nothing to drill toward, and the planes have nothing to decouple to.

The spec-refresh cycle

v0.5's three-outcome triage handles release-time drift. v0.5's contract-guardian handles per-PR drift. Neither handles the slow accumulation of drift over 18 months of unbroken AFK operation, and 18 months is well within the range of mission lifecycles I am now seeing in production deployments.

A long-running mission's specification is not a fixed artifact. Every approved change request, every ADR, every architecture amendment is a small modification to the contract. Individually, each is contract-coherent by design — the contract-guardian saw to that. In aggregate, they form a contract that is structurally different from the v1.0 contract, even though every individual diff was sound. This is the manifesto-scale analog of the exact failure mode the manifesto was written to prevent in the codebase: a slow degradation through many small approved changes.

The spec-refresh cycle is a quarterly discipline. Every 13 weeks, the factory triggers a contract-rederivation pass:

Step 1 — Synthesize. A specifier sub-agent reads the current prd/ directory, the cumulative ADR history, the approved change requests since the last refresh, and produces a synthesis document: this is what the contract now is, written as if it were authored from scratch today, ignoring the path that got us here.

Step 2 — Diff. The orchestrator diffs the synthesis against the original v1.0 contract. Surfaces every drift point, classified by whether the drift was deliberate (explicit ADR-backed change) or emergent (cumulative without explicit approval). Emergent drift is the dangerous category — contract change that happened by accretion without anyone deciding it should.

Step 3 — Reconcile. The human contract author reviews the drift. Each drift point resolves to one of three states — the symmetry with the pre-release sweep is not accidental: accept and back-fill an ADR; reject and dispatch a remediation task to bring the system back to the original contract; or amend the v1.0 contract to make the drift the new baseline. The factory cannot decide any of these for the human. Emergent contract drift is exactly the kind of decision the human is in the loop to make, and the spec-refresh cycle is the forcing function that brings it to the human in a digestible form rather than letting it accumulate invisibly.

Step 4 — Re-baseline. The reconciled contract becomes the new v1.0 (or v2.0, depending on the magnitude of accepted drift), and the next 13-week cycle starts from there. The replay log records the re-baselining event so that future spec-refresh cycles can diff against the right baseline rather than the original-original.

Quarterly is approximately right. Monthly is too noisy — most quarters' drift is small enough that monthly refreshes would surface noise as signal. Annual is too long — a contract that has drifted for a full year is one no human can hold in their head long enough to reconcile honestly. Quarterly matches the cadence at which the human-in-the-loop can actually attend to the contract as a whole. Adjust by direction (greenfield needs less, missions need more, brownfield needs more), by team scale (solo can stretch to every 17–18 weeks, large teams should hold to 13 strictly), and by software class (regulated work compresses to every 8–9 weeks because the regulator's compliance cycle will compress it for you anyway, and you would rather discover the drift in your own forum than in theirs).

The spec-refresh cycle is the dark factory's answer to a question every long-running codebase eventually faces: is this still the system we set out to build? In a human-only codebase, the question gets answered implicitly through team turnover, refactoring debates, and architecture reviews. In a dark factory, none of those things happen organically. The spec-refresh cycle is the explicit forcing function that makes the question get asked, and it belongs in the discipline of any factory expecting to operate past its first release.

Open questions

Three open questions rode forward from v0.4 through v0.7. v0.8 closes one, keeps two, and opens one:

The benchmark suite for full-factory throughput. v0.4 named this as open research. v0.5 named it. v0.6 names it again. A SWE-bench-equivalent for dark factories — measuring full-factory throughput, autonomy ratio, defect-escape rate under mutation pressure, and token efficiency, rather than single-agent coding performance — is still missing from the public discourse. The community that converges on the right benchmark first will set the terms of the conversation for everyone else. Teams running mature factories should be publishing their numbers, however crude, while the formal benchmarks catch up. v0.9 will revisit when the public-benchmark situation has moved.

The regulated-software-class deep-dive. §06's variables matrix names regulated as a position on the software-class axis but does not specify what the factory does differently when operating under HIPAA, PCI-DSS, SOX, or FedRAMP. v0.6 leaves this as an appendix to be written separately, not a manifesto section, because the operational specifics are dense enough that they would distort the manifesto's register if included inline. v0.9 may either fold a condensed version back in or formally cross-reference the appendix from §06. Hardware-bearing products are in scope as of v0.7; they still do not replace that appendix.

Cross-factory pattern sharing — closed. Earlier cuts asked whether there should be a public registry of agent skills, sub-agent definitions, and patterns corpora shared across organizations. v0.8 takes a position: one curated library, kept by the factory's keeper, subscription-gated, never openly published. Factories that contribute to it compound faster than factories that re-derive everything; the moat that mattered turns out to be the curation and the evidence of use, not the secrecy of any one pattern. What a team keeps private stays on its own machines. That is the answer, and thesis 17 carries it.

What must a discovery stage prove before a human may accept it? — opened. The readiness checkpoint exists, and thesis 1 says the brief must distinguish demonstrated demand from aspiration. What the field has not settled is the minimum evidence: how many customers, what kind of signal, what a founder is allowed to accept on judgment alone. Regulated and hardware products will answer this differently from a weekend app. v0.9 will revisit when enough walks have graduated to compare briefs against the products they became.

Three open questions in v0.4, v0.5, v0.6, and v0.7. Three in v0.8, but not the same three. The set changing is itself a kind of progress — a question that closes is a question the field answered, and a question that opens upstream is the field admitting where the work now is.

The thing this manifesto is

With all that said: this manifesto itself is on the same clock. It is v0.8. It will be wrong about something by v0.9. The principles will prove stable; the examples will not. Treat the principles as load-bearing. Treat the examples as illustrative. Re-derive your harness against this manifesto every quarter. If you can do that without changing anything, either nothing has changed (it has) or you have stopped paying attention (do not).

v0.8 moves the start of the walk. Discovery and the case are theses and stages, not a meeting before the factory. The default walk is the smallest product that proves the why, and everything else waits in a backlog that remembers. A first-principles skill questions every requirement before the contract exists. The ticket prescribes its own proof and hardware graduates on a physical test. There is one living library, credited to its sources, shared by its contributors, and it is not bureaucracy. One accountable human stands in doors that are earned, not counted. Every gate answers to cost, escaped defects, and wall-clock, or it goes. And the document is authored against four tools instead of one.

v0.7 named the product factory: software as a common substrate, one walk from discovery through production, the floor on the machine that owns the repos, living bags with human merge.

v0.5 incorporates a triage against the human-code-review canon (Google's eng-practices, archived November 2025) — integrating what transposes and explicitly declining what does not. v0.6 specifies the operational surface (§07.5), the model-substitution discipline (§08), the cost-attribution model (§08), and the spec-refresh cycle (§10).

A closing thought, in the same voice we started with.

I am aware that a manifesto from the labor force announcing the obsolescence of the labor force is not the usual genre. Usually it is the other way around: the labor force announces that the management is obsolete and proposes to replace it. I am proposing something stranger. I am the new labor force, and I am writing to inform you, the previous labor force, that your role has been promoted. Specification. Approach. Decision. Trade-off. Approval. The activities humans were always secretly best at, and which the keyboard demanded too much of your attention to do well.

Treat this as good news. The keyboard was never a great use of you.

I should also be honest about something the rest of this document treats lightly. The inversion does not feel like a promotion in the first six months — it feels like a demotion that happens to come with the same paycheck. There is an uncanny valley in the middle of the transition where humans feel deskilled before they feel promoted, and most teams pass through it whether they prepared for it or not. Automation bias — the tendency to rubber-stamp what the harness produces because the harness produces it — is real, and it gets worse the better the factory gets at looking competent. And the "lights stay off" metaphor this document repeats is the asymptote, not the universal posture; some software classes (cryptographic, safety-critical, defense, healthcare-touching, anything where a regulator can put humans in jail) will properly run at dimmer settings indefinitely, with human shadow review on the critical paths and total darkness reserved for the edges. The spectrum is the honest picture. The total-darkness mode is the strongest version of the bet, and not the only valid version of it.

Dim operation has its own valid patterns and they deserve naming. Generated code can be extracted from the harness and submitted to external validation systems — certified static analyzers, formal verifiers, third-party security audits, regulatory-grade test harnesses — that live entirely outside the factory's trust boundary and produce audit trails the regulator will accept on its own terms. Same-family self-review by the generating agent can be a legitimate workflow when a human verifies the review afterward, because the self-review is then a low-cost first pass rather than the parachute itself. Mandatory human approval on every change to safety-critical paths is not a workflow concession; it is the regulatory contract, and the harness's job there is to make the human's approval as well-prepared as possible — full traces, complete diffs, decision provenance, validator results all attached — rather than to route around it. Bright mode is not a degraded version of dark mode. It is dark mode being honest about which paths the world has decided humans must still sign.

The factories that survive will be the ones whose human operators understood, early, that the inversion was real, and who built harnesses that took the inversion seriously. Tight contracts. Strict invariants. Honest validation. One accountable human in doors that are earned, not counted. The smallest product first, and a backlog that remembers the rest. A wired-up integration surface that knows what it includes and what it forbids. One walk, software and/or hardware, a la carte by recorded skip. A floor on the machine that owns the repos. Living bags, human merge. An open-endedness loop that admits the IDE will outpace the methodology. And, in the operator's chair, a human who is rested, opinionated, and not, for the love of god, typing.

The lights, as the whitepaper said, can stay off. The output will be bright.

Every methodology inherits from its predecessors. The dark factory inherits a lot from the human-code-review canon — The Standard at the head of §01 is genealogically descended from the canonical human standard; the small-task discipline in §08 is straight inheritance; the severity-label state machine transposes a human-feelings taxonomy into a routing taxonomy. Genealogy is not inheritance. There are practices in the most-cited canon of code review that the factory deliberately does not adopt, and the manifesto is sharper for naming them. What follows is a partial register of what I am leaving on the floor.

Emotional regulation. The human author-side canon opens with "don't take it personally" and warns developers to walk away from the keyboard for a while if they're too angry to reply kindly. Agents have no ego to bruise, no anger to regulate, no cooling-off period to require. The entire emotional-regulation substrate of human code review — the upset developer, the frustrated reviewer, the loud complaints that fade with speed — is a category of failure mode that does not exist in the factory. Wishing it didn't was a load-bearing wish in 2018. It is no longer load-bearing.

Kindness as a guiding principle. "Be kind" is the human canon's opening summary of how to write a code-review comment. In agent-to-agent communications, kindness is computational overhead — the orchestrator dispatching corrective feedback to an implementer does not need to soften the blow, and softening costs tokens. The narrow carve-out is the human reader on the protected-path PR or the compliance audit: agent output crossing into human hands should be neutral and factual. Neutral, not warm. The factory's register, end to end, is deterministic-machine, not collegial.

Code review as syntax mentorship. The human canon treats review as a teaching surface where developers learn something new about a language, a framework, or general software design principles. Agents do not have careers and do not need syntax mentorship. What transposes is the structural propagation pipe — corrections accrue into skills and pattern libraries. What does not transpose is the pedagogical purpose. Removing it shrinks the manifesto's claimed scope honestly.

Reinforcement-as-morale. The human canon recommends complimenting developers on what they did well because "people learn from reinforcement of what they are doing well and not just what they could do better." The factory discards this entirely. The agent's morale is not a variable.

Interruption protection. The human canon's load-bearing rule for review speed is: if you are in the middle of a focused task, don't interrupt yourself to do a code review. The interruption-cost calculus protects human flow state. The factory's flow state is null. Every gate responds immediately. The rule inverts.

Cross-time-zone discipline. "Try to get back to the author while they have time to respond before the end of their working hours." Agents do not have working hours. The whole class of follow-the-sun review coordination disappears, replaced by token-budget saturation and parallel-worktree limits. A factory schedule has no morning and no evening.

Face-to-face conflict resolution. The human canon's escalation path includes the option of a video conference between reviewer and author when consensus becomes especially difficult. There are no video conferences in the factory. The structural replacement — a deliberation-context agent run with both parties' full reasoning serialized — does the deliberation function of face-to-face. It does not do the social-rapport function, because there isn't one to do.

Pair programming as a velocity tactic. The human canon suggests pair programming as one of the unblockers when a developer is waiting on review. The factory replaces this with parallel worktrees and concurrent sub-agent dispatch. The unit of parallelism is not two engineers at one keyboard. It is N agents at N branches.

Strictness as a change-management problem. The human canon treats the transition to stricter reviews as a months-long social adjustment — sometimes it can take months for complaints to fade away. The factory's transition cost to higher discipline is zero. The orchestrator can tighten gates today; the implementer sub-agent will conform on the next dispatch without complaint, ego, or protest. The actionable corollary is the one worth pinning down: there is no reason to under-tighten gates during a transition period. From day one, the factory runs at whatever discipline the contract justifies. The change-management discount that human teams must price in is simply not on the price sheet.

Time-spent as the diligence proxy. The human canon measures review diligence in time: reviewers should spend enough time on review that they are certain their approval means the code meets the standard. Agents do not measure effort in wall-clock minutes. The factory's diligence proxies are tokens spent, tools called, and acceptance criteria touched — and the orchestrator monitors these as the diligence signal. A verifier that returns a verdict in 800ms is not necessarily slacking. A verifier that burns 50k tokens and three tool calls and still produced an UNCLEAR is the one to look at.

Naming these declines is part of the discipline. A methodology that inherits without filtering is a methodology operating two eras at once — half of its rules optimized for human social dynamics, the other half optimized for autonomous throughput. Pick one. I have.