nccgs 2.1.0 → 2.1.1

package/docs/PROJECT-POLICY.md

@@ -1,94 +1,94 @@
-# Project policy
-
-`.nccgs/project.yaml` adapts NCCGS to one project. Keep generic framework behavior out
-of this file; record only choices that change routing, authority, ownership, context,
-verification, closure, or Unity execution for the project.
-
-## Required decisions
-
-- project stage and platforms;
-- enabled departments and bounded orchestration;
-- execution policy and external/manual acceptance obligations;
-- `claude-standalone`, `astra-claude`, `quality`, `balanced`, or `inherit` model profile and fallback policy;
-- canonical sources for product, design, architecture, planning, art, narrative,
-  audio, and release;
-- protected/user-owned/generated paths and hand-tuned settings;
-- architecture constraints, packages and services;
-- Unity version, render/UI/input systems and CLI/Pipeline preference;
-- test/build/runtime baselines and recurring Product Owner gates;
-- closure mode, linked artifacts, completion rules and waiver policy.
-
-## Model policy
-
-New installations use standalone execution with `claude-standalone`: Sonnet/medium
-for FAST, Opus/medium for STANDARD, Opus/high for CONTROLLED and Opus/high for
-independent review. These are requested aliases and effort, not runtime observations.
-Execution policy lives separately in `.nccgs/execution.json`; changing a model
-profile does not remove task gates or migrate compatibility execution.
-
-Existing compatibility projects selecting `astra-claude` retain Astra planning,
-Fable review and their configured approval chain. See the
-[compatibility protocol](../.claude/nccgs/protocols/astra-claude.md). Ordinary
-updates preserve existing selections and obligations.
-
-Use `quality` when result quality is primary and all model tiers are available. Use
-`balanced` when leadership coordination does not need Opus by default. Use `inherit`
-when subscription/context compatibility or explicit user control is more important
-than automatic routing.
-
-The `models.overrides` field is reserved; the configurator does not apply it. Routing
-is compiled from `.claude/nccgs/pipeline.json`. The astra-claude profile intentionally
-pins task routes through `contract.taskTiers`; changing required stage models or risk policy is a Product Owner decision.
-
-For the Astra profile, map the checks, artifacts and manual gates below into
-`.nccgs/gates.json` and pin its `policySha256` to this project policy. Task-specific
-requirements may add obligations. The executable manifest does not automatically
-translate YAML conditions: Astra must preserve and map all existing safeguards.
-See [task gates](../.claude/nccgs/protocols/task-gates.md) for evidence formats.
-
-`contract.taskTiers` selects each task's implementation class and review limit.
-Compatibility `task init --risk` defaults to STANDARD; standalone intake uses its
-classifier and explicit risk evidence. FAST allows two recorded reviews and
-STANDARD/CONTROLLED allow three. Re-recording implementation does not reset the
-counter. Only an explicit external `task extend-review` decision adds rounds.
-An exhausted budget is not acceptance. Planning estimates do not extend configured
-dispatch/session/check limits. Read the active execution policy and actual ledger.
-
-## Canonical sources and context
-
-Map existing documents where they live. Workflows address semantic roles, not fixed
-folder names. Context packets refer to exact sections and source revisions; they do
-not replace canonical documents.
-
-## Closure example
-
-```yaml
-closure:
-  mode: strict
-  canonical_record: ".nccgs/closures/{feature_id}.md"
-  required_artifacts:
-    - id: implementation-report
-      type: report
-      path_pattern: "project-docs/reports/{feature_id}*.md"
-      required: true
-      completion_rule: exists
-    - id: implementation-register
-      type: register_entry
-      path_pattern: "project-docs/implementation-register.md"
-      required: true
-      completion_rule: entry_present
-    - id: deletion-gate
-      type: checklist
-      path_pattern: "project-docs/gates/{feature_id}*.md"
-      required: true
-      completion_rule: all_conditions
-      expected_conditions: 7
-  done_requires:
-    - implementation
-    - objective_verification
-    - required_artifacts
-    - applicable_manual_gates
-```
-
-Start migration with the strongest live safeguard and weaken it only through an
-explicit Product Owner decision after the replacement has proven its purpose.
+# Project policy
+
+`.nccgs/project.yaml` adapts NCCGS to one project. Keep generic framework behavior out
+of this file; record only choices that change routing, authority, ownership, context,
+verification, closure, or Unity execution for the project.
+
+## Required decisions
+
+- project stage and platforms;
+- enabled departments and bounded orchestration;
+- execution policy and external/manual acceptance obligations;
+- `claude-standalone`, `astra-claude`, `quality`, `balanced`, or `inherit` model profile and fallback policy;
+- canonical sources for product, design, architecture, planning, art, narrative,
+  audio, and release;
+- protected/user-owned/generated paths and hand-tuned settings;
+- architecture constraints, packages and services;
+- Unity version, render/UI/input systems and CLI/Pipeline preference;
+- test/build/runtime baselines and recurring Product Owner gates;
+- closure mode, linked artifacts, completion rules and waiver policy.
+
+## Model policy
+
+New installations use standalone execution with `claude-standalone`: Sonnet/high
+for FAST, Opus/high for STANDARD, Opus/xhigh for CONTROLLED/leadership and Fable/high for
+independent review. These are requested aliases and effort, not runtime observations.
+Execution policy lives separately in `.nccgs/execution.json`; changing a model
+profile does not remove task gates or migrate compatibility execution.
+
+Existing compatibility projects selecting `astra-claude` retain Astra planning,
+Fable review and their configured approval chain. See the
+[compatibility protocol](../.claude/nccgs/protocols/astra-claude.md). Ordinary
+updates preserve existing selections and obligations.
+
+Use `quality` when result quality is primary and all model tiers are available. Use
+`balanced` when leadership coordination does not need Opus by default. Use `inherit`
+when subscription/context compatibility or explicit user control is more important
+than automatic routing.
+
+The `models.overrides` field is reserved; the configurator does not apply it. Routing
+is compiled from `.claude/nccgs/pipeline.json`. The astra-claude profile intentionally
+pins task routes through `contract.taskTiers`; changing required stage models or risk policy is a Product Owner decision.
+
+For the Astra profile, map the checks, artifacts and manual gates below into
+`.nccgs/gates.json` and pin its `policySha256` to this project policy. Task-specific
+requirements may add obligations. The executable manifest does not automatically
+translate YAML conditions: Astra must preserve and map all existing safeguards.
+See [task gates](../.claude/nccgs/protocols/task-gates.md) for evidence formats.
+
+`contract.taskTiers` selects each task's implementation class and review limit.
+Compatibility `task init --risk` defaults to STANDARD; standalone intake uses its
+classifier and explicit risk evidence. FAST allows two recorded reviews and
+STANDARD/CONTROLLED allow three. Re-recording implementation does not reset the
+counter. Only an explicit external `task extend-review` decision adds rounds.
+An exhausted budget is not acceptance. Planning estimates do not extend configured
+dispatch/session/check limits. Read the active execution policy and actual ledger.
+
+## Canonical sources and context
+
+Map existing documents where they live. Workflows address semantic roles, not fixed
+folder names. Context packets refer to exact sections and source revisions; they do
+not replace canonical documents.
+
+## Closure example
+
+```yaml
+closure:
+  mode: strict
+  canonical_record: ".nccgs/closures/{feature_id}.md"
+  required_artifacts:
+    - id: implementation-report
+      type: report
+      path_pattern: "project-docs/reports/{feature_id}*.md"
+      required: true
+      completion_rule: exists
+    - id: implementation-register
+      type: register_entry
+      path_pattern: "project-docs/implementation-register.md"
+      required: true
+      completion_rule: entry_present
+    - id: deletion-gate
+      type: checklist
+      path_pattern: "project-docs/gates/{feature_id}*.md"
+      required: true
+      completion_rule: all_conditions
+      expected_conditions: 7
+  done_requires:
+    - implementation
+    - objective_verification
+    - required_artifacts
+    - applicable_manual_gates
+```
+
+Start migration with the strongest live safeguard and weaken it only through an
+explicit Product Owner decision after the replacement has proven its purpose.

package/docs/RELEASE-STATUS.md

@@ -1,13 +1,21 @@
 # NCCGS release status
 
-Current source: **2.1.0**, unpublished. It adds reversible project uninstallation,
-safe backup/rollback and launch/update protection during interrupted removal.
-See [removal semantics](UNINSTALL.md). Local tests do not claim a new native
-Claude Code/Unity run. The first independent maintenance review returned
-CHANGES_REQUIRED. This candidate adds logged operator session reconciliation,
-shared admission locking for configuration writers, pre-mutation cancellation
-and best-effort directory cleanup. Its exact archive requires fresh full
-regression and independent review; the earlier negative verdict is retained.
+Current local source: **2.1.1**, prepared and unpublished. The registry already
+contains a different 2.1.0 artifact; the accepted local R11 r05 source is retained
+unchanged as the qualification baseline. This release variant changes package
+identity and current documentation, with no runtime, policy, model-route, role,
+gate, quota or budget changes. Exact artifact checks and the subsequent release
+review are recorded in separate receipts. No registry publication or tag update
+is performed by preparation.
+
+The accepted baseline accounts for 353 passing top-level cases; one top-level
+and 12 nested link/junction cases remain host-skipped, not PASS. Its independent
+Fable static review returned PASS with no conditions. New version-sensitive
+framework/policy and packaged-install checks qualify the separate patch artifact;
+the receipts identify fresh executions versus inherited unchanged scopes.
+Effective native effort remains UNKNOWN. The earlier guarded headless managed
+smoke was blocked before dispatch and remains unclosed; no new Unity run is claimed.
+Earlier negative verdicts and consumed allowances are preserved.
 
 Version **2.0.0** was published on 2026-10-28 after exact-archive qualification.
 The frozen publication receipt verified npm metadata and downloaded bytes,
@@ -16,7 +24,7 @@ fresh consumer installation and all 472 packaged files. Its archive SHA-256 is
 Its maintenance audit and native Unity case completed with independent PASS;
 the Unity case retained all 28 criteria/385 assertions, handoff, repair and the
 unsaved-scene guard. Detailed private task/provider/cost receipts stay outside
-the public package. That evidence does not transfer to 2.1.0 automatically.
+the public package. That evidence does not transfer to this 2.1.1 artifact automatically.
 
 ## Historical 2.0.0 preparation evidence
 

package/docs/UNINSTALL.md

@@ -1,7 +1,7 @@
 # Remove NCCGS from a project
 
-`uninstall` is available in the **unpublished 2.1.0 package**. The published
-2.0.0 CLI does not have this command. Use the local 2.1.0 archive (or its source
+`uninstall` is available in the **unpublished 2.1.1 package**. The published
+2.0.0 CLI does not have this command. Use the local 2.1.1 archive (or its source
 CLI) to remove an existing 2.0.0 installation; no preliminary update is needed.
 
 Close Claude Code sessions and let managed workers/verification finish first.
@@ -13,7 +13,7 @@ session record, so they must also be closed by the operator.
 ## Preview and remove
 
 ```powershell
-$NccgsArchive = "D:\path\to\nccgs-2.1.0.tgz"
+$NccgsArchive = "D:\path\to\nccgs-2.1.1.tgz"
 npx --yes --package "$NccgsArchive" nccgs uninstall --project "D:\path\to\UnityProject" --dry-run
 npx --yes --package "$NccgsArchive" nccgs uninstall --project "D:\path\to\UnityProject"
 ```

package/docs/WFK17-HOOK-REPAIR.md

@@ -0,0 +1,71 @@
+# WFK17 R04 local hook/context repair
+
+This is an unpublished local candidate based on NCCGS 2.1.0. Its archive SHA-256
+and the outer R04 identity distinguish it from the original package. It is not an
+npm release, rollout or acceptance of full NCCGS orchestration. The common
+workflow R03 remains frozen and unchanged.
+
+## Runtime scope
+
+The qualification target is Claude Code 2.1.316 on the named Windows host.
+Earlier CLI versions are not qualified for this candidate. Direct executable
+hook arguments and `onFailure: block` must be supported; do not use this fragment
+on an older CLI that silently ignores those settings. The local runner checks
+the tested version before calling the native launcher.
+
+All twelve managed command hooks invoke Node directly through `command`/`args`.
+They retain their existing scripts, matchers, arguments and timeouts. PreToolUse
+and subagent integrity hooks block when their transport/runtime fails. No native
+model, design, dispatch, review or closure obligation is removed. Hook identity
+includes its script and phase; unrelated custom Node hooks remain owner-owned.
+The installer migrates exact legacy hooks, doctor checks argv and failure policy,
+and uninstall removes only recognized managed hooks.
+
+## Optional shared context reads
+
+The external operator can bind a session to an already accepted common workflow:
+
+- `NCCGS_SHARED_WORKFLOW_ROOT`: its absolute tools root;
+- `NCCGS_SHARED_WORKFLOW_MANIFEST_SHA256`: SHA-256 of its exact
+  `implementation/ARTIFACT_MANIFEST.json`.
+
+These are process-local trust anchors, not a second project configuration or
+graph. The common project configuration remains
+`docs/workflow/workflow.config.json`. Native read admission verifies the installed
+bridge fingerprint and all pinned workflow-manifest files before accepting only:
+
+```text
+node .claude/nccgs/tools/shared-context.mjs --project PROJECT --workflow-root ROOT --action status
+node .claude/nccgs/tools/shared-context.mjs --project PROJECT --workflow-root ROOT --action query --text Restore
+node ROOT/tools/workflow.mjs status --config PROJECT/docs/workflow/workflow.config.json
+```
+
+The exact current project/root are mandatory. Queries allow only bounded plain
+text. This coordinator admission denies setup, refresh, update, hold secrets,
+duplicate/unknown options, foreign roots, modified readers and shell composition.
+An absent binding grants no shell permission. Worker reservations and native task
+obligations are unchanged. Arbitrary audit shell execution remains denied; do not
+change task mode or create a worker just to obtain context-read permission.
+
+Use PowerShell natively on this Windows fixture because its Git Bash/MSYS host
+cannot create the required named object. This changes the tool transport and
+keeps the same Bash|PowerShell integrity matcher. It is not a way around a
+native denial. Semantic Graphify coverage remains unavailable without an approved
+backend, and original documents still require direct reads.
+
+For the tested foreground Windows session, set the process-local variables
+`CLAUDE_CODE_USE_POWERSHELL_TOOL=1` and
+`CLAUDE_CODE_DISABLE_WINDOWS_SHELL_LAUNCHER=1`. The second uses direct PowerShell
+instead of the cmd.exe lifecycle launcher; background tasks remain disabled by
+NCCGS. The default launcher returned tool error 5 after producing correct JSON
+on this restricted host. A diagnostic suppressing experimental warnings did not
+fix it and is not part of the final profile. Do not translate that error into a
+successful semantic or process exit status.
+
+The user's optional mcpmarket-me plugin has its own Bash startup hook. The
+qualification fixture disables only that plugin at local scope, using Claude's
+plugin CLI. Global plugins/settings remain unchanged. The candidate package does
+not automatically disable user plugins in other projects.
+
+References: https://code.claude.com/docs/en/hooks#exec-form-and-shell-form and
+https://code.claude.com/docs/en/env-vars .

package/docs/WORKFLOWS.md

@@ -1,85 +1,85 @@
-# NCCGS workflows — 2.0.0
-
-New installations use standalone Claude Code execution with the claude-standalone
-model profile. The coordinator owns intake, planning, dispatch, verification and
-reporting; a separate Claude Code reviewer owns the verdict. External/manual
-acceptance is required only by the configured policy and approved contract.
-See [standalone execution](../.claude/nccgs/protocols/standalone.md) and
-[standalone gates](../.claude/nccgs/protocols/standalone-gates.md).
-
-Existing compatibility projects retain their Astra/Fable or legacy chain; select
-obligations from execution.json before model routing. Updates do not silently
-convert those projects. See [upgrading](../UPGRADING.md).
-
-## Risk tiers
-
-| Tier | Typical work | Required structure |
-|---|---|---|
-| FAST | Local, unambiguous, easy rollback | One lightweight implementer; concise plan/report; targeted evidence; 2 review rounds |
-| STANDARD | Ordinary feature or coordinated change | Contract, context packet, one standard implementer, independent verification, closure; 3 review rounds |
-| CONTROLLED | Architecture, compatibility, dependency, migration, security, release | One deep implementation lead, impact/decision record, relevant specialists, rollback, full gates; 3 review rounds |
-
-Standalone intake is classified conservatively; ready local fixes may use FAST,
-ordinary features STANDARD, and cross-system/high-risk work CONTROLLED. Compatibility
-tasks also support explicit risk. FAST uses nccgs-fast-implementer; CONTROLLED uses
-nccgs-unity-implementer as its deep lead. Use the read-only task scout only for a
-specific missing fact. All tiers retain independent review and applicable contract
-gates; standalone review requests Opus/high.
-
-Stop when criteria and relevant checks pass without actionable blockers. Avoid
-speculative scope expansion, duplicate reviewers, and repeated green checks.
-Rerun only for changed inputs, failures, or new evidence. Subjective questions go
-to a playable test. Exhausted review rounds require an evidence-backed stop or an
-explicit external `task extend-review`; re-recording implementation does not reset
-them. Configured dispatch, supervised session and verification limits remain effective;
-advisory planning estimates never extend them or waive a gate.
-
-## End-to-end work
-
-```text
-request -> approved contract, mode, risk and design readiness
-  -> reserved Claude Code worker with bounded ownership
-  -> verification tied to current source and contract
-  -> independent reviewer verdict
-  -> report and configured external/manual acceptance
-  -> task close after all executable gates pass
-```
-
-The primary session composes modules automatically. Explicit specialized commands are
-available when a user wants a bounded workflow or output.
-
-## Workflow families
-
-- **Planning/context**: `project-stage`, `context-pack`, `story-readiness`,
-  `plan-feature`, `sprint-plan`, `milestone-review`, `retrospective`.
-- **Design**: `design`, `design-review`, `balance-review`, `accessibility-review`,
-  `ui-review`, `prototype-feature`, `playtest`.
-- **Technical**: `architecture-decision`, `dependency-review`,
-  `compatibility-review`, `nccgs-code-review`, `performance-audit`, `security-audit`.
-- **Implementation/quality**: `work`, `qa-plan`, `test`, `bug-triage`,
-  `evidence-review`, `review`, `asset-audit`, `closure`.
-- **Delivery/recovery**: `release-readiness`, `release`, `hotfix`,
-  `incident-recovery`, `localize-game`, `migrate-project`.
-- **Visibility**: `audit`, `status`.
-
-## Role composition examples
-
-The standalone coordinator routes feature design to the game designer and obtains
-independent design review before dependent implementation when required.
-One gameplay programmer owns implementation; a Unity systems specialist may support
-a separate bounded concern where needed, followed by verification. A UI feature
-has one UI implementation owner; UX, accessibility, or Unity UI specialists join only
-for a concrete question or distinct deliverable, followed by independent verification.
-
-CONTROLLED network-save work can enable optional technical architect, network
-programmer and security engineer roles. The standalone reviewer reviews all three
-risk tiers. Optional roles are activated explicitly; the default loads 13 of 47 roles.
-
-## Evidence states
-
-- IMPLEMENTED: change exists.
-- VERIFIED: objective evidence proves approved criteria.
-- VALIDATED: applicable subjective gate accepted.
-- DONE: all configured objective, artifact and subjective gates closed.
-
-Status labels are evidence claims, not progress decoration.
+# NCCGS workflows — 2.0.0
+
+New installations use standalone Claude Code execution with the claude-standalone
+model profile. The coordinator owns intake, planning, dispatch, verification and
+reporting; a separate Claude Code reviewer owns the verdict. External/manual
+acceptance is required only by the configured policy and approved contract.
+See [standalone execution](../.claude/nccgs/protocols/standalone.md) and
+[standalone gates](../.claude/nccgs/protocols/standalone-gates.md).
+
+Existing compatibility projects retain their Astra/Fable or legacy chain; select
+obligations from execution.json before model routing. Updates do not silently
+convert those projects. See [upgrading](../UPGRADING.md).
+
+## Risk tiers
+
+| Tier | Typical work | Required structure |
+|---|---|---|
+| FAST | Local, unambiguous, easy rollback | One lightweight implementer; concise plan/report; targeted evidence; 2 review rounds |
+| STANDARD | Ordinary feature or coordinated change | Contract, context packet, one standard implementer, independent verification, closure; 3 review rounds |
+| CONTROLLED | Architecture, compatibility, dependency, migration, security, release | One deep implementation lead, impact/decision record, relevant specialists, rollback, full gates; 3 review rounds |
+
+Standalone intake is classified conservatively; ready local fixes may use FAST,
+ordinary features STANDARD, and cross-system/high-risk work CONTROLLED. Compatibility
+tasks also support explicit risk. FAST uses nccgs-fast-implementer; CONTROLLED uses
+nccgs-unity-implementer as its deep lead. Use the read-only task scout only for a
+specific missing fact. All tiers retain independent review and applicable contract
+gates; standalone review requests Fable/high.
+
+Stop when criteria and relevant checks pass without actionable blockers. Avoid
+speculative scope expansion, duplicate reviewers, and repeated green checks.
+Rerun only for changed inputs, failures, or new evidence. Subjective questions go
+to a playable test. Exhausted review rounds require an evidence-backed stop or an
+explicit external `task extend-review`; re-recording implementation does not reset
+them. Configured dispatch, supervised session and verification limits remain effective;
+advisory planning estimates never extend them or waive a gate.
+
+## End-to-end work
+
+```text
+request -> approved contract, mode, risk and design readiness
+  -> reserved Claude Code worker with bounded ownership
+  -> verification tied to current source and contract
+  -> independent reviewer verdict
+  -> report and configured external/manual acceptance
+  -> task close after all executable gates pass
+```
+
+The primary session composes modules automatically. Explicit specialized commands are
+available when a user wants a bounded workflow or output.
+
+## Workflow families
+
+- **Planning/context**: `project-stage`, `context-pack`, `story-readiness`,
+  `plan-feature`, `sprint-plan`, `milestone-review`, `retrospective`.
+- **Design**: `design`, `design-review`, `balance-review`, `accessibility-review`,
+  `ui-review`, `prototype-feature`, `playtest`.
+- **Technical**: `architecture-decision`, `dependency-review`,
+  `compatibility-review`, `nccgs-code-review`, `performance-audit`, `security-audit`.
+- **Implementation/quality**: `work`, `qa-plan`, `test`, `bug-triage`,
+  `evidence-review`, `review`, `asset-audit`, `closure`.
+- **Delivery/recovery**: `release-readiness`, `release`, `hotfix`,
+  `incident-recovery`, `localize-game`, `migrate-project`.
+- **Visibility**: `audit`, `status`.
+
+## Role composition examples
+
+The standalone coordinator routes feature design to the game designer and obtains
+independent design review before dependent implementation when required.
+One gameplay programmer owns implementation; a Unity systems specialist may support
+a separate bounded concern where needed, followed by verification. A UI feature
+has one UI implementation owner; UX, accessibility, or Unity UI specialists join only
+for a concrete question or distinct deliverable, followed by independent verification.
+
+CONTROLLED network-save work can enable optional technical architect, network
+programmer and security engineer roles. The standalone reviewer reviews all three
+risk tiers. Optional roles are activated explicitly; the default loads 13 of 47 roles.
+
+## Evidence states
+
+- IMPLEMENTED: change exists.
+- VERIFIED: objective evidence proves approved criteria.
+- VALIDATED: applicable subjective gate accepted.
+- DONE: all configured objective, artifact and subjective gates closed.
+
+Status labels are evidence claims, not progress decoration.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nccgs",
-  "version": "2.1.0",
+  "version": "2.1.1",
   "description": "Unity-first game-studio operating system for Claude Code",
   "license": "MIT",
   "type": "module",