Coldstart is in final cutover and has not been released. This page describes the project seed in the pinned development build, not a supported activation workflow for an available release.
Installation leaves machinery in a dedicated machine root. Activation is the separate act of choosing one project and giving it the smallest mechanical surfaces Coldstart needs to be discoverable there.
The word “mechanical” carries the boundary. Init can know how to create a pointer, register a shipped hook or route a command stub. It cannot know what the project is for, which architecture is right, how an existing plan should be interpreted or which documents should be migrated. Those choices need judgment and belong after activation.
[Visual 8.2 — The one-project-activation lane enlarged. A validated "machine root" enters a box called "plan before writing". The plan fans into four grouped stacks inside "selected project": "empty knowledge mount + generated map", "resume pointer + open queue + lifecycle state", "managed instruction and settings merges", and "command + skill + agent discovery stubs". Above the fan, a bar reads "fixed mechanical seed only"; silhouettes labelled "brief", "architecture", "project plan", "rooms" and "existing documents" remain outside it. Beneath the project is an ownership receipt. A return path marked "undo" has three branches: "remove unchanged created file", "restore backup", and "leave human-edited file". A dashed arrow toward "adopt existing corpus" stops at a gate labelled "no verified migration path".]
Init resolves a machine root first
The Bash and PowerShell launchers are deliberately thin. Each resolves a valid Coldstart root, finds Python 3.12 or newer and passes the request to the same scaffold module. The seed logic lives in one implementation, so the shell entry points do not carry two independent definitions of a project.
Runtime root resolution is stricter than installer root selection. Init does not use the development install default to guess where the machinery might be. It accepts a valid explicit or environment root where supported, otherwise its own installed location, and fails loudly if the identity evidence is missing. A root setting that is present but invalid is an error, not a reason to fall through somewhere else.
This prevents a subtle split: one command writing project state from one machine root while the registered hooks later run from another. Root identity is checked before the scaffold plans a project change.
The seed is fixed and deliberately small
The scaffold creates four kinds of project surface.
First, it creates an empty knowledge mount, a generated empty-state map, a resume pointer, an open-work queue and canonical lifecycle state. The pointer claims no active section. Its honest initial mode is preparation: the next meaningful work is to understand the project and plan the first section.
Second, it inserts a managed block into the project's instruction file. The block explains where the knowledge mount and pointer live, the order in which they are read, and the lifecycle commands that operate on them. Text outside the managed markers remains project-owned.
Third, it merges the shipped hook roster into the project's settings. The scaffold validates that each registration points to a hook the selected machine root actually carries. Foreign settings and foreign hook entries keep their content and position; only registrations that resolve through Coldstart's own hook root are replaced on a re-run.
Fourth, it creates host-discovery surfaces for the shipped commands, skills and agents. Command and skill stubs keep the canonical description used for discovery and route back to the body in the machine root. Agent definitions are copied from the shipped roster. If a promised source surface is absent, the seed is refused rather than described as a smaller dormant installation.
The pinned tests bind this list from the outside. They spell out the expected seed rather than asking the scaffold what it intended to write. That way, adding a new project file changes the test and implementation together instead of disappearing into a self-fulfilling assertion.
Judgment-shaped files are refused
Init writes no brief, architecture, master plan, first section plan, room or box. The scaffold has an explicit refusal for those shapes, and the tests inject a room-shaped path to confirm that the plan fails before a byte moves.
That is more than restraint in the current implementation. It keeps preparation honest. A blank architecture document looks like a place somebody has already decided architecture belongs. A generic room hierarchy makes the same claim about the project's subjects. Empty authoritative shapes can steer later work even when nobody consciously chose them.
Activation therefore ends with a project that Coldstart can locate and resume, not with a project Coldstart claims to understand. Preparation is the next judgment step.
Re-running converges without taking over the project
Before writing, the scaffold classifies every planned path as create, managed block, settings merge or keep.
A created seed file that already exists is kept as-is. The scaffold does not assume that matching the expected filename makes the contents its property. The managed instruction block is inserted or replaced only between its markers, leaving surrounding bytes untouched. Settings must parse as an object before any merge; unreadable settings are refused rather than reformatted or replaced.
On an unchanged project, a second plan contains no writes. The pinned idempotence tests compare the whole project tree before and after a re-run and also add human prose outside the managed block to prove it survives.
Idempotence here means convergence on the managed seed, not repeated enforcement over everything in the repository. Coldstart owns its block, registrations, newly created seed files and receipt. It does not make the rest of the project conform to a generic template.
Undo reads the ownership receipt
Every init write is recorded in a project-local receipt with the digest of what was written. Pre-existing files touched by a managed block or settings merge are backed up before the first change. A re-run keeps the pristine backup rather than replacing it with a backup of its own prior output.
Undo uses that evidence:
- A created file is removed only when its current contents still match init's digest.
- A touched pre-existing file is restored from its recorded backup.
- A created file edited by a person is left in place.
- A project with no receipt is refused; the tool does not guess what it once owned.
After those file actions, empty directories created by the seed can be pruned from the deepest level upward. A directory still containing somebody else's file remains.
The tests exercise a full round trip against a temporary version-controlled project and require the working tree to return to its pre-init state. They also edit the queue after seeding and require undo to leave that human-owned change alone.
Activation is not adoption
A repository may already contain plans, instructions, memory, generated maps or another agent harness. The mechanical seed does not decide whether those artifacts are current, compatible, redundant or safe to move.
The scaffold's keep behavior is intentionally not a migration algorithm. Keeping a pre-existing path avoids overwriting it; it does not prove Coldstart can read the material, reconcile competing pointers or preserve the semantics of another corpus. Likewise, adding a managed block beside project instructions does not settle conflicts in those instructions.
At the pinned revision, existing-corpus adoption has no verified migration path. A safe future workflow would need to inventory the corpus, classify ownership, propose changes, preserve provenance and test rollback. This page does not borrow the seed's reversibility claim for work the seed never performs.
Evidence and its limit
The isolated setup run exercised the scaffold's exact-seed, lint, refusal, idempotence, undo, registration and discovery cases. The project trees were temporary, and the Bash-backed hook registration case ran on the documentation machine.
One init launcher parity case was explicitly skipped because its test recognizes a legacy PowerShell executable name but not the available PowerShell 7 name. The installer parity suite did exercise PowerShell 7 separately. The skip remains a limit on the init-launcher claim; it is not converted into a platform pass.
Next
Activation prepares one project. Personal calibration stays elsewhere: your profile.
How current this page is
Checked on 10 August 2026 against the pinned init launchers, scaffold implementation, exact-seed and round-trip tests, and installed-discovery tests. To ask whether a claim here still holds, or to report one that does not, write to [email protected].