nccgs 2.0.0-rc.2 → 2.0.0

package/README.md

@@ -1,30 +1,35 @@
 # NCCGS — New Claude Code Game Studio
 
-**2.0.0-rc.2** is a release candidate for standalone game-development orchestration
-in **Claude Code**, published on npm's **next** channel. The stable/latest channel
-is not promoted by this release.
+**2.0.0** is a prepared stable package for standalone game-development
+orchestration in **Claude Code**. It is not published and does not move npm tags.
+It includes handoff automation, bounded task slicing and Unity repair, protected
+final-review allocation, managed Unity settlement and exact first-import output
+declarations. New repair steps block unsaved loaded scenes before execution.
+See [handoff operations](docs/HANDOFF-AUTOMATION.md), [bounded repair](docs/BOUNDED-REPAIR.md),
+[task slicing](docs/TASK-SLICING.md) and [release notes](CHANGELOG.md).
 
 Claude Code handles intake, planning, specialist dispatch, testing, independent
 review and reporting. External review can be configured separately. This major
-candidate introduces standalone defaults and explicit execution-policy migration
+version introduces standalone defaults and explicit execution-policy migration
 from the older compatibility workflow; existing task obligations remain preserved.
 
 ## Validation and limits
 
-Framework regression: 183 passed, 0 failed, 6 Windows symlink-fixture skips (189
-tests). A scoped delivery V2 case reached 24/24 criteria, 137 EditMode tests,
-52 PlayMode tests and an independent Claude Code PASS with no remaining conditions.
-That case included operator intervention; it is not a clean autonomous benchmark,
-a human acceptance decision or a claim about all games. Its earlier failed attempts
-and negative findings remain preserved in the development evidence.
-
-The release source includes the reviewed fixes to reviewer capacity, handoff schema
-guidance and standalone command syntax. The game case used a frozen framework with
-a session-only reviewer capacity override. This exact RC has not yet completed a
-fresh full game task or a published-1.3.0 upgrade qualification. Use a disposable
-project or backed-up copy while evaluating it. See [release status](docs/RELEASE-STATUS.md), [Vietnamese quick start](docs/HUONG-DAN-MIGRATE-VA-SU-DUNG.md), [release notes](CHANGELOG.md),
-[upgrading](UPGRADING.md), [delivery acceptance](.claude/nccgs/protocols/delivery-acceptance.md)
-and [portable framework decisions](MEMORY.md).
+The frozen exact RC4 archive was exercised through actual Claude Code on a
+controlled Unity scene repair: dirty-scene refusal preserved unsaved content,
+a fresh worker repaired the target, deterministic PARTIAL handoff required no
+continuation, all five checks and 28 criteria/385 assertions passed, and a fresh
+independent reviewer returned unconditional PASS before normal task closure.
+This is scoped workflow evidence, not broad game-quality or productivity proof.
+
+Version 2.0.0 keeps those runtime guards and adds a receipt publisher so external
+Editor stop evidence is available inside the reviewer's project. It does not
+operate processes or alter acceptance. See [Editor evidence](docs/EDITOR-SESSION-EVIDENCE.md).
+Release receipts separately record archive tests, installation/upgrades and
+independent maintenance review. Preparation does not publish npm or claim a new
+full Unity game run through the stable archive. Frozen history remains intact.
+See [release status](docs/RELEASE-STATUS.md), [upgrading](UPGRADING.md),
+[Vietnamese quick start](docs/HUONG-DAN-MIGRATE-VA-SU-DUNG.md) and [decisions](MEMORY.md).
 
 ## What changed
 
@@ -63,20 +68,23 @@ The studio retains 47 roles (13 active by default, including Game Designer), 36
 rules, lifecycle hooks and unmodified official Unity Skills. Enable specialists
 when their expertise resolves a concrete problem; do not dispatch the whole studio.
 
-## Try the release candidate
+## Try the prepared stable package
 
 Requirements: Claude Code and Node.js 18+. Unity CLI/Pipeline is needed for live
 Unity operations. Run against a disposable Unity project first:
 
+Use the locally prepared archive and its accompanying SHA-256 manifest:
+
 ```powershell
-npx --yes nccgs@2.0.0-rc.2 install --project "D:\path\to\UnityProject" --dry-run
-npx --yes nccgs@2.0.0-rc.2 install --project "D:\path\to\UnityProject"
-npx --yes nccgs@2.0.0-rc.2 doctor --project "D:\path\to\UnityProject"
+$NccgsArchive = "D:\path\to\nccgs-2.0.0.tgz"
+npx --yes --package "$NccgsArchive" nccgs install --project "D:\path\to\UnityProject" --dry-run
+npx --yes --package "$NccgsArchive" nccgs install --project "D:\path\to\UnityProject"
+npx --yes --package "$NccgsArchive" nccgs doctor --project "D:\path\to\UnityProject"
 ```
 
-Use nccgs@next to follow candidate releases, or pin the exact version above for
-repeatability. Use update for an existing installation only after reviewing its
-dry run and backup. Published-1.3.0 upgrade qualification is still pending for this RC.
+Before publication, use this local archive. After publication, pin nccgs@2.0.0
+for repeatability; npm tags are not changed by this preparation. Use update for an existing installation only after reviewing its
+dry run and backup. See [the tested upgrade matrix](docs/UPGRADE-QUALIFICATION.md) and its limits.
 The installer preserves customized files and unrelated Claude settings, records
 overrides and backs up replacements. Do not use --force as an ordinary update path.
 
@@ -84,7 +92,7 @@ New installs default to standalone with `claude-standalone`. Existing installati
 without execution.json remain compatibility. To migrate explicitly:
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.2 migrate-execution --project "D:\path\to\UnityProject" --to standalone --model-profile claude-standalone --dry-run
+npx --yes --package "$NccgsArchive" nccgs migrate-execution --project "D:\path\to\UnityProject" --to standalone --model-profile claude-standalone --dry-run
 ```
 
 Inspect the dry run, then remove `--dry-run`. Omitting `--model-profile` preserves
@@ -96,7 +104,7 @@ task handling. Updating files never converts an old approval into a new one.
 Start a task session with native permissions already selected:
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.2 run --project "D:\path\to\UnityProject"
+npx --yes --package "$NccgsArchive" nccgs run --project "D:\path\to\UnityProject"
 ```
 
 New installations default to task autonomy `full`. Existing installations keep

package/UPGRADING.md

@@ -1,7 +1,7 @@
-# Upgrading NCCGS 2.0 RC
+# Upgrading NCCGS 2.0.0
 
-Current candidate: **2.0.0-rc.2** on npm **next**. `latest` remains on the stable
-release line. Pin an exact version when reproducing an installation.
+Current prepared stable package: **2.0.0**, unpublished. Preparation does not change
+npm `next` or `latest`. Use the local archive for reproducible evaluation.
 Read [release status](docs/RELEASE-STATUS.md) for what has and has not been verified.
 
 ## Choose the operation
@@ -13,9 +13,11 @@ Read [release status](docs/RELEASE-STATUS.md) for what has and has not been veri
 | Intentionally adopt standalone execution | `migrate-execution --to standalone` | Explicitly changes execution configuration; separate from updating files |
 | Resume work | `run` | Launches Claude Code with the project's configured obligations |
 
-**Published-1.3.0 upgrade qualification is pending.** The commands below document
-the supported interface; they are not evidence that this upgrade has passed.
-Try a complete copy of the project before applying an RC to active work.
+**Historical published-1.3.0 → RC3 upgrade qualification covers its tested fixture matrix.**
+See [upgrade qualification](docs/UPGRADE-QUALIFICATION.md) for scope and the RC2
+issue corrected in RC3. RC4 archive checks are recorded separately in its release
+receipts; historical results do not certify a different archive. Try a complete
+copy before applying this package to active work.
 
 ## New installation
 
@@ -24,9 +26,10 @@ Unity project with Assets, Packages and ProjectSettings. Live Unity operations
 also require the appropriate Unity Editor/CLI integration.
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.2 install --project "D:\path\to\UnityProject" --dry-run
-npx --yes nccgs@2.0.0-rc.2 install --project "D:\path\to\UnityProject"
-npx --yes nccgs@2.0.0-rc.2 doctor --project "D:\path\to\UnityProject"
+$NccgsArchive = "D:\path\to\nccgs-2.0.0.tgz"
+npx --yes --package "$NccgsArchive" nccgs install --project "D:\path\to\UnityProject" --dry-run
+npx --yes --package "$NccgsArchive" nccgs install --project "D:\path\to\UnityProject"
+npx --yes --package "$NccgsArchive" nccgs doctor --project "D:\path\to\UnityProject"
 ```
 
 New installations select standalone execution and the claude-standalone model
@@ -41,9 +44,9 @@ open task records and evidence. Stop active NCCGS sessions before applying an
 update. Do not update a frozen evaluation in place.
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.2 update --project "D:\path\to\ProjectCopy" --dry-run
-npx --yes nccgs@2.0.0-rc.2 update --project "D:\path\to\ProjectCopy"
-npx --yes nccgs@2.0.0-rc.2 doctor --project "D:\path\to\ProjectCopy"
+npx --yes --package "$NccgsArchive" nccgs update --project "D:\path\to\ProjectCopy" --dry-run
+npx --yes --package "$NccgsArchive" nccgs update --project "D:\path\to\ProjectCopy"
+npx --yes --package "$NccgsArchive" nccgs doctor --project "D:\path\to\ProjectCopy"
 ```
 
 Inspect the dry-run changes before the second command. Ordinary updates preserve
@@ -57,9 +60,9 @@ reviewed migration workflow; do not use `--force` just to make doctor green. Kee
 the project's canonical requirements and applicable gates. Reopen Claude Code
 after changing hooks, settings or managed agents.
 
-If update reports that NCCGS is not installed, use the exact RC `install` command
+If update reports that NCCGS is not installed, use the exact local-archive `install` command
 above after checking the target. Some legacy CLI messages mention `@latest`;
-that selects the stable channel and does not select this RC.
+that selects the published stable channel, not this unpublished local archive.
 
 ## Optional execution-policy migration
 
@@ -67,34 +70,35 @@ After installing/updating, migrate only when the owner intends to adopt standalo
 Review any active task's pinned obligations before changing policy.
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.2 migrate-execution --project "D:\path\to\ProjectCopy" --to standalone --model-profile claude-standalone --dry-run
+npx --yes --package "$NccgsArchive" nccgs migrate-execution --project "D:\path\to\ProjectCopy" --to standalone --model-profile claude-standalone --dry-run
 ```
 
 Inspect the result, then repeat without `--dry-run` to apply. Omit
 `--model-profile` to preserve model routes. An update alone does not perform this
 migration. Schema-1 tasks retain their original gates/history; do not relabel them
-as schema-2, reuse stale approvals or reset consumed attempts. Finish under the
-pinned policy or explicitly scope subsequent work with retained lineage/evidence.
+as schema-2, reuse stale approvals or reset consumed attempts. A changed pipeline can block resuming an old task. Finish it before upgrading,
+or explicitly scope subsequent work with retained lineage/evidence; updating or
+rolling back execution settings does not re-approve an old task.
 
 The command archives configuration under `.nccgs/backups/execution/<ID>`. To
 preview restoration of that execution migration:
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.2 migrate-execution --project "D:\path\to\ProjectCopy" --rollback "MIGRATION_UUID" --dry-run
+npx --yes --package "$NccgsArchive" nccgs migrate-execution --project "D:\path\to\ProjectCopy" --rollback "MIGRATION_UUID" --dry-run
 ```
 
 Use the actual printed UUID; remove `--dry-run` only after reviewing the preview.
 Rollback refuses changed current configuration or altered backup hashes and
 requires a compatible framework version. It restores execution configuration,
 **not a complete package downgrade**. A full recovery uses the complete project
-backup. Do not install 1.3.0 over an RC project and assume task-schema downgrade
+backup. Do not install 1.3.0 over a 2.0 project and assume task-schema downgrade
 is safe. Caught migration failures restore captured configuration; an OS kill is
 not an atomic transaction and may require manual recovery.
 
 ## Start and review work
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.2 run --project "D:\path\to\UnityProject"
+npx --yes --package "$NccgsArchive" nccgs run --project "D:\path\to\UnityProject"
 ```
 
 Use `/status` in Claude Code to inspect obligations. Use `/migrate-project` when
@@ -104,5 +108,5 @@ game quality, completion of a task or human acceptance.
 
 Existing projects that intentionally use Astra/Fable keep their configured chain.
 See [compatibility gates](.claude/nccgs/protocols/task-gates.md). Historical 1.4/1.5
-guides describe their original versions; this document governs the current RC's
-installation commands and release status.
+guides describe their original versions; this document governs the current 2.0.0 package's
+installation commands and release status.

package/VERSION

@@ -1 +1 @@
-2.0.0-rc.2
+2.0.0

package/docs/ARCHITECTURE.md

@@ -11,8 +11,9 @@ distinct decision surface, failure mode, artifact, or verification lens.
 1. **Kernel** — constitution, authority, project policy, ownership, state, closure.
 2. **Router** — domain/risk classification, model profile, context packet, execution
    graph and write ownership.
-3. **Studio roles** — twelve active core agents, with 35 optional roles in a 47-agent
-   library. Activation choices survive updates; customized files are preserved.
+3. **Studio roles** — a focused active set plus optional specialists. Counts, model
+   routes and native turn ceilings come from the [generated routing reference](../.claude/nccgs/routing.generated.md).
+   Activation choices survive updates; customized files are preserved.
 4. **Workflow modules** — 36 composable skills with eight user-facing entrypoints.
 5. **Unity operations** — unmodified official Unity Skills and Unity CLI/Pipeline.
 6. **Automation** — Node hooks for recovery, audit and safety.
@@ -20,18 +21,32 @@ distinct decision surface, failure mode, artifact, or verification lens.
 
 ## Bounded orchestration
 
-The primary Claude Code session is the sole Claude subagent orchestrator. Under the
-default astra-claude profile, Astra owns planning/documents outside that session;
-Claude executes within Astra's plan. It constructs an implementation DAG,
+The primary Claude Code session is the sole Claude subagent orchestrator. New
+installations use standalone execution: Claude Code owns intake, planning,
+documents, dispatch and reporting. It constructs an implementation DAG,
 selects the smallest complete role set, passes a context packet, assigns one writer
 per path, and merges handoffs. Studio agents do not recursively delegate.
 
 This preserves domain decomposition while preventing context-amplifying chains such
-as director → lead → engine lead → specialist. Read-only agents may run concurrently;
-overlapping writes are serialized.
+as director → lead → engine lead → specialist. The 2.0.0 operating protocol launches
+one foreground Agent call at a time and waits for its final result. The configured
+worker ceiling is not a promise of parallel dispatch. Review/analysis reserves a
+stable snapshot and cannot overlap source writers in the same project.
+
+Execution obligations are selected before models. Missing execution.json means
+compatibility; existing Astra/Fable/Product Owner gates survive updates. Explicit
+execution migration and model-profile selection are separate operations.
 
 ## Context architecture
 
+Large standalone implementation tasks can use a pinned [slice plan](TASK-SLICING.md)
+within the same task. Exact file ownership, original criterion IDs and dependency
+dispatches bound each assignment. One final integration receives the full contract;
+intermediate handoffs cannot satisfy implementation or acceptance. Independent
+review excludes every implementation contributor in the task subtree. Plans and
+revisions retain attempts and reserve capacity inside existing ancestor limits;
+they create no child task, review round or session budget.
+
 The feature contract stores approved scope. The context packet stores the current
 working-set map: source anchors and revisions, decision summaries, ownership,
 dependencies, verification, and reasons for any full-source read. Agents receive the
@@ -45,9 +60,11 @@ require reconstructing truth from chat history.
 Each catalog role has a capability class: lightweight, standard, deep, leadership,
 or review. `pipeline.json` is the routing source; the compiler generates catalog
 routes and agent frontmatter, and validation rejects drift. The default
-astra-claude profile uses Sonnet/medium for lightweight work, Opus 5.5/medium for standard work, Opus 5.5/high for deep/leadership work, and Fable/high for
-independent review. It also configures the main project session. Legacy quality,
-balanced, and inherit profiles remain available without duplicating agent prompts.
+claude-standalone profile requests Sonnet/medium for FAST, Opus/medium for STANDARD,
+Opus/high for CONTROLLED and Opus/high for independent review. Requested routes
+do not establish actual provider execution. The generated reference includes
+compatibility routes; quality, balanced and inherit profiles remain available
+without duplicating agent prompts.
 
 Legacy profiles support policy-directed fallback. The astra-claude profile instead
 blocks a required stage when its model/effort cannot be confirmed; it never labels
@@ -61,10 +78,12 @@ SHA-256 manifest makes upstream modifications visible.
 
 ## Evidence and closure
 
-For astra-claude, every code change follows risk-selected implementation -> Fable review ->
-report to Astra -> Astra check -> explicit Product Owner acceptance. The accountable implementer fixes
-findings and Fable re-reviews each changed snapshot. These gates apply to FAST and
-lean work as well. `task.mjs` enforces this sequence using snapshot hashes, immutable
+Standalone work follows scoped intake and reviewed design where required ->
+risk-selected implementation -> measured verification -> independent review ->
+report -> configured external/manual/acceptance gates. The accountable implementer
+fixes findings and an independent reviewer re-reviews changed work. Compatibility
+with astra-claude retains Fable review, Astra checking and explicit Product Owner
+acceptance. `task.mjs` enforces the selected sequence using snapshot hashes, immutable
 artifact references, runtime observations and explicit external decisions. A changed
 snapshot invalidates previous review/acceptance. Re-recording an earlier stage clears
 downstream stages while retaining history. Hooks supplement the task gate; they are
@@ -75,15 +94,23 @@ Task risk selects a frozen implementation route and a review budget from
 CONTROLLED/deep/3. Valid review records consume rounds even for negative verdicts.
 Re-recording implementation preserves the counter. A PASS at the limit can proceed;
 otherwise exhaustion stops the task until an explicit external, reasoned extension.
-Context and elapsed-time budgets are advisory rather than executable runtime caps.
+Planning estimates are advisory. Standalone dispatch and configured worker
+time/cost limits govern admission using observed telemetry; they do not measure
+account-wide usage or interrupt a provider request already running.
 
 Requested model settings and observed runtime values are separate fields. Native
 events can report the resolved model and fallback history; absent observed effort
 stays unknown until supporting runtime evidence is imported.
 
-Every workflow dispatcher loads exactly one `references/astra.md` or
-`references/legacy.md`. Risk affects the extent of verification, never the mandatory
-Fable gate in the Astra profile. Legacy profiles retain their risk-based review.
+Every workflow dispatcher selects execution policy first. Standalone loads the
+shared standalone protocol; design entrypoints also load the design lifecycle.
+Compatibility loads exactly one Astra or legacy reference. Risk selects scope and
+model routing; all standalone tiers retain independent review.
+
+Handoff helpers generate bounded prompts and PARTIAL drafts, validate structure
+before completion, and import a completed reviewer's pinned result through the
+existing record gate. They never supply provider evidence, change a verdict,
+close the task, or reset budgets. See [handoff operations](HANDOFF-AUTOMATION.md).
 
 One implementer remains accountable for the task. The scout closes a named factual
 gap; specialist reviewers add distinct risk coverage. Neither is a compulsory

package/docs/BOUNDED-REPAIR.md

@@ -1,11 +1,80 @@
-# Bounded source repair — 2.0 RC
+# Bounded repair — NCCGS 2.0.0
 
 Read the [complete bounded repair protocol](../.claude/nccgs/protocols/bounded-repair.md).
 It is installed in every project at `.claude/nccgs/protocols/bounded-repair.md`,
-alongside the guards that enforce it. The packet template is installed at
-`.nccgs/templates/repair-packet.json`.
+alongside the guards that enforce it. The stable package is prepared but unpublished; existing
+reservations keep their pinned policy. New Editor steps use a single `eval` body
+with fully qualified C# types. The runner checks all loaded scenes immediately
+before the body in the same Editor call. Dirty named, additive or untitled scenes
+block execution without saving/discarding user work. The failed attempt remains
+recorded; resolving the scene does not replay or refund it. The owner resolves
+unsaved work before a new authorized repair packet.
 
-The repair worker receives an already-chosen correction for 1–4 exact source files,
-with durable work/read limits and a separate handoff allowance. The coordinator
-owns verification after return. Local fixtures establish framework behavior;
-fresh real Claude Code/Unity acceptance is still required.
+Choose one template after diagnosing the recorded failure:
+
+| Template under `.nccgs/templates/` | Use |
+|---|---|
+| `repair-packet.json` | Unchanged small source edit: 1–4 existing files, 12 work calls. |
+| `repair-unity-code.json` | 1–8 exact code files including new regression tests; 24 work calls. Import new metadata through a pinned Editor step before returning. |
+| `repair-unity-editor.json` | 1–8 exact scenes/prefabs/assets through pinned Editor commands; 20 work calls. No raw serialized-file or metadata edits. |
+
+Each profile has a separate handoff allowance. Unity packets bind file operations,
+Editor commands, timeouts and original GUIDs; they detect changes outside scope.
+An uncertain Editor call retains exclusive ownership until external reconciliation.
+Attempts and original receipts remain in history; no automatic retry or refund.
+
+Flow: recorded failure → chosen packet → reserve/dispatch-prompt → bounded edits
+and import/save → native completion → coordinator checks → independent re-review
+→ existing acceptance gates. An Editor receipt never substitutes for compile,
+EditMode, PlayMode, runtime, build or manual checks required by the contract.
+
+Local fixtures establish framework behavior only. On 2026-10-27, an actual
+Claude Code/Unity regression case exercised a schema-2 `unity-code` repair of one
+existing file after a disclosed post-review fault caused a real PlayMode failure.
+Fresh checks and a second independent unconditional PASS allowed normal closure,
+with the original criteria, history, GUID and total budgets retained. See
+[qualification scope](RELEASE-STATUS.md). This known-component case does not qualify
+new-file imports, `unity-editor` operations or scene/prefab repair; those still
+need fresh native qualification against the installed Unity CLI command catalog.
+
+A subsequent new-script/scene/prefab attempt on 2026-10-27 stopped before independent
+design review: the native coordinator pinned a per-worker `maxCostUsd` ceiling,
+but the completed designer's cost was unknown. The reservation guard correctly
+refused the reviewer. The attempt spent USD 2.3247276 of its shared USD 12 envelope;
+no native repair or Unity acceptance was performed. Its original cap, partial
+report and history remain intact. Session cost cannot replace missing worker cost
+telemetry. The subsequent source fix admits a separately recorded, exclusive
+supervised-session ceiling only when prior native costs plus its allowance fit
+the unchanged cap and cover all started worker sessions;
+see [telemetry and pinned limits](../.claude/nccgs/protocols/standalone-gates.md).
+The preserved attempt was then continued under that unchanged aggregate cap. Actual
+Claude workers created the script, imported Unity-generated metadata, and repaired
+the existing prefab and connected scene through three pinned Editor operations.
+The initial 16 PASS/3 FAIL and intermediate 17 PASS/2 FAIL EditMode runs remain;
+the intermediate run proves the script worked before asset repair. All five final
+checks passed: 19/19 EditMode, 8/8 PlayMode, and 28 criteria/385 measured assertions.
+The final delivery review did not run: aggregate native list-cost reached
+USD 11.589259/12 and the coordinator stopped with insufficient review allowance.
+The task remains PARTIAL and unclosed, with no recorded implementation approval
+or invented reviewer verdict. This establishes observed repair/test execution,
+not full qualification of the new-script/scene/prefab delivery lifecycle.
+
+A separately authorized case on 2026-10-28 pinned a USD4/15-minute final-review
+reserve inside a new USD12/75-minute total before any native work. The same
+new-script/import and prefab/scene repair path then reached a fresh independent
+unconditional PASS and normal closure: all five final checks, 19/19 EditMode,
+8/8 PlayMode and the unchanged 28 criteria/385 assertions passed. It spent
+USD9.816888 in 22 min 35 s, with 5 dispatches and 2 independent reviewers. The
+single allowed automatic continuation and its work-phase handoff stop remain
+recorded; no failed attempt or consumed allowance was erased. The old PARTIAL
+case remains unchanged; combined old/new cost is USD21.406147. This is scoped
+qualification of the disclosed warmed fixture and exact pinned operations,
+not arbitrary scene editing or cold-start behavior. See the findings and limits
+in [release status](RELEASE-STATUS.md) and the
+[protected allocation procedure](PHASE-1-OPERATIONS.md#protect-the-final-independent-review-before-starting-work).
+
+## External Editor stop handoff
+
+Publish the original operator start/shutdown/stop receipts into reviewer-readable
+project evidence before handing off. Preserve sealed cases through a separate
+addendum; never recreate or overwrite historical process facts. See [Editor lifecycle evidence](EDITOR-SESSION-EVIDENCE.md).

package/docs/EDITOR-SESSION-EVIDENCE.md

@@ -0,0 +1,52 @@
+# Editor lifecycle evidence visible to the reviewer
+
+An external operator may own a Unity Editor while native workers run bounded
+operations. Keep ownership with that operator. Before handing the task to review,
+publish the operator's existing start, graceful shutdown command and settled stop
+receipts under the project's `.nccgs/evidence/editor-control/` directory.
+An external artifact directory alone is insufficient when the reviewer can only
+read the project tree.
+
+Use the installed helper from the external operator's existing harness:
+
+```js
+import { publishEditorSessionEvidence } from './.claude/nccgs/tools/editor-session-evidence.mjs';
+const reference = publishEditorSessionEvidence(project, {
+  sourceProject: project,
+  startFile: absoluteStartReceipt,
+  stopFile: absoluteStopReceipt,
+  shutdownFile: absoluteShutdownCommandReceipt
+});
+```
+
+The supported receipt format is the Windows owned-Editor harness format: start
+has `at`, `project`, and `identity` (`pid`, `windowsJob`, `groupName`); stop has the
+same identity, `state: "dead"`, `forced: false`, and `result: {code: 0, signal: null}`.
+The shutdown command receipt has `at`, fixed Unity `args` with the exact
+`--project-path` and `UnityEditor.EditorApplication.Exit(0)`, its own owned CLI
+identity, `treeState: "dead"`, `code: 0`, and `signal: null`.
+
+The helper checks ownership/project consistency, event order and reported normal
+settlement. It copies the three original files byte for byte, adds SHA-256
+references, and returns the reference to an immutable receipt bundle. Existing
+bundle IDs cannot be overwritten. Include that reference in the coordinator's
+review handoff alongside the ordinary managed-check receipts.
+
+This publisher performs no process operation or live process probe. The operator
+must still verify its owned group is dead using the existing process manager.
+Forced, failed, live or uncertain stops retain their original evidence and cannot
+be published as a normal stop by this helper. A copied receipt is not a new stop,
+native worker execution, a reviewer verdict, or acceptance evidence for gameplay.
+Untrusted receipt contents never authorize commands. Other producer formats need
+an explicit adapter and qualification; do not invent observations to fit this one.
+
+When the original case is already sealed, publish to a separate addendum project
+and pass the original absolute `sourceProject`. The bundle marks itself as a
+historical import. Keep the original task, findings, costs and hashes untouched;
+a fresh independent reviewer assesses the addendum without rewriting the old
+verdict. Do not restart the Editor merely to manufacture a replacement receipt.
+
+For future runs, publish after every externally controlled normal stop, including
+the stop after resolving an unsaved-scene refusal, before the next native handoff.
+This evidence step does not grant save/discard authority, expand worker scope,
+waive any check, or enlarge the original total budget.

package/docs/HANDOFF-AUTOMATION.md

@@ -0,0 +1,144 @@
+# Handoff preparation, validation and review recording
+
+These helpers are included in the prepared, unpublished 2.0.0 stable package.
+Package preparation does not establish fresh Claude Code execution. They reduce mechanical copying within the
+existing standalone workflow. Existing task gates, native completion, measured
+acceptance, independent review, history and budgets remain authoritative.
+
+## Prepare a registered assignment
+
+Reserve the worker normally, including fresh `handoffPaths`. Read-only paths must
+already be declared in the task's `analysisArtifacts`. Then run one plain command:
+
+```text
+node .claude/nccgs/tools/task.mjs dispatch-prompt --id TASK --dispatch DISPATCH_ID
+```
+
+For implementation, analysis and review, the response includes the Agent prompt,
+role and PARTIAL handoff templates with task/dispatch/contract identities. It reads
+the existing reservation and does not write files, launch a worker, reserve another
+attempt or grant source ownership. Give the returned prompt to that foreground
+Agent. Add only bounded assignment context consistent with the contract. The
+worker writes its draft early and owns its contents. No declared handoff is created
+automatically; a missing handoff still fails completion.
+
+A review template begins BLOCKED with an explicit unfinished-review condition.
+Only the reviewer replaces the draft with actual findings and its own verdict.
+Review policy, objective checks and source-backed reasoning are still required.
+Bounded repair uses its injected packet and separate tool allowances. The handoff
+helpers do not grant repair permissions; see [typed Unity repair](BOUNDED-REPAIR.md)
+for the separate, opt-in Editor operation workflow.
+
+## Validate before returning
+
+After writing the handoff, a running non-repair worker may execute this one fixed,
+read-only operation for its own task, dispatch and declared file:
+
+```text
+node .claude/nccgs/tools/task.mjs handoff-validate --id TASK --dispatch DISPATCH_ID --file .nccgs/evidence/analysis/TASK-review.md
+```
+
+The coordinator can also call it. It checks the current contract/source, declared
+path and marker. Review handoffs additionally check JSON fields, finding enums,
+design acceptance impacts and the prohibition on conditional PASS. A PARTIAL draft
+can be structurally VALID with `complete: false`; VALID is never acceptance or a
+claim that review finished. General handoff inspection checks structure only,
+not completeness of prose or evidence.
+
+This is the only worker shell exception added here. Extra flags, duplicate flags,
+forwarded commands, another dispatch/path and shell composition are rejected.
+Repair workers do not gain this validation shell exception; typed Unity packets
+may separately permit the fixed repair-editor wrapper. Their coordinator can
+inspect the captured handoff after return. Validation changes no file or ledger,
+and consumes no new dispatch or review round. Native tool/turn usage still applies.
+
+Fix structural errors while the same worker owns its draft. Once the invocation
+ends, its captured handoff is immutable. Failed/incomplete attempts retain their
+costs and quotas and still need an eligible fresh attempt to continue.
+
+## Record the completed review
+
+For tasks with `reviewContractRequired: true`, the coordinator can import the
+completed reviewer's pinned handoff without copying its JSON into another file:
+
+```text
+node .claude/nccgs/tools/task.mjs record-review --id TASK --dispatch DISPATCH_ID --file .nccgs/evidence/analysis/TASK-review.md
+```
+
+The command derives runtime identity, source snapshot and evidence from the
+completed reservation, and copies verdict, criteriaMet, findings and conditions
+exactly from the pinned JSON block. It calls the existing `record --stage review`
+gate. It never edits the reviewer document or chooses a verdict. Missing runtime,
+same-agent review, stale source, tampered evidence, unproven criteria, exhausted
+budgets and previously consumed dispatches still reject recording. A complete
+negative verdict can be recorded honestly. A successful record appends the usual
+history and consumes the usual review round; rejected recording does not refund
+the already-spent dispatch. Repeating the command does not record a second round.
+
+Reporting, configured external review, manual acceptance and `task close` remain
+separate. The helper never closes a task. Older policies without a reviewer-owned
+JSON contract keep their original record workflow and are not migrated by import.
+
+## Deterministic protected-work handoff
+
+After a supervised implementation invocation ends, the work phase can record a
+PARTIAL report without spending another Claude continuation solely on reporting.
+This requires a pinned final-review allocation, complete native session cost,
+no active/uncertain worker or pending job, a current implementation record made
+within this run after the latest receipt, review readiness and all automatic
+measured criteria passing. Stale, failed or incomplete evidence keeps the ordinary
+bounded continuation/blocked path. Existing coordinator reports are preserved.
+
+The report is marked **supervisor-work-handoff**, identifies its run and uses the
+normal report/history writer. It means only “awaiting independent review”. It
+cannot create a reviewer verdict, close the task, satisfy manual/external gates,
+refund attempts or enlarge any cap. Recovery reuses the recorded handoff.
+This automation is disabled for analysis/design and final-review phases.
+
+## Configuration and validation limits
+
+Read [generated routing and native ceilings](../.claude/nccgs/routing.generated.md)
+and check the actual installed role/session override before dispatch. A prompt's
+turn count cannot change native capacity. Run source checks with `npm run
+policy:check`, `npm run validate` and `npm test`. Fixture tests are synthetic.
+The controlled Claude Code/Unity case on 2026-10-27 exercised generated dispatch
+prompts, worker handoffs and exact independent review import; see
+[qualification scope](RELEASE-STATUS.md). It does not establish general efficiency.
+
+Update only through the documented [upgrade workflow](../UPGRADING.md). Do not
+install new source into a frozen evaluation or rewrite an existing source/input
+pin to carry an old approval forward.
+
+External operator Editor stop receipts must be visible in the project before
+review. See [the evidence publication procedure](EDITOR-SESSION-EVIDENCE.md).
+## Native returned text for read-only handoffs
+
+An analysis or independent review reservation may opt into
+`"handoffTransport": "native-result"` with exactly one fresh `handoffPaths` entry
+already declared in the task's `analysisArtifacts`. Use `dispatch-prompt` to supply
+the assignment. The worker returns the complete Markdown document as its sole
+final text block, without an outer code fence, and does not write that path.
+This supports native clients that require read-only subagents to return findings.
+
+The correlated foreground PostToolUse hook copies the exact UTF-8 text (maximum
+256 KiB) using exclusive creation and pins its hash in the native observation.
+Session, tool call, agent identity and unchanged source snapshot must match.
+Missing, multiple, oversized, incomplete or ambiguous native output fails closed;
+existing files cannot be replaced. The hook never supplies a COMPLETE marker or
+edits a review verdict. Existing file transport and old dispatches are unchanged.
+
+The coordinator still records analysis with current checks, or imports the exact
+review using `record-review`. Required measured acceptance, independent identity,
+conditions, review limits and closure gates remain mandatory. A captured report is
+not automatic acceptance. A historical failed dispatch stays failed; use a fresh
+authorized attempt and preserve its lineage and spent allowances.
+
+Audit work must use the task's selected model route, just like implementation.
+For a FAST audit use a Sonnet analysis role; an Opus role does not satisfy that
+route merely because its handoff was captured. Classify broader runtime/governance
+changes with their actual scope before launching work. Audit tasks with a pinned
+review reserve use `work` for analysis and `final-review` for their independent
+review; that reserve cannot dispatch another analyst or an implementation worker.
+Plan/design reviews retain their work-phase rules and cannot consume the final
+delivery reserve.
+