Coldstart is in final cutover and has not been released. This page documents the personal-profile contract in the pinned development build, not an onboarding flow available in a public release.
A project needs instructions about the project. A work session needs state about where the work stopped. A person may want a durable preference for how explanations, recommendations and risky actions are handled across projects. Those are three different records.
Coldstart's profile is the third one. It belongs to the person, lives outside the project and is loaded as personal calibration. It must not become another project plan, another resume pointer or a place to hide project-specific rules.
[Visual 8.3 — The personal-calibration lane enlarged. On the left, a profile card contains eight labelled field bands: "subscription", "experience", "stack", "environment", "project context", "working style", "output format" and "risk + safety"; a ninth narrow band reads "Coldstart defaults". The card enters a box labelled "same action, options and evidence". Two equal outputs leave it: a plain card saying "what changed + quick example + one concrete next step" and a compact card saying "result + technical shorthand + implied next step". A level bar across both reads "capability unchanged". Below, two separate boxes called "project instructions" and "project state" have no arrow from the profile; a note reads "more specific project guidance still wins". A side shield says "no secrets; no silent self-update".]
The profile is personal and external to the project
The pinned profile lives in the user's host configuration area, beside the global instruction stub, rather than inside a Coldstart install root or a project repository. The global stub imports it for each session.
That location gives the profile a specific lifetime. It can survive a reinstall or update of the Coldstart payload. It does not become a tracked project file by accident. The same calibration can apply when the person moves between projects.
The separation also constrains its content. The profile records durable facts about the person and their preferences. Project conventions, architecture choices and rules about one repository belong in that project's instructions. The active section, next action, blockers and reading list belong in project state. A personal preference cannot replace either record.
More specific project guidance wins when the two touch the same subject. Security rules remain in force at every level; a profile cannot relax them.
What the fixed structure captures
The profile template uses stable headings and bold field labels because downstream readers parse them. Its main sections cover:
- Subscription and cost posture.
- Experience and areas of confidence or learning.
- Primary, secondary and avoided stacks.
- Operating system, version-control host and plan-layout preferences.
- Typical work, artifact shape, deployment and team context.
- Push-back, answer length, reasoning depth, proactive signals and session shape.
- Explanation, code presentation, comments, voice and writing-style choices.
- Command tolerance.
- Optional Coldstart thresholds and cue phrases.
Some deep fields can remain explicitly unfilled. Two first-run express fields use a different deferred sentinel so a real consumer can ask once at the first genuine need. Jurisdiction and marketing context have their own lazy-capture state. These distinct values stop “not asked yet” from looking like a user answer.
The structure is data, not an essay. On a full re-onboarding pass, unchanged values are preserved and newly shipped default fields can be appended without overwriting custom values. A narrow single-field change touches only that field.
Onboarding starts only when asked
A missing profile does not authorize a long interview. The welcome surface may invite the person to set one up, but the onboarding skill begins only after an onboarding request.
On a first run, experience is asked first because it selects the least burdensome useful path. Someone who never writes code or mainly steers the assistant takes a two-question express path: experience and primary stack. The operating system and version-control host are detected where possible, safe defaults fill push-back and typical work, output fields derive from the experience rung, and subscription and artifact shape wait for a real decision.
A coder continues through ten essentials. Those cover subscription, experience, stack, push-back, answer length, reasoning depth, typical work, operating system, version-control host and artifact shape. The profile is saved before any optional expansion.
The deep interview remains opt-in. It adds nineteen questions, with two conditional deployment questions for a user-facing application, and can offer two optional after-edit hooks. Those hook choices are settings changes with explicit approval, not hidden profile effects. The express path does not touch settings at all.
One question at a time is part of the interface contract. A profile is supposed to reduce repeated calibration, not front-load a wall of choices onto a new user.
Experience changes the register, not the capability
The pinned experience model has seven rungs, from a person brand new to computers through an experienced system designer. The user chooses the rung; Coldstart does not infer it from behavior. An unknown stored value falls back to the plain steering register rather than guessing upward.
Each rung changes vocabulary, jargon, examples, visible reasoning, next-step wording and how much internal machinery is translated. At the plain registers, an abstract idea receives a concrete example or analogy, machine identifiers are translated, and a substantive response closes with one clearly recommended action. At the technical registers, shorthand and implied context can stay compact.
The underlying action is unchanged. A beginner and an expert see the same scope, options, safety boundary and verification result. The profile changes how those facts are rendered. It never hides an available path because of an experience label.
Four output values derive from experience when they are not pinned: answer length, reasoning depth, explanation style and the structure of the close. Derived values are baked into the profile with a tag so re-onboarding can recompute them if the experience rung changes. Explicit pins remain.
The two lowest rungs also derive a more careful confirmation posture for irreversible actions. That is a guard, not a capability gate: the action remains available after a clear, plain-language confirmation. Ordinary reversible edits do not become one-way doors merely because the register is simple.
Every captured field needs an honest effect
The field-effects registry classifies profile fields by how they work.
A mechanically wired field has a named consumer that reads it. A behavioral field changes response behavior without a simple literal reader. A gate ranks or offers a relevant capability family but does not hide it on demand. An ambient field travels with the always-loaded profile and honestly names no branching consumer.
A decorative field is a build error. If onboarding asks a question, writes the answer and then nothing changes, the user was asked to calibrate a control that is not connected.
The pinned field guard checks the profile template against the field-effects registry in both directions. It rejects a template field with no row, a row for a field nobody can set, a mechanical claim whose consumer stopped reading the field, a dead behavioral exemption and a gate pointing at a missing capability card. Its test rig plants each class of defect and requires the guard to fail.
This does not prove that every preference produces a perfect response. It does make the connection reviewable and prevents a field from remaining documented as functional after its mechanism has disappeared.
The profile does not learn behind your back
Coldstart does not silently update the profile from observed behavior. A durable preference changes through onboarding or an explicit edit. Session-level corrections stay session-level unless the person decides they should persist.
The interview also excludes secrets and identifying client data. A useful profile can say that the person prefers a warm explanation, works mainly on web applications or wants confirmation before writes. It does not need addresses, credentials, API keys or private customer names.
That restraint is part of the ownership boundary. Personal calibration should remain small enough to understand, review and remove. It is not a memory dump about the person.
What this page does not claim
The profile does not migrate project instructions, activate a project or prove that every host loads the same configuration surface. It documents the pinned product's profile path and consumer contracts.
It also does not promise that a chosen voice or experience rung changes model capability. Those fields shape register, tone and recommendation form. Correctness still depends on the underlying work and evidence.
Next
Finish with the boundary of the whole handbook: fit and limits.
How current this page is
Checked on 10 August 2026 against the pinned onboarding router, profile template, profile reference, field-effects registry, experience-register specification and hermetic field-guard tests. To ask whether a claim here still holds, or to report one that does not, write to [email protected].