Coldstart is in final cutover and has not been released. This section explains the setup contracts in the development build at the source revision named above. It is not a download guide for an available release.
“Set up Coldstart” sounds like one action. In the pinned build it is three actions with different owners and different rollback boundaries.
First, an installer copies an allowlisted payload into a dedicated machine root. Second, an init tool uses that root to place a mechanical seed in one chosen project. Third, onboarding writes a personal profile that changes how the same workflow is presented to one person. Treating those steps as one switch would hide which machine, project or person a change belongs to.
[Visual 8 — One wide frame with three left-to-right lanes separated by solid vertical boundaries. Lane one is labelled "machine installation": a sealed stack called "allowlisted payload" passes through two host entry points into "dedicated machine root"; a stop bar underneath reads "copies machinery, activates no project". Lane two is labelled "one-project activation": an arrow from the machine root enters "plan the mechanical seed", then "selected project"; a return arrow labelled "record + undo" points back, while a dashed branch called "existing corpus adoption" ends before the lane with "not verified". Lane three is labelled "personal calibration": "profile fields" enter one workflow box and leave as two equal cards, "plain register" and "technical register"; neither card connects to project files. A footer spanning all lanes reads "machine payload ≠ project seed ≠ personal profile". Pages 8.1, 8.2 and 8.3 enlarge the three lanes without merging their boundaries.]
The three pages
| # | Concept | What it covers |
|---|---|---|
| 8.1 | Installing | The closed payload, root selection and refusals, the two declared host entry points, idempotent copying, and the boundary of the local platform evidence |
| 8.2 | Activating one project | The fixed mechanical seed, project-local registration, managed merges, idempotence, undo, and why activation is not adoption |
| 8.3 | Your profile | Personal calibration, interview depth, field effects, experience registers, and the separation from project instructions and project state |
Installation gives the machinery a home
The first lane begins with a closed list of payload paths. The installers read that list, validate it, and copy only those files into a dedicated root. They do not sweep the source tree and decide what looks useful. Missing entries, unsafe paths and malformed manifest rows are refusals rather than reasons to produce a partial install.
The Bash entry point declares macOS, Linux and Git Bash as its host surface. The PowerShell entry point is designed as its flag-for-flag twin. Both choose a target root from the same precedence, apply matching structural refusals, create the same install manifest and preserve the distinction between a clean refusal and a usage or internal error.
That agreement is tested, but the test has a boundary. The pinned parity suite compares the two installed path sets, the manifest bytes, the installed class map and root selection. It does not prove every operating-system journey, shell version or later runtime action. A locally green installer test is evidence about that test machine and payload revision, not a universal support statement.
Most importantly, the installer does not turn Coldstart on for every project. It may preserve an optional settings file as a backup, but it does not add the per-project registrations. Its output is a machine root containing the machinery and a receipt naming what that install owns.
Activation gives one project a reversible seed
The second lane starts only after a machine root can be resolved and validated. Init takes one selected project and computes a plan before writing. The plan contains mechanical surfaces: the empty knowledge mount and its map, a resume pointer, an open-work queue, canonical lifecycle state, a managed project-instructions block, the hook roster, and the host-discovery stubs for commands, skills and agents.
It deliberately does not invent a brief, architecture, project plan, section, room or decision. Those artifacts need judgment about the project. A generic initializer cannot know them without creating empty headings that look authoritative.
The seed is designed to converge. Files already present are kept. A managed prose block is replaced only between its own markers. Existing settings are parsed and foreign entries are retained while Coldstart's registrations are refreshed. A second run against an unchanged seed plans no writes.
Undo follows the receipt rather than guessing from filenames. It removes a created file only when the file still matches what init wrote, restores backed-up pre-existing files, and leaves a human-edited seed file alone. That makes activation reversible within the evidence represented by the seed and its tests.
It does not make activation equivalent to adopting an existing project corpus. Seeding mechanical surfaces into a repository says nothing about how existing plans, instructions, memories or generated views should be reconciled. The pinned build has no verified migration path for that judgment-heavy work. The dashed adoption branch in the visual stops for that reason.
A profile belongs to a person
The third lane has a different subject. A personal profile captures durable preferences such as experience, stack, environment, working style, output format and command tolerance. It lives in the user's configuration area, outside both the Coldstart machine root and any one project's repository, so a project does not silently become the owner of personal calibration.
The profile can render the same underlying workflow in different registers. A newcomer can receive plain language, a concrete example and one spelled-out next action. An experienced developer can receive compact technical shorthand. The action, available options and verification result stay the same. The profile changes the explanation, not the project state.
Some profile fields do influence behavior or routing, but they do so through named contracts. A command-tolerance choice changes when a write needs confirmation. Stack and artifact fields can change which examples or capability families are offered first. Other fields are honestly ambient. The pinned field guard rejects a captured field that claims to do something while having no real consumer.
Onboarding is also explicit. A missing profile can produce an invitation, but it does not launch a long interview without being asked. The shortest first-run branch asks only the experience and stack questions, writes conservative defaults and defers two high-stakes fields. A coder can take the ten-question essentials path, and a deeper pass remains opt-in.
The order is intentional
These lanes can be entered at different times, but they should not be collapsed.
- Installation answers: which payload files does this machine root own?
- Activation answers: which mechanical changes does Coldstart own in this project?
- Personalization answers: how should the same work be explained and guarded for this person?
- Adoption, when it exists, must answer a fourth question: how should existing authored material be understood and migrated without loss?
The first three have implementations and bounded tests at the pinned revision. The fourth does not have a verified path, so this section names it as a limit instead of turning activation into a migration promise.
What this section does not claim
This section does not claim that Coldstart is publicly available, release-ready or supported on every host named by its entry points. It does not turn one local test run into cross-platform proof. It also does not claim that a reversible mechanical seed makes the adoption of an existing knowledge corpus reversible.
Personalization is not an ownership shortcut either. A profile cannot override project-specific instructions or weaken safety rules. More specific project guidance still governs the project, and security boundaries remain in force at every register.
Next
Start at the machine boundary: installing.
How current this page is
Checked on 10 August 2026 against the pinned product revision's two installers, payload allowlist, project scaffold, onboarding router and experience-register specification. The product has moved since that pin; sections 1 to 7 use the same revision, so this section keeps it rather than mixing source snapshots mid-handbook. To ask whether a claim here still holds, or to report one that does not, write to [email protected].