Coldstart has not been released. This lesson explains the setup contracts in the pinned development build; it is not a download guide or a promise that an installer is available today.
Setting up Coldstart is not one switch. It takes three separate keys: one gives the machinery a home on a machine, one activates that machinery in a chosen project, and one records how a person wants the same work explained.
Keep the keys separate and ownership stays visible. You can tell whether a change belongs to the laptop, the order-app repository, or the person using both—and you can undo one without pretending the other two moved with it.
One situation, three changes
The order app has accumulated decisions about CSV fields, authorization and deferred historical IDs. Its maintainer wants future coding sessions to find that state without turning the repository over to a black-box migration.
Without Coldstart, the maintainer might put a few global scripts on the laptop, paste instructions into the repository and repeat personal preferences in each chat. That can be perfectly adequate. The friction appears when those layers blur: nobody can tell which files an update owns, whether a project opted in, or whether a tone preference accidentally became a project rule.
Coldstart makes the same setup explicit:
| Key | Action | Owner | What it does not mean |
|---|---|---|---|
| Machine | Copy a closed payload into an installation root—the directory that holds Coldstart's machinery | The installer and its receipt | No project is active |
| Project | Seed the selected repository with the small integration surfaces Coldstart needs | The project seed and its undo receipt | Existing documents were not adopted or migrated |
| Person | Write a profile of durable interaction preferences | The person | Project instructions and capability do not change |
The order matters because each action can be inspected on its own. Installation answers what the machine received. Activation answers what changed in this repository. The profile answers how the same choices and evidence should be presented to this maintainer.
The machine key installs machinery
The installer reads a closed list of payload paths, checks the destination and copies the listed material into a dedicated installation root. It refuses unsafe paths and incomplete input instead of guessing its way to a partial install. Its receipt records what the installation owns.
A manual script folder can be simpler when you have one machine and a few obvious files. The closed-list approach earns its cost when updates and removals need an ownership boundary. It still does not prove that every declared coding-agent journey works, and it does not activate the order app.
The project key activates one repository
Activation selects the order-app repository and plans a fixed mechanical seed before writing. A mechanical seed is the small set of integration files and registrations the tool can place without claiming to understand the product: a starting pointer, project-local discovery surfaces, managed settings and an ownership receipt.
The tool keeps existing files, limits edits to managed areas and uses its receipt to decide what an undo may remove or restore. A hand-edited file is not deleted merely because its name once appeared in the seed.
That reversibility is narrow. The order app's existing plans, decisions and generated views still need human interpretation. Activation does not reconcile them, and the pinned build has no verified path for migrating an existing document collection. The repository has opted into the machinery; it has not been adopted into a new knowledge system.
The personal key calibrates the conversation
The maintainer may prefer plain explanations, compact technical shorthand, more visible reasoning or a stronger confirmation posture for irreversible actions. A personal profile stores those durable preferences outside the project.
It can render the same action in different registers. It cannot change the action's evidence, weaken project rules or make the model more capable. Project-specific instructions remain with the project, and more specific safety rules still win.
A profile is useful when the same calibration is repeated across projects. If a short opening note already produces the right interaction, that smaller method may be enough.
What the three keys do not open
The three-key setup does not establish public availability, release readiness or universal coding-agent support. It also does not make a mature repository safe to migrate. Those conclusions require different evidence.
The practical boundary is simple: inspect the machine receipt, the project receipt and the personal profile as three separate records. If you cannot say which one owns a change, the setup boundary has been lost.
Next
Start with the machine key: installing.