Most software teams treat merge as the finish line. Code passes review, the test suite is green, the pull request closes, ship it. DreamerOS treats merge as the middle of the pipeline, not the end. The finish line is the six-row P37 walk: code path connects, deploy is live, customer can reach the capability through the intended entrypoint at the intended tier, the capability delivers what the directive or marketing promised, no surface on the site or in the app oversells it, and failure modes are observable to either the customer or to operations. If any one of those six rows is false, the change is PARTIAL or OPEN, never DONE. The literal HC quote that ratified the rule is on file: "Done is done. Not any fucking excuse."
The verification gates we run on every change are designed to catch the failure modes that produce drift. The PHP syntax sweep proves every page actually parses, so a typo cannot ship a 500 to a customer. The em dash audit on every pull request title and body keeps the public canon written in spaced hyphens, not in dashes that read like edits a human did not finish. The Crown Jewels scanner keeps operational internals (token paths, vendor playbooks, attack surfaces) out of the public canon files; if a contributor puts an internal mechanism into a public doc, the scanner catches it before merge. The deploy guard refuses any change to the FTP deploy that would climb out of the chroot or write to a nested directory, because past incidents proved that misconfiguration takes the site down. The metadata cleanliness check refuses pull requests whose body cites file lines that no longer exist in the diff. None of those gates protect the team from each other; they protect the customer from a drift between what we said we did and what actually happened.
The merge gate on the pull request narrative itself is deterministic and hard-blocking. Five classes of automated audit run on every pull request - hallucinated facts, claims about files not actually read, conflated counts, speculation framed as fact, and internal field leaks in customer-facing strings. Each class is a pattern-based check written as code, each class is a hard gate, and a failure in any class blocks the merge. There is no human override lane in the workflow: the fix is to make the claim true, not to talk past the check. We chose deterministic checks over an LLM grader on purpose - graders drift faster than codebases, and a model upgrade should never silently move the merge bar.
Where you can see this as a customer: the how-it-ships page inside the app walks the same seven-stage pipeline and the six-row done gate in plain language, exactly as they bind us internally. It is a static explainer, not an interactive auditor - it does not run the walk for you, it shows you the standard every ship is held to. This entry is the discipline that keeps every claim on that page checkable.
Why this matters
A team that ships on merge confidence drifts away from what its marketing promised, one quiet exception at a time. A team that ships on a six-row walk keeps the promise and the product on the same line. Mis-selling is a hard escalation to the human conductor, not a copy edit, and the gates above are how we catch ourselves before the customer does.
Open standalone page ->
