Not installable yet

This page documents the profile contract in an unreleased development build, not a public onboarding flow available today.

A profile is a small personal record of how you want the work explained and presented. It belongs to you, outside the order-app repository and outside the machine installation. It is the third setup key, not another project plan.

The same decision, action and evidence must survive every register. A profile can ask for plain language or compact technical shorthand; it cannot make the model more capable, hide an option or weaken a project rule.

Repeating preferences manually is often enough

Without a profile, the maintainer can begin a session with “keep this concise” or “explain unfamiliar terms plainly.” For occasional work, that is direct and cheap.

The friction appears when the same calibration is repeated across projects and fresh sessions, or when a tool keeps drifting back to the wrong level of detail. A durable profile avoids that repeated setup. It also creates maintenance: the record must stay accurate and small enough to review.

Use a profile when the repetition earns it. Keep the opening note when it does not.

Three records, three subjects

The profile records durable personal facts and preferences. Project instructions record how the order app should be worked on. Project state records where the current work stopped.

RecordExampleMust not become
Personal profile“Explain unfamiliar terms with one concrete example”A rule about the order app
Project instructions“CSV exports use approved raw fields”A preference applied to every project
Project state“Historical IDs remain queued”A permanent fact about the person

The profile lives in the user's configuration area so it can survive a payload update and apply across projects. More specific project guidance wins when subjects overlap. Security boundaries remain in force at every explanation level.

Onboarding starts only when requested

A missing profile may produce an invitation. It does not authorize a long interview. The pinned onboarding flow starts after an explicit request and asks one question at a time.

The shortest path asks for experience and primary stack, detects a small amount of environment context where possible and fills conservative defaults. A coder can continue through an essentials path. A deeper interview is opt-in, and optional settings changes still require explicit approval.

This sequence keeps the profile proportional to the need. It also distinguishes “not asked yet” from an actual user answer, so a deferred high-stakes choice is not mistaken for consent.

The profile has stable fields with named effects

The fixed structure covers experience, stack, environment, typical work, working style, output format and risk posture, plus selected Coldstart defaults. A full re-onboarding pass preserves unchanged values and can add newly shipped defaults. A narrow edit changes one field.

Every captured field needs an honest effect. Some fields have a mechanical reader. Some influence response behavior. Some rank relevant guidance without hiding other choices. Others are ambient context and explicitly claim no branch.

The pinned field check compares the profile template with that effects register. It can catch a documented control whose consumer disappeared or a routed family that no longer exists. That makes the wiring reviewable; it does not prove that every response will match the person's taste.

Experience changes the register

Suppose the order app's authorization check fails. A plain register might say what failed, explain why that blocks close and give one concrete next action. A technical register might name the same result and next step with less explanation.

Both versions preserve:

  • the failed check;
  • the available repair or stop choices;
  • the safety boundary;
  • the evidence needed before close.

The user chooses the experience register; Coldstart does not infer it from behavior. An unknown stored value falls back to a plain register instead of guessing upward. Simpler language never removes an available action, though irreversible actions may receive a more explicit confirmation.

The profile does not learn behind your back

A durable preference changes through onboarding or an explicit edit. Session corrections remain local unless the person chooses to keep them. The profile also excludes secrets, credentials and identifying customer data; useful calibration does not require a personal dossier.

These limits preserve ownership. The profile should remain understandable, reviewable and removable. It does not activate a project, migrate its documents or establish that every coding agent loads the same configuration surface.

The three setup keys are now separate. The next question is whether carrying any of this ceremony is worth it for the work at hand.

Next

Move from setup to the adoption decision: fit and limits.