nccgs 2.0.0-rc.3 → 2.1.0

package/README.md

@@ -1,31 +1,41 @@
 # NCCGS — New Claude Code Game Studio
 
-**2.0.0-rc.3** 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.1.0** is the unpublished next package for standalone game-development
+orchestration in **Claude Code**. It adds reversible project uninstallation;
+the published **2.0.0** archive remains unchanged. Local preparation moves no npm tags.
+It retains 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), [uninstallation](docs/UNINSTALL.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. Published-1.3.0 upgrade scope is documented in
-[upgrade qualification](docs/UPGRADE-QUALIFICATION.md). 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).
+The exact 2.0.0 archive subsequently passed its scoped native Unity qualification
+and was published on 2026-10-28. Frozen release receipts retain its tests and
+independent reviews. The new 2.1.0 uninstaller receives local filesystem/CLI tests;
+that does not claim another Claude Code/Unity run. The first independent maintenance
+review required four fixes; this candidate adds those fixes and awaits qualification
+of its exact archive, including a fresh independent review. Earlier verdicts remain
+unchanged in their separate receipts.
+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
 
@@ -64,19 +74,22 @@ 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 local 2.1.0 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.3 install --project "D:\path\to\UnityProject" --dry-run
-npx --yes nccgs@2.0.0-rc.3 install --project "D:\path\to\UnityProject"
-npx --yes nccgs@2.0.0-rc.3 doctor --project "D:\path\to\UnityProject"
+$NccgsArchive = "D:\path\to\nccgs-2.1.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
+Before 2.1.0 publication, use this local archive. Published nccgs@2.0.0 does not
+include the uninstall command. 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.
@@ -85,7 +98,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.3 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
@@ -97,7 +110,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.3 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
@@ -132,6 +145,23 @@ Independent review uses Opus/high. These aliases are requested routes. Real Clau
 model resolution and provider access must be verified in the target session.
 Historical `astra-claude` routes remain available under compatibility execution.
 
+## Remove NCCGS when it is no longer needed
+
+Close Claude Code sessions, then preview and apply from an external terminal:
+
+```powershell
+npx --yes --package "$NccgsArchive" nccgs uninstall --project "D:\path\to\UnityProject" --dry-run
+npx --yes --package "$NccgsArchive" nccgs uninstall --project "D:\path\to\UnityProject"
+```
+
+This also supports an existing 2.0.0 installation without updating it first.
+Game source, customized files and `.nccgs` history/budgets remain. The command
+removes unchanged managed files and exact framework hooks/imports, saves a backup
+and refuses active or uncertain work. Use `uninstall --rollback ID` to restore
+that backup when no later edits conflict. Shared permission/model settings stay
+because their ownership was not recorded by earlier installers.
+See [details and recovery](docs/UNINSTALL.md).
+
 ## Maintainer verification and limits
 
 These commands run from a source/package checkout. They are not extra steps for

package/UPGRADING.md

@@ -1,7 +1,7 @@
-# Upgrading NCCGS 2.0 RC
+# Upgrading NCCGS 2.1.0
 
-Current candidate: **2.0.0-rc.3** on npm **next**. `latest` remains on the stable
-release line. Pin an exact version when reproducing an installation.
+Current source: **2.1.0**, unpublished. Version 2.0.0 was published on 2026-10-28.
+Preparation does not change npm tags. Use the local 2.1.0 archive for evaluation.
 Read [release status](docs/RELEASE-STATUS.md) for what has and has not been verified.
 
 ## Choose the operation
@@ -12,10 +12,14 @@ Read [release status](docs/RELEASE-STATUS.md) for what has and has not been veri
 | Existing NCCGS installation | `update` | Updates managed files; preserves project-owned policy and customizations |
 | 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 |
+| Stop using NCCGS in this project | `uninstall` | Removes unchanged framework files/hooks; retains source, customizations and history |
+| Undo removal | `uninstall --rollback ID` | Restores verified backup bytes, refusing later edits |
 
-**Published-1.3.0 upgrade qualification is covered for the tested fixture matrix.**
+**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. Try a complete copy before applying an RC to active work.
+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 +28,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.3 install --project "D:\path\to\UnityProject" --dry-run
-npx --yes nccgs@2.0.0-rc.3 install --project "D:\path\to\UnityProject"
-npx --yes nccgs@2.0.0-rc.3 doctor --project "D:\path\to\UnityProject"
+$NccgsArchive = "D:\path\to\nccgs-2.1.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 +46,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.3 update --project "D:\path\to\ProjectCopy" --dry-run
-npx --yes nccgs@2.0.0-rc.3 update --project "D:\path\to\ProjectCopy"
-npx --yes nccgs@2.0.0-rc.3 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,17 +62,21 @@ 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
 
+For removal instead of migration, use [uninstall and recovery](docs/UNINSTALL.md).
+The 2.1.0 CLI can remove an existing 2.0.0 installation directly. Removing or
+reinstalling never resets prior task, review, acceptance or budget obligations.
+
 After installing/updating, migrate only when the owner intends to adopt standalone.
 Review any active task's pinned obligations before changing policy.
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.3 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
@@ -81,21 +90,21 @@ The command archives configuration under `.nccgs/backups/execution/<ID>`. To
 preview restoration of that execution migration:
 
 ```powershell
-npx --yes nccgs@2.0.0-rc.3 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.3 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
@@ -105,5 +114,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
+guides describe their original versions; this document governs the current 2.1.0 package's
 installation commands and release status.

package/VERSION

@@ -1 +1 @@
-2.0.0-rc.3
+2.1.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.