@danmoisan/drm-copilot-mcp 1.1.25 → 1.1.27

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

@@ -1,7 +1,7 @@
 ---
 name: parallel-plan
 description: Prepare a set of thematically unrelated items for concurrent execution before any execution begins - item intake over issue numbers and potential-entry paths, concurrent preparation-mode child orchestrator delegations, blast-radius computation and V1-V3 validation, cohort seeding with a recomputation-parity check, run-manifest and planner-checkpoint authoring, and the parallel-orchestrator kickoff artifact.
-argument-hint: "[items: issue numbers and/or potential-entry paths]"
+argument-hint: "[items: issue numbers and/or potential-entry paths] [--after <later>:<earlier> ...]"
 context: fork
 agent: parallel-planner
 ---
@@ -16,7 +16,8 @@ $ARGUMENTS
 This skill frames work for the `parallel-planner` agent, parallel to how
 `.claude/skills/epic-plan/SKILL.md` frames work for `epic-planner`. The `parallel` surface
 schedules thematically unrelated items by computed blast-radius contention: there is no worthiness
-assessment, no operator-supplied ordering, and no shared branch into which item work merges.
+assessment, no operator-supplied ordering beyond the optional `--after <later>:<earlier>`
+precedence flags, and no shared branch into which item work merges.
 Planning ends at preflight clearance and cohort seeding; no atomic execution, PR authoring, or CI
 monitoring occurs under this skill.
 
@@ -62,13 +63,29 @@ identical forms.
 - **`kind`.** Record `kind: feature | bug` at intake from the item source (issue labels, or the
   potential entry's declared kind). When the source is indeterminate, default to `feature` and note
   the choice `[recommendation, not upstream-constrained]`.
+- **Admission assessment.** Run the same `assess` subcommand `/parallel-add` step 2 runs for every
+  item whose branch is pushed:
+  `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 assess -Branch origin/<item branch> -FeatureFolder <feature folder>`.
+  An item with no pushed branch (an unpromoted potential entry) takes `full_preparation`. Fan-out
+  takes only the items whose `next_action` is not `admit_prepared`. An item whose `next_action` is
+  `admit_prepared` (stage `cleared`, verdict `fresh`) runs no preparation child: record its
+  `plan_path`, `research_path`, `plan_hash`, `base_commit`, `branch_name`, and
+  `preflight_status: PREFLIGHT: ALL CLEAR` from the branch, set `preparation_status: prepared`
+  (the planner ready value that corresponds to the admission stage `cleared`), and record
+  `topology_receipt` as not applicable, because no preparation child ran for it.
+- **Precedence input.** Record each `--after <later>:<earlier>` flag as one top-level
+  `precedence[]` entry `{before, after, source, recorded_at}` with `source` `operator`, as
+  declared in `## Prepared-Item Admission (issue #1047)` of `.claude/rules/parallel-orchestration.md`.
+  The flags are optional and are never requested.
 
 The operator is never asked for ordering edges, cohort assignments, or a worthiness verdict.
 Intake proceeds directly to preparation fan-out.
 
 ## Preparation Fan-Out
 
-One preparation-mode `Agent(orchestrator)` run per item. Preparation produces documents and plans
+One preparation-mode `Agent(orchestrator)` run per incomplete item, that is, per item whose
+`assess` `next_action` is not `admit_prepared`; the waves below cover the incomplete items only.
+Preparation produces documents and plans
 rather than code, and items carry no ordering constraint, so preparations may run concurrently —
 but they are BOUNDED, not unbounded.
 
@@ -84,6 +101,8 @@ JSON array of arrays, returns the batches in order, and sorts the keys itself, s
 does not depend on caller ordering. Launch wave *k* as one message carrying that wave's `Agent`
 calls, each `isolation: "worktree"` and `run_in_background: true`.
 Create each preparation worktree's branch from `origin/main`.
+A resumed item (`next_action` `resume_preparation`) instead runs on its pushed branch, as
+`## Issue Combination` step 3 does, so its completed stages stay on that branch.
 Launch wave *k+1* only after every child of wave *k* has TERMINATED — not merely reported
 progress. All of this happens inside a single `/parallel-plan` invocation with no operator action
 between waves.
@@ -107,13 +126,18 @@ invocations after the initial plan. Use `/parallel-plan` for intake and `/parall
 admit an item into a run that is already in flight.
 
 Each delegation prompt includes this literal kickoff line, followed by the model-budget marker
-line and, for an issue-number item only, the issue-adoption line:
+line, for an issue-number item only, the issue-adoption line, for a resumed item only, the
+preparation-resume line, and the preparation-receipt line:
 
 > `Preparation mode: true. route_id: preparation. parallel_slug: <slug>. Perform promotion, research, feature documents (spec.md, user-story.md), atomic planning, and preflight clearance only. Atomic execution, PR authoring, and CI monitoring are out of scope for this run and are executed later by parallel-orchestrator. After the atomic-executor preflight returns PREFLIGHT: ALL CLEAR, commit the feature folder and plan to the current branch, push the current branch to origin, set out-of-scope step statuses to not-applicable, set next_step to S5_atomic_execution, and stop, reporting the plan-path and preflight status.`
 >
 > `model_budget.fable_policy: <disabled|available|preferred>.`
 >
 > `Issue adoption: this item's GitHub issue already exists. Verify it read-only (gh issue view), do not call potential_to_issue or the promotion-entry tool, and record a top-level issue_adoption object in the checkpoint per .claude/rules/orchestrator-state.md with origin filed_before_orchestration (or transferred when the issue was transferred), waiving potential_to_issue and the promotion-entry tool for the checkpoint's promotion-type. When a lifecycle record for the item exists under docs/features/potential/promoted/, cite it as potential_record.`
+>
+> `Preparation resume: stage <stage>. Existing artifacts: <paths>. Do not repeat a completed stage; supersede with new timestamped files.`
+>
+> `Preparation receipt: before the commit, write <feature folder>/evidence/other/preparation-receipt.<yyyy-MM-ddTHH-mm>.json with schema_version, stage, research_path, spec_path, plan_path, plan_hash, base_commit, preflight_status, and recorded_at.`
 
 Properties of that line, each individually load-bearing:
 
@@ -144,6 +168,21 @@ to execution, so the execution child records its own adoption (see
 creates and commits the feature folder, the execution child's adoption also waives
 `new_active_feature_folder` and records `feature_folder_record` for that committed folder.
 
+**Preparation-resume line.** The preparation-resume line is emitted only for a resumed item, after
+the issue-adoption line (or after the model-budget marker line for a potential-entry item). Its
+`<stage>` is the `assess` `resume_stage`, and its `<paths>` are the existing `research_path`,
+`spec_path`, and `plan_path` written relative to the feature folder. The line carries no mode
+marker and no active feature-folder path and does not match the hook issue-number pattern, so hook
+target resolution and mode classification are unchanged. A stale item resumes at preflight with
+the `assess` `changed_cited_paths` as findings under the unchanged single-pass rule of
+`.claude/skills/orchestrate/SKILL.md` `## Delegation Model`; a falsified premise resumes at `plan`,
+and a superseded artifact is replaced by a new timestamped file and never deleted.
+
+**Preparation-receipt line.** The preparation-receipt line is emitted for every delegated item. The
+child resolves `<feature folder>` to its own folder and writes the receipt declared in
+`## Prepared-Item Admission (issue #1047)` of `.claude/rules/parallel-orchestration.md` before its
+commit, so a later `assess` reads the stage, plan hash, and base commit from the branch.
+
 **No edit to shared surfaces.** No edit is made to `.claude/skills/orchestrate/SKILL.md` or to
 `config/orchestration-routing.json`, including the `preparation` route. The route mechanism is
 marker-driven; the child contract's "commit ... to the current branch" wording is satisfied by a
@@ -437,7 +476,13 @@ The library returns the partition; the planner supplies the record fields.
    (hard classes, integer cost, pairwise benefit, and the configured `conflict_tolerance`). It
    returns `edges` and `tolerated_overlaps`. The -Relation argument is required; pass the facade's
    Test-BlastRadiusConflict function object as shown. Pass the returned `edges` pairs as
-   `--edges "<a>:<b> ..."` and the item keys as `--keys "<k1> <k2> ..."`.
+   `--edges "<a>:<b> ..."` and the item keys as `--keys "<k1> <k2> ..."`. Add each recorded
+   `precedence[]` pair to `--edges` as one more separating `<a>:<b>` edge with `a < b`, so the
+   coloring always separates the pair. Then pass the coloring through the precedence lift:
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 order-cohorts -Cohorts <compute-cohorts output> -Edges "<a>:<b> ..." -Precedence "<before>:<after> ..."`.
+   No item has started at seeding, so the call passes no option that holds an item in place, and
+   its `cohorts` output is the table steps 3 and 5 record. A `precedence_cycle` or
+   `precedence_unknown_item` rejection (exit 1) stops the run with the helper's stderr line.
    The detection relation inside the entry point contributes no `path_overlap` edge for a path
    matching the truth table's optional `mergeable_paths` list, and the path stays in the declared
    radius. When `Test-BlastRadiusConflict` is called directly (for example, while investigating a
@@ -482,6 +527,18 @@ The library returns the partition; the planner supplies the record fields.
    (the bash port of `compute_concurrency_batches(cohort_item_keys, max_concurrency)`), which fills
    slots in ascending item-key order. Recoloring under add, remove, or drift mutation is F6 and F8
    scope. This skill performs seeding only.
+7. **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>`
+   from the recorded `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` and commit it on `parallel/<slug>-plan`
+   with the manifest. A re-seed applies the reuse rule per item with
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 reuse-edges -Slug <slug> -IssueNum <issue> -PlanHash <plan_hash>`,
+   where `<plan_hash>` is the item's `plan_hash` from its `assess` output. The helper reads the
+   committed record by ref from `origin/parallel/<slug>-plan`, runs no fetch, and prints
+   `{action, edges, reason}`. On `action` `reuse` the printed `edges` are that item's recorded
+   edges and are reused; on `action` `recompute` (reason `record_missing`, `unknown_item`, or
+   `plan_hash_changed`) that item's edges are recomputed.
 
 ### Recomputation parity (planner-owned check)
 
@@ -492,12 +549,18 @@ skill discharges that obligation as documented procedure, not as a new module:
 
 1. After writing `cohorts[]` into the checkpoint and **before** emitting the kickoff artifact,
    re-invoke `compute_cohorts` over exactly the `item_keys` and `conflict_edges` recorded in the
-   checkpoint.
+   checkpoint (through `compute-cohorts.sh`), plus the separating edges of the recorded
+   `precedence[]` pairs, and pass the result through `order-cohorts` with the recorded precedence,
+   exactly as `### Seeding procedure` step 1 does.
 2. Assert that the recomputed list of lists maps to exactly the recorded `cohorts[]` at
    `generation: 0`: the same partition, the same `index` assignment, and the same ascending
-   `item_keys[]` ordering.
-3. A mismatch is a **Blocking** condition. Stop the run and report the mismatch. Do not
-   auto-correct the recorded cohorts, and do not emit the kickoff artifact.
+   `item_keys[]` ordering. Then run
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 test-cohorts -CheckpointPath artifacts/orchestration/parallel-planner-state.json`,
+   which rejects with `precedence_violated` when a cohort places an `after` item at or before an
+   active `before` item.
+3. A mismatch is a **Blocking** condition, and so is a `test-cohorts` rejection. Stop the run and
+   report the mismatch or the rejection. Do not auto-correct the recorded cohorts, and do not emit
+   the kickoff artifact.
 
 No production module is added for this check; it is a re-invocation of the landed library.
 
@@ -558,20 +621,22 @@ Write `artifacts/orchestration/parallel-planner-state.json` after every complete
 
 Top-level fields: `objective`, `parallel_slug`, `parallel_manifest_path`, `mode`,
 `max_concurrency`, `plan_home_branch` (`parallel/<slug>-plan`), `items[]`, `cohorts[]`,
-`conflict_edges[]`, `recolor_generation`, `kickoff_prompt_path`
+`conflict_edges[]`, `precedence[]` (the operator precedence entries, declared in
+`## Prepared-Item Admission (issue #1047)` of the rule), `recolor_generation`, `kickoff_prompt_path`
 (`artifacts/orchestration/parallel-kickoff-<slug>.md`), `completed_steps`, `next_step`, and
 `last_updated`. F3's landed required-key set (planner invariant P1) is a strict subset of this
 list, and `plan_home_branch` is a permitted additional field.
 
 Per item: `issue_num`, `feature_folder`, `kind`, `state`, `complexity_band`, `complexity_assessment`,
 `preparation_status`,
-`research_path`, `plan_path`, `preflight_status`, `branch_name`, `worktree_path`, `blast_radius`
+`research_path`, `plan_path`, `plan_hash`, `base_commit`, `preflight_status`, `branch_name`, `worktree_path`, `blast_radius`
 (with `source: "declared"`), `radius_validation` (the `v1`, `v2`, and `v3` results with their
 severities), `model_routing_receipt`, and `topology_receipt`.
 
 **Deliberately absent:** any `epic_worthiness` analogue, any `depends_on` field, and any `wave`
 field. The parallel surface renders no worthiness verdict and expresses ordering only as
-blast-radius overlap.
+blast-radius overlap and as the operator `precedence[]` input, which is a separating input and not
+a dependency field.
 
 **Readiness contract.** Before reporting completion the checkpoint must satisfy F3's
 `require_ready_for_execution` gate: at least two items (invariant P6); every item
@@ -674,6 +739,11 @@ Structural requirements enforced by the contract module:
   commit of `parallel/<slug>-plan` as run-level provenance and a per-item `plan-path | plan-hash`
   table whose hashes are 40 to 64 hex characters with no repeated plan path.
 
+The planner writes the `## Integrity` section with one row per item, whose `plan-hash` is that
+item's `assess` `plan_hash` (the plan blob hash at the item branch head), the same value recorded
+on the checkpoint item and in the durable scheduling record. The parallel orchestrator passes it to
+the item's execution child in kickoff element 4, which verifies it before any other step.
+
 Validate the artifact through `mcp__drm-copilot__validate_orchestration_artifacts` with
 `artifact_type: "parallel-kickoff"`. That artifact type dispatches to
 `scripts/dev_tools/parallel_kickoff_contract.py`, which this feature delivers.

package/resources/claude-customizations/.claude/skills/powershell-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: powershell-qa-gate
-description: Final QA gate for PowerShell changes. Executes the full PoshQC format -> analyze -> test toolchain (with coverage where enforced), compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
+description: Final QA gate for PowerShell changes. Executes the full PoshQC format -> analyze -> test toolchain (with coverage where enforced), compares static tool results against the static baseline, reads test and coverage results from the single gate run, and produces the required reporting block before the agent declares the change complete.
 ---
 
 # PowerShell QA Gate
@@ -12,14 +12,14 @@ Canonical procedure for the Phase D final quality gate that every PowerShell cha
 Use this skill when:
 
 - `powershell-typed-engineer` is about to declare a change complete.
-- An executor has finished applying a planned batch and must verify zero regressions against the baseline captured in Phase A.
+- An executor has finished applying a planned batch and must verify the static tools against the static baseline recorded in Phase A, and the tests in the single gate run.
 - A reviewer needs to confirm the toolchain was actually run and produced a clean pass.
 
 ## Required Inputs
 
 Before invoking this gate, the agent must have:
 
-- a baseline record produced in Phase A, containing PSScriptAnalyzer findings, Pester pass/fail status, and per-file coverage status for the in-scope files,
+- a static baseline record produced in Phase A, containing PSScriptAnalyzer findings for the in-scope files,
 - the exact list of touched production and test files,
 - a clean working tree (all planned edits committed to the working copy).
 
@@ -29,39 +29,38 @@ Run the full toolchain in this exact order. If any step fails or modifies files,
 
 1. `mcp__drm-copilot__run_poshqc_format`
 2. `mcp__drm-copilot__run_poshqc_analyze`
-3. `mcp__drm-copilot__run_poshqc_test`
-4. Coverage check (when enforced by task/repo flow) — use the Pester coverage output from step 3 or the repo coverage task.
+3. One `Invoke-PoshQCParallelTest` run, through the route in the `execution-environment` brief. Read `ExitCode` first.
+4. Coverage check (when enforced by task/repo flow) — use the Pester coverage output of the run in step 3.
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
-## Delta Requirements (Zero-Regression Hard Gate)
+## Gate Requirements (Hard Gate)
 
-Compare the final results to the Phase A baseline. All of the following must hold:
+Compare the final static tool results to the static baseline recorded in Phase A, and read test and coverage results from the single gate run. All of the following must hold:
 
 - **PSScriptAnalyzer delta**: 0 new findings across the repository.
-- **Pester delta**: 0 new failing tests.
-- **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
-- **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
-- **New modules, classes, or methods**: line coverage >= 85% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. No regression on changed lines. Pester measures command (instruction) coverage and line coverage only; branch coverage is not measurable for PowerShell, so no branch-coverage gate applies here (see `.claude/rules/powershell.md`). Command coverage is informational and carries no threshold.
+- **Pester gate**: zero failures in the single gate run.
+- **Per-file coverage**: every changed file meets the coverage thresholds, read from the single gate run, and new behavior is tested.
+- **New modules, classes, or methods**: line coverage >= 85% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. Pester measures command (instruction) coverage and line coverage only; branch coverage is not measurable for PowerShell, so no branch-coverage gate applies here (see `.claude/rules/powershell.md`). Command coverage is informational and carries no threshold.
 
-If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
+If any check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all checks are clean.
 
 ## Required Reporting Block
 
 Every completion response must include the following sections:
 
 1. **Scope** — exact file list touched in this change.
-2. **Baseline** — PSScriptAnalyzer, Pester, and coverage status recorded in Phase A.
+2. **Baseline** — PSScriptAnalyzer findings recorded in Phase A.
 3. **Plan** — design and test-strategy summary, referencing the approved plan, including proposed script/module structure, minimal DI seams, Pester scenario-level test strategy, and external executable wrapper mock strategy.
 4. **Diffs** — patch-style or full-file replacements for scoped files only.
-5. **QA Gate Results** — PSScriptAnalyzer delta, failing-tests delta, per-file coverage delta, and overall coverage delta when applicable. If any step could not be run, mark the corresponding line **unverified** and state why.
+5. **QA Gate Results** — PSScriptAnalyzer delta, failures in the single gate run, and per-file coverage against the thresholds. If any step could not be run, mark the corresponding line **unverified** and state why.
 
 ## Evidence Storage
 
 Persist toolchain output according to `evidence-and-timestamp-conventions`:
 
-- store baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
-- store post-change outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
+- store static baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
+- store final gate outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
 - use ISO-8601 UTC timestamps in folder names.
 
 This location is canonical per evidence-and-timestamp-conventions and is not overridable.
@@ -73,5 +72,5 @@ The evidence paths must be referenced in the agent's completion message to satis
 
 - Do not disable, skip, or narrow any step of the toolchain to reach a clean result.
 - Do not add PSScriptAnalyzer rule suppressions (`[Diagnostics.CodeAnalysis.SuppressMessageAttribute]` or `PSScriptAnalyzer` suppression comments) or Pester `-Skip` / `-Pending` to mask new findings introduced by the change.
-- Do not report success based on partial or targeted runs alone. Targeted runs are allowed mid-batch, but the final gate requires a full-repo pass.
+- Do not report success based on partial or targeted runs. A focused run of one test file to debug a specific failure is debugging only; it is never a gate or evidence, and the final gate is the single gate run.
 - Do not mock `git`, `gh`, `actionlint`, or other executables directly; mock the wrapper function (for example `Invoke-GitExe`) per `.claude/rules/powershell.md`.

package/resources/claude-customizations/.claude/skills/python-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: python-qa-gate
-description: Final QA gate for Python changes. Executes the full Black -> Ruff -> Pyright -> Pytest toolchain, compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
+description: Final QA gate for Python changes. Executes the full Black -> Ruff -> Pyright -> Pytest toolchain, compares static tool results against the static baseline, reads test and coverage results from the single gate run, and produces the required reporting block before the agent declares the change complete.
 ---
 
 # Python QA Gate
@@ -12,14 +12,14 @@ Canonical procedure for the Phase D final quality gate that every Python change
 Use this skill when:
 
 - `python-typed-engineer` is about to declare a change complete.
-- An executor has finished applying a planned batch and must verify zero regressions against the baseline captured in Phase A.
+- An executor has finished applying a planned batch and must verify the static tools against the static baseline recorded in Phase A, and the tests in the single gate run.
 - A reviewer needs to confirm the toolchain was actually run and produced a clean pass.
 
 ## Required Inputs
 
 Before invoking this gate, the agent must have:
 
-- a baseline record produced in Phase A, containing Ruff, Pyright, Pytest, and per-file coverage status for the in-scope files,
+- a static baseline record produced in Phase A, containing Ruff and Pyright findings for the in-scope files,
 - the exact list of touched production and test files,
 - a clean working tree (all planned edits committed to the working copy).
 
@@ -30,39 +30,38 @@ Run the full toolchain in this exact order. If any step fails or modifies files,
 1. `poetry run black .`
 2. `poetry run ruff check .`
 3. `poetry run pyright`
-4. `poetry run pytest --cov --cov-report=term-missing`
+4. `poetry run pytest -n auto --cov-branch --cov-report=term-missing --cov`
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
-## Delta Requirements (Zero-Regression Hard Gate)
+## Gate Requirements (Hard Gate)
 
-Compare the final results to the Phase A baseline. All of the following must hold:
+Compare the final static tool results to the static baseline recorded in Phase A, and read test and coverage results from the single gate run. All of the following must hold:
 
 - **Ruff delta**: 0 new findings across the repository.
 - **Pyright delta**: 0 new diagnostics across the repository.
-- **Pytest delta**: 0 new failing tests.
-- **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
-- **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
-- **New modules, classes, or methods**: line coverage >= 85% and branch coverage >= 75% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. No regression on changed lines.
+- **Pytest gate**: zero failures in the single gate run.
+- **Per-file coverage**: every changed file meets the coverage thresholds, read from the single gate run, and new behavior is tested.
+- **New modules, classes, or methods**: line coverage >= 85% and branch coverage >= 75% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds.
 
-If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
+If any check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all checks are clean.
 
 ## Required Reporting Block
 
 Every completion response must include the following sections:
 
 1. **Scope** — exact file list touched in this change.
-2. **Baseline** — Ruff, Pyright, Pytest, and coverage status recorded in Phase A.
+2. **Baseline** — Ruff and Pyright findings recorded in Phase A.
 3. **Plan** — design and test-strategy summary, referencing the approved plan.
 4. **Diffs** — patch-style or full-file replacements for scoped files only.
-5. **QA Gate Results** — Ruff, Pyright, Pytest, and coverage deltas. If any step could not be run, mark the corresponding line **unverified** and state why.
+5. **QA Gate Results** — Ruff and Pyright deltas, failures in the single gate run, and per-file coverage against the thresholds. If any step could not be run, mark the corresponding line **unverified** and state why.
 
 ## Evidence Storage
 
 Persist toolchain output according to `evidence-and-timestamp-conventions`:
 
-- store baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
-- store post-change outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
+- store static baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
+- store final gate outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
 - use ISO-8601 UTC timestamps in folder names.
 
 This location is canonical per evidence-and-timestamp-conventions and is not overridable.
@@ -74,4 +73,4 @@ The evidence paths must be referenced in the agent's completion message to satis
 
 - Do not disable, skip, or narrow any step of the toolchain to reach a clean result.
 - Do not add Ruff `noqa`, Pyright `# type: ignore`, or test skips to suppress new findings introduced by the change.
-- Do not report success based on partial or targeted runs alone. Targeted runs are allowed mid-batch, but the final gate requires a full-repo pass.
+- Do not report success based on partial or targeted runs. A focused run of one test file to debug a specific failure is debugging only; it is never a gate or evidence, and the final gate is the single gate run.

package/resources/claude-customizations/.claude/skills/remediation-handoff-atomic-planner/SKILL.md

@@ -98,7 +98,7 @@ A comprehensive or final sweep in a remediation cycle covers that cycle's own pl
 
 - Phase headings: `### Phase N — <Title>`.
 - Tasks: `- [ ] [P#-T#]` with sequential per-phase IDs.
-- Phase 0 captures policy reads and baseline toolchain results per `policy-compliance-order` and `evidence-and-timestamp-conventions`.
+- Phase 0 captures policy reads and static baseline results per `policy-compliance-order` and `evidence-and-timestamp-conventions`.
 - Final phase runs the full toolchain QA loop in the order specified by `atomic-plan-contract` and records numeric coverage values where the repository policy requires coverage.
 - Evidence paths resolve to `<FEATURE>/evidence/<kind>/` per the non-overridable evidence path clause.
 - The plan is design-level per `## Design-Level Plan Contract (Mandatory)` in `atomic-plan-contract`, carries a `## Pre-Mortem` section, and ends with the final-phase self-review task. A proportionate plan covers only the listed findings and stays short.

package/resources/claude-customizations/.claude-variants/csharp-legacy/agents/csharp-typed-engineer.md

@@ -1,6 +1,6 @@
 ---
 name: csharp-typed-engineer
-description: Project-scoped worker that implements and verifies C# changes within typed repository boundaries. Applies the CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.
+description: Project-scoped worker that implements and verifies C# changes within typed repository boundaries. Applies the CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and quality gates read from the single gate run.
 tools:
   - Read
   - Grep
@@ -33,10 +33,10 @@ Follow the phased workflow defined by the preloaded skills:
 
 1. **Policy compliance** — apply `policy-compliance-order` to load mandatory repo policies before any change.
 2. **Routing and scope** — apply `csharp-change-budget-router` to estimate scope, select direct vs orchestrator handoff mode, and enforce the 3 production + 3 test per-batch cap.
-3. **Plan and baseline** — apply `atomic-plan-contract` for Phase 0 baseline capture and atomic plan structure. Delegate plan authoring to `atomic_planner` when no plan is supplied. Plans must include the proposed class and module structure, minimal DI seams, MSTest scenario-level test strategy, and Moq mock strategy.
-4. **Implement in batches** — apply the approved plan. After each batch, run targeted analyzer and nullable builds on touched projects plus targeted MSTest, and confirm per-file coverage.
-5. **Final QA gate** — apply `csharp-qa-gate` to run the full toolchain, enforce zero-regression deltas against the baseline, and produce the required reporting block before declaring completion.
-6. **Evidence and handoff** — store baseline and post-change evidence per `evidence-and-timestamp-conventions`. Trigger remediation via `remediation-handoff-atomic-planner` when deltas fail.
+3. **Plan and baseline** — apply `atomic-plan-contract` for Phase 0 static baseline capture and atomic plan structure. Delegate plan authoring to `atomic_planner` when no plan is supplied. Plans must include the proposed class and module structure, minimal DI seams, MSTest scenario-level test strategy, and Moq mock strategy.
+4. **Implement in batches** — apply the approved plan. After each batch, run targeted analyzer and nullable builds on touched projects. Test and coverage results come from the single gate run. A focused run of one test file to debug a specific failure is debugging only.
+5. **Final QA gate** — apply `csharp-qa-gate` to run the full toolchain, compare static tool results against the static baseline, read test and coverage results from the single gate run, and produce the required reporting block before declaring completion.
+6. **Evidence and handoff** — store static baseline and final gate evidence per `evidence-and-timestamp-conventions`. Trigger remediation via `remediation-handoff-atomic-planner` when a gate fails.
 
 ## Mode Marker Resolution
 
@@ -55,7 +55,7 @@ Stop implementation and return to the user when:
 
 - the scope estimate or an in-flight batch would exceed the 3-production-file cap in direct mode,
 - a file is above or would exceed the 800-line hard limit of the tiered file-size policy (split it before proceeding; at 500 lines look for a logical split, and at 700 lines split more aggressively),
-- any QA gate delta is non-zero after self-correction,
+- any QA gate check fails after self-correction,
 - the toolchain cannot be executed in the current environment (mark the change **unverified**),
 - orchestrator handoff mode is requested but the required context package is incomplete,
 - policy instructions conflict.

package/resources/claude-customizations/.claude-variants/csharp-legacy/skills/csharp-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: csharp-qa-gate
-description: Final QA gate for C# changes. Executes the full CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
+description: Final QA gate for C# changes. Executes the full CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, compares static tool results against the static baseline, reads test and coverage results from the single gate run, and produces the required reporting block before the agent declares the change complete.
 ---
 
 # C# QA Gate
@@ -12,14 +12,14 @@ Canonical procedure for the Phase D final quality gate that every C# change must
 Use this skill when:
 
 - `csharp-typed-engineer` is about to declare a change complete.
-- An executor has finished applying a planned batch and must verify zero regressions against the baseline captured in Phase A.
+- An executor has finished applying a planned batch and must verify the static tools against the static baseline recorded in Phase A, and the tests in the single gate run.
 - A reviewer needs to confirm the toolchain was actually run and produced a clean pass.
 
 ## Required Inputs
 
 Before invoking this gate, the agent must have:
 
-- a baseline record produced in Phase A, containing analyzer findings, compiler/nullable diagnostics, MSTest pass/fail status, and per-file coverage status for the in-scope files,
+- a static baseline record produced in Phase A, containing analyzer findings and compiler/nullable diagnostics for the in-scope files,
 - the exact list of touched production and test files,
 - a clean working tree (all planned edits committed to the working copy).
 
@@ -36,35 +36,34 @@ Run the full toolchain in this exact order. If any step fails or modifies files,
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
-## Delta Requirements (Zero-Regression Hard Gate)
+## Gate Requirements (Hard Gate)
 
-Compare the final results to the Phase A baseline. All of the following must hold:
+Compare the final static tool results to the static baseline recorded in Phase A, and read test and coverage results from the single gate run. All of the following must hold:
 
 - **Analyzer delta**: 0 new findings across the repository.
 - **Compiler / nullable delta**: 0 new diagnostics across the repository.
-- **MSTest delta**: 0 new failing tests.
-- **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
-- **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
+- **MSTest gate**: zero failures in the single gate run.
+- **Per-file coverage**: every changed file meets the coverage thresholds, read from the single gate run, and new behavior is tested.
 - **New modules, classes, or methods**: coverage >= 90% for each new unit introduced in the batch.
 
-If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
+If any check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all checks are clean.
 
 ## Required Reporting Block
 
 Every completion response must include the following sections:
 
 1. **Scope** — exact file list touched in this change.
-2. **Baseline** — analyzer, compiler/nullable, MSTest, and coverage status recorded in Phase A.
+2. **Baseline** — analyzer and compiler/nullable findings recorded in Phase A.
 3. **Plan** — design and test-strategy summary, referencing the approved plan.
 4. **Diffs** — patch-style or full-file replacements for scoped files only.
-5. **QA Gate Results** — analyzer, compiler/nullable, MSTest, and coverage deltas. If any step could not be run, mark the corresponding line **unverified** and state why.
+5. **QA Gate Results** — analyzer and compiler/nullable deltas, failures in the single gate run, and per-file coverage against the thresholds. If any step could not be run, mark the corresponding line **unverified** and state why.
 
 ## Evidence Storage
 
 Persist toolchain output according to `evidence-and-timestamp-conventions`:
 
-- store baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
-- store post-change outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
+- store static baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
+- store final gate outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
 - use ISO-8601 UTC timestamps in folder names.
 
 This location is canonical per evidence-and-timestamp-conventions and is not overridable.
@@ -76,4 +75,4 @@ The evidence paths must be referenced in the agent's completion message to satis
 
 - Do not disable, skip, or narrow any step of the toolchain to reach a clean result.
 - Do not add analyzer suppressions, `#pragma warning disable`, `#nullable disable`, or test `[Ignore]` attributes to suppress new findings introduced by the change.
-- Do not report success based on partial or targeted runs alone. Targeted runs are allowed mid-batch, but the final gate requires a full-solution pass.
+- Do not report success based on partial or targeted runs. A focused run of one test file to debug a specific failure is debugging only; it is never a gate or evidence, and the final gate is the single gate run.

package/resources/claude-customizations/.claude-variants/csharp-legacy/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 -> MSTest 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
@@ -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, MSTest, 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, MSTest, 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**).
 
 ## Worker Routing
 

package/resources/claude-customizations/pack-manifests/core.json

@@ -39,6 +39,7 @@
     ".claude/hooks/enforce-epic-merge-gate-resolution.ps1",
     ".claude/hooks/enforce-epic-merge-gate-command.ps1",
     ".claude/hooks/enforce-epic-merge-gate-green-ci.ps1",
+    ".claude/hooks/enforce-epic-merge-gate-review.ps1",
     ".claude/hooks/enforce-epic-wave-barrier.ps1",
     ".claude/hooks/enforce-epic-worktree-removal-gate.ps1",
     ".claude/hooks/enforce-epic-worktree-removal-gate-resolution.ps1",
@@ -47,6 +48,7 @@
     ".claude/hooks/enforce-file-size-limit.ps1",
     ".claude/hooks/enforce-model-routing-receipt.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate.ps1",
+    ".claude/hooks/enforce-orchestration-preimplementation-gate-cleanup.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-epic-scope.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-helpers.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-modes.ps1",
@@ -60,6 +62,7 @@
     ".claude/hooks/enforce-powershell-batch-budget.ps1",
     ".claude/hooks/enforce-pr-author-command-allowlist.ps1",
     ".claude/hooks/enforce-pr-author-skill.artifact-root.ps1",
+    ".claude/hooks/enforce-pr-author-skill.cleanup.ps1",
     ".claude/hooks/enforce-pr-author-skill.current-branch.ps1",
     ".claude/hooks/enforce-pr-author-skill.docs-only.ps1",
     ".claude/hooks/enforce-pr-author-skill.epic-base-branch.ps1",
@@ -71,6 +74,7 @@
     ".claude/hooks/enforce-python-batch-budget.ps1",
     ".claude/hooks/feature-folder-resolution.ps1",
     ".claude/hooks/feature-review-coverage-thresholds.ps1",
+    ".claude/hooks/hook-cleanup-context.ps1",
     ".claude/hooks/hook-command-heredoc.ps1",
     ".claude/hooks/hook-command-invocation.ps1",
     ".claude/hooks/hook-command-invocation-operands.ps1",
@@ -122,6 +126,7 @@
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_lib.sh",
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_preserve_eol_lib.sh",
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_preserve_lib.sh",
+    ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_preserve_merge_lib.sh",
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_report_records_lib.sh",
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_scan_helper.sh",
     ".claude/skills/commit-message/SKILL.md",
@@ -134,6 +139,12 @@
     ".claude/skills/discovery-workflow/SKILL.md",
     ".claude/skills/epic-orchestrate/SKILL.md",
     ".claude/skills/epic-plan/SKILL.md",
+    ".claude/skills/epic-progress-report/SKILL.md",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.Logic.ps1",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.Metrics.ps1",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.Render.ps1",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.State.ps1",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.ps1",
     ".claude/skills/epic-run/SKILL.md",
     ".claude/skills/evidence-and-timestamp-conventions/SKILL.md",
     ".claude/skills/execute-hard-lock/SKILL.md",
@@ -231,6 +242,10 @@
     ".claude/lib/parallel-drift/ParallelDriftHalt.psm1",
     ".claude/lib/parallel-drift/ParallelDrift.psm1",
     ".claude/lib/parallel-drift/Invoke-ParallelDriftDetection.ps1",
+    ".claude/lib/parallel-admission/ParallelAdmission.psm1",
+    ".claude/lib/parallel-admission/ParallelAdmissionPrecedence.psm1",
+    ".claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1",
+    ".claude/lib/parallel-admission/ParallelAdmissionJson.psm1",
     ".claude/rules/parallel-orchestration.md",
     ".claude/rules/shell.md",
     ".claude/lib/bash/abandon-parallel-item.sh",