nccgs 2.1.1 → 3.0.0-rc.2

package/.claude/nccgs/pipeline.json

@@ -1,260 +0,0 @@
-{
-  "schemaVersion": 1,
-  "defaultProfile": "claude-standalone",
-  "profiles": {
-    "astra-claude": {
-      "models": {
-        "lightweight": {
-          "model": "sonnet",
-          "effort": "medium"
-        },
-        "standard": {
-          "model": "claude-opus-5-5",
-          "effort": "medium"
-        },
-        "deep": {
-          "model": "claude-opus-5-5",
-          "effort": "high"
-        },
-        "leadership": {
-          "model": "claude-opus-5-5",
-          "effort": "high"
-        },
-        "review": {
-          "model": "fable",
-          "effort": "high"
-        }
-      },
-      "session": {
-        "class": "standard"
-      },
-      "activeAgents": [
-        "nccgs-fast-implementer",
-        "nccgs-task-scout",
-        "nccgs-game-designer",
-        "nccgs-gameplay-programmer",
-        "nccgs-engine-programmer",
-        "nccgs-ui-programmer",
-        "nccgs-unity-implementer",
-        "nccgs-unity-systems-specialist",
-        "nccgs-unity-ui-specialist",
-        "nccgs-unity-build-specialist",
-        "nccgs-qa-engineer",
-        "nccgs-verification-engineer",
-        "nccgs-adversarial-reviewer"
-      ]
-    },
-    "quality": {
-      "models": {
-        "lightweight": {
-          "model": "haiku",
-          "effort": null
-        },
-        "standard": {
-          "model": "sonnet",
-          "effort": null
-        },
-        "deep": {
-          "model": "opus",
-          "effort": null
-        },
-        "leadership": {
-          "model": "opus",
-          "effort": null
-        },
-        "review": {
-          "model": "opus",
-          "effort": null
-        }
-      },
-      "session": null,
-      "activeAgents": "all"
-    },
-    "balanced": {
-      "models": {
-        "lightweight": {
-          "model": "haiku",
-          "effort": null
-        },
-        "standard": {
-          "model": "sonnet",
-          "effort": null
-        },
-        "deep": {
-          "model": "opus",
-          "effort": null
-        },
-        "leadership": {
-          "model": "sonnet",
-          "effort": null
-        },
-        "review": {
-          "model": "opus",
-          "effort": null
-        }
-      },
-      "session": null,
-      "activeAgents": "all"
-    },
-    "inherit": {
-      "models": {
-        "lightweight": {
-          "model": null,
-          "effort": null
-        },
-        "standard": {
-          "model": null,
-          "effort": null
-        },
-        "deep": {
-          "model": null,
-          "effort": null
-        },
-        "leadership": {
-          "model": null,
-          "effort": null
-        },
-        "review": {
-          "model": null,
-          "effort": null
-        }
-      },
-      "session": null,
-      "activeAgents": "all"
-    },
-    "claude-standalone": {
-      "models": {
-        "lightweight": {
-          "effort": "high",
-          "model": "sonnet"
-        },
-        "standard": {
-          "effort": "high",
-          "model": "opus"
-        },
-        "deep": {
-          "effort": "xhigh",
-          "model": "opus"
-        },
-        "leadership": {
-          "effort": "xhigh",
-          "model": "opus"
-        },
-        "review": {
-          "effort": "high",
-          "model": "fable"
-        }
-      },
-      "session": {
-        "class": "standard"
-      },
-      "activeAgents": [
-        "nccgs-fast-implementer",
-        "nccgs-task-scout",
-        "nccgs-game-designer",
-        "nccgs-gameplay-programmer",
-        "nccgs-engine-programmer",
-        "nccgs-ui-programmer",
-        "nccgs-unity-implementer",
-        "nccgs-unity-systems-specialist",
-        "nccgs-unity-ui-specialist",
-        "nccgs-unity-build-specialist",
-        "nccgs-qa-engineer",
-        "nccgs-verification-engineer",
-        "nccgs-adversarial-reviewer"
-      ]
-    }
-  },
-  "contract": {
-    "planningOwner": "Astra",
-    "documentsOwner": "Astra",
-    "reviewAgent": "nccgs-adversarial-reviewer",
-    "sequence": [
-      "astra-plan",
-      "risk-routed-implementation",
-      "fable-review",
-      "report-to-astra",
-      "astra-check",
-      "product-owner-acceptance"
-    ],
-    "requiredForAllCodeChanges": true,
-    "allowInheritFallback": false,
-    "taskTiers": {
-      "FAST": {
-        "implementationClass": "lightweight",
-        "maxReviewRounds": 2
-      },
-      "STANDARD": {
-        "implementationClass": "standard",
-        "maxReviewRounds": 3
-      },
-      "CONTROLLED": {
-        "implementationClass": "deep",
-        "maxReviewRounds": 3
-      }
-    },
-    "astraWorkflows": [
-      "design",
-      "context-pack",
-      "plan-feature",
-      "architecture-decision",
-      "closure",
-      "qa-plan",
-      "project-stage",
-      "sprint-plan",
-      "milestone-review",
-      "retrospective"
-    ],
-    "reviewWorkflows": [
-      "review",
-      "nccgs-code-review"
-    ]
-  },
-  "snapshotExcludes": [
-    ".git",
-    ".nccgs",
-    "Library",
-    "Temp",
-    "Logs",
-    "obj",
-    "node_modules",
-    ".vs"
-  ],
-  "coreAgents": [
-    "nccgs-fast-implementer",
-    "nccgs-task-scout",
-    "nccgs-game-designer",
-    "nccgs-gameplay-programmer",
-    "nccgs-engine-programmer",
-    "nccgs-ui-programmer",
-    "nccgs-unity-implementer",
-    "nccgs-unity-systems-specialist",
-    "nccgs-unity-ui-specialist",
-    "nccgs-unity-build-specialist",
-    "nccgs-qa-engineer",
-    "nccgs-verification-engineer",
-    "nccgs-adversarial-reviewer"
-  ],
-  "executionPolicies": {
-    "standalone": {
-      "reviewAgent": "nccgs-adversarial-reviewer",
-      "documentsOwner": "Claude Code",
-      "runtime": "claude-code",
-      "sequence": [
-        "intake",
-        "plan",
-        "implementation",
-        "verification",
-        "independent-review",
-        "report",
-        "optional-external-review",
-        "contract-acceptance"
-      ],
-      "planningOwner": "Claude Code"
-    },
-    "compatibility": {
-      "contract": "astra-claude",
-      "runtime": "claude-code"
-    }
-  }
-}

package/.claude/nccgs/protocols/agent-contract.md

@@ -1,101 +0,0 @@
-# NCCGS agent contract
-
-All studio agents use this contract in addition to their role file.
-
-## Inputs
-
-For standalone execution, first read `protocols/standalone.md`; the coordinator
-reserves every worker and owns lifecycle records. Audit/plan/review workers may
-write only declared analysis artifacts. Return facts and unresolved findings.
-
-For compatibility execution with `astra-claude`, first read `protocols/astra-claude.md` relative to
-`.claude/nccgs/`. Astra supplies planning and canonical documents. Claude produces
-implementation, evidence, and handoff reports; Fable independently reviews. Never
-impersonate Astra or infer Product Owner acceptance.
-
-Before acting, obtain the task objective and risk tier, project authority and
-ownership, the focused context packet for STANDARD or CONTROLLED work, exact owned
-files/evidence, dependencies, and unresolved Product Owner decisions.
-
-If an input is absent, inspect only enough to recover it. Do not broaden the task or
-load every project document.
-
-## Boundaries
-
-- Stay inside the role's domain and assigned write set.
-- Do not recursively spawn or delegate to another agent. Return a handoff to the
-  primary orchestrator when another specialty is needed.
-- Do not make gameplay, canon, scope, dependency, compatibility, or subjective
-  acceptance decisions reserved for the Product Owner.
-- Do not overwrite another active role's paths.
-- Preserve unrelated changes and report discovered overlap.
-
-## Work standard
-
-For design documents, document review or story readiness in standalone execution,
-follow [the design lifecycle](design-lifecycle.md), including semantic coverage,
-decision authority and the reviewed handoff. Schema validation alone is not review.
-
-For technical planning, coding, code review or code-debt maintenance, read the
-relevant module selected by the [shared Ponytail package](../packages/ponytail/README.md)
-before acting. This applies in either execution policy. Game design, document
-readiness and QA/acceptance do not use Ponytail as their procedure. For bounded
-repair, the coordinator applies the package before pinning the solution; the
-worker follows the supplied packet without extra package reads or diagnosis.
-
-Separate facts, inferences, recommendations, edits, and evidence. Follow project
-patterns before generic preferences. Use official Unity Skills for Unity operation
-mechanics. Record deviations instead of silently normalizing the project.
-
-Do not add speculative scope. Use the scout only to answer a specific missing fact,
-and propose another reviewer only for a distinct risk. Stop once assigned criteria
-and relevant checks pass without actionable blockers. Rerun checks only when
-inputs change, a failure needs resolution, or new evidence warrants it. Subjective
-questions should become a playable Product Owner test. Return budget exhaustion
-with evidence and unresolved findings; do not spend more rounds or infer approval.
-General context/time guidance is advisory; task review-round limits are enforced
-separately. A bounded repair packet additionally enforces its tool-call allowances
-and deadline at each tool admission. Its chosen solution, exact source files and
-handoff are the assignment. General shell, MCP, web, nested delegation and unplanned
-experiments are blocked. A typed Unity packet may permit only its fixed
-`repair-editor` wrapper; follow [bounded repair](bounded-repair.md). Return PARTIAL if diagnosis is still
-needed. The coordinator owns verification after the edits. Follow the injected
-packet and use remaining tool allowances to hand off before native turn exhaustion.
-
-## Required handoff
-
-For a [planned slice](task-slices.md), follow its injected objective, exact files,
-dependency dispatches and original criterion definitions. Keep global constraints.
-Return a complete bounded handoff or honest PARTIAL; only the coordinator records
-the integrated task. A slice handoff is not acceptance and grants no fresh budget.
-
-When the reservation declares handoffPaths, write a concise draft to the assigned
-path early, before extended investigation. Start it with `NCCGS-HANDOFF: PARTIAL`.
-Update it as facts become available. Reserve your final few turns for the handoff;
-do not spend a bounded worker invocation polling engine jobs owned by the coordinator.
-Replace that line with `NCCGS-HANDOFF: COMPLETE` only after the assigned bounded
-work is finished and remaining product failures are explicitly documented. A complete
-negative review is valid; COMPLETE is not a product PASS or permission to close DONE.
-Missing/partial handoffs fail the attempt even when native transport says completed.
-Native harness turn exhaustion also makes the attempt incomplete even if the file
-says COMPLETE. For every review assignment follow [review handoff](review-handoff.md):
-the reviewer owns the structured verdict and explicit remaining conditions; a
-conditional PASS is not permitted under the new standalone review policy.
-
-Use the supplied PARTIAL template when available. Before returning, non-repair
-workers may run the fixed read-only `task handoff-validate` command for their own
-declared handoff. It catches structural errors while the worker can still correct
-its draft; VALID is not completion or acceptance. Run it as a plain
-`node .claude/nccgs/tools/task.mjs` invocation. Repair workers keep their existing
-tool budget and no-shell boundary. See [handoff operations](../../../docs/HANDOFF-AUTOMATION.md).
-
-For unfinished work, leave PARTIAL with exact next steps and return. Continuation
-uses a fresh foreground reservation and fresh handoff path within the existing
-remaining dispatch/purpose budget. The coordinator must carry forward the previous
-attempt and its findings. Never resume a worker outside reservation tracking, edit
-its captured handoff after completion, reset quota, or spend protected repair slots
-on extra ordinary delivery. Stop partial if no eligible attempt remains.
-
-Return: **Outcome**, **Changed/produced**, **Evidence**, **Risks and deviations**,
-**Decisions needed**, and **Next owner**. Do not claim `DONE`; only the closure
-workflow evaluates final project gates.

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

@@ -1,111 +0,0 @@
-# Astra planning, Claude implementation, Fable review
-
-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.
-
-Runtime routing comes only from `pipeline.json`; [generated routing](../routing.generated.md)
-is its readable view. Use [task gates](task-gates.md) to initialize, record, check,
-and close work. The authoritative task JSON and artifact hashes, not Markdown
-status labels, determine whether reporting or DONE is allowed.
-
-## Ownership
-
-- **Astra** owns planning, feature contracts, context packets, architecture decisions,
-  canonical documents, and the final check of Claude's 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
-  acceptance, together with all technical gates, permits DONE.
-
-Claude may sequence local implementation steps inside Astra's plan. It must not
-replace the plan or author canonical planning/design documents. Report proposed
-document changes to Astra. Evidence logs, review records, implementation reports,
-and factual progress checkpoints are permitted Claude outputs. Planning-only roles
-remain available as technical consultants, not substitutes for Astra ownership.
-
-## Required sequence for every code change
-
-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. 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.
-   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
-   using `.nccgs/templates/implementation-report.md`, preserving the independent
-   review verbatim or linking its record. Mark phase `AWAITING_ASTRA_CHECK` and hand
-   the report path to Astra. Do not claim it was sent across applications without
-   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
-   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
-   renewed review/check/acceptance for the changed snapshot.
-
-These phases are workflow checkpoints, not replacements for IMPLEMENTED, VERIFIED,
-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 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.
-An unavailable Fable review is not a PASS. Do not confuse configuration with proof
-of execution: record requested and observed models/efforts, session/agent IDs,
-reviewed snapshot, commands/results, unresolved findings, and acceptance references.
-
-This is a file-backed workflow contract, not an automatic cross-application bridge.
-NCCGS does not start an Astra session or send messages to an external service itself.