Coldstart is in final cutover and has not been released. This page documents the self-CI runner in the development build at the source revision named above, not a generally available command.
A green verification run is evidence. It is not a synonym for “the system is correct.” To know what the evidence supports, you need four parts of the receipt: which checks were registered, which of them applied to this tree, which mode they ran under, and which of the three process exits the runner returned.
Coldstart makes those parts visible because hiding any one of them creates a false pass. A shorter roster can look like a faster clean run. A skipped class can look like a passing class. A crashed check can look like a check that found nothing. A warning can look like silence if only the process code is retained.
[Visual 7.1 — The left panel of the section frame, enlarged. A vertical roster labelled "27
registered check classes at the pinned revision" enters a filter labelled "does this class have a
subject on this tree?". Its side branch lists skipped classes by name; its main branch enters the
runner labelled "applicable roster". A small --only selector may narrow that branch but cannot add
an unknown class. The runner ends in three equal boxes: "0 — applicable checks passed", "1 — one or
more represented findings", and "2 — root, roster, selection, runner or check broke". Beneath exit
0, two mode cards read "default: ratchet warnings may remain" and "strict: ratchets promoted;
falsifiability matrix runs". A footer reads "green is a statement about this roster, tree, mode and
environment — nothing larger".]
The roster is part of the result
At the pinned revision, the verification runner names 27 modules in one explicit ordered roster. Each module must declare a name, a summary, a scope and a function to run. Duplicate names, missing declarations and unreadable scopes break roster loading. They do not quietly shorten the run.
That design turns the roster into a reviewable contract. A newly created check file does not become a guarantee merely by existing. It must be registered. A class also cannot disappear because an automatic file search stopped finding it. Both changes leave a deliberate edit at the point where the product says what verification contains.
The number 27 is evidence-bound, not timeless branding. A later revision may add or remove classes. The stable idea is that the run announces the applicable count against the total and names anything skipped. A reader should repeat the count from the receipt rather than carry this page's snapshot number into a different version.
Applicable is not the same as registered
Coldstart can inspect two shapes of tree. A harness root contains Coldstart's own tools, registry, capability library and warehouse. A mount is the knowledge root Coldstart owns inside a user's project; the surrounding application tree is not Coldstart's subject.
Every class declares whether its subject exists only in the harness or in both shapes. Before the runner starts, it selects the applicable classes. On a mount, harness-only classes are skipped by name, with an explanation that their subjects cannot exist there. The report therefore distinguishes “this class passed” from “this class did not run here.”
The operator can narrow the applicable roster further with an exact class selection. Repeating the selector asks for several named classes. An unknown name is a runner error, and asking only for classes that cannot run on the current shape is also a runner error. “I ran nothing” cannot return the same code as a clean run.
This makes a one-class exit 0 useful but narrow. It says that one selected, applicable predicate passed. It does not inherit the meaning of a full-roster run.
Exit 0: the applicable checks passed
Each check returns findings. Findings resolve to errors or warnings under the current mode. Exit 0 means no applicable check returned an error and no check or runner operation broke.
In default mode, that can include warnings. The runner has a ratchet severity for rules that are
still being tightened: it resolves to a warning by default and an error under strict mode. A class
with warnings prints an ok status followed by the warning details. Saving only the process code
would discard that distinction, so the report remains part of the evidence.
Checks can also attach factual notes, such as how many objects were counted or why a subject is not owed in this tree. A note is not a finding. It explains the surface the class inspected so the reader can interpret the result.
Exit 0 therefore supports a precise sentence: “The applicable registered checks completed without errors in this mode and environment.” It does not support “there are no defects,” “the project is safe,” or “the product works.” Those larger claims need predicates and evidence the receipt does not contain.
Exit 1: a represented finding exists
Exit 1 means at least one check completed and returned an error about its represented subject. A finding always names the file or registry row it concerns and supplies a message. The runner keeps going through the roster so the final report can show every represented error it encountered rather than stopping at the first one.
This is an ordinary red tree, not broken verification. The checking machinery reached a judgment. Examples in the pinned self-test rig include an unclassified file, a missing generated map, a map whose bytes drift from regeneration, or a malformed registry row. Each case plants a controlled defect and asserts that the responsible class names it.
The word “represented” matters. Exit 1 does not enumerate every problem in the project. It reports the problems the applicable classes know how to express and could observe in this environment.
Exit 2: the judgment machinery broke
Exit 2 means the runner cannot honestly classify the tree as passing or as carrying an ordinary represented defect. The root may be unresolvable. The roster may fail to load. A requested class may be unknown. A check may raise an exception. A selected set may contain no class that can run on this tree.
The runner treats an exception inside one check as broken machinery, records that class, and continues to the rest of the roster. Exit 2 outranks exit 1 in the final result. If one class finds a tree defect and another class crashes, the run is broken: the crash leaves part of the promised judgment unknown.
This distinction closes a common gate failure. If an exception were converted to “no findings,” a broken check would look green. If it were converted to an ordinary finding, the report would imply that the tree was judged and found defective when the real problem was that the judge failed.
Strict mode tests the checks as well as the tree
The pinned roster includes a self-test-integrity class. Its cheap pass always checks that every registered class declares a real, non-empty self-test target. Under strict mode it performs the expensive matrix: for every class, a child process neuters that class so it returns no findings and runs the class's declared test. The test must go red.
That proves a narrow but important property. If a check were hollowed out to return nothing, its own self-test would catch the loss. The matrix first proves that its neutering shim actually bites; otherwise intact checks could leave their tests green and invert the verdict.
Strict mode does not prove the checks are complete or well chosen. A falsifiable test can still model the wrong defect or miss another important one. The matrix establishes that each registered class has a working “inject one defect” tripwire, not that the roster contains every tripwire the project will ever need.
How to read the receipt
When a verification result is used to approve a close or explain health, retain these questions:
- Which source revision supplied the runner and roster?
- Did the report say harness root or mount, and how many classes were applicable?
- Was the run full-roster or narrowed with exact selections?
- Was strict mode active, and were any warnings or notes printed?
- Did the process exit 0, 1 or 2?
- Which files, rows or classes did the report name?
Those questions turn “CI was green” into reviewable evidence. They also keep two different repair paths separate. Exit 1 asks you to address the named tree defects. Exit 2 asks you to repair the judgment machinery or its invocation before trusting any claim about the tree.
What this page does not claim
A full strict run at exit 0 still proves only the predicates represented by the applicable roster under the observed environment. It cannot see an unregistered risk, an external consumer outside its scope, a production condition absent from the run, or a human requirement that was never translated into a check.
The page also does not claim that more classes automatically mean stronger verification. A short, specific roster with falsifiable checks can be better evidence than a long roster of overlapping or irrelevant rules. The contract protects legibility and failure posture; people still decide what deserves representation.
Next
The second upkeep job starts where authored truth becomes a machine-owned view: re-deriving projections.
How current this page is
Checked on 10 August 2026 against the pinned product revision's runner, shared check contract, self-test-integrity class and hermetic runner tests. To ask whether a claim here still holds, or to report one that does not, write to [email protected].