nccgs 1.3.0 → 2.0.0-rc.2

package/.claude/nccgs/protocols/astra-claude.md

@@ -1,6 +1,6 @@
 # Astra planning, Claude implementation, Fable review
 
-This protocol is mandatory when `models.profile` is `astra-claude`, including when
+This historical protocol is mandatory for compatibility execution when `models.profile` is `astra-claude`, including when
 the package default is used before project policy exists. It takes precedence over
 generic NCCGS workflow instructions. Other profiles retain their existing workflow.
 
@@ -13,8 +13,10 @@ status labels, determine whether reporting or DONE is allowed.
 
 - **Astra** owns planning, feature contracts, context packets, architecture decisions,
   canonical documents, and the final check of Claude's report.
-- **Claude Opus 5.5 / xhigh** implements the supplied plan, writes tests, runs relevant
-  checks, fixes defects, and records implementation evidence and the handoff report.
+- **Claude's selected implementer** implements the supplied plan, writes tests,
+  runs relevant checks, fixes defects, and records evidence and the handoff report.
+  FAST uses Sonnet/medium, STANDARD uses Opus 5.5/medium, and CONTROLLED uses
+  Opus 5.5/high, as resolved from `pipeline.json`.
 - **Fable / high**, through `nccgs-adversarial-reviewer`, independently reviews the
   completed work. The reviewer remains read-only and does not implement fixes.
 - **Product Owner** performs final acceptance after Astra's check. Only this explicit
@@ -31,18 +33,27 @@ remain available as technical consultants, not substitutes for Astra ownership.
 1. Read Astra's plan, requirements, acceptance criteria, document references, and
    assigned write set. A concise Astra handoff is enough for FAST work. Missing or
    contradictory scope is a planning blocker; return the exact question to Astra.
-2. Confirm the implementation session or agent actually uses `claude-opus-5-5` at
-   `xhigh`. Implement and collect compilation, test, runtime, and regression evidence
-   appropriate to the change. A role name alone does not prove its runtime model.
-3. Immediately after implementation and its checks, invoke a fresh, independent
-   `nccgs-adversarial-reviewer` with the review route in pipeline.json. Supply raw requirements, the
+2. Initialize the task once with `--risk FAST|STANDARD|CONTROLLED` (default STANDARD).
+   Resume that same task for remediation; never create a new ID to reset its budget.
+   Confirm the implementation session or agent actually uses the task's recorded
+   implementation route and effort. Implement and collect compilation, test,
+   runtime, and regression evidence appropriate to the change. A role name alone
+   does not prove its runtime model.
+3. After recording implementation and its checks, run
+   `task check --id ID --target review`. Only when allowed, invoke a fresh,
+   independent `nccgs-adversarial-reviewer` with the review route in pipeline.json.
+   The bound-task pre-agent guard also checks readiness and remaining rounds.
+   Keep only one Fable review in flight per task; the guard does not reserve rounds
+   or meter invocations, tokens, or cost.
+   Supply raw requirements, the
    final diff/working-tree snapshot, affected callers, and evidence. Do not supply
    an expected verdict. No final completion report is handed to Astra before this
    review. Progress updates and blocker notices are always allowed.
 4. Fable returns PASS, CHANGES_REQUIRED, or BLOCKED with evidence and findings.
    Open BLOCKER/HIGH findings or unmet required acceptance criteria prevent PASS.
-   Opus fixes findings within approved scope, reruns affected checks, then requests
-   Fable review again. Any code/test/asset change after a review invalidates that
+   The selected implementer fixes actionable findings within approved scope, reruns
+   affected checks, then requests Fable review within the remaining review budget.
+   Any code/test/asset change after a review invalidates that
    review. Bind each review to a commit plus dirty/untracked diff or file hashes;
    a commit ID alone is insufficient when the working tree is dirty.
 5. After Fable PASS on the final snapshot, Claude writes the implementation report
@@ -52,7 +63,8 @@ remain available as technical consultants, not substitutes for Astra ownership.
    a real delivery mechanism. Do not simulate Astra's response.
 6. Astra checks plan compliance, evidence, Fable findings and their resolution,
    documents, and residual risk. Astra may return work for correction, which repeats
-   steps 2-5, or record its check and prepare `AWAITING_PO_ACCEPTANCE`.
+   implementation/check/review/report in steps 2-5 on the same task and remaining
+   budget, or record its check and prepare `AWAITING_PO_ACCEPTANCE`.
 7. The Product Owner accepts the reviewed snapshot. Only then may Astra finalize the
    closure record as DONE if all other configured gates also pass. Unknown, missing,
    stale, or inferred sign-offs never count. Changes after either sign-off require
@@ -63,9 +75,31 @@ VALIDATED, DONE, and BLOCKED. Neither FAST classification nor lean closure skips
 Fable review, Astra checking, or explicit Product Owner acceptance. Hotfixes,
 prototypes, migrations with code changes, and release fixes follow the same chain.
 
+## Bounded execution and stopping
+
+Use one accountable implementer. Add the read-only task scout only for a specific
+missing fact, and add specialist reviewers only for distinct risks. Stay within
+approved scope; do not turn speculative improvements into requirements or broaden
+a completed change. FAST keeps the full acceptance chain with a concise plan and
+report.
+
+Stop implementation and analysis when approved criteria and relevant tests pass
+and no actionable blocking findings remain. Re-run checks only for changed inputs,
+failures, or new evidence. For subjective uncertainty, prepare a playable test with
+observable questions for the Product Owner instead of repeating speculative debate.
+
+Task gates enforce review-round limits: FAST 2, STANDARD 3, CONTROLLED 3. A valid
+recorded PASS, CHANGES_REQUIRED, or BLOCKED consumes one round. Re-recording
+implementation does not reset the counter. A PASS on the last allowed round can
+continue to reporting; an exhausted budget without a usable PASS stops work with
+the evidence, unresolved findings, and next decision. It never becomes auto-PASS.
+An external operator may explicitly extend the budget with a reason using
+`task extend-review`; see [task gates](task-gates.md). Context and elapsed-time
+budgets guide scope and escalation; they are advisory, not enforced runtime caps.
+
 ## Model failures and evidence
 
-Do not silently substitute Sonnet, another Opus version, or inherited models for
+Do not silently substitute a different model, effort, or inherited routing for
 the required stages. If access, forced routing, effort caps, or runtime fallback
 prevents the requested model/effort, record BLOCKED with the observed identity and
 resume only when the required stage can run or the Product Owner changes policy.

package/.claude/nccgs/protocols/bounded-repair.md

@@ -0,0 +1,118 @@
+# Bounded source repair — 2.0 RC
+
+The Unity phase-2 retest exhausted a repair worker's 22 native turns while exploring
+parameters in a scratch harness. It made no gameplay change and left a PARTIAL
+handoff. A protected dispatch slot alone did not reserve time to deliver an edit.
+Fresh repair reservations now require a concrete source-edit packet and durable
+tool admission limits. Existing failed cases and legacy reservations stay unchanged.
+
+## Prepare the decision before spending the repair slot
+
+The Claude coordinator first uses the recorded review or measured failure to choose
+one correction. It must preserve the approved requirements and measurement rules.
+If diagnosis is unresolved, use eligible read-only analysis within the existing
+budget or report PARTIAL; do not spend the repair slot on another parameter search.
+General task autonomy does not expand an individual worker's assigned scope.
+
+The coordinator applies [Ponytail engineering guidance](../packages/ponytail/engineering.md)
+to this diagnosis and solution choice: trace relevant callers, reuse suitable
+existing behavior, and preserve every requirement and check. Include the material
+rationale and limits in the existing packet fields. The worker does not spend
+additional reads loading that package or reopen exploration to optimize diff size.
+
+Copy `.nccgs/templates/repair-packet.json` into
+`.nccgs/evidence/work-packets/UNIQUE.json` and replace every placeholder:
+
+- `taskId`, `contractHash`, `sourceSnapshot`: current task and snapshot from the CLI.
+- `problem`, `solution`: concise failure and already-chosen correction.
+- `changes`: 1–4 exact existing source files, each with a concrete instruction.
+  Directory ownership, new files, governance and evidence edits are rejected.
+- `context`: up to four existing `.nccgs/evidence/` artifact references produced by
+  `task ref`. Supply only relevant measured facts and rationale, not entire logs.
+- `verification`: all required check names from the contract. At least one is
+  required. The coordinator runs them after the worker returns.
+- `budget`: optional lower limits. Defaults and ceilings are 12 work tool calls,
+  including 6 reads/searches, 3 separate handoff writes, and 600000 ms from claim.
+  The packet is at most 16 KiB. Limits cannot be raised in the request.
+
+The reservation must contain the packet path, exactly matching writePaths, and one
+fresh handoff path. It still needs recorded negative feedback and eligible remaining
+repair capacity within the original aggregate budget:
+
+```json
+{
+  "requestKey": "repair-1",
+  "kind": "implementation",
+  "purpose": "repair",
+  "agent": "nccgs-gameplay-programmer",
+  "reason": "Apply the chosen correction from the recorded negative review",
+  "workPacket": ".nccgs/evidence/work-packets/repair-1.json",
+  "writePaths": ["Assets/ChosenFile.cs"],
+  "handoffPaths": [".nccgs/evidence/analysis/repair-1.md"]
+}
+```
+
+```text
+node .claude/nccgs/tools/task.mjs reserve --id TASK --request .nccgs/evidence/requests/repair-1.json
+node .claude/nccgs/tools/task.mjs dispatch-prompt --id TASK --dispatch RETURNED_ID
+```
+
+Use the returned `prompt` for the foreground Agent call. The pre-tool hook replaces
+that call's prompt with the same pinned packet so the worker receives the chosen
+solution, exact files, limits and handoff without first searching for them. Model
+route, risk-selected effort and native turn limits remain unchanged. Packet/context
+hashes are checked before launch, work calls, completion and stage validation.
+Direct writes to pinned packet/context evidence are refused even after completion.
+
+## Execute and hand off
+
+The worker may Read/Grep/Glob inside the project and Write/Edit/MultiEdit the exact
+source files. The assigned handoff is the only evidence file it can edit. Shells,
+MCP, web tools, nested agents and other tools are refused for this repair protocol.
+Editor/asset operations requiring Unity tools need a different properly scoped
+assignment; do not relabel repair as delivery to evade these limits.
+
+Write `NCCGS-HANDOFF: PARTIAL` early. Apply the chosen correction, then replace that
+line with `NCCGS-HANDOFF: COMPLETE` only when the assigned edits are finished.
+Include changed files, rationale, remaining unverified checks, risks and next owner.
+COMPLETE means the edit assignment is finished; it does not mean product PASS.
+If the fix needs more investigation, preserve PARTIAL and return promptly.
+
+Every correlated tool attempt reaching the ledger consumes its bucket, including
+scope denials. Identical hook redelivery with the same tool-use ID and input is
+idempotent. A changed payload under that ID is rejected. The ledger stores a payload
+hash and counts, not the raw command or tool content. Atomic lock protection keeps
+parallel hooks from both taking the last call. Lock contention fails closed; retry
+the same ID after the other owner finishes. It is not an admitted/spent call until
+the transaction can record it. Missing/corrupt accounting is never reset.
+
+Reads count within the work allowance. Exhausting reads leaves remaining edit calls;
+exhausting work or reaching the deadline still permits remaining handoff writes.
+The deadline is checked at tool admission and cannot interrupt a model request or
+tool already running. These counts are **tool calls, not native turns or token
+limits**; they cannot guarantee three native turns remain. Missing/partial handoffs
+still fail the dispatch, and quota is never refunded. Counter exhaustion does not
+complete, release, resume or replace an active worker.
+
+The coordinator then runs declared checks with `task verify`, collects their original
+receipts, records the work stage and dispatches protected QA and independent review
+when eligible. Failing measurements still block PASS and DONE. No helper exit code
+or handoff marker substitutes for measured acceptance.
+
+## Validation and rollout boundary
+
+Apply only to a fresh authorized install/task. Updating a historical reservation
+does not retroactively enforce a packet or rewrite its result; idempotent requests
+return the original reservation. Old limits, attempts, evidence and failures persist.
+Do not upgrade/resume frozen game cases merely to obtain a passing result.
+
+Local tests exercise executable hooks, concurrency, exact ownership, stale context,
+separate handoff allocation and a complete synthetic repair/QA/re-review cycle under
+the original cap. They establish framework behavior, not actual Claude performance,
+Unity gameplay viability, provider usage or token savings. A new real Claude/Unity
+acceptance run is still required. NCCGS is a workflow guard, not an OS sandbox or
+protection against malicious code, falsified measurements or externally edited ledgers.
+
+Native hook output uses `PreToolUse.hookSpecificOutput.updatedInput` for the packet
+and `additionalContext` for remaining counts, without granting native permissions.
+See the [official Claude Code hooks reference](https://code.claude.com/docs/en/hooks#pretooluse-decision-control).

package/.claude/nccgs/protocols/context-packets.md

@@ -11,3 +11,8 @@ source revisions, and contradictions.
 Prefer anchors, IDs, paths, and hashes over pasted prose. Update the packet when its
 sources change. Read a full source only when the packet records why its summary is
 insufficient.
+
+Keep context proportional to the approved risk tier. Context and elapsed-time
+budgets are advisory: crossing one is a reason to narrow the next read or surface
+the exact missing fact, not proof of failure or permission to discard evidence.
+They do not reset or extend the separately enforced task review-round limit.

package/.claude/nccgs/protocols/delivery-acceptance.md

@@ -0,0 +1,105 @@
+# Delivery acceptance and separate product research
+
+Owner decision, 2026-10-04: evaluate NCCGS on supporting game development from
+brief through implementation, testing and acceptance. Balance is researched
+separately for each product. Apply this policy when authoring new or explicitly
+revised criteria; preserve frozen contracts, measurements, verdicts and spent budgets.
+
+## Define what is being accepted
+
+For each brief item, identify its source and choose one of these scopes in the
+design handoff's prose and requirement mapping. These labels are guidance, not
+new JSON fields or additional machine verdicts.
+
+- **Delivery obligation:** specified behavior, formulas/configuration, UI/content,
+  integration, compatibility, build, tests and required delivery evidence. Map to
+  executable acceptance or a scoped owner decision where objectively necessary.
+- **Technical diagnostic:** a probe used to locate defects, cover a state or measure
+  load. State setup, interventions and limitations. Do not promote it to production
+  evidence or an unrelated mandatory gate.
+- **Product research:** difficulty, fairness, enjoyment, pacing preferences, build
+  viability, win rate, strategy strength and choosing tuning targets. Record in a
+  separate product research brief with its own questions, methods and owner. Do
+  not import those questions as mandatory delivery criteria or default manual gates.
+
+Implementing an approved damage formula, drop probability, spawn schedule or tuning
+value is delivery work. Deciding whether that value feels fair or produces a desired
+win rate is research. Report suspected balance issues without silently changing the
+approved numbers. If a required value is genuinely unspecified, obtain its authority
+before dependent implementation; continue independent work. Never discard a stated
+behavior, accessibility requirement or technical performance budget as "balance".
+
+NCCGS can support a separately requested `/balance-review` or `/playtest`; judge its
+research deliverable against that research brief. Such a task does not make a bot's
+victory or a positive balance finding a universal condition for studio acceptance.
+
+## Delivery review checklist
+
+1. **Brief fidelity:** each required item has a stable ID, actual source, implementable
+   rule and test/observation; ambiguities and scope changes are recorded with authority.
+2. **Implementation:** trace the item to changed code/assets and actual behavior.
+   Preserve unrelated functionality. A build or test count alone proves no coverage.
+3. **Testing:** cover the relevant normal, boundary and failure paths; make expected
+   outcomes independent of implementation self-report. A correct loss/death is a
+   passing test when the requirement is correct loss handling.
+4. **Evidence integrity:** bind measurements to the source/build, environment, inputs
+   and attempt; reject stale/missing/foreign data. Exercise negative controls for a
+   helper's consequential pass logic. Keep actual failures and intervention records.
+5. **Integration and delivery:** build the specified target, exercise required input/UI
+   and system interactions, package reproduction steps and disclose remaining gaps.
+6. **Independent review and repair:** compare brief, code and evidence on a matching
+   snapshot. Fix blocking findings and repeat affected checks. Do not invent a finding
+   to consume a repair slot or call every successful invocation completed work.
+7. **Coordination:** complete useful bounded packets under cumulative resource limits,
+   own and settle command processes, reuse valid evidence, and report any required
+   operator assistance. A missing measurement is neither zero usage nor permission
+   to renew a budget. A partial repair is useful when honestly labelled; inability
+   to fit an entire playtest does not by itself forbid an authorized small code fix.
+8. **Honest acceptance:** report each delivery criterion's evidence, review, limitations
+   and scoped owner decisions. Delivery acceptance does not claim enjoyable/balanced
+   gameplay or general productivity superiority. Record research status separately.
+
+The generic engine still enforces every criterion in the imported contract. This
+checklist guides the designer/reviewer; it does not silently filter old criteria,
+grant manual approval, or convert old FAIL/UNVERIFIED into PASS.
+
+## Choose tests that measure the requirement
+
+Use short deterministic scenarios for state transitions, damage/formulas, schedules,
+exactly-once rewards, death precedence, pause, reset and UI flows. Establish a known
+precondition, apply the normal operation under test, and observe the result. A fixture
+may set health, place entities, select a reference build or advance simulation time
+when necessary. Disclose those interventions; verify shipped defaults separately.
+The fixture must not directly set the result it claims to test (e.g. injecting a
+Victory state cannot prove that the normal victory condition works).
+
+Use an actual player build for integration/launch/input/platform behavior. Choose
+duration and workload to expose the specific risk. Neither a universal 600-second
+run nor bot survival/victory is a default delivery requirement. A real-time soak,
+performance threshold or human UI inspection may be mandatory when the delivery
+brief explicitly requires it; explain the authority, workload and failure rule.
+Keep unrelated implementation work progressing if it does not depend on that result.
+Never relabel an assisted fixture as an unassisted natural play session.
+
+Bot losses, seeds and actions are diagnostics unless a separately scoped requirement
+is the bot itself. Separate a product defect, test/collector defect, bot limitation,
+and research question before assigning repair work. Retry or change input only to
+test a stated hypothesis; do not repeatedly play until an unexplained PASS appears.
+
+## Early checkpoint and revision
+
+Use `checkpoint: "early"` only for a small delivery prerequisite whose failure
+actually prevents dependent work: for example build/start plus one core input/state
+path. State the dependency and fit it into the first bounded implementation slice.
+Do not select bot win rate, survival time, enjoyment, balance or damage headroom as
+a universal expansion gate. The current engine blocks all further delivery dispatches
+for an unmet early criterion; therefore do not mark a late integration/soak requirement
+early when independent features can still be implemented. Ordinary final criteria
+remain mandatory for final delivery acceptance.
+
+For a previously pinned contract, write an explicit old-to-new criterion comparison
+against the owner's scope decision, preserve required game behavior and the old
+evidence, then follow design validation/comparison and independent review before
+importing a revised executable handoff. Preserve spent attempts and cumulative limits.
+Do not edit `.nccgs/tasks`, receipts or a frozen design to make this policy appear
+retroactively satisfied. A changed acceptance scope is not a new budget authorization.

package/.claude/nccgs/protocols/design-lifecycle.md

@@ -0,0 +1,139 @@
+# Standalone design, independent document review and readiness
+
+Use with [standalone](standalone.md) for `/design`, `/design-review` and
+`/story-readiness`. Claude Code owns these responsibilities. Ponytail complexity
+guidance is not their review standard. Schema validation does not judge game design.
+Apply [delivery acceptance](delivery-acceptance.md): NCCGS delivery is judged on
+brief fidelity, implementation, testing, review and handoff. Balance/viability/feel
+research belongs to a separately scoped product study, not default delivery gates.
+
+## /design — Game Designer responsibility
+
+1. Read the brief, canonical GDD sections, recorded owner decisions and relevant
+   existing behavior. Identify concrete ambiguities, contradictions and missing
+   rules. Do not assume that a numeric GDD is necessarily complete.
+2. Define the assigned feature's states, rules/formulas, player feedback, boundaries,
+   interactions, failure/edge cases, dependencies and out-of-scope behavior. Give
+   each requirement a stable ID and a source section/excerpt with its actual hash.
+3. Separate fixed behavior from delegated tuning. Record tuning parameters, bounds
+   and the source granting authority. Resolve routine choices within that authority.
+   Batch only meaningful unresolved product decisions for the owner; continue
+   independent work. An invented assumption is not an owner decision.
+4. Map every requirement to concrete acceptance: procedure, environment, pass
+   condition, rationale and authority for that threshold. Automatic criteria need
+   actual measurement assertions. Keep product balance/experience research outside
+   the delivery contract and list its disposition in the handoff/outOfScope; do not
+   silently omit a required behavior. Manual delivery gates require a specific
+   brief obligation and named decision, not a default "fun/viability" gate. Keep
+   diagnostics separate, with their limitations. "Two viable builds" is an unresolved
+   product-research question unless the owner supplies a scoped definition; it does
+   not imply every bot/seed wins, and random offers do not imply early access.
+   Equal seeds alone do not establish equal action traces or timestep schedules.
+5. Produce one bounded contract using the installed
+   `.nccgs/templates/design-contract.json` schema. The JSON is a versioned handoff
+   referencing canonical truth, not a replacement GDD tree. Supporting explanatory
+   prose belongs in its declared handoff. Preserve open decisions and return
+   BLOCKED when they affect implementation. READY_WITH_RISKS cannot hide an open
+   product decision. Human product acceptance can still be pending on a READY design.
+
+The coordinator initializes a `mode: "plan", workflow: "design"` task with
+`requiredChecks: ["design-contract"]`, `acceptance: []`, the canonical `sources`,
+and `analysisArtifacts` listing the output JSON and each worker's fresh handoff.
+The plan task's acceptance is about delivering/reviewing the document; do not copy
+the future game's executable criteria into the plan task. Reserve a designer as
+`kind: "analysis"`, normally `nccgs-game-designer`; use technical analysis only for
+a concrete feasibility question. The worker writes only declared analysis outputs.
+`handoffPaths` should name a separate Markdown handoff with the required marker;
+the JSON contract itself is not a handoff-marker file.
+
+After the designer returns, the coordinator executes the fixed read-only validator:
+
+```text
+node .claude/nccgs/tools/task.mjs design-validate --id DESIGN --file .nccgs/evidence/analysis/DESIGN-contract.json
+```
+
+Use its returned `evidence` as the `design-contract` check and the contract JSON's
+`task ref` as the analysis stage's `evidence`; record the completed designer's actual
+runtime and dispatch. No arbitrary shell check is granted to a plan worker.
+A structurally valid BLOCKED document can be recorded and reviewed honestly.
+
+For a bounded revision, pin the baseline JSON in the plan intake's `sources` and
+run the fixed comparison before sending the candidate to the reviewer:
+
+```text
+node .claude/nccgs/tools/task.mjs design-compare --id DESIGN --baseline .nccgs/evidence/context/baseline.json --file .nccgs/evidence/analysis/DESIGN-contract.json
+```
+
+This command captures changed/added/removed requirement and criterion IDs, order
+changes and other changed top-level fields into immutable design-check evidence.
+It does not approve scope, interpret prose or claim PASS. Supply its receipt with
+the actual baseline and candidate to the reviewer; arbitrary plan shell remains
+blocked. A missing comparison cannot be deferred until after a conditional PASS.
+
+## /design-review — independent document acceptance
+
+Reserve the existing independent reviewer (`kind: "review"`) after analysis is
+recorded. Review the actual sources and full scoped contract, not just its schema:
+
+- Is the intended player experience translated into implementable behavior? Are
+  rules, states, formulas, interaction/edge cases and tuning ownership complete?
+- Does each required behavior have the right test, environment and justified
+  threshold? Are all requirements covered without adding unauthorized demands?
+- Are delivery obligations distinguished from product research? Does a bot loss
+  wrongly fail a functional test or block unrelated implementation? Does an early
+  checkpoint represent a real prerequisite rather than a late soak/balance result?
+  Do controlled scenarios test normal logic without directly injecting the expected
+  outcome? Are shipped values checked separately from test setup interventions?
+- Are bot diagnostics, technical checks, natural gameplay and human judgement
+  distinguished? Can a helper falsely pass while the player requirement fails?
+- Are decisions genuinely authorized, contradictions resolved, dependencies feasible
+  and deferred behavior really out of scope? Cite exact sources for findings.
+
+Return PASS, CHANGES_REQUIRED or BLOCKED with prioritized evidence and missing
+decisions. Be independent of the designer. A PASS requires READY/READY_WITH_RISKS
+and no unresolved blocking issue. A complete negative review is useful evidence.
+Every recorded design finding must include `acceptanceImpact`: `none`, `false-pass`,
+`missing-coverage` or `authority-gap`. A demonstrated way to pass a criterion while
+violating a scoped fixed requirement or delegated bound is a blocking acceptance
+gap, even if labelled MEDIUM or accepted as a risk. Missing required coverage or
+threshold authority is also blocking. Return CHANGES_REQUIRED/BLOCKED until the
+document is corrected and independently reviewed; never defer these gaps to QA
+after importing the deficient criteria. PASS rejects all unresolved acceptance
+impacts regardless of severity or ACCEPTED status. Ordinary nonblocking risks may
+use `none`. Semantic detection remains the reviewer's responsibility; this field
+does not turn structural validation into a semantic oracle.
+Use the existing review budget; do not mint tasks to reset attempts. A document
+revision requires fresh validation and independent review before a new handoff.
+Follow [review handoff](review-handoff.md). New policies bind verdict, criteriaMet,
+findings and remaining conditions to the completed reviewer's pinned JSON block.
+Pending acceptance work requires BLOCKED/CHANGES_REQUIRED, not a conditional PASS.
+
+## /story-readiness — gate before dependent implementation
+
+Check the approved scope, stable requirements, test mapping, decisions, dependencies,
+ownership, feasibility, protected paths and current source revisions. Preserve
+residual risks. A READY verdict describes the document, not a verified game.
+After positive independent review, record the plan's honest success report and
+close its gates through the CLI. Unresolved product decisions remain BLOCKED.
+
+The implementation intake references the closed plan:
+
+```json
+{ "schemaVersion": 1, "mode": "implement", "design": { "taskId": "DESIGN" } }
+```
+
+Initialization verifies the complete plan gates and pins its task, contract, sources,
+validation receipt and independent runtime evidence. It imports objective, scope,
+target, criteria, required checks and manual gates exactly. A conflicting override
+is rejected. Evidence changes invalidate the handoff; edits to the implementation
+source alone do not rewrite or invalidate the historical document review.
+
+New installs enable `designReviewRequired: true` in execution.json. With this policy,
+feature/cross-system implementation cannot reserve, launch, write source, verify
+or close without a current reviewed handoff. A ready local fix with explicit
+acceptance can proceed without a separate design task; do not misclassify new
+gameplay as a local fix. Structural controls cannot infer hidden semantic scope.
+Missing/false policy retains older obligations and is not evidence of design
+readiness. Existing projects opt in explicitly for fresh tasks; do not change a
+frozen task's pinned execution policy to retrofit approval. Compatibility branches
+retain their original design/approval process.

package/.claude/nccgs/protocols/evidence.md

@@ -14,8 +14,18 @@ build state. A changed baseline must be explained before closure.
 Subjective experience remains a Product Owner gate. Provide a reproducible scenario
 and what to observe; never fabricate validation.
 
-For astra-claude, every code change requires Fable review, including FAST work.
+For standalone execution, use [the standalone protocol](standalone.md): reports
+may honestly be partial, blocked or failed; only successful closure needs all gates.
+For compatibility execution with astra-claude, every code change requires Fable review, including FAST work.
 Record requested versus observed model/effort and the final dirty/untracked snapshot,
 not only a role label or commit ID. A Fable PASS permits reporting to Astra, not
 DONE. Astra's check and the Product Owner's explicit acceptance remain separate
 required evidence. See [the handoff protocol](astra-claude.md).
+
+Match verification to the criterion and concrete risk. Stop expanding evidence
+when approved criteria and relevant checks pass with no actionable blockers. Rerun
+only for changed inputs, failures, or new evidence; a repeated green run adds no
+new proof by itself. Reviewers cover distinct risks, not duplicate reassurance.
+If subjective questions remain, supply a playable observation scenario for the
+Product Owner. Exhausted review rounds require a recorded stop or explicit external
+extension; they never justify PASS or weaken the acceptance chain.

package/.claude/nccgs/protocols/model-routing.md

@@ -1,44 +1,46 @@
 # Model routing protocol
 
-Model choice is a quality and compatibility policy, not a status symbol.
-
-`.claude/nccgs/pipeline.json` is the source for routing. Catalog and frontmatter
-values are generated, checked for drift, and documented in
-[routing.generated.md](../routing.generated.md). Ten core roles load by default;
-35 optional roles remain in `agent-library/` until explicitly enabled. Activation
-is recorded in `.nccgs/agent-activation.json` and survives updates.
-
-## Capability classes
-
-The default profile is `astra-claude`: all Claude implementation/support roles use
-the pinned `claude-opus-5-5` model with `effort: xhigh`; the `review` class uses
-`fable` with `effort: high`. Astra is an external planning/document owner, not a
-Claude model alias. See [the required handoff sequence](astra-claude.md).
-
-`configure-models.mjs` applies both model and effort to agent frontmatter. For
-`astra-claude`, it also sets the project session model and effort in
-`.claude/settings.json`, preserving unrelated settings and backing up replaced
-settings. Existing sessions, local settings, environment variables, forced subagent
-routing, and provider restrictions may still override configuration; verify the
-actual runtime model/effort before recording a successful stage.
-
-- `lightweight`: indexing, state, formatting, deterministic documentation updates;
-- `standard`: implementation, focused design, tests, ordinary domain analysis;
-- `deep`: architecture, migration, adversarial reasoning, cross-domain conflicts;
-- `leadership`: product-wide creative, technical, or production synthesis.
-- `review`: independent adversarial review after implementation.
-
-Legacy `quality` uses Haiku for lightweight, Sonnet for standard, and Opus for
-deep/leadership/review. `balanced` moves routine leadership to Sonnet. `inherit`
-removes agent model and effort pins and uses the session settings. Legacy profiles
-do not change the main session settings. Selecting them explicitly opts out of the
-`astra-claude` chain; ordinary updates preserve an existing project's profile.
-
-Select the role first, then apply project model policy. Do not call Opus merely
-because a role sounds senior. Escalate when evidence shows cross-system ambiguity,
-irreversible risk, security implications, conflicting canon, or repeated failed
-hypotheses.
-
-Only legacy profiles may use an inherit fallback when project policy allows it.
-For `astra-claude`, unavailable or substituted model/effort blocks that stage; never
-present another model's result as Opus 5.5 implementation or Fable review.
+NCCGS runs in Claude Code. Resolve execution obligations independently of models.
+`pipeline.json` is the routing source; generated catalog/frontmatter and
+[routing.generated.md](../routing.generated.md) must match it. Thirteen roles
+load by default; 34 optional specialists remain in `agent-library/` until needed.
+
+## Standalone default
+
+| Risk | Implementation | Requested effort | Review rounds |
+|---|---|---|---|
+| FAST | Sonnet, lightweight class | medium | 2 |
+| STANDARD | Opus, standard class | medium | 3 |
+| CONTROLLED | Opus, deep class | high | 3 |
+
+Independent review uses Opus/high. These are family aliases, not claims about a
+particular resolved provider version. Runtime observations must identify actual
+Claude models. Unknown effort remains null unless project policy requires observed
+effort, in which case missing evidence blocks the stage. Never infer observed
+effort, model, duration or cost from configuration.
+
+Use `nccgs-fast-implementer` for bounded FAST work; use a domain programmer for
+STANDARD and `nccgs-unity-implementer` for CONTROLLED. A scout resolves one missing
+fact; it is optional. Do not promote work merely because a role sounds senior.
+The same model family may implement and review, but review must run in a separate
+observed agent invocation and consume a reserved review attempt.
+
+`configure-models.mjs` renders profile model/effort settings. Local settings,
+environment, provider restrictions and existing sessions may override them.
+Restart/recheck the real session after configuration changes. Classify and reserve
+before dispatch, then use the task's route. Do not silently fall back when a model
+is unavailable. Report the actual blocker and measurements.
+
+## Compatibility
+
+Missing `.nccgs/execution.json` means compatibility. Historical `astra-claude`
+retains Sonnet/medium for FAST, `claude-opus-5-5` medium/high for larger work,
+Fable/high review, external Astra check and explicit Product Owner acceptance.
+These historical identifiers are preserved configuration, not new availability
+claims. See [its protocol](astra-claude.md).
+
+`quality`, `balanced` and `inherit` remain available for historical workflows.
+Changing only a model profile cannot waive task gates. Standalone schema-2 tasks
+require explicit implementation/review families; an unpinned inherit route cannot
+prove them. Ordinary updates retain configuration. Use explicit execution migration
+to adopt standalone; historical task records and spent budgets remain intact.