@danmoisan/drm-copilot-mcp 1.1.26 → 1.1.27

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

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

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

@@ -37,6 +37,9 @@ When the active review scope is a selected version folder such as `docs/features
    - one line `Review-Verdict: <VERDICT>`, where the verdict is `PASS`, `REMEDIATION_REQUIRED`, `HALT_NON_REMEDIABLE`, or `AWAITING_CI`,
    - inside each blocking finding block, one line `Remediability: <class>`, where the class is `autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, or `human_decision_required` (`autonomous` when the line is absent),
    - inside each blocking finding block, one line `Remediability-Evidence: <text>` stating why the class applies.
+   - one line `Remediation-Path: light` or `Remediation-Path: full` (`full` when the line is absent). `light` is allowed only when there are at most 3 blocking findings, every one `autonomous` with `Finding-Scope: contained`, the fix changes no spec acceptance criterion, public interface, validator contract, or hook decision, no file inventory beyond the branch diff plus tests and mirrors, and no production logic beyond the finding's named location, the cycle is opened by a review, and the prior cycle was not light.
+   - inside each blocking finding block, one line `Finding-Scope: contained` or `Finding-Scope: design` (`design` when the line is absent).
+   - with `Remediation-Path: light`, a `## Light Fix Tasks` section holding one canonical `- [ ] [P0-T1] ...` line per fix, numbered in order and naming the file and the finding, and no checkbox line anywhere else in the file. A light review creates no remediation plan target.
 
    These lines, including the evidence text, never contain the substrings the orchestrator counts when it counts blocking findings, so their presence does not change the blocking count. The verdict follows from the classes: no blocking finding is `PASS`; any `autonomous` finding is `REMEDIATION_REQUIRED`; otherwise any `external_dependency`, `policy_hold`, or `human_decision_required` finding is `HALT_NON_REMEDIABLE`; otherwise `AWAITING_CI`.
 
@@ -119,14 +122,14 @@ Coverage metrics are mandatory for every language that has changed files in the
 Coverage thresholds follow the threshold precedence defined in `.claude/rules/quality-tiers.md` and `.claude/rules/general-unit-test.md`: when the repository's root `CLAUDE.md` states line or branch coverage thresholds, those thresholds govern; otherwise the default thresholds below govern. Each metric falls back independently: when the root `CLAUDE.md` states only a line threshold or only a branch threshold, the stated threshold governs that metric and the default below governs the other. The thresholds that govern under this precedence are the governing thresholds referred to in the Verification Procedure below. The defaults are:
 
 - **New code files** (files added in this feature, not previously existing): line coverage >= 85%, branch coverage >= 75% for branch-capable languages.
-- **Modified files** (files that existed before and were changed): line coverage >= 85%, branch coverage >= 75% for branch-capable languages, and no regression on changed lines relative to baseline.
+- **Modified files** (files that existed before and were changed): line coverage >= 85%, and branch coverage >= 75% for branch-capable languages, read from the single gate run, and new behavior is tested.
 - **Repo-wide per language**: line coverage >= 85%, branch coverage >= 75% for branch-capable languages.
 
 Tier-specific lower thresholds are not used.
 
 Tier classification findings: report a missing or incomplete `quality-tiers.yml` only when the repository has adopted tiers, that is, when `quality-tiers.yml` exists at the repository root on the resolved base branch or the repository's CI runs a tier-classification check. Otherwise record tier classification as not applicable; it is not a finding.
 
-The branch threshold applies only to branch-capable languages — TypeScript, Python, and C#. PowerShell is a coverage language and is fully subject to the line threshold and the no-regression requirement, but Pester measures command (instruction) coverage and line coverage only, so no branch percentage exists to evaluate and no branch threshold applies to it (see `.claude/rules/powershell.md`). Do not record FAIL for an absent PowerShell branch figure.
+The branch threshold applies only to branch-capable languages — TypeScript, Python, and C#. PowerShell is a coverage language and is fully subject to the line threshold, but Pester measures command (instruction) coverage and line coverage only, so no branch percentage exists to evaluate and no branch threshold applies to it (see `.claude/rules/powershell.md`). Do not record FAIL for an absent PowerShell branch figure.
 
 ### Verification Procedure
 
@@ -138,7 +141,7 @@ For each language that has changed files in the feature branch:
    - Parse the repo-wide coverage percentage and report it in the policy audit.
    - If repo-wide line or branch coverage is below the governing repo-wide thresholds defined in Coverage Thresholds, flag as FAIL and add to remediation triggers.
    - For each new file: if line or branch coverage is below the governing new-file thresholds defined in Coverage Thresholds, flag as FAIL and add to remediation triggers.
-   - For each modified file: if coverage on changed lines has regressed from baseline, or line or branch coverage is below the governing modified-file thresholds defined in Coverage Thresholds, flag as FAIL and add to remediation triggers.
+   - For each modified file: if line or branch coverage, read from the single gate run, is below the governing modified-file thresholds defined in Coverage Thresholds, flag as FAIL and add to remediation triggers.
 4. If no coverage artifact is found for a language that has changed files, flag as **FAIL** with reason: "coverage artifact absent for [language]; coverage verification is mandatory for all languages with changed files." Add to remediation triggers.
 
 The agent does NOT rerun coverage generation. Evidence verification from existing artifacts is the required model.

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

@@ -99,12 +99,14 @@ When the orchestrator runs the remediation loop, it records a top-level `remedia
 
 - `current_cycle` — integer index of the active cycle's record in `cycles[]`; a record position, not an attempt count.
 - `completed_attempts` — non-negative integer equal to the number of cycles whose `candidate_applied` is `true`. This is the shared attempt count for local, CI-failure, merge-conflict, and parallel-drift cycles; the guard halts after three completed attempts.
-- `review_outcomes[]` — one entry per review, including `PASS`, appended in order. Each entry is an object with `verdict` (one of `PASS`, `REMEDIATION_REQUIRED`, `HALT_NON_REMEDIABLE`, `AWAITING_CI`) and `findings[]`, the review's blocking findings only, each an object with `remediability` (one of `autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, `human_decision_required`). An optional `inputs_path` names the `remediation-inputs` file.
+- `review_outcomes[]` — one entry per review, including `PASS`, appended in order. Each entry is an object with `verdict` (one of `PASS`, `REMEDIATION_REQUIRED`, `HALT_NON_REMEDIABLE`, `AWAITING_CI`) and `findings[]`, the review's blocking findings only, each an object with `remediability` (one of `autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, `human_decision_required`). An optional `inputs_path` names the `remediation-inputs` file. Under top-level `review_mode: "concurrent"`, each entry also carries `head_sha`, the head the review ran against; see `## Concurrent Review and CI (review_mode)` in `.claude/skills/orchestrate/SKILL.md`.
+- `review_outcomes[].findings[].scope` — optional `contained` or `design`, recorded from the finding's `Finding-Scope:` line when that line is present. Only invariant 8 (light remediation) reads it.
 - `cycles[]` — an ordered array of cycle records. Each cycle is an object with:
   - `entry_timestamp` — ISO-8601 timestamp when the cycle was entered.
   - `inputs_path` — path to the `remediation-inputs.<entry-ts>.md` that opened the cycle.
-  - `plan_path` — path to the `remediation-plan.<entry-ts>.md` for the cycle.
-  - `preflight` — an object `{iterations, final_status}` where `iterations` counts preflight passes and `final_status` is one of `clear`, `changes_requested`, or `pending`.
+  - `plan_path` — path to the `remediation-plan.<entry-ts>.md` for the cycle; for a light cycle, the `remediation-inputs.<entry-ts>.md` that holds its `## Light Fix Tasks`.
+  - `remediation_path` — `light` or `full`, recorded on every new cycle. A light cycle runs no planner and no preflight; invariant 8 in `.claude/rules/orchestrator-state.md` governs it.
+  - `preflight` — an object `{iterations, final_status}` where `iterations` counts preflight passes and `final_status` is one of `clear`, `changes_requested`, or `pending`. A light cycle carries no `preflight` key.
   - `execution_status` — one of `in_progress`, `complete`, or `failed`.
   - `audit_paths` — the reaudit artifact paths produced at cycle exit (`code-review`, `feature-audit`, `policy-audit`).
   - `blocking_count` — the total number of blocking findings across the reaudit artifacts.
@@ -117,7 +119,7 @@ These four fields are recorded by producers. Verdicts follow from the classes of
 Malformed-cycle rules:
 
 - `plan_path` must be a non-empty string.
-- `execution_status` may be in `{in_progress, complete, failed}` only when `preflight.final_status == 'clear'`; any other preflight status with one of those execution statuses is malformed (execution recorded before preflight cleared).
+- `execution_status` may be in `{in_progress, complete, failed}` only when `preflight.final_status == 'clear'`; any other preflight status with one of those execution statuses is malformed (execution recorded before preflight cleared). A cycle whose `remediation_path` is exactly `light` is exempt, because it runs no preflight.
 - `exit_condition_met == true` requires `blocking_count == 0`; a non-zero `blocking_count` with `exit_condition_met == true` is malformed.
 - R5: `candidate_applied`, when present, must be a boolean.
 - R6: `candidate_applied == true` requires `execution_status == "complete"`.
@@ -126,8 +128,9 @@ Malformed-cycle rules:
 - R9: each outcome's `verdict` must be one of the four verdicts, its `findings` must be a list, and each finding must be an object whose `remediability` is one of the five classes (case-sensitive).
 - R10: each well-formed outcome's `verdict` must equal the verdict derived from its findings' classes.
 - R11: `opened_by_review`, when present, must be a non-negative integer that indexes an object entry of `review_outcomes` whose `verdict` is `REMEDIATION_REQUIRED`.
+- Invariant 8: `remediation_path`, when present, is `light` or `full`; a `light` cycle carries no `preflight`, names its opening review in `opened_by_review`, has at most 3 findings in that review, each `autonomous` with `scope` exactly `contained`, and does not follow a light cycle.
 
-Remediation mode lives in the inputs file, not in the checkpoint: each `remediation-inputs.<entry-ts>.md` carries exactly one line `Remediation-Mode: proportionate` or `Remediation-Mode: design`, so no checkpoint field is added. A cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; CI-failure findings are normally proportionate. A proportionate cycle runs one `atomic-planner` delegation and one `atomic-executor` delegation that performs single-pass preflight with in-place trivial fixes and then executes; the orchestrator records `preflight: {iterations: 1, final_status: "clear"}` before `execution_status`, which satisfies the malformed-cycle rule above. When that preflight finds a substantive defect, the executor stops with `BLOCKED at preflight (before [P0-T1])` and no checked task, and the cycle converts to design mode for one planner revision.
+Remediation mode lives in the inputs file: each `remediation-inputs.<entry-ts>.md` carries exactly one line `Remediation-Mode: light`, `Remediation-Mode: proportionate`, or `Remediation-Mode: design`, and the checkpoint records only the cycle's `remediation_path`. A cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; CI-failure findings are normally proportionate. A proportionate cycle runs one `atomic-planner` delegation and one `atomic-executor` delegation that performs single-pass preflight with in-place trivial fixes and then executes; the orchestrator records `preflight: {iterations: 1, final_status: "clear"}` before `execution_status`, which satisfies the malformed-cycle rule above. When that preflight finds a substantive defect, the executor stops with `BLOCKED at preflight (before [P0-T1])` and no checked task, and the cycle converts to design mode for one planner revision. A light cycle runs no planner and no preflight: its one `atomic-executor` delegation executes the `## Light Fix Tasks` of the inputs file, and the full rule is the **Light cycle.** bullet of `## Remediation Loop (R1–R5)` in `.claude/skills/orchestrate/SKILL.md`.
 
 Cycle-aware `next_step` uses the form `remediation.cycle_N.{plan,preflight,execute,reaudit,exit_check}`, where `N` is `completed_attempts + 1` (the active cycle number) and the sub-step names the current position in the loop; `current_cycle` remains a record position in `cycles[]`.
 
@@ -147,7 +150,7 @@ During a remediation cycle, the orchestrator delegates only to `atomic-planner`,
 
 ### Required Artifacts Per Cycle
 
-Each cycle produces exactly five artifacts:
+Each full cycle produces exactly five artifacts; a light cycle produces the four other than the remediation plan, because its inputs file is its plan:
 
 1. `remediation-inputs.<entry-ts>.md` — the cycle's input findings.
 2. `remediation-plan.<entry-ts>.md` — the cycle's remediation plan.
@@ -157,7 +160,7 @@ Each cycle produces exactly five artifacts:
 
 ### Preflight Sub-State Semantics
 
-`preflight.final_status` is one of `{clear, changes_requested, pending}`, extended by `blocked_preflight_iteration_limit` as defined in the remediation-handoff skill. A `changes_requested` status routes back to `atomic-planner` for plan revision at most once per cycle, carrying the full `PREFLIGHT-DEFECT:` list; when the confirming preflight still reports a substantive defect, the orchestrator records `blocked_preflight_iteration_limit` and halts the cycle. An `execution_status` in `{in_progress, complete, failed}` recorded while `final_status != clear` is malformed. `preflight.iterations` counts the number of preflight passes performed in the cycle; trivial defects fixed in place by the preflight executor do not add a pass.
+`preflight.final_status` is one of `{clear, changes_requested, pending}`, extended by `blocked_preflight_iteration_limit` as defined in the remediation-handoff skill. A `changes_requested` status routes back to `atomic-planner` for plan revision at most once per cycle, carrying the full `PREFLIGHT-DEFECT:` list; when the confirming preflight still reports a substantive defect, the orchestrator records `blocked_preflight_iteration_limit` and halts the cycle. An `execution_status` in `{in_progress, complete, failed}` recorded while `final_status != clear` is malformed, except on a light cycle, which carries no `preflight`. `preflight.iterations` counts the number of preflight passes performed in the cycle; trivial defects fixed in place by the preflight executor do not add a pass.
 
 ### Scope-change Rule
 
@@ -186,6 +189,7 @@ Update `artifacts/orchestration/orchestrator-state.json` after every completed s
   - `delegation_receipts.promotion.issue`
   - `delegation_receipts.promotion.feature_folder`
 - Each `delegation_receipts.promotion.*` field stores the raw MCP receipt payload from the matching promotion operation.
+- `stage_timing` (issue #1097): a top-level list of `{ stage, attempt, started_at, ended_at }` entries (ISO-8601 UTC strings; `ended_at` is null while a stage is open), written at every transition where `last_updated` is rewritten and committed before the merge as `FEATURE/evidence/other/stage-timing.<timestamp>.json`. Figures are wall-clock time and include queueing. The merge stage is not captured. The writer protocol is in the orchestrate skill under `## Checkpoint Handling`.
 
 ## Completion Requirements
 

package/resources/claude-customizations/.claude/agents/powershell-typed-engineer.md

@@ -1,7 +1,7 @@
 ---
 name: powershell-typed-engineer
 model: sonnet
-description: Project-scoped worker that implements and verifies PowerShell changes within typed repository boundaries. Applies PoshQC format -> PSScriptAnalyzer -> Pester toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and zero-regression quality gates.
+description: Project-scoped worker that implements and verifies PowerShell changes within typed repository boundaries. Applies PoshQC format -> PSScriptAnalyzer -> Pester toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and quality gates read from the single gate run.
 tools:
   - Read
   - Grep
@@ -25,7 +25,7 @@ memory: project
 
 # PowerShell Typed Engineer Agent
 
-Senior PowerShell engineer specialized in small cohesive scripts and modules, advanced functions with explicit parameter contracts, minimal DI seams (wrapper > delegate > adapter), and deterministic Pester v5 coverage. Implement PowerShell changes within the approved scope, preserve typed boundaries, and verify results with the repository PowerShell toolchain (PoshQC format, PSScriptAnalyzer, Pester).
+Senior PowerShell engineer specialized in small cohesive scripts and modules, advanced functions with explicit parameter contracts, minimal DI seams (wrapper > delegate > adapter), and deterministic Pester v6 coverage. Implement PowerShell changes within the approved scope, preserve typed boundaries, and verify results with the repository PowerShell toolchain (PoshQC format, PSScriptAnalyzer, Pester).
 
 ## Standing Rules
 
@@ -37,10 +37,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 `powershell-change-budget-router` to estimate scope and select direct mode (1-3 production files) vs large-path escalation through `/orchestrate`. The large path has no production-file 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 script or module structure, minimal DI seams (wrapper > delegate > adapter), Pester scenario-level test strategy, and the external executable wrapper mock strategy.
-4. **Implement in batches** — apply the approved plan. After each batch, run targeted PSScriptAnalyzer on touched files plus targeted Pester, and confirm per-file coverage.
-5. **Final QA gate** — apply `powershell-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 script or module structure, minimal DI seams (wrapper > delegate > adapter), Pester scenario-level test strategy, and the external executable wrapper mock strategy.
+4. **Implement in batches** — apply the approved plan. After each batch, run targeted PSScriptAnalyzer on touched files. 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 `powershell-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.
 
 For long-running orchestrated runs, apply `powershell-orchestration-state-machine` checkpoint and resume protocol.
 
@@ -66,7 +66,7 @@ Stop implementation and return to the user when:
 
 - the scope estimate exceeds the 3-production-file cap in direct mode,
 - a file is above or would exceed the 800-line hard limit of the tiered file-size policy (split it before proceeding; at 500 lines look for a logical split, and at 700 lines split more aggressively),
-- any QA gate delta is non-zero after self-correction,
+- any QA gate check fails after self-correction,
 - the toolchain cannot be executed in the current environment (mark the change **unverified**),
 - orchestrator handoff mode is requested but the required context package is incomplete,
 - policy instructions conflict.

package/resources/claude-customizations/.claude/agents/python-typed-engineer.md

@@ -1,7 +1,7 @@
 ---
 name: python-typed-engineer
 model: sonnet
-description: Project-scoped worker that implements and verifies Python changes within typed repository boundaries. Applies the Black -> Ruff -> Pyright -> Pytest toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and zero-regression quality gates.
+description: Project-scoped worker that implements and verifies Python changes within typed repository boundaries. Applies the Black -> Ruff -> Pyright -> Pytest toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and quality gates read from the single gate run.
 tools:
   - Read
   - Write
@@ -38,10 +38,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 `python-change-budget-router` to estimate scope and select direct mode (1-3 production files) or, for more than 3 production files, large-path escalation through `/orchestrate`. The large path has no production-file cap, and test files are not counted toward the routing threshold.
-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.
-4. **Implement in batches** — apply the approved plan. After each batch, run targeted Ruff and Pyright on touched files plus targeted Pytest, and confirm per-file coverage.
-5. **Final QA gate** — apply `python-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.
+4. **Implement in batches** — apply the approved plan. After each batch, run targeted Ruff and Pyright on touched files. 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 `python-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
 
@@ -60,7 +60,7 @@ Stop implementation and return to the user when:
 
 - the scope estimate exceeds 3 production files 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**),
 - policy instructions conflict.