Adoption

STAGE is not a maturity ladder. Its delivery loop is the usable baseline; every other capability is an independent response to an observed project need. A project does not become "more STAGE" by accumulating maps, operations, tools, or evidence artifacts.

Choose from the capability menu below in any order. Add one only while its trigger is present, and stop when the direct project-native path is cheaper and truthful enough. Retrofitting every capability at once creates the same complexity debt the method is intended to control.

Baseline: Safety And Delivery

Use the core delivery loop on one real change:

Frame -> Inspect -> Plan -> Build -> Rehearse -> Judge -> Checkpoint

No STAGE file is required. Apply the eight-rule Safety Kernel, then work through the project's existing architecture, editor, runtime, tests, and source-control practices. Preserve authored work, match evidence to the claim, and leave experiential acceptance with the human.

Start here. Stay here unless a concrete trigger below demonstrates the need for another persistent capability. The stage-deliver-change skill packages this path.

Optional Capability: Map

Create STAGE.md and .stage/project.yaml.

Map when the project repeatedly pays to rediscover ownership, lifecycle, operations, terminology, evidence, or prohibited actions. Mapping is an earned coordination aid, not a prerequisite for delivery and not the automatic next step.

Choose a map profile from coordination and change risk: compact, standard, or extended. Start smaller when uncertain.

Identify:

• current project phase;
• domains and vocabulary;
• composition and lifecycle entry points;
• authoring and runtime state;
• verification commands;
• manual and generated ownership;
• unresolved authority and prohibited operations;
• known fragile workflows.

Do not refactor yet.

Keep the map stable enough to orient future work. Record operation capability, readiness, claim boundaries, and the canonical verification route, but do not copy exact test counts, revisions, timestamps, hashes, or individual outcomes into multiple map surfaces. Those volatile coordinates belong in one verification history or in an explicitly revision-bound audit or release record.

Optional Capability: Observe

Instrument the most expensive invisible failures. Add composed startup smoke, useful logs, timing probes, deterministic scenarios, or fixed seeds where failures recur.

Record operation state and evidence coordinates. Do not convert “documented” into “passed” until the real tool and relevant scope have been exercised.

Optional Capability: Expose Authoring Or Operations

Expose frequently changed behavior through stable authoring surfaces when manual editing is error-prone or indirect. Add a named operation only when a repeated human or agent job has an understood readiness, failure, reset, and teardown lifecycle. Remove duplicate sources of truth when they cause real drift.

An in-game almanac, codex, bestiary, model viewer, world previewer, or editor gallery belongs here only when it independently serves players, authors, or a recurring development job. It remains an ordinary project feature using canonical content, not STAGE review infrastructure.

Optional Capability: Bound

Clarify module dependencies, lifecycle ownership, safe operations, and agent decision rights. Add compiler or semantic enforcement where convention repeatedly fails.

Optional Capability: Automate Or Transfer

Add only the durable adapters, automated map checks, reusable skills, or cross-project validation that named consumers actually use. An evidence receipt is one possible adapter, not a maturity requirement. Measure whether each capability reduces correction cost rather than merely increasing output.

Selection By Trigger

Observed trigger	Consider	Do not infer
Ordinary bounded change	Deliver	A map or custom operation is missing
Repeated ownership, terminology, or orientation rediscovery	Map	The runtime architecture must change
Important failures remain invisible or irreproducible	Observe	Every domain needs diagnostics or fixed fixtures
Repeated editing or operation is fragile and indirect	Expose Authoring Or Operations	Every useful action needs an agent API
Boundary, lifecycle, or authority mistakes recur	Bound	More interfaces are automatically safer
A named CI, release, external, or cross-project consumer recurs	Automate Or Transfer	Durable receipts or reusable tooling are universally valuable

Capabilities may be removed when their trigger disappears. A project may use only delivery for its entire lifetime and still apply STAGE correctly.

Brownfield Rule

Start with one real change in a frequently changed domain or one recurring failure. Use the direct project path first. Map its intent, runtime, operation, ownership, and evidence surfaces only when preserving that knowledge is cheaper than repeatedly rediscovering it. Expand after the first durable aid demonstrates lower oversight cost.

Existing 0.1 maps remain valid. Use the explicit migration command only when the project wants the richer 0.3 schema; review the generated candidate before adoption:

python3 scripts/migrate_project_map.py \
  --manifest path/to/project.yaml \
  --output path/to/project-v0.3.yaml \
  --profile standard

Migration defaults ambiguous ownership and operation effects to conservative states. It does not confer authority. It also refuses to overwrite either the source or an existing review candidate without the corresponding explicit --in-place or --force flag.

There Is No Full Adoption

Use only the useful parts, especially for:

• game jams;
• short-lived prototypes;
• tiny linear games;
• experiments where local engine components already make ownership obvious.

A project does not become better by manufacturing systems, interfaces, editors, operations, or documentation that no real change requires. There is no terminal STAGE level and no checklist whose completion establishes product quality, agent readiness, or architectural maturity.

Current Validation Boundary

STAGE 0.6 retains external mapping across compact Unity, custom browser, Godot, and data-driven Rust/Bones projects, with operational trials in several toolchains. Its owner workflow is operational. It has not demonstrated independent maintainer adoption, controlled cross-project changes, or longitudinal maintenance value; those limits bound transferability claims rather than owner use. See Evaluation, Readiness, And Transferability.