This page describes an unreleased development build. It is not a supported activation guide for a product available today.
Activation chooses one project and adds the small integration surfaces Coldstart can own without claiming to understand the project. The machine installation stays where it is; this second setup key changes only the selected repository.
For the order app, activation can add the starting pointer and local registrations needed for later sessions. It cannot decide what the existing CSV decisions mean or move the repository's current documents into new homes. Activation is not adoption.
Manual opt-in works until ownership gets fuzzy
Without an initializer, the maintainer could copy a pointer template, paste hook entries into a settings file and add command links by hand. That may be the clearest route for one small project.
The friction begins when the integration is updated or removed. Which lines were pasted by the tool? Which file existed first? Is an edited queue still safe to delete? Manual notes can answer those questions, but only if somebody keeps them accurate.
Coldstart addresses that repeated ownership problem with a mechanical seed. “Mechanical” means the initializer can derive the file shape without deciding product intent. It plans the complete change before writing and records the result for a later undo.
The machine root is resolved first
The thin launchers locate a valid installation root and hand the request to one shared scaffold implementation. Runtime root resolution is stricter than the installer's destination choice: it does not guess from the development default. A configured but invalid root is an error rather than a reason to try somewhere else.
This matters because the project registrations must point back to the same machinery that planned the seed. Otherwise activation could appear green while later sessions invoke another installation.
The seed contains integration, not judgment
The planned seed has four groups:
| Group | Reader-visible job | Boundary |
|---|---|---|
| Starting state | Give a fresh session a pointer, open-work queue and lifecycle state | No active plan is invented |
| Project instructions | Add a managed explanation of where the integration lives | Prose outside the markers remains project-owned |
| Settings | Add the shipped project-local lifecycle registrations | Foreign entries are retained |
| Discovery | Let the coding agent find the shipped commands, skills and agents | Missing promised sources cause refusal |
The initializer refuses to invent a brief, architecture, project plan, plan section or knowledge hierarchy. Empty authoritative-looking files can steer later work even when nobody chose their contents. Preparation, not activation, owns those decisions.
For the order app, that means activation does not file the approved export fields, the rejected background-job idea or the historical-ID queue item. Those facts already have human meaning. A generic seed cannot assign it safely.
Re-running manages only marked surfaces
Before writing, each path is classified as a new file, a managed prose block, a settings merge or a file to keep. An existing seed filename is kept rather than claimed. A managed block changes only between its markers. Unreadable settings are refused instead of being reformatted or replaced.
On an unchanged project, the next plan contains no writes. This is useful when the integration must be refreshed repeatedly. It does not mean the initializer continuously enforces a template over the whole repository.
Undo follows evidence, not filenames
The activation receipt records each write and the content that was written. Pre-existing files touched by a managed merge receive a preserved backup. Undo then applies three rules:
- Remove a created file only while it still matches the recorded content.
- Restore a pre-existing file from its original backup.
- Leave a person-edited created file in place.
With no receipt, undo refuses to guess. This is safer than deleting every familiar filename, but it is still evidence about the mechanical seed only.
Activation is not adoption
The order app may already have plans, project instructions, decisions, generated maps or another agent workflow. Keeping those files avoids overwriting them. It does not prove that Coldstart can read them, reconcile competing state or preserve their meaning in a different structure.
At the pinned review, no verified existing-corpus migration path exists. A future adoption process would need to inventory the material, identify owners, propose mappings, preserve provenance and test rollback. The initializer performs none of that work.
That makes the honest result narrow: the repository now has a Coldstart integration seed. Its existing knowledge has not been migrated.
Evidence and its limit
The pinned tests exercise the exact seed, refusal cases, repeat run, undo, registrations and coding-agent discovery in temporary projects. One init-launcher parity case was skipped because its test did not recognize the available PowerShell executable name. The skip remains a limit, not a pass.
The tests support claims about those represented project changes. They do not establish safe adoption, complete coding-agent support or release availability.
Next
The project key is in place. Keep personal calibration separate in your profile.