Five factories in one workspace

The chapters describe the concepts. This page describes five working pipelines that were built against them, in one workspace, over about three months — what they share, where they diverge, and which of the book’s claims they actually test.

What kind of evidence this is Everything below is workspace evidence: it comes from repositories on the author's own machine, cited by path and read date. It is real — commits, retro reports, gate ledgers — and it is not independently verifiable by you, which is why it carries its own tier rather than being dressed up as a case study you could check. Treat it as a worked example, not as proof.

The five

Each is a Claude Code plugin: a set of skills for the stages, agents for the judges, and a template that ships build-green.

Five pipelines, one pattern
Factory	Product	What decides “done”	Human gates	Status
first-factoryworkspace	Software from a product idea	A Cucumber suite. Done is machine-decidable.	3	3 stacks proven
demo-factoryworkspace	Visual demos (three.js, WebGL)	A vision judge over rendered screenshots.	1	1 real run
visual-novel-generatorworkspace	Playable branching fiction	Split: graph completeness hard-gated, prose judged.	1	2 real runs
website-factoryworkspace	Published websites	Floor + two judges + a human feel check.	3	in routine use
dark-website-factoryworkspace	The same, deliberately darkened	The same, with the middle gates held by agents.	2	3 runs · 1 human-reviewedworkspace

The status column is a calibration device, not decoration: it says how much weight each row’s lessons can carry. A pipeline that is built teaches you about design; only runs teach you about gates. Each factory’s lesson, at the length it deserves:

first-factory: a lit factory with dark inner build loops.
demo-factory: a judge-capped loop, then a human.
visual-novel-generator: dark mechanics, lit meaning.
website-factory: approve the design, automate the build.
dark-website-factory: dark after design — and evidence before darkness.

The axis that decided the split

What separates the five is what the checker can be. The design note says so directly, and rules the technology out as the deciding axisworkspace.

first-factory hangs on a deterministic green gate, because a task’s definition of done is machine-decidable — a Cucumber scenario passes or it does not. That architecture does not transfer. A website’s definition of done is mostly editorial and visual: does the reading layout breathe, is the sequence comprehensible, does the palette carry the content’s character. No test suite decides that, and forcing sites through BDD produces ceremony-Gherkin that gates nothingworkspace.

That is chapter 8’s rule discovered from the other end. The check has to be un-fakeable for the thing being checked; when it cannot be, the right move is a different kind of checker rather than a weaker version of the same one.

The gate split

Every one of the five uses the same three-way division, which is the single most portable idea in the group:

Floor, judge, feel
Gate	Decides	Held by	Rule
Floor	Does it build, link, validate?	machine	Binary, cheap, and never a taste proxy
Quality	Does it read and look right?	judge agents	Independent of the maker; capped rounds
Feel	Everything the judges cannot see	human	Defined as the residue — never delegated

Two rules keep it honest, and both were learned the expensive way.

Never grow the floor into a taste gate. Screenshot-diff tests are the standing temptation: they look deterministic and they are, technically. They are also flaky, and a flaky gate poisons trust in every other gate beside it. The floor stays binaryworkspace.

Feel is the residue. It is whatever the judges could not verify. Deleting the gate leaves the residue in place, unseenworkspace.

The invariants that survived five pipelines

Maker and checker are never the same agent, and the judge is pinned at or above the maker’s capabilityworkspace.
Worker agents are stack-generic. They read a Commands table in the generated project’s own CLAUDE.md — “Full check”, “Build”, “Shots” — rather than hard-coding a build toolworkspace. Adding a stack means adding a template with that table, not new agents. This is chapter 4’s guide/sensor distinction as a file format.
Templates ship build-green from clean. A template that needs fixing before it builds teaches every generated project to tolerate a red floor.
Rounds are capped, then it goes to a human. Judges converge or they do not; grinding past the cap produces cosmetic changesworkspace.

Where the pattern was proved, in order

demo-factory proved the alternative checker first: a deterministic floor plus an independent judge over rendered output, capped rounds, then a human feel checkworkspace. visual-novel-generator proved the split case — some properties hard-gated, others judged, in one pipelineworkspace. website-factory generalised it, and added the stage its siblings lack: a design mock gated before any scaffolding, so that a rejected design costs minutes instead of a whole build loopworkspace.

That last one is chapter 3’s upstream-judgment argument, implemented. The cheapest place to reject something is before it is built.

One failure worth reading

In July 2026 a hand audit found three published sites carrying 56 dead internal links between them. All three predated a guard recipe that catches every one of them in under a secondworkspace.

Four independent reasons it survived, each of which generalises:

The layouts were always right. Only the prose was wrong — so a broken link sat directly above a working navigation card pointing at the same target. Nothing looked wrong.
The dev server structurally cannot show it. It serves at the root, where the broken form resolves. Local browsing gave positive confirmation of a broken site.
The obvious fix is also broken. Jekyll’s own post_url tag fails the build when its target is missing, which makes it look like the safe choice, and it still emits a path without the base URL.
One of the three sites had a link check the whole time, and it passed. The checker normalises the base URL away before validating, so an already-broken path validates exactly like a correct one. The check could not see the bug by construction.

Point 4 generalises furthest. A green check is not evidence that the property holds; it is evidence that this check did not fail. Knowing what a gate structurally cannot see is part of knowing what it is worth — and it is precisely the knowledge a dark pipeline has no human downstream to supply.

The systemic finding was different again, and sharper: the retro loop had been running in one direction only. Lessons flowed from sites into the factory, so a hardening protected every site built after it and none built before. The fix was to make the sweep run backwardsworkspace.

What this case study tests

It supports chapter 8's claim that the checker's nature — not the technology — decides how dark a pipeline can go, and chapter 5's claim that cheap verification is worthless until it is wired in. It cannot test anything about scale: five small pipelines producing disposable artifacts is the easiest possible case, and the sites are not the brownfield. The factory is.

Next: what happened when one of them was deliberately darkened.