@danmoisan/drm-copilot-mcp 1.1.25 → 1.1.27

package/resources/claude-customizations/.claude/skills/feature-review-workflow/SKILL.md

@@ -42,12 +42,21 @@ Always apply:
   - `code-review-template` for `code-review.<timestamp>.md`
   - `feature-audit-template` for `feature-audit.<timestamp>.md`
 - The MCP-resolved asset is the authoritative template source for review artifacts in this workflow.
+- When an installed template older than this change carries baseline fields, each baseline field is recorded as `N/A - no pre-change run`, and the comparison line reads `Baseline: N/A - no pre-change run -> Post-change: <percent>. Change: N/A.`
 
 ### No silent fixes
 
 - Do not clean up code during review.
 - If checks fail, document the failure and include exact remediation guidance.
 
+### Process-reduction ledger
+
+- This rule applies only when `docs/engineering/process-reductions/` exists, so a repository without that folder is unaffected.
+- A change that reduces evidence, plan tasks, gates, or review process adds its ledger entry in the same commit, in the format of that folder's `README.md`.
+- A branch diff that makes such a reduction with no entry is a Blocking finding.
+- The reviewer confirms from the branch log that each reduction is its own commit, with the `reduction: NNNN` token in its subject.
+- One-off waivers for a single item are not entries.
+
 ### Work-mode acceptance-criteria contract
 
 - Read the persisted marker from `issue.md` using one of:
@@ -105,17 +114,17 @@ If the branch diff modifies any path matching `.github/workflows/**`, `scripts/b
      4. tests
      5. coverage (mandatory for every language that has changed files)
         - TypeScript: `npm run test:unit:coverage` → artifact: `coverage/lcov.info`
-        - Python: `poetry run pytest --cov` → artifact: `artifacts/python/lcov.info`
-        - PowerShell: `mcp__drm-copilot__run_poshqc_test` → artifact: `artifacts/pester/powershell-coverage.xml`
+        - Python: `poetry run pytest -n auto --cov-report=term-missing --cov` → artifact: `artifacts/python/lcov.info`
+        - PowerShell: one `Invoke-PoshQCParallelTest` run → artifact: `artifacts/pester/powershell-coverage.xml`
         - C#: `dotnet test --collect:"XPlat Code Coverage"` → artifact: `artifacts/csharp/coverage.xml`
-        - Coverage thresholds (threshold precedence per `.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, so a root `CLAUDE.md` that states only one of the two thresholds governs only that metric). 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 flag a missing PowerShell branch figure as FAIL:
+        - Coverage thresholds (threshold precedence per `.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, so a root `CLAUDE.md` that states only one of the two thresholds governs only that metric). 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, 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 flag a missing PowerShell branch figure as FAIL:
           - New code files (added in this feature): line coverage >= 85%, and branch coverage >= 75% for branch-capable languages. Flag as FAIL otherwise.
-          - Modified files (changed but previously existing): line coverage >= 85%, branch coverage >= 75% for branch-capable languages, and no regression on changed lines relative to baseline. Flag as FAIL otherwise.
+          - Modified files (changed but previously existing): line coverage >= 85%, and branch coverage >= 75% for branch-capable languages, read from the single gate run, and new behavior is tested. Flag as FAIL otherwise.
           - Repo-wide per language: line coverage >= 85%, and branch coverage >= 75% for branch-capable languages. Flag as FAIL otherwise.
         - If coverage artifacts already exist from the executor run, inspect them instead of re-running.
         - If no coverage artifact exists for a language that has changed files, flag as FAIL — coverage verification is mandatory for all languages with changed files.
         - 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.
-   - Run the smallest relevant subset first when the repo policy permits it.
+   - A focused run of one test file to debug a specific failure is debugging only; a review check does not rest on it.
    - If a tool cannot run in the environment, mark the affected section unverified or partial with a concrete reason.
 
 6. **Produce the code review**
@@ -146,14 +155,17 @@ If the branch diff modifies any path matching `.github/workflows/**`, `scripts/b
      - toolchain checks fail
      - the code review contains blockers
      - required acceptance criteria are FAIL or PARTIAL
-     - coverage below the governing thresholds defined in step 5 (repo-wide per language, modified files including any regression on changed lines, or new files)
+     - coverage below the governing thresholds defined in step 5 (repo-wide per language, modified files, or new files)
      - coverage artifact absent for any language that has changed files
    - Classify each blocking finding before triggering remediation: each receives one remediability class (`autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, or `human_decision_required`; `autonomous` when no class is stated). A published MCP runtime that lags the repository contract is classified `external_dependency`.
    - Trigger the remediation handoff only when at least one blocking finding is `autonomous`. When every blocking finding is non-remediable, write the remediation inputs with the `HALT_NON_REMEDIABLE` or `AWAITING_CI` verdict and create no remediation plan target.
+   - Choose the remediation path. Write one line `Remediation-Path: light` or `Remediation-Path: full` into the remediation inputs, and inside each blocking finding block one line `Finding-Scope: contained` or `Finding-Scope: design`. A missing path line reads as `full`, and a missing scope line reads as `design`. These lines never contain the substrings the orchestrator counts.
+   - Write `Remediation-Path: light` only when all of these hold: at most 3 blocking findings, every one `autonomous` with `Finding-Scope: contained`; no change to a spec acceptance criterion, a public interface, or the file inventory beyond the branch diff plus tests and mirrors; no change to a validator contract, hook decision, or production logic beyond the finding's named location; the cycle is opened by a review; and the prior cycle was not light. Otherwise write `Remediation-Path: full`. The orchestrator may move a cycle to a heavier path and never to a lighter one.
+   - With `Remediation-Path: light`, also write a `## Light Fix Tasks` section: one canonical `- [ ] [P0-T1] ...` line per fix, numbered in order, each naming the file and the finding it fixes. Write no checkbox line anywhere else in the file, because the executor stop hook counts every checkbox line of the file it executes.
    - Create `remediation-inputs.<timestamp>.md` first.
-   - Create the target remediation plan file from the canonical plan template.
-   - Hand off plan creation through `remediation-handoff-atomic-planner`.
-   - Do not report completion unless the remediation plan file exists when remediation was triggered.
+   - With `Remediation-Path: full`, create the target remediation plan file from the canonical plan template.
+   - With `Remediation-Path: full`, hand off plan creation through `remediation-handoff-atomic-planner`.
+   - With `Remediation-Path: full`, do not report completion unless the remediation plan file exists when remediation was triggered. With `Remediation-Path: light`, create no remediation plan target: the inputs file is the light cycle's plan.
 
 9. **Finalize the review**
    - Verify every reported artifact exists on disk before reporting completion.

package/resources/claude-customizations/.claude/skills/invoke-csharp-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-csharp-engineer
-description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> xUnit toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.
+description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and quality gates read from the single gate run.
 ---
 
 # Implement C# Skill
@@ -13,7 +13,7 @@ Use this skill when:
 
 - The user requests a C# code change, bug fix, refactor, or test addition.
 - Estimated scope fits the small path (1-3 production files plus corresponding tests).
-- The toolchain (CSharpier, .NET Analyzers, Nullable Analysis, xUnit) can be run in the current environment, or the user has explicitly authorized an unverified plan-only response.
+- The toolchain (CSharpier, .NET Analyzers, Nullable Analysis, MSTest) can be run in the current environment, or the user has explicitly authorized an unverified plan-only response.
 
 If the estimated scope exceeds the small-path budget, this skill defers to the orchestrated flow via `csharp-change-budget-router` instead of proceeding directly.
 
@@ -28,7 +28,7 @@ If the estimated scope exceeds the small-path budget, this skill defers to the o
 ## Output Paths
 
 - C# source and test files within the approved scope.
-- Baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and post-change evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
+- Static baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and final gate evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
 - This location is canonical per evidence-and-timestamp-conventions and is not overridable. See `.claude/skills/evidence-and-timestamp-conventions/SKILL.md` for the canonical evidence path authority.
 - Plan artifacts under the active feature folder when the task is feature-scoped.
 
@@ -37,10 +37,10 @@ If the estimated scope exceeds the small-path budget, this skill defers to the o
 The worker must return the following reporting block:
 
 1. Scope (exact file list).
-2. Baseline (CSharpier, .NET Analyzers, Nullable Analysis, xUnit, coverage status).
+2. Baseline (CSharpier, .NET Analyzers, and Nullable Analysis findings).
 3. Plan (design and test strategy).
 4. Diffs (patch-style or full-file replacements).
-5. QA Gate Results (CSharpier, .NET Analyzers, Nullable Analysis, xUnit, and coverage deltas, or clearly marked **unverified**).
+5. QA Gate Results (CSharpier, .NET Analyzers, and Nullable Analysis deltas, failures in the single gate run, and per-file coverage against the thresholds, or clearly marked **unverified**).
 
 ## Delegation Identity Lines
 

package/resources/claude-customizations/.claude/skills/invoke-powershell-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-powershell-engineer
-description: Invoke the powershell-typed-engineer worker to design, implement, and verify PowerShell changes within typed repository boundaries. Applies PoshQC format -> analyze -> test toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and zero-regression quality gates.
+description: Invoke the powershell-typed-engineer worker to design, implement, and verify PowerShell changes within typed repository boundaries. Applies PoshQC format -> analyze -> test toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and quality gates read from the single gate run.
 ---
 
 # Implement PowerShell Skill
@@ -27,7 +27,7 @@ If the estimated scope exceeds the direct-mode budget, this skill defers to the
 ## Output Paths
 
 - PowerShell source (`*.ps1`, `*.psm1`, `*.psd1`) and Pester test (`*.Tests.ps1`) files within the approved scope.
-- Baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and post-change evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
+- Static baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and final gate evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
 - This location is canonical per evidence-and-timestamp-conventions and is not overridable. See `.claude/skills/evidence-and-timestamp-conventions/SKILL.md` for the canonical evidence path authority.
 - Plan artifacts under the active feature folder when the task is feature-scoped.
 
@@ -36,10 +36,10 @@ If the estimated scope exceeds the direct-mode budget, this skill defers to the
 The worker must return the `powershell-qa-gate` reporting block:
 
 1. Scope (exact file list).
-2. Baseline (PSScriptAnalyzer, Pester, coverage status).
+2. Baseline (PSScriptAnalyzer findings).
 3. Plan (design and test strategy, including minimal DI seams and external executable wrapper mock strategy).
 4. Diffs (patch-style or full-file replacements).
-5. QA Gate Results (PSScriptAnalyzer, Pester, and coverage deltas, or clearly marked **unverified**).
+5. QA Gate Results (PSScriptAnalyzer delta, failures in the single gate run, and per-file coverage against the thresholds, or clearly marked **unverified**).
 
 ## Delegation Identity Lines
 

package/resources/claude-customizations/.claude/skills/invoke-python-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-python-engineer
-description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black -> Ruff -> Pyright -> Pytest toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and zero-regression quality gates.
+description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black -> Ruff -> Pyright -> Pytest toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and quality gates read from the single gate run.
 ---
 
 # Implement Python Skill
@@ -27,7 +27,7 @@ If the estimated scope is more than 3 production files, this skill defers to the
 ## Output Paths
 
 - Python source and test files within the approved scope.
-- Baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and post-change evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
+- Static baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and final gate evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
 - This location is canonical per evidence-and-timestamp-conventions and is not overridable. See `.claude/skills/evidence-and-timestamp-conventions/SKILL.md` for the canonical evidence path authority.
 - Plan artifacts under the active feature folder when the task is feature-scoped.
 
@@ -36,10 +36,10 @@ If the estimated scope is more than 3 production files, this skill defers to the
 The worker must return the `python-qa-gate` reporting block:
 
 1. Scope (exact file list).
-2. Baseline (Ruff, Pyright, Pytest, coverage status).
+2. Baseline (Ruff and Pyright findings).
 3. Plan (design and test strategy).
 4. Diffs (patch-style or full-file replacements).
-5. QA Gate Results (Ruff, Pyright, Pytest, and coverage deltas, or clearly marked **unverified**).
+5. QA Gate Results (Ruff and Pyright deltas, failures in the single gate run, and per-file coverage against the thresholds, or clearly marked **unverified**).
 
 ## Delegation Identity Lines
 

package/resources/claude-customizations/.claude/skills/orchestrate/SKILL.md

@@ -37,6 +37,12 @@ On every invocation, the main session must:
 3. If no checkpoint exists or the objective is new, begin the orchestration lifecycle from the start.
 4. **Checkpoint hygiene (issue #673).** When the checkpoint at `artifacts/orchestration/orchestrator-state.json` records an `issue-num` other than the item this invocation is about, move it to `artifacts/orchestration/handoff/orchestrator-state.issue-<issue-num>.<yyyy-MM-ddTHH-mm>.json` before writing a new checkpoint, rather than overwriting it or leaving it in place. Apply the same move when this session hands an item whose checkpoint it holds to another session or worktree. A checkpoint left at a session root is read by gates that resolve against that root, so a foreign one there is state a gate can answer from.
 5. **Required checkpoint keys (issue #798).** Every checkpoint write carries each top-level key listed in `.claude/rules/orchestrator-state.md` under `## Required Top-Level Keys`; plain validation reports each absent key as `Checkpoint missing required key: <key>` under every flag combination. The list includes `last_updated`, an ISO-8601 UTC date-time string (for example `2026-10-08T17:28:00Z`) that is rewritten on every checkpoint write: after every completed step and every state transition, including halts.
+6. **Stage timing (issue #1097).**
+   - At each transition where the checkpoint `last_updated` is rewritten, read the clock once (never compose a time) and use that reading as `last_updated`, as `ended_at` of the open `stage_timing` entry, and as `started_at` of the entry for the next stage; `attempt` is one more than the number of earlier entries for the same stage.
+   - `stage_timing` is a top-level list of `{ stage, attempt, started_at, ended_at }` entries with ISO-8601 UTC strings, and `ended_at` is null while a stage is open. The key is tolerated and unvalidated: no validator reads it.
+   - In the last commit before the merge, write the whole list to `FEATURE/evidence/other/stage-timing.<timestamp>.json` as a JSON object with `issue-num` (a string of decimal digits, or an integer of 1 or more; both are read as the same issue) and `stage_timing`, stamped with the UTC write time (`yyyy-MM-ddTHH-mm`); the file sits inside the feature folder, so the commit does not stale a concurrent review, and a re-written file carries a newer stamp, which the report prefers.
+   - A portable handoff archives the source checkpoint byte for byte, so the archive keeps `stage_timing`, but the destination projection copies no unknown key and starts without it; the committed evidence file is the record that spans a handoff.
+   - Print the report with `scripts/dev-tools/Get-StageTimingReport.ps1`. Figures are wall-clock time and include queueing; they are not agent time. The merge stage is not captured.
 
 ## Prepared-State Portable Handoff Intake
 
@@ -253,7 +259,7 @@ After each `feature-review` delegation returns:
 3. If the file exists, count lines matching `BLOCKING` or `Severity: Blocking` (case-sensitive). If count >= 1, enter the remediation loop. If count = 0, advance to the PR creation gate. This count rule applies unchanged when the file carries no `Review-Verdict:` line: a count of at least 1 is `REMEDIATION_REQUIRED` and every finding is treated as `autonomous`.
 4. If the file carries a `Review-Verdict:` line, recompute the verdict from the `Remediability:` lines of the blocking findings (a blocking finding block without a `Remediability:` line counts as `autonomous`): 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`. The `remediation-inputs` file is authoritative; the optional `review-status:` token in the review result is a cross-check.
 5. A mismatch between the declared and recomputed verdicts is a reviewer contract error: record it under `artifact_errors`, re-request the review once, and halt with `blocked_reason: "delegate_contract_incomplete"` if it persists.
-6. Append a `remediation_loop.review_outcomes[]` entry (`verdict` plus one `findings[]` object with `remediability` per blocking finding) for every review, including `PASS`.
+6. Append a `remediation_loop.review_outcomes[]` entry (`verdict` plus one `findings[]` object with `remediability` per blocking finding) for every review, including `PASS`. Each `findings[]` object also records `scope` from the finding's `Finding-Scope:` line when that line is present.
 7. Act on the verdict: `PASS` advances to the PR creation gate; `REMEDIATION_REQUIRED` enters the remediation loop with the plan scoped to the `autonomous` findings, carrying the non-remediable findings forward unchanged; `HALT_NON_REMEDIABLE` follows the halt branch; `AWAITING_CI` follows the wait branch.
 
 Halt branch (`HALT_NON_REMEDIABLE`): set `blocked_reason` to the highest-precedence halt class present, append one `human_interaction.requirements[]` entry with `response: "halt"` for each halt class present (`external_dependency`, `policy_hold`, `human_decision_required`) describing the human action needed, leave `remediation_loop.completed_attempts` unchanged, write no cycle, create no remediation plan, and stop. The precedence is:
@@ -268,10 +274,11 @@ A bounded loop consisting of five steps. The attempt count is `remediation_loop.
 
 Cycle accounting: a remediation attempt is complete when R3 execution finished (`execution_status: "complete"`) and the pre-R4 commit recorded a non-empty change set; only then set `candidate_applied: true` on that cycle and increment `completed_attempts`. A cycle that ends without a candidate (execution not started, execution failed, or an empty staged change set) records `candidate_applied: false` and consumes no number. It is followed by at most one re-plan under the same number when the executor output identifies an autonomous plan defect; otherwise reclassify the blocker (typically `external_dependency`) and halt. Two consecutive no-candidate cycles halt with `step6_status: "blocked_remediation_loop_limit"`. Local, CI-failure, merge-conflict, and parallel-drift cycles share the one count.
 
-Remediation mode. Before R1, the orchestrator writes exactly one line into the cycle's `remediation-inputs.<timestamp>.md`: `Remediation-Mode: proportionate` or `Remediation-Mode: design`. The classification rule: a cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; otherwise the cycle is design. CI-failure findings are normally proportionate.
+Remediation mode. Before R1, or before R3 for a light cycle, the orchestrator writes exactly one line into the cycle's `remediation-inputs.<timestamp>.md`: `Remediation-Mode: light`, `Remediation-Mode: proportionate`, or `Remediation-Mode: design`. The classification rule: a cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; otherwise the cycle is design. CI-failure findings are normally proportionate. `Remediation-Mode:` stays orchestrator-owned. The orchestrator writes `Remediation-Mode: light` only when the reviewer wrote `Remediation-Path: light` and every mechanically checkable condition holds: the finding count and classes, a `Finding-Scope: contained` line for each finding, a non-empty `## Light Fix Tasks` section and no other checkbox line, `opened_by_review` set, a prior cycle that was not light, and the detection rule below. Otherwise it writes `Remediation-Mode: proportionate` or `Remediation-Mode: design` by the rule above. It may move a cycle to a heavier mode and never to a lighter one, and CI-failure and merge-conflict cycles are never light. Each new cycle records `remediation_path` as `light` or `full`.
 
 - **Proportionate cycle.** R1 is one `atomic-planner` delegation that writes a short remediation plan carrying a `## Pre-Mortem` section and a final self-review task. R2 and R3 run as one `atomic-executor` delegation: the executor runs single-pass preflight with in-place trivial fixes (`### Single-Pass Preflight` in `atomic-plan-contract`) and then executes the plan. Record `preflight: {iterations: 1, final_status: "clear"}` on the cycle before `execution_status`. If preflight finds a substantive defect, the executor stops with `BLOCKED at preflight (before [P0-T1])`, a plan delta, and no checked task; the orchestrator rewrites the mode line to `Remediation-Mode: design` and the cycle continues as a design cycle with one planner revision. The pre-R4 commit, R4, and R5 are unchanged.
 - **Design cycle.** R1 to R5 run as listed below, and R2 follows the single-pass preflight and at-most-one-return rule.
+- **Light cycle.** The threshold is the reviewer's: at most 3 blocking findings, every one `autonomous` with `Finding-Scope: contained`; no change to a spec acceptance criterion, a public interface, or the file inventory beyond the branch diff plus tests and mirrors; no change to a validator contract, hook decision, or production logic beyond the finding's named location; a review-opened cycle; and a prior cycle that was not light. Detection: as the last step before the execution delegation, record the cycle truthfully (`plan_path` naming the inputs file, `remediation_path: "light"`, `opened_by_review`, `execution_status: "in_progress"`, and no `preflight`) and validate the checkpoint through the repository-local Python CLI `scripts.dev_tools.validate_orchestration_artifacts` with its `orchestrator-state` subcommand, run through Poetry in module form in the item worktree, or through the MCP tool where the repository has no such CLI. Installed MCP applies invariant 8 only after the extension release that carries it is installed; until then the checkpoint is validated through the Python CLI, and a failed MCP checkpoint call records no receipt and is not repaired by editing the cycle. On that validation, an error naming that cycle means the route lacks invariant 8, so remove `execution_status`, set `remediation_path: "full"`, rewrite the mode line to `Remediation-Mode: proportionate` or `Remediation-Mode: design`, and continue at R1, after which `plan_path` names the remediation plan. No fix work has run at that point, so the record stays true. R1 and R2 do not run. R3 is one `atomic-executor` delegation with the inputs file as its plan and no preflight directive. If the executor stops with `BLOCKED at preflight (before [P0-T1])` before the first checked task, rewrite the mode line to `Remediation-Mode: design`, set `remediation_path: "full"`, remove `execution_status`, and enter the design chain at R1; `plan_path` then names the remediation plan, and no attempt number is consumed. The pre-R4 commit, R4, R5, cycle accounting (`candidate_applied` and `completed_attempts`), and the termination guard are unchanged. The cycle after a light cycle is full.
 
 - **R1 — Remediation planning:** Delegate to `atomic-planner` with `remediation-inputs.<timestamp>.md` path as primary context. Receive `remediation-plan.<timestamp>.md` in the active feature folder.
 - **R2 — Preflight clearance:** Delegate to `atomic-executor` for precondition validation only (no implementation), with the preflight directive in the delegation prompt. Trivial defects are fixed in place. If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, return to R1 once and re-delegate to `atomic-planner` with the full `PREFLIGHT-DEFECT:` list; if the following preflight still reports a substantive defect, record `final_status: "blocked_preflight_iteration_limit"` on the cycle and halt per `.claude/skills/remediation-handoff-atomic-planner/SKILL.md`. Only after `PREFLIGHT: ALL CLEAR` may the orchestrator advance to R3.
@@ -373,6 +380,21 @@ When S9 records `step9_status: "failed_remediation_required"` (a failed check; a
 4. CI-failure cycles share `remediation_loop.completed_attempts` with local-finding cycles; a CI-failure finding stays `autonomous`, and the active cycle number is `completed_attempts + 1`.
 5. The shared guard applies: after three completed attempts without a passing result, the orchestrator records `step9_status: "blocked_ci_loop_limit"`, does not write DONE, and halts. No further automation is attempted.
 
+## Concurrent Review and CI (review_mode)
+
+This section applies to a run whose checkpoint records `review_mode: "concurrent"` (issue #1097). The feature review and CI then run at the same time on an open pull request, and the merge waits for both. A run without that value is sequential and follows every other section of this skill unchanged.
+
+1. **New-run default.** The first checkpoint write of a new run records `review_mode: "concurrent"` when the route opens a pull request and the target worktree holds the guard file `.claude/hooks/enforce-epic-merge-gate-review.ps1`. Without that file the run stays sequential, because a skill newer than its hooks would otherwise stop at readiness.
+2. **Resume.** A run that resumes a checkpoint without the key stays sequential, and the key is never added on resume. A sequential run follows every other section unchanged.
+3. **Sequence.** The local parallel test run passes; commit, with the steps of `## Pre-Feature-Review Commit` running here, before the pull request; open the pull request; a run with a ledger entry commits the entry's pull-request number next, before reading `head_sha`; run the `feature-review` delegation and CI together; join; merge.
+4. **Recording.** Every `remediation_loop.review_outcomes[]` entry carries `head_sha`: the full lowercase head of the pushed branch, read before the review delegation.
+5. **Join.** The merge proceeds only when all of these hold: the last `review_outcomes[]` entry has verdict `PASS` at a current head; `ci_gate.conclusion` is `success` at the live head; and a `CI full run` check with conclusion `success` exists at the reviewed head, or at an ancestor of it whose diff to the reviewed head lists only `feature-folder` paths. A reviewed head is current when it equals the live head, or when it is an ancestor of the live head and the diff between them lists only `feature-folder` paths; this is the rule of the merge guard. The `CI full run` check is required because a docs-only head reports success without the heavy suites.
+6. **Moved conditions.** Conditions 1 and 2 of `## PR Creation Gate` apply at the join, not before the pull request. S9 steps 6 and 7, and DONE, run only after the join. A parallel child still never merges itself.
+7. **Re-entry.** Any code push after a `PASS`, including a CI fix or a merge of `origin/main`, is a stale head and requires a new review and a new S9 pass. Commits inside `feature-folder`, such as review artifacts and stage-timing evidence, do not. Ledger back-fills lie outside `feature-folder`, so they land before the review starts.
+8. **Portable handoff.** The destination projection is a closed key set and drops `review_mode`, so a concurrent run is not handed off between pull-request creation and the join.
+9. **Validators and deny codes.** Readiness stops rejecting `step7_status: pending` only under the key, and `require_complete` then requires the last `PASS` entry with `head_sha`. The TypeScript rule reaches the MCP validator only after an extension release. Until then installed MCP accepts a checkpoint that the PowerShell stop hook and the Python CLI reject, so check a concurrent checkpoint with the repository-local Python validator CLI, in its `orchestrator-state` mode with `--require-complete`. The merge guard denies with `REVIEW_GATE_NOT_PASSED`, `REVIEW_GATE_HEAD_STALE`, or `REVIEW_GATE_HEAD_UNRESOLVED`, each after the token `EPIC_MERGE_GATE_BLOCKED`. The merge is issued as its own Bash call, and any other form is denied with `REVIEW_GATE_HEAD_UNRESOLVED`.
+10. **Step order.** `completed_steps` stays in canonical order, because `.claude/hooks/enforce-checkpoint-monotonic.ps1` denies a checkpoint Write that lists `S8_create_pr` before `S7_feature_review`. When the review completes, insert `S7_feature_review` before the existing `S8_create_pr` entry; do not append it. A later review adds no second entry. `step8_status` is `in_progress` at pull-request creation, because readiness rejects `pending`, and it stays `in_progress` until the join, because `.claude/hooks/enforce-completion-consistency.ps1` reads `completed` there as a completion claim and denies a checkpoint Write whose `ci_gate.conclusion` is not `success`. A `completed` value would therefore deny the `ci_gate` write of every re-entry.
+
 ## PR Creation Gate
 
 The orchestrator must not create a PR, push a branch for PR purposes, or report work complete until all six conditions are simultaneously true:

package/resources/claude-customizations/.claude/skills/parallel-add/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: parallel-add
 description: Admit one new item into a running parallel run — preparation via a preparation-mode child orchestrator run, conflict-edge computation against all items including in-flight ones, and the admission decision that either places the item in the current cohort or defers it and recolors the unstarted subgraph. Appends exactly one mutations[] entry. In-flight items are never moved.
-argument-hint: "[issue|potential-entry]"
+argument-hint: "[issue|potential-entry] [--after <earlier>] [--band <Cn>]"
 context: fork
 agent: parallel-orchestrator
 ---
@@ -28,7 +28,9 @@ this operation may and may not disturb. Read that section before applying anythi
   `/parallel-run` for that.
 - `$ARGUMENTS` names exactly one item: a GitHub issue number or reference, or a path to an entry
   under `docs/features/potential/`. An argument naming more than one item is rejected; admit one
-  item per invocation so each admission decision and its mutation entry stay attributable.
+  item per invocation so each admission decision and its mutation entry stay attributable. The
+  `--after <earlier>` and `--band <Cn>` flags are not items, so the multi-item rejection applies to
+  positional items only.
 - The run-existence check is evaluated first, before any argument-shape check: a pending or
   not-started run, and a run whose `parallel_slug` no checkpoint tracks, are rejected before the
   argument is examined.
@@ -37,6 +39,15 @@ this operation may and may not disturb. Read that section before applying anythi
   the run's slug is known, put the line `parallel_slug: <slug>` before the signal, and end the
   final output with the literal line `PARALLEL_MUTATION_REJECTED: run_not_started` as its last
   line, with no formatting and no trailing text.
+- After the run-existence check passes, apply the closed-run guard in code. Read the manifest mode
+  with `bash .claude/lib/bash/validate-parallel-manifest.sh --print-mode <manifest-path>`, then run
+  `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 guard-run -CheckpointPath artifacts/orchestration/parallel-orchestrator-state.json -ManifestMode <mode>`.
+  The guard rejects when either mode is `closed`, when a `mutations[]` entry has `op` `close`, or
+  when the two modes disagree. On exit 1, stop with the helper's stderr line
+  (`PARALLEL_ADMISSION_REJECTED: run_closed: <detail>`) as the reported reason, change no state,
+  and emit no mutation rejection signal: `run_closed` is an admission rejection code defined in
+  `## Prepared-Item Admission (issue #1047)` of `.claude/rules/parallel-orchestration.md`, not a
+  mutation rejection code.
 - A closed run and an argument naming more than one item are rejected only after the run-existence
   check, while the run's checkpoint exists; each of these rejections emits no rejection signal, and
   the stop validates against that checkpoint.
@@ -61,13 +72,39 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
 1. **Enter `proposed`.** Add the item to `items[]` in state `proposed` with its `issue_num` as the
    primary key. Item keys are integers throughout this surface; there is no string key.
 
-2. **Prepare the item.** Run preparation through a preparation-mode child `Agent(orchestrator)`
+2. **Prepare the item.** First assess how far the item's pushed branch is already prepared:
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 assess -Branch origin/<item branch> -FeatureFolder <feature folder> -PlannerCheckpointPath artifacts/orchestration/parallel-planner-state.json`,
+   adding `-Band <Cn>` when the operator passed `--band`. The helper reads the branch by ref, selects
+   the newest preparation receipt or infers the stage from the branch files, compares the files the
+   plan cites against `origin/main` since the base commit, and prints `next_action`.
+   - When `next_action` is `admit_prepared` (stage `cleared`, verdict `fresh`), run no preparation
+     child, no preflight, and no plan revision. Record the output's `preparation_status`,
+     `plan_hash`, `base_commit`, `complexity_band` (the `band.value`), and `band_source` (the
+     `band.source`) on the item, and continue with step 3.
+   - Otherwise delegate the preparation child described below on the item's pushed branch, not on
+     a new branch, and append after the unchanged kickoff line the resume line
+     `Preparation resume: stage <stage>. Existing artifacts: <paths>. Do not repeat a completed stage; supersede with new timestamped files.`
+     with `<stage>` set to the output's `resume_stage` and `<paths>` listing the existing
+     `research_path`, `spec_path`, and `plan_path` relative to the feature folder. A stale item
+     (verdict `stale`) resumes at preflight with the output's `changed_cited_paths` as the findings,
+     under the single-pass rule of `.claude/skills/orchestrate/SKILL.md` `## Delegation Model`
+     (trivial defects fixed in place, one planner revision for substantive defects, and a halt with
+     the defect list when a second round still fails). A plan that never cleared preflight always
+     runs preflight. A contract change found by that preflight, or a `premise_falsified` verdict
+     (a cited path removed on `main`), resumes at `plan`: the new plan is a new timestamped file,
+     and no superseded artifact is deleted.
+   - The band source order is `--band` (`band_source: caller`), then the planner checkpoint item's
+     `complexity_band` (`planner_checkpoint`), then the `## Complexity Assessment` procedure below
+     (`assessment`).
+
+   Otherwise run preparation through a preparation-mode child `Agent(orchestrator)`
    run, reusing the existing `route_id: preparation` contract UNCHANGED: promotion, research,
    `spec.md`, `user-story.md`, the atomic plan, and preflight clearance. Do not fork a variant
    contract for parallel admission. Preparation yields the item's DECLARED blast radius, and only
    the planner-computed declared radius is authoritative for scheduling. The item's lifecycle
    advances `proposed` -> `admitted` -> `prepared` during this step, recorded as item-state updates in
-   `items[]` with the checkpoint's lifecycle timestamps. After the admitted item's preflight
+   `items[]` with the checkpoint's lifecycle timestamps. When the band source is `assessment`, after
+   the admitted item's preflight
    clearance, perform the `parallel-plan` skill's `## Complexity Assessment` procedure for it, and
    record the resulting `complexity_band` on the admitted orchestrator-checkpoint item so step 3's
    edge derivation and the parent's model routing read the same band.
@@ -125,6 +162,11 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    `qualifies for combination; not combined (combination applies at planning time only)`. This
    step never combines items: it adds no checkpoint field and makes no `mutations[]` change for a
    qualifying pair.
+   Record each `--after <earlier>` flag as one top-level `precedence[]` entry
+   `{before, after, source, recorded_at}` with `before` the earlier item, `after` the candidate,
+   `source` `operator`, and `recorded_at` the current UTC minute. Each precedence pair is a
+   separating input, never a dependency key: add it to the edges passed to steps 4 and 5 as one
+   more `<a>:<b>` edge with `a < b`, so the coloring always separates the pair.
 
 4. **Decide admission.** Call the bundled entry point, which needs no Python interpreter:
 
@@ -166,12 +208,23 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    `.claude/skills/parallel-orchestrate/SKILL.md` — so the current cohort durably holds `scheduled`
    members that a candidate can contend with.
 
+   A candidate with an active unmerged predecessor (a `precedence[]` entry whose `before` item has a
+   `merge_status` other than `merged` or `worktree_removed` and a `state` other than `withdrawn`) is
+   forced to `defer_and_recolor` even when `admit` prints `admit_current_cohort`.
+
    A conflict with an unstarted member of the CURRENT cohort defers the candidate and recolors,
    because the next `max_concurrency` batch would otherwise launch the two concurrently. A conflict
    with an unstarted item OUTSIDE the current cohort does not defer: the cohort barrier keeps the
    two from running concurrently, so the coloring's existing separation already resolves it.
 
-5. **Apply the recolor result.** Write the recolor output field `cohort_assignments` into
+5. **Apply the recolor result.** Before writing, pass the recolor result through the precedence
+   lift: `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 order-cohorts -Cohorts <table-json> -Edges "<a>:<b> ..." -Precedence "<before>:<after> ..." -Pinned "<k> ..." -Floor <current_cohort>`,
+   which moves an unstarted `after` item above its `before` items and never moves a pinned item.
+   After writing, and before step 6 appends the mutation entry, run
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 test-cohorts -CheckpointPath artifacts/orchestration/parallel-orchestrator-state.json`;
+   on exit 1 (`precedence_violated`, `precedence_cycle`, or `precedence_unknown_item`), restore the
+   prior `cohorts[]` and `recolor_generation` and stop with the helper's stderr line.
+   Write the recolor output field `cohort_assignments` (as lifted) into
    `cohorts[]` and set the top-level `recolor_generation` to the output field `generation`. The
    result's key set equals the
    unstarted set exactly and contains no pinned key: no in-flight item changes cohort or state as a
@@ -216,12 +269,23 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    "parallel-orchestrator-state"`. A non-empty error list means the admission was applied
    incorrectly; correct the checkpoint rather than proceeding.
 
+8. **Rewrite the durable scheduling record.** Build the record content with
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 record -RunFolder docs/features/parallel/<slug> -Entry <entry-json>`,
+   where the entry carries the checkpoint's `conflict_edges`, `tolerated_overlaps`, `precedence`,
+   and `items`. The helper prints the content and makes no git write. Write it to
+   `docs/features/parallel/<slug>/parallel-scheduling.json` on `parallel/<slug>-plan` and commit it
+   with a pathspec under `docs/features/parallel/`, so a re-seed from another checkout reads the
+   recorded edges and plan hashes by ref.
+
 ## Constraints
 
 - One admission per invocation, one `mutations[]` entry per successful admission. A failed
   preparation appends no entry and leaves `items[]` without the candidate.
-- No field and no enum member is added to `mutations[]`, `items[]`, or any state or merge-status
-  enum. A `conflict_edges[]` entry may carry only the three tolerated extra fields `hard`, `cost`,
+- No field and no enum member is added to `mutations[]` or any state or merge-status enum. The only
+  fields added to `items[]` are the four tolerated fields `preparation_status`, `plan_hash`,
+  `base_commit`, and `band_source` declared in `## Prepared-Item Admission (issue #1047)` of
+  `.claude/rules/parallel-orchestration.md`, which also declares the top-level `precedence[]` list
+  this skill records. A `conflict_edges[]` entry may carry only the three tolerated extra fields `hard`, `cost`,
   and `benefit` (tolerated-not-validated, returned by the scheduling entry point), and no reason
   member is added: the four `conflict_edges[].reason` members are unchanged. The nine parallel
   enums are owned by `.claude/rules/parallel-orchestration.md` and are consumed, never extended.

package/resources/claude-customizations/.claude/skills/parallel-orchestrate/SKILL.md

@@ -129,6 +129,16 @@ completion notification. A blocked item (`blocked_ci_loop_limit` or `blocked_dri
 `merged` nor `worktree_removed`, so it holds every conflicting later-cohort neighbour and,
 transitively, the tail of its own conflict component; items outside that component are unaffected.
 
+**Precedence.** An item named as `after` in an active `precedence[]` entry (the operator ordering
+input declared in `## Prepared-Item Admission (issue #1047)` of
+`.claude/rules/parallel-orchestration.md`) may start only when its `before` item has `merge_status`
+`merged` or `worktree_removed`, whatever the two items' cohorts. A `withdrawn` predecessor releases
+the constraint, and a `blocked` predecessor holds its dependent. Layer 1 enforces this rule through
+`Test-ParallelCohortBarrierClear` in `.claude/hooks/enforce-parallel-cohort-barrier-helpers.ps1`,
+which denies a target whose predecessor is not released and fails closed on a missing predecessor
+record. Layer 2 does not check precedence: the Python orchestrator-state validator reads
+`conflict_edges[]` only.
+
 **`current_cohort` is a progress indicator, not a gate.** `current_cohort` is the LOWEST
 current-generation cohort index that still contains a non-terminal, non-withdrawn item. It is
 recomputed and written only on durable confirmation from `git worktree list --porcelain`,
@@ -265,6 +275,10 @@ carries exactly these five elements.
    execution from that plan rather than re-running promotion, research, or planning. The item's
    prepared feature folder and approved atomic plan are already committed and preflight-clear on the
    item's own pushed feature branch.
+   The prompt also carries the item's admitted plan hash as `plan-hash: <hex>` and instructs the child, before any other step, to run `git rev-parse HEAD:<plan-path>` and to stop with `blocked_reason: premise_falsified` when the printed hash differs from `<hex>`.
+   The `<hex>` value is the item's `plan_hash` from the orchestrator checkpoint item, else the
+   kickoff `## Integrity` row for its plan path. The check runs before the child reconciles with
+   `origin/main`, so a plan that changed after admission never reaches atomic execution.
    The execution child starts a new checkpoint in its own worktree, and the preparation checkpoint
    does not carry over, so the prompt also instructs the child to verify the item's GitHub issue
    read-only (gh issue view), not to call `potential_to_issue` or the promotion-entry tool, and to
@@ -404,6 +418,23 @@ Procedure, per item:
    CI-dependent acceptance criteria. When either check fails, do not record
    `merge_status: ci_green` and do not run `gh pr merge`; the item waits until its child pushes
    the check-off and re-runs S9, and the parent does not commit the check-off itself.
+   **Turn gap.** A child can end its turn with its pull request open and its CI green gate still
+   pending. On every child completion, read the child checkpoint
+   `<worktree>/artifacts/orchestration/orchestrator-state.json`, with the worktree path located by
+   `git worktree list --porcelain`. When its `step9_status` is not `passed` or its `blocked_reason`
+   is `awaiting_ci`, keep `merge_status: pr_open` and treat the item as not done: poll
+   `gh pr checks` through the parser above until the conclusion is terminal, then
+   re-delegate the child once to resume at the CI green gate, by the same re-delegation mechanism as
+   `## Per-Item Merge-Conflict Handling`; a CI-failure cycle counts toward `remediation_loop`.
+   Record `ci_green` only after that resumed run reports its CI green gate `passed`.
+   **Concurrent review.** When the child checkpoint records `review_mode: "concurrent"`, do not
+   record `merge_status: ci_green` and do not run `gh pr merge` until its last
+   `review_outcomes[]` entry is `PASS` at a current head, as the join in
+   `## Concurrent Review and CI (review_mode)` of `.claude/skills/orchestrate/SKILL.md` defines it;
+   keep `merge_status: pr_open` and treat the item as not done. Issue #1097 amends
+   `.claude/skills/orchestrate/SKILL.md` for every new run and adds no parallel-specific condition
+   to the child's PR Creation Gate. The merge gate reads the child through the item target, so
+   this step is the backstop when that target does not resolve.
 3. Execute `gh pr merge --merge <PR>` for that item's pull request, whose base is `main`.
    Do not pass `--delete-branch` or `--auto`. A zero exit status does not prove a merge: when
    `main` uses a merge queue, `gh pr merge` exits 0 after it enqueues the pull request or enables
@@ -711,8 +742,9 @@ This section is consumption documentation only. The checkpoint schema is owned b
 as prose invariants in `.claude/rules/parallel-orchestration.md`, and enforced by
 `scripts/dev_tools/validate_parallel_orchestrator_state.py`. Consume that schema;
 add no field to it that `.claude/rules/parallel-orchestration.md` does not declare,
-and extend no enum in it. `mergeable_conflicts_resolved` is the one declared optional item
-field.
+and extend no enum in it. The declared optional item fields are `mergeable_conflicts_resolved`,
+`preparation_status`, `plan_hash`, `base_commit`, and `band_source`, and the declared optional
+top-level field is `precedence[]` (`## Prepared-Item Admission (issue #1047)` of the rule).
 
 Fields `parallel-orchestrator` writes to `artifacts/orchestration/parallel-orchestrator-state.json`:
 `objective`, `route_id: "parallel"`, `parallel_slug`, `parallel_manifest_path`,