Two decisions reset the road to V1 at the same time. First: every remaining feature would be validated against a checked-in demo project (a tiny, language-neutral fake build with a 5-task, 3-wave DAG, a stub runner, and files its fake tasks pretend to edit), copied to a disposable temp directory on every run so the working copy never accumulates state between test runs. Second: VeilGremlin, the first real, consequential build, moved to a final acceptance wave, dispatched only after every other V1 feature was proven green against the fake project first. Nothing real got touched until everything unreal had already worked.
The report that would have lied
An ARB review of the finished V1 diff (eight independent finder angles, a dedup pass, a verification pass) found ten confirmed issues. One of them undermined the entire premise of the demo project, and it wasn’t subtle once found: the demo’s own closing step closed every dispatched task without checking whether its verify step had actually passed. A demo run that reported “report OK: 5/5 closed” would say exactly that whether the verify path underneath it was healthy or completely broken. The green report and a genuinely broken system were indistinguishable, because the harness never actually looked at the thing it was supposedly proving.
The fix that made green mean something
The fix is one line of discipline, not a rewrite: run-demo.sh now asserts Verify: PASS for each dispatched task before allowing the demo to close it. A verify failure now stops the demo cold instead of getting silently absorbed into a closing step that didn’t check. That single assertion is the difference between “this harness ran” and “this harness would have caught a real regression”, and it’s exactly the kind of gap that only surfaces under adversarial review, because a harness’s own author is the person least likely to notice their harness can’t fail.
Why “before anything real” was the actual point
The sequencing (demo-project validation for every feature, VeilGremlin held to the final wave) meant every wave of new functionality got exercised end-to-end against something consequence-free before the first real dispatch happened. It also meant the demo doubled as onboarding: a new user, with zero Hekton machinery and zero AI access, clones the repo and runs the same script that gates every feature merge, and watches the identical loop a real user would trust. V1 itself was ultimately declared on this evidence (151 tests, a CI-run end-to-end pass, an ARB review with every finding fixed), not as a formality stamped after the fact, but as the actual gate.
What next
Proving the machinery against a fake project answers “does the tool work.” It says nothing about whether the tool’s own advertised safety features, like the rework path this arc keeps circling back to, actually do what their documentation claims, which is a different kind of finding entirely, and the next post in this arc is exactly that one.
What Next
The Rework Path That Never Existed
An 8-angle review panel discovers the tool's own printed advice, 'block this to send it back for rework', was an illegal state transition the entire time.