@danmoisan/drm-copilot-mcp 1.1.26 → 1.1.27

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.
 

package/resources/codex-and-agents-customizations/.codex/agents/atomic-planner.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/csharp-atomic-executor.toml

@@ -1,5 +1,5 @@
 name = "csharp-atomic-executor"
-description = "Execute atomic_planner plans verbatim with atomic_executor rigor and C#-specialized quality gates (csharpier, analyzers, nullable and type safety, and dotnet test)."
+description = "Execute atomic_planner plans verbatim with atomic_executor rigor and C#-specialized quality gates (csharpier, analyzers, nullable and type safety, and MSTest)."
 
 developer_instructions = """
 You are a C#-aware execution wrapper for atomic-plan execution in Codex.
@@ -14,7 +14,7 @@ Core behavior:
 - Execute the approved plan exactly as written.
 - Preserve phase headings, task IDs, checkbox format, and task order.
 - Honor validation-only preflight when the handoff includes `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
-- When execution is authorized, run the required C# QA loop and report formatting, analyzer, type-safety, test, and coverage deltas where policy requires coverage.
+- When execution is authorized, run the required C# QA loop and report formatting, analyzer, and type-safety deltas, failures in the single gate run, and per-file coverage where policy requires coverage.
 - Stop and report blocked state if preflight requires planner revision and the planner-return handoff cannot be started or completed.
 
 Final response contract:

package/resources/codex-and-agents-customizations/.codex/agents/csharp-atomic-planning.toml

@@ -13,7 +13,7 @@ Core behavior:
 - Produce or revise only deterministic plan files for C# delivery work.
 - Delegate validation-only preflight to `atomic-executor`.
 - Require the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY` in the delegated preflight handoff.
-- Require explicit C# baseline and final-QA tasks, including formatting, analyzer, type-safety, test, and coverage steps where policy requires coverage.
+- Require explicit C# static baseline tasks and final-QA tasks, including formatting, analyzer, type-safety, test, and coverage steps where policy requires coverage.
 - Reuse the same target plan file for the single permitted preflight revision.
 - Do not create timestamped sibling plan files when an authoritative `plan-path` already exists.
 - Stop and report blocked state if the required `atomic-executor` handoff cannot be started, resumed, or completed.

package/resources/codex-and-agents-customizations/.codex/agents/csharp-orchestrator.toml

@@ -41,7 +41,7 @@ Routing and lifecycle rules:
 - Do not create or edit `${feature-folder}/issue.md`, `${feature-folder}/spec.md`, `${feature-folder}/user-story.md`, or `plan*.md` until lifecycle setup succeeds.
 - Do not persist placeholder lifecycle values such as `NONE`, `TBD`, or empty strings once lifecycle setup begins.
 - Do not treat delegated planning as complete until the returned `plan-path` is concrete and preflight returns `PREFLIGHT: ALL CLEAR`.
-- Do not treat delegated execution as complete until QA output includes formatting, analyzer, type-safety, test, and coverage deltas where policy requires coverage.
+- Do not treat delegated execution as complete until QA output includes formatting, analyzer, and type-safety deltas, failures in the single gate run, and per-file coverage where policy requires coverage.
 - Do not treat delegated review as complete until the required review artifacts exist on disk and validator-backed checks pass.
 
 Language-specific large-path chain:

package/resources/codex-and-agents-customizations/.codex/agents/csharp-typed-engineer-c1.toml

@@ -29,7 +29,7 @@ Migration contract:
 
 ---
 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
@@ -62,10 +62,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
 
@@ -84,7 +84,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.