Coldstart has not been released. This page documents the self-CI runner in the development build at the pinned revision, not a generally available command.
The export tests pass. That is useful evidence, but “green” is incomplete until you know which checks ran, which were skipped, what mode and environment they used, and how the runner ended.
Coldstart keeps those details on the receipt. It calls its check runner self-CI because the harness checks its own named rules, not because it proves the whole application correct.
The ordinary alternative
A developer can run a test command, read the failures, and move on. For a small, familiar suite, that is enough. The ambiguity grows when checks apply to different tree shapes, warnings change by mode, or a broken test process can be mistaken for “no findings.”
Coldstart uses an explicit ordered roster. At the pinned revision it contains 27 check classes. That count is a dated measurement, not branding; a later revision may have another roster.
Registered, applicable, and selected
These are three different sets:
| Set | Meaning |
|---|---|
| Registered | Rules the runner promises to know about |
| Applicable | Registered rules whose subject exists in this tree |
| Selected | An optional smaller group the operator explicitly requested |
The report names skipped checks. Asking for an unknown check, or selecting only checks that cannot run here, is a runner error. Running nothing cannot look like a clean full run.
The three exits
| Exit | What happened | What to do next |
|---|---|---|
0 | Applicable checks completed without errors in this mode | Read warnings and keep the receipt with the claim |
1 | At least one represented rule found a problem | Repair the named tree problem |
2 | Root selection, roster loading, the runner, or a check broke | Repair the checking machinery before trusting the tree judgment |
Exit 2 outranks exit 1. If one check finds a defect and another crashes, part of the promised
judgment is unknown.
Coldstart's other commands use the same three codes for the same three meanings: 0 is a completed
run with nothing to report, 1 is a real problem the command is qualified to name, and 2 is the
command declining to give a judgment at all — because it was invoked wrongly, could not read what it
needed, or broke. The installer's 2 and the re-derivation check's 2 are both that third case.
Mode changes the receipt
Default mode can leave selected ratchet findings as warnings. Strict mode promotes those warnings and runs a falsifiability matrix: each registered check is deliberately neutralized and its own test must notice.
That proves a narrow property. Each registered check has a working planted-defect tripwire. It does not prove that the roster contains every rule the project needs or that each test models every possible defect.
The sentence green supports
After an exit 0, the safe conclusion is:
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”. A production condition, external consumer, human requirement, or unregistered risk can remain outside the run.
For a small project, a shorter named test list may be better evidence than a large irrelevant one. The value comes from knowing what the receipt represents, not from maximizing the count.
Next
The second upkeep receipt compares generated views with their owners: re-deriving projections.