Coldstart has not been released. This page documents two projection generators in the development build at the pinned revision, not an available release.
The export decision is stored in an authored project record. A generated map may list that record so a fresh session can find it quickly. If people edit both files by hand, the project now has two answers to the same question.
Coldstart uses re-derivation instead. Authored sources own the facts. A generator rebuilds each projection, a replaceable view of those facts, and compares it with the stored bytes.
The ordinary alternative
For a small collection, maintain a table of contents by hand. It is direct and easy to review. The problem appears when the same fact is copied into several maps or indexes. One source changes while the copies stay plausible.
Coldstart keeps ownership one-way:
- authored project cards and their structure produce warehouse maps;
- authored capability cards produce routing rows and an index.
The generators arrange existing facts. They do not decide whether a card is correct, move a project record, invent a capability, or improve a description.
Rebuild the whole view
Each generator scans its complete authored subject and renders the expected output from scratch. This avoids a second memory of removed rows, renamed fields, or moved cards.
Running the same generator twice against unchanged sources produces the same expected bytes. That makes the operation repeatable, but it does not make the generator bug-free.
Compare exact bytes
The expected rendering is compared byte-for-byte with the stored projection. Exact comparison keeps line-ending and whitespace drift visible instead of normalizing it away.
Byte equality proves one narrow fact: the stored view matches this generator's rendering of the sources it successfully read. It does not prove those sources are correct, current, complete, or wisely owned.
Check first, then write
| State | Check-only mode | Write mode |
|---|---|---|
| Current | Exit 0; change nothing | Change nothing |
| Stale | Exit 1; name the differing view | Replace the differing generated view |
| Source unreadable | Exit 2; give no judgment and write nothing | Write nothing |
Check-only mode answers “would regeneration change a machine-owned view?” without changing the evidence during the question. After an intended write, a second check provides the clean receipt.
Unreadable input is not staleness. If a present card or structure cannot be understood, the tool cannot know what a complete view should contain. It stops rather than silently omitting the bad source and publishing a partial projection.
A practical export receipt
After the authored export decision moves:
- Check-only mode reports the related map as stale.
- A person confirms that the source change is intended.
- Write mode regenerates the map from all readable sources.
- A fresh check reports exact agreement.
The explanation still points to the authored export decision. “The map changed because the map changed” would make generated output its own authority.
Re-derivation is one upkeep job, not the health of the whole harness. Verification, open-work review, and product judgment keep their separate receipts.
Next
Two on-demand entrances act on the harness rather than on the work, and this is where they belong: sweeping and re-deriving.