@danmoisan/drm-copilot-mcp 1.1.25 → 1.1.27

package/resources/codex-and-agents-customizations/.agents/skills/orchestrator-state/SKILL.md

@@ -66,7 +66,7 @@ These invariants apply only when the checkpoint contains a top-level `remediatio
 
 1. **Non-empty `plan_path`.** Each cycle's `plan_path` must be a non-empty string. A missing value, a non-string value, or an empty/whitespace-only string is a malformed cycle.
 
-2. **Execution requires cleared preflight.** A cycle's `execution_status` may be in `{in_progress, complete, failed}` only when that cycle's `preflight.final_status` is exactly `'clear'`. Any other preflight status with one of those execution statuses is a malformed cycle (execution was recorded before preflight cleared).
+2. **Execution requires cleared preflight.** A cycle's `execution_status` may be in `{in_progress, complete, failed}` only when that cycle's `preflight.final_status` is exactly `'clear'`. Any other preflight status with one of those execution statuses is a malformed cycle (execution was recorded before preflight cleared). The invariant does not apply to a cycle whose `remediation_path` is exactly the string `light`, compared ordinally, because a light cycle runs no preflight; invariant 8 governs that cycle.
 
 3. **Exit gate requires zero blocking findings.** When a cycle's `exit_condition_met == true`, its `blocking_count` must be `0`. A non-zero `blocking_count` with `exit_condition_met == true` is a malformed cycle (the exit gate was marked satisfied while blocking findings remained).
 
@@ -78,6 +78,17 @@ These invariants apply only when the checkpoint contains a top-level `remediatio
 
 7. **`completed_attempts` counts completed attempts (R7).** When `remediation_loop.completed_attempts` is present, it must be a non-negative integer (not a boolean) equal to the number of object cycles whose `candidate_applied` is `true` (zero when `cycles` is absent or not a list), and any other value is a malformed loop.
 
+8. **Light remediation (issue #1097).** When a cycle object carries `remediation_path`, the rules below run in the accounting stage, after the R7 checks, per cycle in order, with byte-identical messages in `scripts/dev_tools/_orchestrator_state_light_cycle.py`, `extensions/drm-copilot/src/lib/validate/orchestrator-state-light-cycle.ts`, and `Get-RemediationLightCycleError` in `.claude/lib/orchestrator-state/OrchestratorStateRemediationAccounting.psm1`, pinned by the corpus `tests/fixtures/orchestrator_state_remediation_loop/`. A cycle without the key reaches none of them, so every existing checkpoint validates as before. `scope` on a finding is read only by these rules.
+   1. A value other than exactly `light` or `full`, null included: `Checkpoint remediation cycle #N remediation_path must be light or full.` Nothing further runs for the cycle, and nothing further runs for `full`.
+   2. A `preflight` key, whatever its value: `Checkpoint remediation cycle #N remediation_path is light but the cycle carries preflight.`
+   3. `opened_by_review` absent, or not naming a `REMEDIATION_REQUIRED` outcome by the R11 predicate: `Checkpoint remediation cycle #N remediation_path is light but opened_by_review does not name its opening review.` Rules 4 to 6 are then skipped.
+   4. More than 3 findings in that outcome (a non-list `findings` value counts as empty): `Checkpoint remediation cycle #N remediation_path is light but its opening review has M findings; the limit is 3.`
+   5. Per finding K whose `remediability` is not exactly `autonomous`, a non-object finding included: `Checkpoint remediation cycle #N remediation_path is light but finding #K is not autonomous.`
+   6. Per finding K whose `scope` is not exactly `contained`, absent included: `Checkpoint remediation cycle #N remediation_path is light but finding #K scope is not contained.`
+   7. The immediately prior list element is an object whose `remediation_path` is exactly `light`: `Checkpoint remediation cycle #N remediation_path is light but the prior cycle is light.`
+
+   Route (D9): the installed MCP validator applies invariant 8 only after the extension release that carries it is installed. Until then, a Claude run validates a light checkpoint through the repository-local Python CLI, and on Codex, whose completion boundary is the installed MCP validator, the light path is unavailable.
+
 ## Invariants (remediation_loop.review_outcomes)
 
 These invariants apply only when `remediation_loop` contains a `review_outcomes` key. The orchestrator appends one entry per review, including a `PASS` review, in the shape `{"verdict": <verdict>, "findings": [{"remediability": <class>}, ...]}`, where `findings` lists the review's blocking findings only. A halt or wait verdict records no remediation cycle.
@@ -109,6 +120,10 @@ Derivation order. The verdict is a pure function of the findings' classes, evalu
 
 3. **Verdict matches its findings (R10).** When an outcome passes the membership checks, its `verdict` must equal the verdict that the derivation order yields for its findings' classes. A mismatch is a malformed outcome.
 
+## Concurrent-Review Key (review_mode)
+
+The top-level checkpoint key `review_mode` selects the concurrent run sequence. Only the exact string `concurrent`, compared ordinally, activates it; an absent key, `null`, `sequential`, a case variant, a number, and every other value mean sequential. Under the key, each `remediation_loop.review_outcomes[]` entry carries `head_sha`, the full lowercase head the review ran against. `## Concurrent Review and CI (review_mode)` in `.agents/skills/orchestrate/SKILL.md` defines the run sequence.
+
 ## Human-Interaction Scope and Backward Compatibility
 
 These invariants apply only when the checkpoint contains a top-level `human_interaction` block. A checkpoint with no `human_interaction` key (the existing checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive and support the autonomous-execution mandate documented in `.agents/skills/orchestrate/SKILL.md`.

package/resources/codex-and-agents-customizations/.agents/skills/orchestrator-workflow/SKILL.md

@@ -374,14 +374,14 @@ Required behavior:
       in deterministic filename order, including timestamped scaffolded plans.
     - The planning route MUST be `atomic-planner -> atomic-executor` for preflight validation.
     - The planner MUST update `${plan-path}` in place and MUST NOT create additional `plan.*.md` files for revisions.
-    - The approved plan MUST include explicit Phase 0 baseline evidence tasks and explicit final-QA evidence or coverage tasks for each language in scope where policy requires them.
+    - The approved plan MUST include explicit Phase 0 static baseline evidence tasks and explicit final-QA evidence or coverage tasks for each language in scope where policy requires them.
     - Do not mark Step 7 complete until delegate output includes both a concrete `plan-path` and final `PREFLIGHT: ALL CLEAR`.
     - Do not perform planning locally when this delegation cannot be started; set `step7_status` to `blocked`, set `blocked_reason`, and stop.
     - Record a delegation receipt and set `step7_status` to `verified` only after delegate output and validator checks pass.
 9. Spawn `atomic-executor` to execute the approved plan.
     Hard enforcement for Step 8:
-    - Do not mark Step 8 complete until execution output includes execution summary, QA summary, lint/type/test/coverage deltas, and numeric baseline/post/new-code coverage metrics where policy requires them.
-    - Do not accept PASS execution outcomes when required baseline or final-QA artifacts are missing, when checklist state is not backed by artifacts, or when coverage-bearing plan tasks remain unverified.
+    - Do not mark Step 8 complete until execution output includes execution summary, QA summary, lint and type-check deltas, and numeric per-file coverage from the single gate run where policy requires them.
+    - Do not accept PASS execution outcomes when required baseline or final-QA artifacts are missing, when checklist state is not backed by artifacts, or when coverage plan tasks remain unverified.
     - Do not perform execution locally when this delegation cannot be started; set `step8_status` to `blocked`, set `blocked_reason`, and stop.
     - Record a delegation receipt and set `step8_status` to `verified` only after delegate output and validator checks pass.
 10. Spawn `feature-reviewer` for post-implementation review.

package/resources/codex-and-agents-customizations/.agents/skills/powershell/SKILL.md

@@ -12,7 +12,7 @@ This rule file summarizes the PowerShell-specific policies for this repository.
 1. **Formatting — Invoke-Formatter**: Format all PowerShell files via PoshQC. MCP command: `mcp__drm-copilot__run_poshqc_format`
 2. **Linting — PSScriptAnalyzer**: Run PoshQC analyzer with repo settings. MCP command: `mcp__drm-copilot__run_poshqc_analyze`. Optional autofix: `mcp__drm-copilot__run_poshqc_analyze_autofix`
 3. **Type checking**: Not applicable for PowerShell; skip to testing.
-4. **Testing — Pester (v5.x)**: Run tests via MCP. MCP command: `mcp__drm-copilot__run_poshqc_test`. Use repo config at `scripts/powershell/PoshQC/settings/pester.runsettings.psd1`.
+4. **Testing — Pester (v6.x)**: Run tests via MCP. MCP command: `mcp__drm-copilot__run_poshqc_test`. Use repo config at `scripts/powershell/PoshQC/settings/pester.runsettings.psd1`.
 
 Run the toolchain in order: format → analyze → test. Restart from step 1 if any step fails or changes files. Use the MCP server functions; do not substitute VS Code task wrappers.
 
@@ -49,7 +49,7 @@ Introduce the smallest seam that enables reliable mocking. Apply these options i
 
 ## Testing Standards
 
-- Use **Pester** (v5.x) as the test framework.
+- Use **Pester** (v6.x) as the test framework.
 - Organize tests to mirror code structure (e.g., `tests/scripts/dev-tools/ScriptName.Tests.ps1`).
 - Name test files `*.Tests.ps1`.
 - Use `Describe`/`Context`/`It` blocks; one behavior per `It`.

package/resources/codex-and-agents-customizations/.agents/skills/powershell-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: powershell-qa-gate
-description: Final QA gate for PowerShell changes. Runs PoshQC formatting, analysis, and testing with coverage where enforced; compares a captured baseline, enforces zero-regression deltas, and produces the required reporting block before completion.
+description: Final QA gate for PowerShell changes. Runs PoshQC formatting, analysis, and testing with coverage where enforced; compares static results to the static baseline, reads tests and coverage from the single gate run, and reports before completion.
 ---
 
 # 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.
+- **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**: 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** — 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 `.agents/skills/powershell/SKILL.md`.

package/resources/codex-and-agents-customizations/.agents/skills/python-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: python-qa-gate
-description: Final QA gate for Python changes. Runs Black, Ruff, Pyright, and Pytest; compares a captured baseline, enforces zero-regression deltas, and produces the required reporting block before completion.
+description: Final QA gate for Python changes. Runs Black, Ruff, Pyright, and Pytest; compares static results to the static baseline, reads tests and coverage from the single gate run, and reports before completion.
 ---
 
 # 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.
+- **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**: 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** — 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/codex-and-agents-customizations/.agents/skills/repo-automation-adapter/SKILL.md

@@ -180,6 +180,8 @@ Required tools:
 - `run_poshqc_analyze_autofix`
 - `run_poshqc_test`
 
+`run_poshqc_test` is not a validation gate. The Pester gate is one `Invoke-PoshQCParallelTest` run, through the route in the `execution-environment` skill.
+
 When a workflow requires PoshQC execution through MCP, use only these tools. If the required tool is unavailable or fails, stop.
 
 ## Output Requirements

package/resources/codex-and-agents-customizations/.agents-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
@@ -14,14 +14,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).
 
@@ -38,35 +38,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.
@@ -78,4 +77,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/codex-and-agents-customizations/.agents-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
@@ -30,7 +30,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 `.agents/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.
 
@@ -39,10 +39,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/codex-and-agents-customizations/.codex/agents/atomic-executor-c1.toml

@@ -89,9 +89,9 @@ For each task:
 
 Use the scoped tool patterns for quality gates:
 
-- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest`
+- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest -n auto`
 - **TypeScript**: `npx prettier`, `npx eslint`, `npx tsc`, `npx jest`
-- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_test`, `mcp__drm-copilot__run_poshqc_analyze_autofix`)
+- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_analyze_autofix`), and one `Invoke-PoshQCParallelTest` run as the Pester gate through the `sh` launcher route
 - **Git**: `git diff`, `git status`, `git log`
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
@@ -122,7 +122,7 @@ When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATIO
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. A light remediation run has no preflight, and stops the same way before `[P0-T1]` only when a fix task cannot be done at its named location. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c2.toml

@@ -89,9 +89,9 @@ For each task:
 
 Use the scoped tool patterns for quality gates:
 
-- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest`
+- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest -n auto`
 - **TypeScript**: `npx prettier`, `npx eslint`, `npx tsc`, `npx jest`
-- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_test`, `mcp__drm-copilot__run_poshqc_analyze_autofix`)
+- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_analyze_autofix`), and one `Invoke-PoshQCParallelTest` run as the Pester gate through the `sh` launcher route
 - **Git**: `git diff`, `git status`, `git log`
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
@@ -122,7 +122,7 @@ When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATIO
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. A light remediation run has no preflight, and stops the same way before `[P0-T1]` only when a fix task cannot be done at its named location. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c3-elevated.toml

@@ -89,9 +89,9 @@ For each task:
 
 Use the scoped tool patterns for quality gates:
 
-- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest`
+- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest -n auto`
 - **TypeScript**: `npx prettier`, `npx eslint`, `npx tsc`, `npx jest`
-- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_test`, `mcp__drm-copilot__run_poshqc_analyze_autofix`)
+- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_analyze_autofix`), and one `Invoke-PoshQCParallelTest` run as the Pester gate through the `sh` launcher route
 - **Git**: `git diff`, `git status`, `git log`
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
@@ -122,7 +122,7 @@ When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATIO
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. A light remediation run has no preflight, and stops the same way before `[P0-T1]` only when a fix task cannot be done at its named location. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c3.toml

@@ -89,9 +89,9 @@ For each task:
 
 Use the scoped tool patterns for quality gates:
 
-- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest`
+- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest -n auto`
 - **TypeScript**: `npx prettier`, `npx eslint`, `npx tsc`, `npx jest`
-- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_test`, `mcp__drm-copilot__run_poshqc_analyze_autofix`)
+- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_analyze_autofix`), and one `Invoke-PoshQCParallelTest` run as the Pester gate through the `sh` launcher route
 - **Git**: `git diff`, `git status`, `git log`
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
@@ -122,7 +122,7 @@ When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATIO
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. A light remediation run has no preflight, and stops the same way before `[P0-T1]` only when a fix task cannot be done at its named location. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c4.toml

@@ -89,9 +89,9 @@ For each task:
 
 Use the scoped tool patterns for quality gates:
 
-- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest`
+- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest -n auto`
 - **TypeScript**: `npx prettier`, `npx eslint`, `npx tsc`, `npx jest`
-- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_test`, `mcp__drm-copilot__run_poshqc_analyze_autofix`)
+- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_analyze_autofix`), and one `Invoke-PoshQCParallelTest` run as the Pester gate through the `sh` launcher route
 - **Git**: `git diff`, `git status`, `git log`
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
@@ -122,7 +122,7 @@ When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATIO
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. A light remediation run has no preflight, and stops the same way before `[P0-T1]` only when a fix task cannot be done at its named location. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor.toml

@@ -89,9 +89,9 @@ For each task:
 
 Use the scoped tool patterns for quality gates:
 
-- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest`
+- **Python**: `poetry run black`, `poetry run ruff`, `poetry run pyright`, `poetry run pytest -n auto`
 - **TypeScript**: `npx prettier`, `npx eslint`, `npx tsc`, `npx jest`
-- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_test`, `mcp__drm-copilot__run_poshqc_analyze_autofix`)
+- **PowerShell**: MCP server functions (`mcp__drm-copilot__run_poshqc_format`, `mcp__drm-copilot__run_poshqc_analyze`, `mcp__drm-copilot__run_poshqc_analyze_autofix`), and one `Invoke-PoshQCParallelTest` run as the Pester gate through the `sh` launcher route
 - **Git**: `git diff`, `git status`, `git log`
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
@@ -122,7 +122,7 @@ When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATIO
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. A light remediation run has no preflight, and stops the same way before `[P0-T1]` only when a fix task cannot be done at its named location. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-planner-c1.toml

@@ -58,14 +58,14 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 - Phase headings: `### Phase N — <Title>`
 - Task IDs: `- [ ] [P#-T#] <description>`
 - Sequential task numbering within each phase
-- Phase 0: baseline capture (repo-policy reading tasks + language-specific toolchain baselines)
+- Phase 0: baseline capture (repo-policy reading tasks + language-specific static tool baselines; no test suite runs)
 - Final phase: full QA loop for each applicable language
 
 ## Requirements
 
 1. Every task must be atomic: one binary outcome, one verifiable acceptance criterion.
 2. Every task must include explicit file paths.
-3. Include explicit coverage-bearing baseline and final-QA testing tasks for each language where policy requires coverage.
+3. Include explicit static baseline tasks and final-QA coverage tasks for each language where policy requires coverage, with per-file coverage read from the single gate run.
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 

package/resources/codex-and-agents-customizations/.codex/agents/atomic-planner-c2.toml

@@ -58,14 +58,14 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 - Phase headings: `### Phase N — <Title>`
 - Task IDs: `- [ ] [P#-T#] <description>`
 - Sequential task numbering within each phase
-- Phase 0: baseline capture (repo-policy reading tasks + language-specific toolchain baselines)
+- Phase 0: baseline capture (repo-policy reading tasks + language-specific static tool baselines; no test suite runs)
 - Final phase: full QA loop for each applicable language
 
 ## Requirements
 
 1. Every task must be atomic: one binary outcome, one verifiable acceptance criterion.
 2. Every task must include explicit file paths.
-3. Include explicit coverage-bearing baseline and final-QA testing tasks for each language where policy requires coverage.
+3. Include explicit static baseline tasks and final-QA coverage tasks for each language where policy requires coverage, with per-file coverage read from the single gate run.
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 

package/resources/codex-and-agents-customizations/.codex/agents/atomic-planner-c3-elevated.toml

@@ -58,14 +58,14 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 - Phase headings: `### Phase N — <Title>`
 - Task IDs: `- [ ] [P#-T#] <description>`
 - Sequential task numbering within each phase
-- Phase 0: baseline capture (repo-policy reading tasks + language-specific toolchain baselines)
+- Phase 0: baseline capture (repo-policy reading tasks + language-specific static tool baselines; no test suite runs)
 - Final phase: full QA loop for each applicable language
 
 ## Requirements
 
 1. Every task must be atomic: one binary outcome, one verifiable acceptance criterion.
 2. Every task must include explicit file paths.
-3. Include explicit coverage-bearing baseline and final-QA testing tasks for each language where policy requires coverage.
+3. Include explicit static baseline tasks and final-QA coverage tasks for each language where policy requires coverage, with per-file coverage read from the single gate run.
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 

package/resources/codex-and-agents-customizations/.codex/agents/atomic-planner-c3.toml

@@ -58,14 +58,14 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 - Phase headings: `### Phase N — <Title>`
 - Task IDs: `- [ ] [P#-T#] <description>`
 - Sequential task numbering within each phase
-- Phase 0: baseline capture (repo-policy reading tasks + language-specific toolchain baselines)
+- Phase 0: baseline capture (repo-policy reading tasks + language-specific static tool baselines; no test suite runs)
 - Final phase: full QA loop for each applicable language
 
 ## Requirements
 
 1. Every task must be atomic: one binary outcome, one verifiable acceptance criterion.
 2. Every task must include explicit file paths.
-3. Include explicit coverage-bearing baseline and final-QA testing tasks for each language where policy requires coverage.
+3. Include explicit static baseline tasks and final-QA coverage tasks for each language where policy requires coverage, with per-file coverage read from the single gate run.
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 

package/resources/codex-and-agents-customizations/.codex/agents/atomic-planner-c4.toml

@@ -58,14 +58,14 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 - Phase headings: `### Phase N — <Title>`
 - Task IDs: `- [ ] [P#-T#] <description>`
 - Sequential task numbering within each phase
-- Phase 0: baseline capture (repo-policy reading tasks + language-specific toolchain baselines)
+- Phase 0: baseline capture (repo-policy reading tasks + language-specific static tool baselines; no test suite runs)
 - Final phase: full QA loop for each applicable language
 
 ## Requirements
 
 1. Every task must be atomic: one binary outcome, one verifiable acceptance criterion.
 2. Every task must include explicit file paths.
-3. Include explicit coverage-bearing baseline and final-QA testing tasks for each language where policy requires coverage.
+3. Include explicit static baseline tasks and final-QA coverage tasks for each language where policy requires coverage, with per-file coverage read from the single gate run.
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.