nccgs 2.0.0 → 2.1.1

package/UPGRADING.md

@@ -1,112 +1,130 @@
-# Upgrading NCCGS 2.0.0
-
-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
-
-| Situation | Operation | Effect |
-|---|---|---|
-| No NCCGS installation | `install` | Adds framework and initial project policy |
-| 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 |
-
-**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
-
-Requirements: Node.js 18+, Claude Code with access to the selected models, and a
-Unity project with Assets, Packages and ProjectSettings. Live Unity operations
-also require the appropriate Unity Editor/CLI integration.
-
-```powershell
-$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
-profile. External review is off by default; manual/project acceptance obligations
-still apply when required. New task autonomy defaults to full, activated by `run`;
-OS restrictions, explicit deny rules and evidence/destructive-action guards remain.
-
-## Update an existing installation
-
-Back up the complete project first, including .claude, .nccgs, source, settings,
-open task records and evidence. Stop active NCCGS sessions before applying an
-update. Do not update a frozen evaluation in place.
-
-```powershell
-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
-model profile, execution policy and project customizations. A project with no
-execution.json retains compatibility obligations; selecting a model profile alone
-does not migrate its execution policy. Existing autonomy settings are preserved.
-
-Changed or intentionally missing managed files are recorded in
-`.nccgs/framework-overrides.json`. Resolve pending overrides through the project's
-reviewed migration workflow; do not use `--force` just to make doctor green. Keep
-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 local-archive `install` command
-above after checking the target. Some legacy CLI messages mention `@latest`;
-that selects the published stable channel, not this unpublished local archive.
-
-## Optional execution-policy migration
-
-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 --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. 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 --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 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 --package "$NccgsArchive" nccgs run --project "D:\path\to\UnityProject"
-```
-
-Use `/status` in Claude Code to inspect obligations. Use `/migrate-project` when
-the installer/doctor reports project migration or override review is required.
-Installation and doctor checks prove package/setup integrity, not Claude execution,
-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 2.0.0 package's
-installation commands and release status.
+# Upgrading NCCGS 2.1.1
+
+Current source: **2.1.1**, unpublished. Version 2.0.0 was published on 2026-10-28.
+The registry already contains a different `nccgs@2.1.0` tarball. This prepared
+2.1.1 package derives from the accepted local R11 r05 qualification; it does not
+replace or retroactively qualify the registry artifact. No npm tags are changed.
+
+Preparation does not change npm tags. Use the local 2.1.1 archive for evaluation.
+Read [release status](docs/RELEASE-STATUS.md) for what has and has not been verified.
+
+## Choose the operation
+
+| Situation | Operation | Effect |
+|---|---|---|
+| No NCCGS installation | `install` | Adds framework and initial project policy |
+| 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 |
+
+**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
+
+Requirements: Node.js 18+, Claude Code with access to the selected models, and a
+Unity project with Assets, Packages and ProjectSettings. Live Unity operations
+also require the appropriate Unity Editor/CLI integration.
+
+```powershell
+$NccgsArchive = "D:\path\to\nccgs-2.1.1.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
+profile. External review is off by default; manual/project acceptance obligations
+still apply when required. New task autonomy defaults to full, activated by `run`;
+OS restrictions, explicit deny rules and evidence/destructive-action guards remain.
+
+## Update an existing installation
+
+Back up the complete project first, including .claude, .nccgs, source, settings,
+open task records and evidence. Stop active NCCGS sessions before applying an
+update. Do not update a frozen evaluation in place.
+
+```powershell
+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
+model profile, execution policy and project customizations. A project with no
+execution.json retains compatibility obligations; selecting a model profile alone
+does not migrate its execution policy. Existing autonomy settings are preserved.
+
+Changed or intentionally missing managed files are recorded in
+`.nccgs/framework-overrides.json`. Resolve pending overrides through the project's
+reviewed migration workflow; do not use `--force` just to make doctor green. Keep
+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 local-archive `install` command
+above after checking the target. Some legacy CLI messages mention `@latest`;
+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.1 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 --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. 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 --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 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 --package "$NccgsArchive" nccgs run --project "D:\path\to\UnityProject"
+```
+
+Use `/status` in Claude Code to inspect obligations. Use `/migrate-project` when
+the installer/doctor reports project migration or override review is required.
+Installation and doctor checks prove package/setup integrity, not Claude execution,
+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 2.1.1 package's
+installation commands and release status.
+
+## R07 CLI-only working candidate (unpublished)
+
+The Unity CLI-only transport boundary now applies at launch, normal and repair tool admission, and project hooks. A strict empty MCP configuration is the default; separately approved non-Unity configurations remain explicit. Retained supervised runs without strict MCP isolation are refused before launch and without rewriting original run/cost/dispatch records. Start a properly authorized fresh continuation using the existing task/history/budget; never reset quotas to pass. No global configuration or game project is migrated automatically.
+
+This working candidate retains the R06 completion/returned-handoff repairs and shared Graphify consumer. Frozen R03/R04/R06 records remain unchanged. Native scoped qualification and human acceptance are separate; no npm tag is changed.
+
+R07 review repair: Claude Code declares its MCP-config option variadic. The one validated config is therefore placed at argv end or immediately before the explicit option terminator, preserving positional prompts and preventing an unchecked second config. Recovery requires that canonical boundary without rewriting retained state. Ordinary Claude/Codex Unity MCP registration is denied; non-Unity community server/method names remain available. Provider instruction-pattern warnings remain fail-closed; qualification handoffs describe settings in prose instead of reproducing configuration JSON.

package/VERSION

@@ -1 +1 @@
-2.0.0
+2.1.1

package/docs/ARCHITECTURE.md

@@ -1,131 +1,131 @@
-# NCCGS architecture
-
-## Design objective
-
-NCCGS optimizes correctness, specialization, context efficiency, recoverability, and
-evidence. File or agent count is not an objective. A component exists when it owns a
-distinct decision surface, failure mode, artifact, or verification lens.
-
-## Layers
-
-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** — 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.
-7. **Evaluation** — structural validation and executable behavioral tests.
-
-## Bounded orchestration
-
-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. 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
-packet path and exact responsibility rather than copies of every canonical document.
-
-State, packets, and handoffs are file-backed so compaction and session restarts do not
-require reconstructing truth from chat history.
-
-## Model architecture
-
-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
-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
-an inherited model's output as Fable review or the selected implementation route.
-
-## Unity boundary
-
-NCCGS does not copy Unity API/CLI procedures into agent prompts. Studio roles own
-product and technical intent; official Unity Skills own operation mechanics. The
-SHA-256 manifest makes upstream modifications visible.
-
-## Evidence and closure
-
-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
-not a security sandbox. There is no automatic cross-app transport.
-
-Task risk selects a frozen implementation route and a review budget from
-`contract.taskTiers`: FAST/lightweight/2 rounds, STANDARD/standard/3, or
-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.
-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 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
-ritual. Approved scope and evidence determine the stopping point: once criteria
-and relevant checks pass without actionable blockers, hand off. New checks require
-changed inputs, failures, or new evidence; subjective questions require a playable
-Product Owner test instead of indefinite model debate.
-
-One canonical closure record links existing project artifacts. `lean`, `linked`, and
-`strict` policies determine what blocks DONE. Waivers are item-specific and retain
-Product Owner authority.
-
-## Extension rules
-
-Add a role only for a distinct domain contract. Add a workflow when a repeated
-sequence, gate, or artifact benefits from independent discovery and testing. Put
-conditional detail in references. Do not modify official Unity Skills for local
-policy, and do not hard-code one project's paths in framework files.
+# NCCGS architecture
+
+## Design objective
+
+NCCGS optimizes correctness, specialization, context efficiency, recoverability, and
+evidence. File or agent count is not an objective. A component exists when it owns a
+distinct decision surface, failure mode, artifact, or verification lens.
+
+## Layers
+
+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** — 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.
+7. **Evaluation** — structural validation and executable behavioral tests.
+
+## Bounded orchestration
+
+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. 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
+packet path and exact responsibility rather than copies of every canonical document.
+
+State, packets, and handoffs are file-backed so compaction and session restarts do not
+require reconstructing truth from chat history.
+
+## Model architecture
+
+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
+claude-standalone profile requests Sonnet/high for FAST, Opus/high for STANDARD,
+Opus/xhigh for CONTROLLED/leadership and Fable/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
+an inherited model's output as Fable review or the selected implementation route.
+
+## Unity boundary
+
+NCCGS does not copy Unity API/CLI procedures into agent prompts. Studio roles own
+product and technical intent; official Unity Skills own operation mechanics. The
+SHA-256 manifest makes upstream modifications visible.
+
+## Evidence and closure
+
+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
+not a security sandbox. There is no automatic cross-app transport.
+
+Task risk selects a frozen implementation route and a review budget from
+`contract.taskTiers`: FAST/lightweight/2 rounds, STANDARD/standard/3, or
+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.
+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 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
+ritual. Approved scope and evidence determine the stopping point: once criteria
+and relevant checks pass without actionable blockers, hand off. New checks require
+changed inputs, failures, or new evidence; subjective questions require a playable
+Product Owner test instead of indefinite model debate.
+
+One canonical closure record links existing project artifacts. `lean`, `linked`, and
+`strict` policies determine what blocks DONE. Waivers are item-specific and retain
+Product Owner authority.
+
+## Extension rules
+
+Add a role only for a distinct domain contract. Add a workflow when a repeated
+sequence, gate, or artifact benefits from independent discovery and testing. Put
+conditional detail in references. Do not modify official Unity Skills for local
+policy, and do not hard-code one project's paths in framework files.