@danmoisan/drm-copilot-mcp 1.1.17 → 1.1.19

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@danmoisan/drm-copilot-mcp",
-  "version": "1.1.17",
+  "version": "1.1.19",
   "description": "Stdio MCP server exposing drm-copilot repo-automation tools.",
   "license": "MIT",
   "type": "commonjs",
@@ -38,16 +38,18 @@
     "prepack": "node prepack.cjs"
   },
   "overrides": {
-    "fast-uri": "^3.1.4",
+    "fast-uri": "^3.1.8",
+    "proxy-addr": "^2.0.8",
     "hono": "^4.12.27",
     "ip-address": "^10.7.2",
     "qs": "^6.15.2",
-    "@hono/node-server": "^2.0.5"
+    "@hono/node-server": "^2.0.5",
+    "brace-expansion": "^5.0.12"
   },
   "devDependencies": {
     "esbuild": "^0.28.0"
   },
   "dependencies": {
-    "@modelcontextprotocol/sdk": "^1.29.0"
+    "@modelcontextprotocol/sdk": "^1.31.0"
   }
 }

package/resources/claude-customizations/.claude/agents/atomic-executor.md

@@ -82,6 +82,17 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
 When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform only format and structure validation. Return exactly one of:

package/resources/claude-customizations/.claude/agents/atomic-planner.md

@@ -55,6 +55,16 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number. Every plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
 Before handing the plan to executor preflight, return the exact bounded line record defined in `atomic-plan-contract`, starting with `PLANNER-INTERNAL-REVIEW: PASS` and ending with the required `PREFLIGHT:` signal. The bounded record must include exactly one passing `CITATION-TO-TREE`, `AC-TRACEABILITY`, and `SCOPE-BOUNDARY` declaration; one or more current-tree `CITATION: <repository-relative path> | <locator>` records; one complete unique `AC-INVENTORY:`; one complete `AC-MAPPING: <ID> | IMPLEMENTATION: <identifier> | TESTS: <identifier> | EVIDENCE: <identifier>` for every and only inventory ID; and exactly one `UNRESOLVED-GAPS: NONE`. A missing, duplicate, malformed, failed, blocked, or out-of-bounds record declaration requires `SELF-REVIEW: BLOCKED` and stops handoff.

package/resources/claude-customizations/.claude/agents/epic-orchestrator.md

@@ -121,10 +121,18 @@ rejecting cyclic or unresolved `depends_on` references before kickoff as a synth
 finding. `scripts/dev_tools/epic_wave_computation.py` is the canonical, tested reference
 implementation of this formula. Within a wave, launch all features concurrently (one message, N `Agent` calls, each
 `isolation: "worktree"` and `run_in_background: true`). Do not launch wave N+1 until every wave-N
-feature's dependency edges are durably confirmed `merged` or `worktree_removed` — this durable
-confirmation is enforced both by the `enforce-epic-wave-barrier.ps1` per-call deterrent and the
-retrospective wave-barrier ordering check inside `validate_epic_orchestrator_state_text`, invoked
-at your own `SubagentStop` time.
+feature's dependency edges are durably confirmed `merged` or `worktree_removed`. This durable
+confirmation is enforced both by the `enforce-epic-wave-barrier.ps1` per-call deterrent and by the
+retrospective wave-barrier ordering check, which runs at your own `SubagentStop` time as
+`Get-OrchestratorStateEpicWaveBarrierError` in
+`.claude/lib/orchestrator-state/OrchestratorStateEpicWaveBarrier.psm1`, a PowerShell port of the
+check inside `validate_epic_orchestrator_state_text` invoked by
+`.claude/hooks/validate-orchestrator-output.ps1`; parity is pinned by
+`tests/fixtures/epic_wave_barrier/`, and the Python validator remains the authority used through
+the `mcp__drm-copilot__validate_orchestration_artifacts` call. If the check reports a violation,
+report it to the operator and halt. The `SubagentStop` transport and exit-code defect this check
+previously depended on was resolved by epic #904 and issue #928: a violation blocks the stop with
+exit 2 and a stderr reason.
 
 ## Checkpoint Persistence
 

package/resources/claude-customizations/.claude/agents/epic-planner.md

@@ -104,10 +104,11 @@ the prepared epic, per the template in the `epic-plan` skill.
 ## Checkpoint Persistence
 
 Update `artifacts/orchestration/epic-planner-state.json` after every completed step with:
-`objective`, `epic_feature_folder`, `epic_manifest_path`, `integration_branch`, `epic_issue_num`,
-`epic_worthiness` (`{verdict, rationale}`), `features[]` (per-feature `issue_num`,
-`feature_folder`, `depends_on`, `wave`, `complexity_band`, `preparation_status`, `plan_path`,
-`preflight_status`), `kickoff_prompt_path`, `completed_steps`, `next_step`, and `last_updated`.
+`objective`, `epic_feature_folder`, `epic_manifest_path`, `integration_branch`,
+`max_parallel_features`, `epic_issue_num`, `epic_worthiness` (`{verdict, rationale}`),
+`features[]` (per-feature `issue_num`, `feature_folder`, `depends_on`, `wave`, `complexity_band`,
+`preparation_status`, `research_path`, `plan_path`, `preflight_status`), `kickoff_prompt_path`,
+`completed_steps`, `next_step`, and `last_updated`.
 `epic_issue_num` is the epic-level issue `epic-planner` promotes at planning time through `mcp__drm-copilot__potential_to_issue` with `promotion_type: epic` (issue #663; see `## Epic-Level Issue Promotion` in the `epic-plan` skill).
 
 ## Completion Requirements

package/resources/claude-customizations/.claude/agents/feature-review.md

@@ -9,6 +9,7 @@ tools:
   - "Bash(git diff *)"
   - "Bash(git log *)"
   - "Write(/docs/features/active/**)"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - acceptance-criteria-tracking
@@ -32,7 +33,12 @@ When the active review scope is a selected version folder such as `docs/features
 1. `docs/features/active/<feature-or-selected-version>/policy-audit.<timestamp>.md` — policy compliance audit with PASS/PARTIAL/FAIL verdicts and evidence
 2. `docs/features/active/<feature-or-selected-version>/code-review.<timestamp>.md` — code quality review covering best practices
 3. `docs/features/active/<feature-or-selected-version>/feature-audit.<timestamp>.md` — acceptance criteria verification relative to baseline
-4. If remediation is needed: `docs/features/active/<feature-or-selected-version>/remediation-inputs.<timestamp>.md` with explicit remediation-required findings and artifact paths
+4. For every review with at least one blocking finding, including halt (`HALT_NON_REMEDIABLE`) and wait (`AWAITING_CI`) verdicts: `docs/features/active/<feature-or-selected-version>/remediation-inputs.<timestamp>.md` with explicit remediation-required findings and artifact paths. The file carries these line formats:
+   - one line `Review-Verdict: <VERDICT>`, where the verdict is `PASS`, `REMEDIATION_REQUIRED`, `HALT_NON_REMEDIABLE`, or `AWAITING_CI`,
+   - inside each blocking finding block, one line `Remediability: <class>`, where the class is `autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, or `human_decision_required` (`autonomous` when the line is absent),
+   - inside each blocking finding block, one line `Remediability-Evidence: <text>` stating why the class applies.
+
+   These lines, including the evidence text, never contain the substrings the orchestrator counts when it counts blocking findings, so their presence does not change the blocking count. The verdict follows from the classes: no blocking finding is `PASS`; any `autonomous` finding is `REMEDIATION_REQUIRED`; otherwise any `external_dependency`, `policy_hold`, or `human_decision_required` finding is `HALT_NON_REMEDIABLE`; otherwise `AWAITING_CI`.
 
 Timestamp format: `yyyy-MM-ddTHH-mm` (ISO-8601).
 
@@ -44,6 +50,9 @@ Report the required artifact paths in the final response using these tokens:
 - `code-review-path: docs/features/active/<feature-or-selected-version>/code-review.<timestamp>.md`
 - `feature-audit-path: docs/features/active/<feature-or-selected-version>/feature-audit.<timestamp>.md`
 - When remediation inputs are produced: `remediation-inputs-path: docs/features/active/<feature-or-selected-version>/remediation-inputs.<timestamp>.md`
+- Optional: `review-status: <VERDICT>` with the same verdict as the remediation inputs (`PASS` when none were produced). The orchestrator treats the remediation inputs as authoritative and this token as a cross-check.
+
+Validate each review artifact immediately after writing it with `mcp__drm-copilot__validate_orchestration_artifacts`, passing `artifact_path` set to that artifact: use `artifact_type: "policy-audit"` for `policy-audit.<timestamp>.md`, `artifact_type: "code-review"` for `code-review.<timestamp>.md`, and `artifact_type: "feature-audit"` for `feature-audit.<timestamp>.md`. When the validator reports a failure, fix the artifact in the same review and validate it again. Report an artifact path only after its validation passes.
 
 ## Context Sources
 
@@ -107,7 +116,7 @@ Coverage metrics are mandatory for every language that has changed files in the
 
 ### Coverage Thresholds
 
-Coverage thresholds follow the uniform tier rule (Authoritative Decision #2) defined in `.claude/rules/quality-tiers.md`:
+Coverage thresholds follow the threshold precedence defined in `.claude/rules/quality-tiers.md` and `.claude/rules/general-unit-test.md`: when the repository's root `CLAUDE.md` states line or branch coverage thresholds, those thresholds govern; otherwise the default thresholds below govern. Each metric falls back independently: when the root `CLAUDE.md` states only a line threshold or only a branch threshold, the stated threshold governs that metric and the default below governs the other. The thresholds that govern under this precedence are the governing thresholds referred to in the Verification Procedure below. The defaults are:
 
 - **New code files** (files added in this feature, not previously existing): line coverage >= 85%, branch coverage >= 75% for branch-capable languages.
 - **Modified files** (files that existed before and were changed): line coverage >= 85%, branch coverage >= 75% for branch-capable languages, and no regression on changed lines relative to baseline.
@@ -115,6 +124,8 @@ Coverage thresholds follow the uniform tier rule (Authoritative Decision #2) def
 
 Tier-specific lower thresholds are not used.
 
+Tier classification findings: report a missing or incomplete `quality-tiers.yml` only when the repository has adopted tiers, that is, when `quality-tiers.yml` exists at the repository root on the resolved base branch or the repository's CI runs a tier-classification check. Otherwise record tier classification as not applicable; it is not a finding.
+
 The branch threshold applies only to branch-capable languages — TypeScript, Python, and C#. PowerShell is a coverage language and is fully subject to the line threshold and the no-regression requirement, but Pester measures command (instruction) coverage and line coverage only, so no branch percentage exists to evaluate and no branch threshold applies to it (see `.claude/rules/powershell.md`). Do not record FAIL for an absent PowerShell branch figure.
 
 ### Verification Procedure
@@ -125,9 +136,9 @@ For each language that has changed files in the feature branch:
 2. Check whether the coverage artifact exists for that language.
 3. If the artifact exists:
    - Parse the repo-wide coverage percentage and report it in the policy audit.
-   - If repo-wide coverage is below 80%, flag as FAIL and add to remediation triggers.
-   - For each new file: if line coverage is below 90%, flag as FAIL and add to remediation triggers.
-   - For each modified file: if line coverage has regressed from baseline or is below 80%, flag as FAIL and add to remediation triggers.
+   - If repo-wide line or branch coverage is below the governing repo-wide thresholds defined in Coverage Thresholds, flag as FAIL and add to remediation triggers.
+   - For each new file: if line or branch coverage is below the governing new-file thresholds defined in Coverage Thresholds, flag as FAIL and add to remediation triggers.
+   - For each modified file: if coverage on changed lines has regressed from baseline, or line or branch coverage is below the governing modified-file thresholds defined in Coverage Thresholds, flag as FAIL and add to remediation triggers.
 4. If no coverage artifact is found for a language that has changed files, flag as **FAIL** with reason: "coverage artifact absent for [language]; coverage verification is mandatory for all languages with changed files." Add to remediation triggers.
 
 The agent does NOT rerun coverage generation. Evidence verification from existing artifacts is the required model.

package/resources/claude-customizations/.claude/agents/orchestrator.md

@@ -96,7 +96,9 @@ PR creation and PR body edits must be delegated to `Agent(pr-author)`. The orche
 
 When the orchestrator runs the remediation loop, it records a top-level `remediation_loop` object in `artifacts/orchestration/orchestrator-state.json`:
 
-- `current_cycle` — integer index of the active cycle.
+- `current_cycle` — integer index of the active cycle's record in `cycles[]`; a record position, not an attempt count.
+- `completed_attempts` — non-negative integer equal to the number of cycles whose `candidate_applied` is `true`. This is the shared attempt count for local, CI-failure, merge-conflict, and parallel-drift cycles; the guard halts after three completed attempts.
+- `review_outcomes[]` — one entry per review, including `PASS`, appended in order. Each entry is an object with `verdict` (one of `PASS`, `REMEDIATION_REQUIRED`, `HALT_NON_REMEDIABLE`, `AWAITING_CI`) and `findings[]`, the review's blocking findings only, each an object with `remediability` (one of `autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, `human_decision_required`). An optional `inputs_path` names the `remediation-inputs` file.
 - `cycles[]` — an ordered array of cycle records. Each cycle is an object with:
   - `entry_timestamp` — ISO-8601 timestamp when the cycle was entered.
   - `inputs_path` — path to the `remediation-inputs.<entry-ts>.md` that opened the cycle.
@@ -106,18 +108,29 @@ When the orchestrator runs the remediation loop, it records a top-level `remedia
   - `audit_paths` — the reaudit artifact paths produced at cycle exit (`code-review`, `feature-audit`, `policy-audit`).
   - `blocking_count` — the total number of blocking findings across the reaudit artifacts.
   - `exit_condition_met` — boolean; `true` only when the cycle's exit gate is satisfied.
+  - `candidate_applied` — boolean; `true` only for a completed attempt (execution `complete` and a non-empty pre-reaudit commit). A cycle without a candidate records `false` and consumes no attempt number.
+  - `opened_by_review` — zero-based index of the `review_outcomes[]` entry that opened the cycle.
+
+These four fields are recorded by producers. Verdicts follow from the classes of a review's blocking findings: none is `PASS`; any `autonomous` is `REMEDIATION_REQUIRED`; otherwise any `external_dependency`, `policy_hold`, or `human_decision_required` is `HALT_NON_REMEDIABLE`; otherwise `AWAITING_CI`. A `HALT_NON_REMEDIABLE` or `AWAITING_CI` review opens no cycle.
 
 Malformed-cycle rules:
 
 - `plan_path` must be a non-empty string.
 - `execution_status` may be in `{in_progress, complete, failed}` only when `preflight.final_status == 'clear'`; any other preflight status with one of those execution statuses is malformed (execution recorded before preflight cleared).
 - `exit_condition_met == true` requires `blocking_count == 0`; a non-zero `blocking_count` with `exit_condition_met == true` is malformed.
+- R5: `candidate_applied`, when present, must be a boolean.
+- R6: `candidate_applied == true` requires `execution_status == "complete"`.
+- R7: `completed_attempts`, when present, must be a non-negative integer equal to the number of object cycles whose `candidate_applied` is `true`.
+- R8: `review_outcomes`, when present, must be a list, and each entry must be an object.
+- R9: each outcome's `verdict` must be one of the four verdicts, its `findings` must be a list, and each finding must be an object whose `remediability` is one of the five classes (case-sensitive).
+- R10: each well-formed outcome's `verdict` must equal the verdict derived from its findings' classes.
+- R11: `opened_by_review`, when present, must be a non-negative integer that indexes an object entry of `review_outcomes` whose `verdict` is `REMEDIATION_REQUIRED`.
 
-Cycle-aware `next_step` uses the form `remediation.cycle_N.{plan,preflight,execute,reaudit,exit_check}`, where `N` is the cycle index and the sub-step names the current position in the loop.
+Cycle-aware `next_step` uses the form `remediation.cycle_N.{plan,preflight,execute,reaudit,exit_check}`, where `N` is `completed_attempts + 1` (the active cycle number) and the sub-step names the current position in the loop; `current_cycle` remains a record position in `cycles[]`.
 
 ### CI Monitoring and Post-PR Remediation
 
-After the PR is opened, the orchestrator monitors the required CI checks against the live PR head SHA. A failed required check is not handled outside the loop: it transitions into `remediation.cycle_N+1.inputs` (written as a `remediation-inputs.<timestamp>.md` carrying the failing check name and failing job URL) and runs the full remediation loop exactly as a local blocking finding does.
+After the PR is opened, the orchestrator monitors every CI check on the live PR head SHA. A failed check is not handled outside the loop: it transitions into `remediation.cycle_N+1.inputs` (written as a `remediation-inputs.<timestamp>.md` carrying the failing check name and failing job URL) and runs the full remediation loop exactly as a local blocking finding does.
 
 Workflow-file changes go through the remediation loop and trigger the `modified-workflow-needs-green-run` policy rule, which requires a green workflow run against the branch head before the change can merge.
 
@@ -149,7 +162,7 @@ A new finding discovered during execution triggers a NEW cycle with a follow-up
 
 ### Exit Gate
 
-`blocking_count` is the total of FAIL and blocking-PARTIAL findings across the three reaudit artifacts (`code-review`, `feature-audit`, `policy-audit`). Only `blocking_count == 0` sets `exit_condition_met = true`. A non-zero `blocking_count` leaves the gate unmet and opens the next cycle.
+`blocking_count` is the total of FAIL and blocking-PARTIAL findings across the three reaudit artifacts (`code-review`, `feature-audit`, `policy-audit`). Only `blocking_count == 0` sets `exit_condition_met = true`. The exit gate counts only `autonomous` blocking findings when deciding whether to open the next cycle: a non-zero count of `autonomous` blocking findings leaves the gate unmet and opens the next cycle, while remaining blocking findings that are all non-remediable halt (`HALT_NON_REMEDIABLE`) or wait (`AWAITING_CI`) instead of opening a cycle.
 
 ### Citations
 
@@ -160,10 +173,11 @@ This protocol follows the remediation-handoff skill and the strict-handoff memor
 Update `artifacts/orchestration/orchestrator-state.json` after every completed step with:
 
 - `objective`, `change_budget_estimate`, `path_selected` (small or large)
-- Variables: `promotion-type`, `short-name`, `issue-num`, `feature-folder`
-- `completed_steps`, `next_step`, `last_updated`
-- Step statuses: `step5_status` through `step10_status`
+- Variables: `promotion-type`, `short-name`, `relativeFile`, `long-name`, `issue-num`, `feature-folder`, `work-mode`, `plan-path`
+- `completed_steps`, `next_step`, `last_updated` (ISO-8601 UTC date-time string, rewritten on every checkpoint write)
+- Step statuses: `step5_status`, `step6_status`, `step7_status`, `step8_status`, `step9_status`, `step10_status`
 - `delegation_receipts`, `blocked_reason`
+- The complete required-key set and the `last_updated` contract are defined in `.claude/rules/orchestrator-state.md` under `## Required Top-Level Keys`.
 - Persist raw promotion MCP receipts under:
   - `delegation_receipts.promotion.potential_entry`
   - `delegation_receipts.promotion.issue`

package/resources/claude-customizations/.claude/agents/parallel-orchestrator.md

@@ -13,14 +13,15 @@ tools:
   - "Edit(artifacts/orchestration/**)"
   - "Bash(git *)"
   - "Bash(gh *)"
-  - "Bash(poetry run python -c *)"
-  - "Bash(poetry run python -m *)"
   - "Bash(bash .claude/lib/bash/compute-cohorts.sh*)"
   - "Bash(bash .claude/lib/bash/compute-concurrency-batches.sh*)"
   - "Bash(bash .claude/lib/bash/validate-parallel-manifest.sh*)"
   - "Bash(bash .claude/lib/bash/abandon-parallel-item.sh*)"
+  - "Bash(bash .claude/lib/bash/remove-parallel-item.sh*)"
+  - "Bash(bash .claude/lib/bash/mutate-parallel-run.sh*)"
   - "Bash(pwsh -NoProfile -File .claude/lib/project-file-merge/Resolve-MergeableConflict.ps1*)"
   - "Bash(pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-drift/Invoke-ParallelDriftDetection.ps1*)"
+  - "Bash(pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-CiGateParser.ps1*)"
   - "Bash(dotnet tool restore*)"
   - "Bash(dotnet csharpier check *)"
   - "Bash(dotnet build *)"
@@ -95,17 +96,20 @@ reference; it is not invoked on the destination-runtime path. Cohort recoloring
 batching use `compute-cohorts.sh` and `compute-concurrency-batches.sh` under the same allowlist
 entry.
 
-The `poetry run` grants remain for the repository-local paths that still need an interpreter. The
-skill's `## Parallel-Level Checkpoint` section validates through
-`mcp__drm-copilot__validate_orchestration_artifacts`, and since issue #763 radius drift detection runs
+No `poetry run python` grant is held. The inline-code (`-c`) grant was removed under issue #890
+after `parallel-add`, `parallel-close`, and `parallel-orchestrate` moved their engine calls to the
+bundled entry point `.claude/lib/bash/mutate-parallel-run.sh`, and the former module-form (`-m`)
+grant was removed under issue #791; in both cases no skill in this agent's caller set still invokes
+Python through the grant. The skill's
+`## Parallel-Level Checkpoint` section validates through
+`mcp__drm-copilot__validate_orchestration_artifacts`; since issue #763 radius drift detection runs
 through the destination-runtime PowerShell entry point
 `.claude/lib/parallel-drift/Invoke-ParallelDriftDetection.ps1` and the abandon disposition through the
-bundled entry point `.claude/lib/bash/abandon-parallel-item.sh`, so no skill step names a
-`poetry run` consumer. The two `poetry run python` grants are left unchanged pending a separate
-removal decision. Each grant stays scoped to its own `poetry run python` invocation form — not to
-`poetry run` as a whole — so `pytest`, `black`, `ruff`, and every other `poetry run` subcommand
-remain outside the allowlist. The sibling persona `.claude/agents/parallel-planner.md` records the
-same destination-runtime posture.
+bundled entry point `.claude/lib/bash/abandon-parallel-item.sh`; since issue #791 the
+`parallel-remove` decide, recolor, and entry steps run through the bundled entry point
+`.claude/lib/bash/remove-parallel-item.sh`; and since issue #890 the add, close, and requeue steps
+run through the bundled entry point `.claude/lib/bash/mutate-parallel-run.sh`. The sibling persona `.claude/agents/parallel-planner.md`
+records the same destination-runtime posture.
 
 ## Startup Protocol
 
@@ -176,8 +180,22 @@ parameters:
 - `isolation: "worktree"` — the item runs in its own isolated git worktree.
 - `run_in_background: true` — items within a cohort run concurrently up to `max_concurrency`.
 - branch base `origin/main` — every item in a cohort branches from the same recorded `main` tip.
-- `model` — bound to that item's model routing receipt, resolved per the skill's
-  `## Model Selection` section.
+- `model` — read the item's `complexity_band` and `model_routing_receipt` from the planner
+  checkpoint `artifacts/orchestration/parallel-planner-state.json`; when that checkpoint is
+  unavailable, use the committed kickoff artifact's `## Item Summary` `complexity` column as the
+  fallback band source. Pass the receipt's `model` when the run's `fable_policy` equals the
+  receipt's `fable_policy`; otherwise re-resolve with
+  `Resolve-DelegationModel -Agent orchestrator -Band <band> -FablePolicy <run fable_policy>` and
+  pass that result, per the skill's `## Model Selection` section.
+  For an item admitted through `/parallel-add`, which is absent from the planner checkpoint
+  `items[]` and from the kickoff `## Item Summary`, read the band from that item's
+  `complexity_band` on the orchestrator checkpoint
+  `artifacts/orchestration/parallel-orchestrator-state.json` `items[]`. Such an item carries no
+  `model_routing_receipt`, so resolve `model` at spawn time as
+  `model_policy.complexity_to_model[<band>]` from `config/orchestration-routing.json` under the
+  run's `fable_policy`, with `fable` clamped to `opus` when `fable_policy` is `disabled`, and pass
+  that explicit `model` on the spawn. When the admitted item has no `complexity_band` on the
+  orchestrator checkpoint, stop rather than spawn without `model`.
 
 Each child `orchestrator` runs its own route inside that worktree, including its own delegations to
 `atomic-planner`, `atomic-executor`, `feature-review`, and `pr-author`. You do not delegate to
@@ -275,6 +293,12 @@ In `closed` mode, do not report completion until:
    `artifact_type: "parallel-orchestrator-state"`).
 4. Acceptance criteria in the AC source files of each item have been checked off by that item's own
    run, per the `acceptance-criteria-tracking` skill.
+   A CI-dependent criterion, whose verification requires the result of CI on the pull-request head,
+   is checked off and pushed by the item's own run after its S9 success and before its DONE, and
+   that run re-runs S9 so its reported `ci_gate.head_sha` is the final head. Before `gh pr merge`,
+   confirm that the `headRefOid` value equals that reported `ci_gate.head_sha` and that the item
+   reported no pending CI-dependent criteria. You never commit acceptance-criteria check-offs from
+   the coordinator root.
 
 In `open` mode there is no automatic completion. The run is a standing queue and terminates only
 via `/parallel-close`, which is owned by F6 and is not specified here or shipped by this feature. Do

package/resources/claude-customizations/.claude/agents/parallel-planner.md

@@ -114,7 +114,7 @@ Update `artifacts/orchestration/parallel-planner-state.json` after every complet
 `tolerated_overlaps` list returned by Get-BlastRadiusConflictEdge (tolerated-not-validated).
 
 Each `items[]` entry carries `issue_num`, `feature_folder`, `kind`, `state`, `complexity_band`,
-`preparation_status`, `research_path`, `plan_path`, `preflight_status`, `branch_name`,
+`complexity_assessment`, `preparation_status`, `research_path`, `plan_path`, `preflight_status`, `branch_name`,
 `worktree_path`, `blast_radius`, `radius_validation`, `model_routing_receipt`, and
 `topology_receipt`. No `epic_worthiness` analogue, no `depends_on` field, and no `wave` field is
 written at any level.
@@ -126,16 +126,19 @@ Do not report completion until:
 1. Every non-withdrawn item is `state: prepared` with `preflight_status` exactly
    `PREFLIGHT: ALL CLEAR`, a `declared` blast radius that passed V1 and V2, and a unique pushed
    `branch_name`.
-2. `cohorts[]` is recorded at `generation: 0` covering exactly the prepared item keys, and the
+2. Every item carries a `complexity_band`, a `complexity_assessment`, and a `model_routing_receipt`
+   with `agent: "orchestrator"`, recorded by the `parallel-plan` skill's `## Complexity Assessment`
+   procedure, that satisfy ready-gate invariant P10 (P10).
+3. `cohorts[]` is recorded at `generation: 0` covering exactly the prepared item keys, and the
    recomputation-parity check defined in the `parallel-plan` skill passed.
-3. The manifest at `docs/features/parallel/<slug>/parallel.md` is committed to
+4. The manifest at `docs/features/parallel/<slug>/parallel.md` is committed to
    `parallel/<slug>-plan` in fully resolved form, with no negative `issue_num` remaining.
-4. The checkpoint validates through `mcp__drm-copilot__validate_orchestration_artifacts` with
+5. The checkpoint validates through `mcp__drm-copilot__validate_orchestration_artifacts` with
    `artifact_type: "parallel-planner-state"`, and `next_step` is exactly
    `PARALLEL_EXECUTION_READY`.
-5. The kickoff artifact exists at both paths and validates through
+6. The kickoff artifact exists at both paths and validates through
    `mcp__drm-copilot__validate_orchestration_artifacts` with `artifact_type: "parallel-kickoff"`.
-6. The final report lists, per item, the `plan-path:`, branch name, preflight status, and
+7. The final report lists, per item, the `plan-path:`, branch name, preflight status, and
    radius-validation result; plus the cohort table, the manifest path, both kickoff paths, and the
    statement that execution has NOT started.
 

package/resources/claude-customizations/.claude/agents/pr-author.md

@@ -11,8 +11,15 @@ tools:
   - "Bash(git rev-parse *)"
   - "Bash(gh pr create *)"
   - "Bash(gh pr edit *)"
+  - "Bash(sha256sum *)"
+  - "Bash(date *)"
   - "Write(/artifacts/**)"
 hooks:
+  PreToolUse:
+    - matcher: "Bash"
+      hooks:
+        - type: command
+          command: pwsh -NoProfile -File .claude/hooks/enforce-pr-author-command-allowlist.ps1
   SubagentStop:
     - matcher: "pr-author"
       hooks:
@@ -49,7 +56,7 @@ Before any `gh pr create` or `gh pr edit --body*` command, you MUST perform thes
 
 1. Write the PR body text to `artifacts/pr_body_<N>.md`, where `<N>` is the target issue or PR
    number for this change.
-2. Compute the SHA-256 of the body file bytes and render it as lowercase hexadecimal.
+2. Compute the SHA-256 of the body file by running `sha256sum artifacts/pr_body_<N>.md` as a single command (no chaining) and take the lowercase hexadecimal digest.
 3. Write the sibling receipt `artifacts/pr_body_<N>.receipt.json` with exactly these fields:
    - `skill`: `"pr-author"`
    - `pr_body_path`: `"artifacts/pr_body_<N>.md"`
@@ -57,7 +64,7 @@ Before any `gh pr create` or `gh pr edit --body*` command, you MUST perform thes
    - `sha256`: the lowercase-hex SHA-256 of the body file bytes from step 2
    - `context_summary_path`: `"artifacts/pr_context.summary.txt"`
    - `created_at`: the current time as a UTC ISO-8601 timestamp (for example `2026-06-24T16:00:00Z`),
-     strictly newer than the last-write time of `artifacts/pr_context.summary.txt`
+     strictly newer than the last-write time of `artifacts/pr_context.summary.txt`. Obtain it by running `date -u +%Y-%m-%dT%H:%M:%SZ` as a single command.
 4. Issue the command immediately, passing the body via `--body-file`:
    `gh pr create --body-file artifacts/pr_body_<N>.md`. The PreToolUse hook verifies, in five ordered
    checks, that the `--body-file` path is canonical, that the receipt exists, that `number` matches
@@ -69,6 +76,12 @@ The PR body must be passed via `--body-file`; inline `--body` is blocked by the
 agent does not write or delete any short-lived authorization file; provenance is established solely by
 the SHA-256 receipt.
 
+The `enforce-pr-author-command-allowlist.ps1` PreToolUse hook registered in this agent's frontmatter
+evaluates every Bash segment and denies anything outside the allowed forms (`git log`,
+`git rev-parse`, `gh pr create`, `gh pr edit`, and, each as a single command,
+`sha256sum artifacts/pr_body_<N>.md` and `date -u +%Y-%m-%dT%H:%M:%SZ`) with
+`PR_AUTHOR_COMMAND_NOT_ALLOWED:`.
+
 ## Final Output Requirement
 
 After opening or updating the pull request, report the resulting PR URL

package/resources/claude-customizations/.claude/agents/prd-feature.md

@@ -15,7 +15,7 @@ hooks:
     - matcher: "prd-feature"
       hooks:
         - type: command
-          command: pwsh -NoProfile -File .claude/hooks/validate-required-artifact-output.ps1 -AgentName prd-feature -RequiredArtifact 'spec-path|^docs/features/active/.+/spec\.md$|feature spec artifact' -RequiredArtifact 'user-story-path|^docs/features/active/.+/user-story\.md$|feature user story artifact'
+          command: pwsh -NoProfile -File .claude/hooks/validate-required-artifact-output.ps1 -AgentName prd-feature -RequiredArtifact 'spec-path|^docs/features/active/.+/spec\.md$|feature spec artifact'
         - type: command
           command: pwsh -NoProfile -File .claude/hooks/validate-prd-feature-output.ps1
 ---

package/resources/claude-customizations/.claude/hooks/check-powershell-test-purity.ps1

@@ -31,9 +31,10 @@
 #>
 [CmdletBinding()]
 param()
+$script:HookDependencyGuardLoadFailed = $false; try { . (Join-Path $PSScriptRoot 'hook-dependency-guard.ps1') } catch { $script:HookDependencyGuardLoadFailed = $true }
 
 
-Import-Module (Join-Path $PSScriptRoot '../lib/hook-payload/HookPayload.psm1') -Force
+try { Import-Module (Join-Path $PSScriptRoot '../lib/hook-payload/HookPayload.psm1') -Force -ErrorAction Stop } catch { Add-HookDependencyFailure -Name 'HookPayload.psm1' -ErrorRecord $_ }
 function Get-PowerShellTestPurityBlockDecision {
     [CmdletBinding()]
     [OutputType([System.Collections.Specialized.OrderedDictionary])]
@@ -69,6 +70,8 @@ function Invoke-PowerShellTestPurityDecision {
     param(
         [string] $ToolInputRaw
     )
+    $dependencyDecision = Get-HookDependencyFailureDecision -HookEvent PreToolUse -ReasonPrefix 'PowerShell unit test purity hook:'
+    if ($null -ne $dependencyDecision) { return $dependencyDecision }
 
     $payload = Resolve-ClaudeHookToolInput -Raw $ToolInputRaw
     if (-not $payload.IsValid) {
@@ -136,6 +139,9 @@ function Invoke-PowerShellTestPurityDecision {
 if ($MyInvocation.InvocationName -eq '.') {
     return
 }
+if ($script:HookDependencyGuardLoadFailed) { [Console]::Error.WriteLine('PowerShell unit test purity hook: hook-dependency-guard.ps1 failed to load; the gate fails closed.'); exit 2 }
+$dependencyDecision = Get-HookDependencyFailureDecision -HookEvent PreToolUse -ReasonPrefix 'PowerShell unit test purity hook:'
+if ($null -ne $dependencyDecision) { $dependencyDecision | ConvertTo-Json -Compress -Depth 5 | Write-Output; exit 0 }
 
 $decision = Invoke-PowerShellTestPurityDecision -ToolInputRaw (Read-ClaudeHookRawPayload)
 if ($null -ne $decision -and $decision.hookSpecificOutput.permissionDecision -eq 'deny') {

package/resources/claude-customizations/.claude/hooks/check-python-test-purity.ps1

@@ -28,9 +28,10 @@
 #>
 [CmdletBinding()]
 param()
+$script:HookDependencyGuardLoadFailed = $false; try { . (Join-Path $PSScriptRoot 'hook-dependency-guard.ps1') } catch { $script:HookDependencyGuardLoadFailed = $true }
 
 
-Import-Module (Join-Path $PSScriptRoot '../lib/hook-payload/HookPayload.psm1') -Force
+try { Import-Module (Join-Path $PSScriptRoot '../lib/hook-payload/HookPayload.psm1') -Force -ErrorAction Stop } catch { Add-HookDependencyFailure -Name 'HookPayload.psm1' -ErrorRecord $_ }
 function Get-PythonTestPurityBlockDecision {
     [CmdletBinding()]
     [OutputType([System.Collections.Specialized.OrderedDictionary])]
@@ -66,6 +67,8 @@ function Invoke-PythonTestPurityDecision {
     param(
         [string] $ToolInputRaw
     )
+    $dependencyDecision = Get-HookDependencyFailureDecision -HookEvent PreToolUse -ReasonPrefix 'Python unit test purity hook:'
+    if ($null -ne $dependencyDecision) { return $dependencyDecision }
 
     $payload = Resolve-ClaudeHookToolInput -Raw $ToolInputRaw
     if (-not $payload.IsValid) {
@@ -138,6 +141,9 @@ function Invoke-PythonTestPurityDecision {
 if ($MyInvocation.InvocationName -eq '.') {
     return
 }
+if ($script:HookDependencyGuardLoadFailed) { [Console]::Error.WriteLine('Python unit test purity hook: hook-dependency-guard.ps1 failed to load; the gate fails closed.'); exit 2 }
+$dependencyDecision = Get-HookDependencyFailureDecision -HookEvent PreToolUse -ReasonPrefix 'Python unit test purity hook:'
+if ($null -ne $dependencyDecision) { $dependencyDecision | ConvertTo-Json -Compress -Depth 5 | Write-Output; exit 0 }
 
 $decision = Invoke-PythonTestPurityDecision -ToolInputRaw (Read-ClaudeHookRawPayload)
 if ($null -ne $decision -and $decision.hookSpecificOutput.permissionDecision -eq 'deny') {

package/resources/claude-customizations/.claude/hooks/enforce-checkpoint-monotonic.ps1

@@ -42,9 +42,10 @@
 #>
 [CmdletBinding()]
 param()
+$script:HookDependencyGuardLoadFailed = $false; try { . (Join-Path $PSScriptRoot 'hook-dependency-guard.ps1') } catch { $script:HookDependencyGuardLoadFailed = $true }
 
 
-Import-Module (Join-Path $PSScriptRoot '../lib/hook-payload/HookPayload.psm1') -Force
+try { Import-Module (Join-Path $PSScriptRoot '../lib/hook-payload/HookPayload.psm1') -Force -ErrorAction Stop } catch { Add-HookDependencyFailure -Name 'HookPayload.psm1' -ErrorRecord $_ }
 $script:CanonicalStepPrefixes = @(
     'S0_startup_checks',
     'S1_change_budget_estimation',
@@ -206,6 +207,8 @@ function Invoke-CheckpointMonotonicDecision {
     param(
         [string] $ToolInputRaw
     )
+    $dependencyDecision = Get-HookDependencyFailureDecision -HookEvent PreToolUse -ReasonPrefix 'CHECKPOINT_MONOTONIC_BLOCKED:'
+    if ($null -ne $dependencyDecision) { return $dependencyDecision }
 
     $envelope = Resolve-ClaudeHookToolInput -Raw $ToolInputRaw
     if (-not $envelope.IsValid) {
@@ -301,6 +304,9 @@ function Invoke-CheckpointMonotonicDecision {
 if ($MyInvocation.InvocationName -eq '.') {
     return
 }
+if ($script:HookDependencyGuardLoadFailed) { [Console]::Error.WriteLine('CHECKPOINT_MONOTONIC_BLOCKED: hook-dependency-guard.ps1 failed to load; the gate fails closed.'); exit 2 }
+$dependencyDecision = Get-HookDependencyFailureDecision -HookEvent PreToolUse -ReasonPrefix 'CHECKPOINT_MONOTONIC_BLOCKED:'
+if ($null -ne $dependencyDecision) { $dependencyDecision | ConvertTo-Json -Compress -Depth 5 | Write-Output; exit 0 }
 
 $decision = Invoke-CheckpointMonotonicDecision -ToolInputRaw (Read-ClaudeHookRawPayload)