How We Ship
A change is not done when the code merges. It is done when a customer can use it end to end.
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.
One gate is intentionally advisory, not blocking. An LLM grader reads the pull request and scores it for hallucinated claims, missing held-back scope, and citation drift. We read the verdict as advice. A red grader verdict does not block merge by itself, because LLM graders drift faster than the codebase does and we do not want a model upgrade to silently raise our merge bar. The grader output goes into the discussion; the human conductor still owns the merge decision. That is the honest line between automation and judgment.
What you can do with this as a paying customer: ask your AI to walk the six rows against any DreamerOS capability you depend on, and the system returns a row-by-row receipt. Light tier sees the verdicts. Pro and above see the full audit trail and the signed receipt for the chat turn that produced the walk. The three categories we are defining live on the moat trends section; this entry is the discipline that keeps every claim on that page checkable.
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.