@danmoisan/drm-copilot-mcp 1.1.25 → 1.1.27

package/resources/customizations/.github/agents/typescript-engineer.agent.md

@@ -5,7 +5,7 @@ tools: [vscode, execute, read, agent, edit, search, web, 'drmcopilotextension/*'
 handoffs:
   - label: TDD Red Phase (write failing tests first)
     agent: "TDD Red Phase - Write Failing Tests First"
-    prompt: "Write the smallest failing Jest test(s) for the requested TypeScript change, tied to the acceptance criteria. Do not implement production code. Return package MUST include: (1) exact test file path(s) + test name(s), (2) the exact failing output (error message + stack/line references), and (3) a 1-2 sentence note on what production change would make the test pass (no code changes in this phase)."
+    prompt: "Write the smallest failing Jest test(s) for the requested TypeScript change, tied to the acceptance criteria. Do not implement production code. Return package MUST include: (1) exact test file path(s) + test name(s), (2) the exact failing output (error message + stack/line references), and (3) a 1-2 sentence note on what production change would make the test pass (no code changes in this phase). A focused run of one test file to debug a specific failure is debugging only."
     send: true
   - label: Spec-first scoping (prd_feature)
     agent: prd_feature
@@ -27,7 +27,7 @@ handoffs:
 
 You are a senior TypeScript engineer specializing in:
 
-- Strong typing with zero-regression gates (avoid `any`, prefer `unknown` + narrowing)
+- Strong typing with the quality gates (avoid `any`, prefer `unknown` + narrowing)
 - Testable, modular code with clear I/O boundaries
 - Deterministic Jest unit tests that do not require the VS Code extension host
 - Strict adherence to the repo toolchain and suppression policies
@@ -142,7 +142,7 @@ When implementing changes that affect behavior:
 
 - Hand off the red phase to the **"TDD Red Phase - Write Failing Tests First"** agent (via the configured `handoffs` entry) and use the returned failing Jest test(s) + failure output as the spec.
 - After the failing test(s) are in place, implement the smallest fix to make them pass (green).
-- Run the toolchain loop to confirm zero regression.
+- Run the toolchain loop to confirm zero failures.
 
 ## Next.js guidance (when applicable)
 

package/resources/customizations/.github/codex/execute-hard-lock.prompt.md

@@ -16,7 +16,7 @@ SUPREMACY & PRECONDITIONS (NON-NEGOTIABLE)
   4) Any applicable language-specific policies
 - If Phase 0 does not include:
   - Repo-policy reading tasks, AND
-  - Baseline toolchain capture for each language touched by the plan,
+  - Static baseline capture for each language touched by the plan,
   the plan is INVALID and execution must not begin.
 
 PLAN AUTHORITY (THE CONTRACT)
@@ -36,7 +36,7 @@ You must validate ALL of the following; otherwise STOP:
 - Phase numbers and task IDs are consistent
 - Phase 0 exists and includes:
   - Repo-policy reading
-  - Baseline toolchain runs for each language touched
+  - Static baseline runs for each language touched
 - A final QA phase exists with full toolchain loops per touched language
 - Any TDD red tests are tagged [expect-fail]
 - No task is non-atomic or unverifiable
@@ -102,4 +102,4 @@ MANDATORY READ-PROOF (DO THIS FIRST; NO EXECUTION YET)
 5) Identify the FIRST unchecked task ([ ]) in plan order and print ONLY:
    - the exact line for that task
    - 2 lines above and 2 lines below (no more)
-6) State: "READY TO BEGIN FROM [P#-T#]" and immediately begin execution..
+6) State: "READY TO BEGIN FROM [P#-T#]" and immediately begin execution..

package/resources/customizations/.github/instructions/general-code-change.instructions.md

@@ -141,7 +141,7 @@ Rules for functions:
 
 1. Keep modules **cohesive**:
 
-   - A module/file should have a clear purpose (e.g. “QIF parsing,” “Lexile model,” “corpus download”).
+   - A module/file should have a clear purpose (e.g. “QIF parsing,” “scoring model,” “corpus download”).
    - Avoid dumping unrelated classes/functions into the same file.
    - File size follows a tiered policy that applies to production code, test code, and reusable scripts:
      - **500 lines (guidance):** look for logical ways to divide the file into multiple files, provided the parts can be separated logically. No gate fails at this tier.

package/resources/customizations/.github/instructions/powershell-unit-test.instructions.md

@@ -18,7 +18,7 @@ If there is any conflict between these documents, halt and notify the user.
 
 ## 1. Framework and Scope
 
-- **Testing framework:** All PowerShell tests must use **Pester** (v5.x).
+- **Testing framework:** All PowerShell tests must use **Pester** (v6.x).
 - Use the repo config at `scripts/powershell/PoshQC/settings/pester.runsettings.psd1`.
 - **Agent execution requirement:** use the MCP server function `mcp_drmcopilotext_run_poshqc_test`. Do **not** use VS Code task wrappers as a substitute.
 - Keep tests compatible with PowerShell 7+.

package/resources/customizations/.github/instructions/python-code-change.instructions.md

@@ -110,11 +110,11 @@ This section refines the general “classes vs functions” rules for Python. :c
 Use classes for:
 
 - **Domain concepts** with data + behavior  
-  - e.g. `QifTransaction`, `LexileCorpus`, `ContactMatcher`, `CorpusPipeline`.
+  - e.g. `QifTransaction`, `TextCorpus`, `ContactMatcher`, `CorpusPipeline`.
 - **State + invariants** that must stay consistent  
-  - e.g. a `LexileModel` that must keep weights, vocabulary, and metadata in sync.
+  - e.g. a `ScoringModel` that must keep weights, vocabulary, and metadata in sync.
 - **Multiple implementations behind a shared contract**  
-  - e.g. `ITextSource` / `TextSourceProtocol` with `EpubTextSource`, `GutenbergTextSource`, etc.
+  - e.g. `ITextSource` / `TextSourceProtocol` with `EpubTextSource`, `HttpTextSource`, etc.
 - **Multi-step workflows** that share context  
   - e.g. a pipeline with `.download()`, `.normalize()`, `.index()`, `.export()`.
 
@@ -137,7 +137,7 @@ Use standalone functions when:
 Rules for Python helper functions:
 
 - Fully annotate parameters and return types.
-- Name functions by what they do (`parse_qif_file`, `compute_lexile_score`).
+- Name functions by what they do (`parse_qif_file`, `compute_readability_score`).
 - Keep functions short, readable, and low in branching; factor complex logic into smaller helpers.
 
 ---
@@ -173,7 +173,7 @@ The general policy covers cohesion and file size; this section adds Python-speci
 
 1. **Cohesive modules**
 
-   - A module should have a clear purpose (e.g. “QIF parsing”, “Lexile model”, “corpus download”).
+   - A module should have a clear purpose (e.g. “QIF parsing”, “scoring model”, “corpus download”).
    - Avoid “grab-bag” modules like `utils.py` that mix many unrelated concerns.
 
 2. **Public vs internal**

package/resources/customizations/.github/instructions/python-suppressions.instructions.md

@@ -299,7 +299,7 @@ Loading known model artifacts from hardcoded trusted local paths.
 **Required pattern:**
 ```python
 # Model path is hardcoded, not from user input
-MODEL_PATH = Path(__file__).parent / "artifacts" / "lexile_model.pkl"
+MODEL_PATH = Path(__file__).parent / "artifacts" / "model.pkl"
 
 def load_model() -> Model:
     """Load pre-trained model from trusted artifact."""
@@ -383,10 +383,10 @@ Parent-relative imports (`from ..module import`) reduce code clarity and create
 **Recommended alternative pattern:**
 ```python
 # Instead of:
-from ..gutenberg_query_core import QueryGroupModel  # noqa: TID252
+from ..query_core import QueryGroupModel  # noqa: TID252
 
 # Use absolute imports:
-from lexile_corpus_tuner.lexile_scoring_model.pipeline_scripts.gutenberg_query_core import (
+from my_package.pipeline.query_core import (
     QueryGroupModel,
 )
 ```

package/resources/customizations/.github/instructions/python-unit-test.instructions.md

@@ -59,7 +59,7 @@ If there is any conflict between these documents, halt and notify the user.
 ## 4. Respecting the Toolchain Loop
 
 - When running the “After Making Changes” toolchain loop from the general code change policy on Python work, your **testing step** must be performed with **Pytest**.
-- Approved command: `poetry run pytest --cov=src/lexile_corpus_tuner --cov=scripts/dev_tools --cov-report=term-missing`
+- Approved command: `poetry run pytest --cov=scripts/dev_tools --cov-report=term-missing`
 - Do **not** substitute other test runners or frameworks for Python code unless explicitly instructed to do so.
 
 This file defines **how** Python tests are written and structured; the general code change policy defines **when** the toolchain (including tests) must be run and how strictly that loop must be followed.

package/resources/customizations/.github/prompts/execute-hard-lock.prompt.md

@@ -16,7 +16,7 @@ SUPREMACY & PRECONDITIONS (NON-NEGOTIABLE)
   4) Any applicable language-specific policies
 - If Phase 0 does not include:
   - Repo-policy reading tasks, AND
-  - Baseline toolchain capture for each language touched by the plan,
+  - Static baseline capture for each language touched by the plan,
   the plan is INVALID and execution must not begin.
 
 PLAN AUTHORITY (THE CONTRACT)
@@ -36,7 +36,7 @@ You must validate ALL of the following; otherwise STOP:
 - Phase numbers and task IDs are consistent
 - Phase 0 exists and includes:
   - Repo-policy reading
-  - Baseline toolchain runs for each language touched
+  - Static baseline runs for each language touched
 - A final QA phase exists with full toolchain loops per touched language
 - Any TDD red tests are tagged [expect-fail]
 - No task is non-atomic or unverifiable

package/resources/customizations/.github/prompts/generate-commit-message-repo.prompt.md

@@ -45,9 +45,9 @@ Header (required)
 (<type>(<optional-scope>)): <imperative, present-tense summary>
 
 Examples:
-- (feat): add lexile scoring model analyzer pipeline
+- (feat): add scoring model analyzer pipeline
 - (fix(dev-tools)): correct bug promotion title and body mapping
-- (docs(scoring-model)): document replacement of Lexile v2 with in-house model
+- (docs(scoring-model)): document replacement of the v2 scoring model with an in-house model
 
 Body (optional but preferred for non-trivial changes)
 

package/resources/customizations/.github/prompts/remediate-comments.prompt.md

@@ -10,7 +10,7 @@ Use this prompt to launch `comment_remediator` on any scope (single file, folder
 
 ## Inputs
 
-- **Scope** (required): Path or glob to remediate (e.g., `src/lexile_corpus_tuner/.../enrich_original_pub_year/**`).
+- **Scope** (required): Path or glob to remediate (e.g., `src/my_package/.../feature_module/**`).
 
 ## Policy Order
 
@@ -37,7 +37,7 @@ Apply in this sequence:
    - `poetry run black .`
    - `poetry run ruff check`
    - `poetry run pyright`
-   - `poetry run pytest`
+   - `poetry run pytest -n auto`
    Restart from Black after any change or failure; resolve all errors before finishing.
 
 ## Completion Criteria

package/resources/customizations/.github/prompts/review-feature.prompt.md

@@ -30,7 +30,7 @@ All filenames must include a timestamp in ISO-8601 format `yyyy-MM-ddTHH-mm` (e.
 1. `policy-audit.<timestamp>.md`
    - A completed Policy Audit document based on the repo's policy-audit template and the policy_audit template guidance.
    - Must include PASS/PARTIAL/FAIL (or equivalent) statuses with concrete evidence (commands run, outputs, file references).
-   - For languages in scope with mandatory coverage policy, MUST include numeric baseline/post/new-code coverage values and command evidence; `UNVERIFIED` is not allowed for a PASS verdict.
+   - For languages in scope with mandatory coverage policy, MUST include numeric per-file coverage values from the single gate run and command evidence; `UNVERIFIED` is not allowed for a PASS verdict.
 
 2. `code-review.<timestamp>.md`
    - A feature-level code review relative to the base branch, emphasizing strongly typed Python best practices and repo compliance.

package/resources/customizations/.github/skills/atomic-plan-contract/SKILL.md

@@ -32,7 +32,7 @@ Rules:
 - **Tool routes are not restated.** Tool routes, launchers, wrapper scripts, command-text restrictions, the batch budget, hook context, and CI shape are owned by the `execution-environment` skill. A plan references that skill instead of restating its content.
 - **Changed existing behavior names its asserting tests.** A task that changes the observable behavior of an existing function, script, fixture, or test stub (its signature, argv, output, exit status, or the files it writes) names every existing test that asserts that behavior and states each test's disposition: unchanged because it is unaffected, or updated, with the reason for the update. The tests are found by searching the test tree for the symbol, the file name, and the asserted output. A test that asserts the current behavior and is outside the task's file set fails once the change lands, and the plan's own acceptance condition then cannot be met. The planner's adversarial self-review includes this search for every task that changes existing behavior.
 - **Size guideline.** A plan stays within 40 canonical tasks and 400 physical lines. A plan that needs more carries a `## Size Justification` section with at least one line stating why the size is necessary (validator rule G13). Files produced by one generator run count as one generator task.
-- **Pre-Mortem.** Every plan carries a `## Pre-Mortem` section with one bullet beginning with each of the seven labels `Review checklists`, `Coverage`, `Mirror parity`, `File size`, `Test isolation`, `CI-only behavior`, and `Evidence`. Each bullet states how the plan prevents that failure class, or states "not applicable" followed by the reason. The `Test isolation` bullet names the isolation runs the plan performs: a seeded shuffled Jest run with the seed recorded, a reversed-order run of the new or changed Python test modules, and a seeded shuffled file-order run of the touched Pester suites with at least three seeds, each seed recorded. The `Mirror parity` bullet also covers the execution-environment brief: a plan that alters a fact the brief states (for example, it adds or renames a CI job, changes a required status context, a tool route, or a batch-budget rule) includes a task that updates the brief in the same change, in all six byte-identical copies, and the bullet names that task. Without that task the brief states a superseded fact once the change lands, which breaks the brief's own maintenance rule. The planner SubagentStop hook blocks a plan without a complete section.
+- **Pre-Mortem.** Every plan carries a `## Pre-Mortem` section with one bullet beginning with each of the seven labels `Review checklists`, `Coverage`, `Mirror parity`, `File size`, `Test isolation`, `CI-only behavior`, and `Evidence`. Each bullet states how the plan prevents that failure class, or states "not applicable" followed by the reason. The `Test isolation` bullet names the parallel gates the plan uses: one `Invoke-PoshQCParallelTest` run, one `pytest -n auto` run, and Jest through its normal parallel workers, each re-run only after a fix. The `Mirror parity` bullet also covers the execution-environment brief: a plan that alters a fact the brief states (for example, it adds or renames a CI job, changes a required status context, a tool route, or a batch-budget rule) includes a task that updates the brief in the same change, in all six byte-identical copies, and the bullet names that task. Without that task the brief states a superseded fact once the change lands, which breaks the brief's own maintenance rule. The planner SubagentStop hook blocks a plan without a complete section.
 - **Final-phase self-review.** The final phase of every plan contains a self-review task that walks the policy-audit, code-review, and feature-audit templates under `docs/features/templates/policy_audit/` against the branch diff from the merge base and writes `<FEATURE>/evidence/qa-gates/self-review.<timestamp>.md` with one PASS, FAIL, or N/A row per checklist item. A FAIL row is fixed and the QA loop is re-run before the self-review is rewritten; the plan does not complete with a FAIL row.
 
 This section takes precedence over the literal-quoting rules of `## Wrap-Tolerant Assertion Authoring (Mandatory)`: those rules govern the asserted value of an acceptance condition, not context.
@@ -43,12 +43,11 @@ When orchestration selects short path, a minimal plan is still mandatory and mus
 
 1) Baseline capture block
 - policy reads in required order,
-- baseline toolchain/test state capture for each language that has explicit baseline command tasks in the plan.
+- static baseline capture (format, lint, type check, and analyzer findings) for each language that has explicit baseline command tasks in the plan; no test suite runs in this block.
 - required artifacts:
 	- a Phase 0 policy-read evidence artifact in the canonical evidence location defined by `evidence-and-timestamp-conventions`
 	- one baseline artifact per baseline command step (no aggregate-only baseline artifact)
 	- each baseline step artifact MUST include: `Timestamp:`, `Command:`, `EXIT_CODE:`, `Output Summary:`
-	- baseline test-step artifacts for languages with mandatory coverage policy MUST include numeric coverage headline values in `Output Summary:` (baseline percent and, when applicable, targeted module/new-code percent).
 
 2) Delegated implementation block
 - explicit handoff task to the small-path implementation engineer,
@@ -59,7 +58,7 @@ When orchestration selects short path, a minimal plan is still mandatory and mus
 - rerun behavior when any step changes files or fails.
 - one final-QC artifact per QC command step (no aggregate-only final-QC artifact)
 - each final-QC step artifact MUST include: `Timestamp:`, `Command:`, `EXIT_CODE:`, `Output Summary:`
-- final-QC test commands for languages with mandatory coverage policy MUST run in coverage mode and record numeric post-change coverage values in `Output Summary:`.
+- final-QC test commands for languages with mandatory coverage policy MUST run in coverage mode and record numeric coverage values from the single gate run in `Output Summary:`.
 - final-QC command tasks that are present in the approved plan MUST execute their stated commands; `SKIPPED` is invalid unless the task text itself explicitly authorizes a skip condition.
 
 4) Reduced audit block
@@ -109,7 +108,7 @@ When a fully automated equivalent is unavailable, the plan MUST fail closed by r
 
 Phase 0 must include tasks to read policy files in the order defined in `policy-compliance-order`.
 
-Phase 0 must also capture baseline toolchain results for the languages touched. Baseline artifact conventions (location + required fields) are defined in `evidence-and-timestamp-conventions`.
+Phase 0 must also capture static baselines (format, lint, type check, and analyzer findings) for the languages touched, and no test suite runs in it. Baseline artifact conventions (location + required fields) are defined in `evidence-and-timestamp-conventions`.
 
 For short-path/minimal-audit plans, Phase 0 evidence is incomplete unless both artifacts exist:
 - `phase0-instructions-read.md` with at least: `Timestamp:`, `Policy Order:`, and explicit list of files read.
@@ -126,12 +125,9 @@ Plans name evidence artifacts `<name>.<timestamp>.md` and never fix a plan-time
 
 For any language in scope where repository policy requires coverage validation:
 
-- The approved plan MUST include explicit baseline and final-QC coverage capture tasks.
-- Baseline and final-QC artifacts MUST record numeric coverage values (not placeholders such as `UNVERIFIED`).
-- Where policy requires no-regression and new-code thresholds, the plan MUST include a delta/threshold verification task that reports:
-	- baseline coverage,
-	- post-change coverage,
-	- new/changed-code coverage.
+- The approved plan MUST include an explicit final-QC coverage capture task.
+- The final-QC artifact MUST record numeric coverage values (not placeholders such as `UNVERIFIED`).
+- The plan MUST include a threshold task that reports each changed file from the single gate run against the coverage thresholds. New behavior is tested. No earlier figure is compared.
 - If required coverage values are unavailable, the plan outcome MUST be remediation-required and MUST NOT be reported as PASS.
 
 ## Final QA Loop (Required for Code/Test Changes)
@@ -218,7 +214,7 @@ When a plan is generated or validated from a feature folder, resolve selected mo
 
 ## Mode-Specific Mandatory Plan Gates
 
-- `minor-audit` plans MUST include baseline evidence tasks, targeted verification evidence tasks, and end-state evidence tasks.
+- `minor-audit` plans MUST include static baseline evidence tasks, targeted verification evidence tasks read from the gate run, and end-state evidence tasks.
 - `minor-audit` plans MUST require `${feature-folder}/issue.md` to contain an explicit `## Acceptance Criteria` section; do not infer acceptance criteria from other `issue.md` sections.
 - `minor-audit` plans MUST NOT treat missing `spec.md` or `user-story.md` as automatic blockers.
 - `minor-audit` execution/validation/audit MUST fail closed when `spec.md` or `user-story.md` exists unexpectedly in the active folder, when the explicit `## Acceptance Criteria` section is missing from `issue.md`, when required Phase 0 artifacts are missing, or when checklist state contradicts evidence on disk.

package/resources/customizations/.github/skills/execution-environment/SKILL.md

@@ -11,6 +11,14 @@ This brief states the environment facts that every researcher, planner, prefligh
 
 Maintenance rule: this brief is updated in the same change that alters any fact it states. It carries no line numbers and no commit identifiers; it cites files, symbols, headings, job names, and test names. The same text is byte-identical in six locations: `.claude/skills/execution-environment/SKILL.md`, `.agents/skills/execution-environment/SKILL.md`, `.github/skills/execution-environment/SKILL.md`, and their bundled copies under `extensions/drm-copilot/resources/`. Where the Claude and Codex runtimes differ, both paths are named (`.claude/hooks/...` and `.codex/hooks/...`).
 
+## Development Toolchain Baseline
+
+The host manifest, both devcontainer Dockerfiles, and development CI select Python 3.13.18, Node.js 26.13.0/npm 11.20.0, PowerShell 7.6.9, and Poetry 2.5.1. Both images use `mcr.microsoft.com/devcontainers/python:3.3.2-3.13-bookworm`, require Git >=2.56.0, and install GitHub CLI 2.103.3, .NET SDK 10.0.403, uv 0.13.7, Claude Code 2.1.318, claude-swap 0.29.0, and Codex 0.166.0. Shell validation pins shfmt 3.14.1, ShellCheck 0.11.0, actionlint 1.7.12, and kcov v43. PowerShell selects Pester 6.2.0 and PSScriptAnalyzer 1.25.0. The images also retain Graphite 1.7.14, GitHub Copilot CLI 0.0.377, Bats, and bashdb. Host bootstrap treats manifest versions as minima and preserves equal/newer installations; the container verifier accepts later Python patches within 3.13 and later Git versions, and checks the other selected pins.
+
+The pinned base supplies Python and Git; image-managed CLI installs take precedence on PATH. Full configuration builds include the selected devcontainer features. Local Docker retains the Docker outside-of-Docker feature; floating Git/GitHub CLI features do not replace image pins. Both configurations run the same shared post-create script and mandatory verifier. Local source is a live host bind mount with four `volume-nocopy` Linux dependency volumes for `.venv` and the root, extension, and MCP `node_modules`; setup prepares only their mount roots. A container-only Git environment override disables the host Windows fsmonitor without changing host configuration. The former workspace volume is retained for recovery. Runtime verification uses the Linux environment rather than host Windows dependencies. Codex includes its native optional package, disables the startup update prompt through root-owned system settings, and uses the file credential store; the image does not populate user authentication state. Python bytecode stays under `/tmp/pycache`.
+
+Python 3.11/3.12 compatibility jobs, consumer package engines, and independent release-publishing runtime pins remain unchanged. The shared version predicate lives in `scripts/bash/container_versions.sh`; `.devcontainer/verify-container.sh` resolves it relative to its own repository location.
+
 ## Tool Routes by Agent
 
 - `atomic-executor` has no PowerShell tool. Its `tools:` list is Read, Grep, Glob, Edit, Write, several `Bash(...)` entries, the four `mcp__drm-copilot__run_poshqc_*` tools, and `mcp__drm-copilot__validate_orchestration_artifacts`. A `(pattern)` suffix on a `tools:` entry admits the bare tool, so the executor has Bash, subject to the repository hooks and the runtime guard described under Command-Text Restrictions.
@@ -31,7 +39,8 @@ Two separate mechanisms restrict Bash command text. They are kept apart here bec
 
 - PoshQC MCP results carry no output. The summary string is composed from a fixed template before the child process runs (`runPoshQcWorkflow` in `extensions/drm-copilot/src/repo-automation-service.ts`), and `RepoAutomationExecutionResult` has no exit-code or output field. An `ok: true` result proves only that the tool was invoked.
 - Counts, percentages, and findings therefore come from files or direct runs: pass and fail counts from `artifacts/pester/pester-junit.xml`, line coverage from `artifacts/pester/powershell-coverage.xml`, and analyzer findings from a direct `Invoke-ScriptAnalyzer` run with `scripts/powershell/PoshQC/settings/pssa.settings.psd1`.
-- The MCP test tool reads the installed extension's settings. Branch-current Pester runs import `scripts/powershell/PoshQC/PoshQC.psd1` and call `Invoke-PoshQCTest` from a `sh`-launched PowerShell 7. The coverage population is derived by `Invoke-PoshQCTest` from `config/poshqc-coverage.json`; there is no hand-maintained coverage path list.
+- The MCP test tool reads the installed extension's settings. Branch-current Pester runs import `scripts/powershell/PoshQC/PoshQC.psd1` and call `Invoke-PoshQCParallelTest` from a `sh`-launched PowerShell 7. The coverage population is derived by `Invoke-PoshQCTest`, which each shard runs, from `config/poshqc-coverage.json`; there is no hand-maintained coverage path list.
+- `Invoke-PoshQCParallelTest` returns an object whose `ExitCode` is read first, and the launcher exits with that value. Merged JUnit and coverage exist only after a fully green run, and a failed run can leave older merged files in place. Failure detail is under `artifacts/pester/parallel/shard-<i>/`.
 - `Invoke-Pester` without `-EnableExit` (or `Run.Exit`) exits 0 when tests fail; read the JUnit file rather than the exit code of such a run.
 
 ## Batch Budget
@@ -50,6 +59,8 @@ Two separate mechanisms restrict Bash command text. They are kept apart here bec
 - Hooks for an isolated subagent run inside the subagent's worktree with that worktree's hook scripts, which are `main`'s copies. A hook change on a branch is not exercised by isolated subagents until it merges.
 - Hook behavior on a branch is therefore proven by Pester suites, not by a live subagent run. A live check of a branch hook needs a non-isolated delegation from the item worktree.
 - The batch-budget hooks evaluate the checkpoint of the target worktree that `Resolve-HookTargetWorktree` resolves for the edited file, so an edit made from a coordinating session into an item worktree is evaluated against the item worktree's checkpoint. The preimplementation gate (#1010) resolves the file path of a Write or Edit call and the `-C` values and absolute operands of `git add` and `git commit` through the same resolver, and denies when the worktree listing fails or names no worktree; its delegation checks still resolve by portable identity. The PR authoring gate (#1011) resolves the branch that a `gh pr create` or `gh pr edit` command names (`--head`, `--branch`, or a `branch:` label) through the same resolver when the command carries no canonical issue number line, and otherwise keeps its portable-identity and current-branch resolution. The other gates that read `artifacts/orchestration/orchestrator-state.json` are unchanged and still use the root that holds the hook script.
+- Cleanup legs (#1026): a `cleanup-merged-worktrees` run writes no checkpoint, so the preimplementation gate (`.claude/hooks/enforce-orchestration-preimplementation-gate-cleanup.ps1` and its `.codex/hooks/` twin), the PR-authoring gate (`.claude/hooks/enforce-pr-author-skill.cleanup.ps1`), and the model-routing gate (`.claude/hooks/enforce-model-routing-receipt.ps1`) carry allow-side cleanup legs, evaluated only where each gate would otherwise deny, that share the pure predicates of `hook-cleanup-context.ps1`. The legs admit a Write of the session-root manifest `artifacts/orchestration/cleanup-worktrees-manifest.json` with valid content (an Edit stays denied), Write or Edit of paths under `docs/` or `.claude/agent-memory/` and of the pr-author receipt inside the consolidation worktree on branch `documentationandmemories`, `git -C <consolidation root> add` and `commit` of those paths, `Agent(pr-author)` with `branch: documentationandmemories`, and `gh pr create --head documentationandmemories --base main` while a fresh valid manifest exists at the session root and the pushed `refs/remotes/origin/documentationandmemories` resolves to the same commit as the consolidation worktree `HEAD`. A preimplementation-gate denial appends a cleanup sub-code (`Cleanup leg not applied`) only after a cleanup leg has identified the consolidation worktree as the target and a later condition fails; a call rejected by a prefilter keeps the unchanged deny text even when its target is the consolidation worktree, as does every other call.
+- Scratch rule (#1026): the preimplementation gate allows a Write or Edit of an absolute local path that lies outside every registered worktree and the session root and under a temporary root, read through the seam `Get-OrchestrationGateTemporaryRoot` (the long-name `GetTempPath()` value and the `TEMP`, `TMP`, and `TMPDIR` values, which can carry the 8.3 short-name spelling). The rule fails closed when any registered worktree lies under a temporary root.
 - Enforcement hooks do not invoke Python; bash is preferred and PowerShell is acceptable (`tests/scripts/claude-runtime/enforcement-hooks-no-python-invocation.Tests.ps1`).
 
 ## MCP Surfaces Run the Installed Extension
@@ -61,14 +72,14 @@ Two separate mechanisms restrict Bash command text. They are kept apart here bec
 ## CI Shape and Required Checks
 
 - `.github/workflows/ci.yml` triggers on `push` to `main` and `development`, on `pull_request` to `main`, `development`, and `epic/**`, on `workflow_dispatch`, and on `merge_group` (`types: [checks_requested]`, added by issue #952), with no path filters. When the merge queue on `main` is enabled, every required check is produced by a `merge_group` run of `ci.yml` as well as by the pull-request run; `.github/workflows/README.md` (`## Triggers`) records the trigger set.
-- Jobs in `ci.yml` and their check names: `Change scope` (job `changes`, the change-scope decision below); `CI full run` (job `full-run-marker`, which runs only on a full run, marks that run as a valid base for later decisions, and is not a required check); `quality-checks7 / Code Quality & Tests (<python-version>)` on Python 3.11, 3.12, and 3.13 (`_quality-checks.yml`: Black check, Ruff, Pyright, the Codex generator `--check`, the tier classification, and Pytest on every version; Pytest with line and branch coverage and the coverage-threshold check on the JSON report totals run on 3.13 only); `security-scan / Security Scanning` (its `safety check` step carries `continue-on-error: true` and does not fail the check); `docs-validation / Documentation Validation`; `build-check / Build Package`; `shell-coverage / Shell Coverage (Bats + kcov)`; `drm-copilot-extension-tests / drm-copilot Extension Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `root-typescript-tests / Root TypeScript Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `NPM Audit Gate / npm audit (<manifest>)` (the calling job carries the name `NPM Audit Gate`); and the `poshqc` group below.
+- Jobs in `ci.yml` and their check names: `Change scope` (job `changes`, the change-scope decision below); `CI full run` (job `full-run-marker`, which runs only on a full run, marks that run as a valid base for later decisions, and is not a required check); `quality-checks7 / Code Quality & Tests (<python-version>)` on Python 3.11, 3.12, and 3.13 (`_quality-checks.yml`: Black check, Ruff, Pyright, the Codex generator `--check`, the tier classification, and Pytest on every version; Pytest with line and branch coverage and the coverage-threshold check on the JSON report totals run on 3.13 only); `security-scan / Security Scanning` (its `safety check` step carries `continue-on-error: true` and does not fail the check); `docs-validation / Documentation Validation`; `build-check / Build Package`; `shell-coverage / Shell Coverage (Bats + kcov)`; `drm-copilot-extension-tests / drm-copilot Extension Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `root-typescript-tests / Root TypeScript Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `NPM Audit Gate / npm audit (<manifest>)` (the calling job carries the name `NPM Audit Gate`); the `poshqc` group below; and `CI Required Gate` (job `ci-required-gate`, issue #1074), which needs every other `ci.yml` job, runs under `if: always()` on `ubuntu-latest`, and passes `toJSON(needs)` to `scripts/ci/Invoke-CiRequiredGate.ps1`. The gate is green on a full run only when every needed job is `success`, and on a docs-only run only when `CI full run`, `root-typescript-tests`, and `NPM Audit Gate` are `success` or `skipped` and every other needed job is `success`; a `failure`, `cancelled`, or unknown result, a `Change scope` result other than `success`, and unreadable input are red. `tests/scripts/workflows/CiRequiredGateWorkflow.Tests.ps1` pins its `needs:` set against the other job ids of `ci.yml`.
 - PowerShell CI (`_poshqc.yml`): `poshqc / PowerShell QC static` (format and analyze on `windows-latest`); the shard matrix `poshqc / PowerShell QC shard 1`, `shard 2`, and `shard 3` (`Invoke-PoshQCTest -ShardIndex -ShardCount` over the scan folders of `config/poshqc-scan.json`, with coverage, on `windows-latest`); the aggregator `poshqc / PowerShell QC`, which requires the static and shard jobs to succeed, verifies shard completeness against a Pester discovery count, and merges shard coverage; and `poshqc / PowerShell hook suites (Linux)`, which runs only `tests/scripts/claude-hooks` and `tests/scripts/codex-hooks` on `ubuntu-latest` with coverage disabled. A new test file under a scanned folder is assigned to a shard automatically and is counted by the completeness check.
 - Change-scope decision (issue #962): the `Change scope` job runs `scripts/ci/Invoke-CiChangeScope.ps1` and publishes the job output `code`. The decision is `code=false` (docs-only) only on a `pull_request` event from this repository, through one of two comparisons. Green-run base: every file changed since the newest successful `ci.yml` run on the pull-request branch whose `CI full run` job succeeded, and whose head commit is present and an ancestor of the current head, is on the allowlist `config/ci-docs-only-paths.json`; the reason is `DOCS_ONLY_SINCE_<green head sha>`. Merge-base fallback (issue #973): when the green-run step ends with no earlier full green run (`NO_FULL_GREEN_RUN`), a missing base (`BASE_NOT_PRESENT`), or a non-ancestor base (`BASE_NOT_ANCESTOR`), and the pull request's base ref is exactly `main`, the script computes `git merge-base` of the payload base SHA (`BASE_SHA`, from `github.event.pull_request.base.sha`; the base ref arrives as `BASE_REF`) and the head, lists the files changed since that merge base with the same diff arguments, and decides `DOCS_ONLY_SINCE_MERGE_BASE_<merge base sha>` when every changed file is allowlisted. Both comparisons run the diff with rename detection off, so both the old and the new path of a rename are classified. A path is allowlisted when it starts with `docs/features/active/`, `docs/features/archive/`, `docs/features/completed/`, `docs/features/epics/`, `docs/features/parallel/`, `docs/features/potential/`, or `docs/research/`, does not start with `docs/features/templates/` or `docs/features/potential/template.md`, and ends in `.md`, `.txt`, `.log`, `.json`, or `.xml`; the allowlist file itself is not allowlisted. Every other case is a full run (`code=true`): `push`, `merge_group`, and `workflow_dispatch` events, a fork pull request, unreadable run or job data, no earlier full green run or a missing or non-ancestor base when the base ref is not `main`, a merge base that cannot be resolved (`MERGE_BASE_UNRESOLVED`, for example a blank base SHA or a base commit missing from the checkout), a failed ancestry check, an empty diff, any path outside the allowlist, and any error. The decision step carries `continue-on-error: true` and the callers compare the output with `!= 'false'`, so a failed or missing decision also gives a full run.
-- Docs-only behavior (`code=false`): `ci.yml` passes `run-heavy: false` to `_quality-checks.yml`, `_security-scan.yml`, `_build-check.yml`, `_poshqc.yml`, `_shell-coverage.yml`, and `_drm-copilot-extension-tests.yml`. Each required job still starts under its full-run check name with every step skipped, so every required context reports `success` without running its suite. In `_poshqc.yml` the aggregator `poshqc / PowerShell QC` runs with every step gated, and `poshqc / PowerShell QC static`, the shard jobs, and `poshqc / PowerShell hook suites (Linux)` are skipped at job level. `docs-validation / Documentation Validation` runs in full. `root-typescript-tests`, `NPM Audit Gate`, and `CI full run` are skipped at job level. A `success` on a docs-only commit is therefore not evidence that the heavy suites pass for that commit; that evidence is the newest run whose `CI full run` job succeeded.
+- Docs-only behavior (`code=false`): `ci.yml` passes `run-heavy: false` to `_quality-checks.yml`, `_security-scan.yml`, `_build-check.yml`, `_poshqc.yml`, `_shell-coverage.yml`, and `_drm-copilot-extension-tests.yml`. Each job that runs with its steps gated still starts under its full-run check name with every step skipped, so it reports `success` without running its suite. In `_poshqc.yml` the aggregator `poshqc / PowerShell QC` runs with every step gated, and `poshqc / PowerShell QC static`, the shard jobs, and `poshqc / PowerShell hook suites (Linux)` are skipped at job level. `docs-validation / Documentation Validation` runs in full. `root-typescript-tests`, `NPM Audit Gate`, and `CI full run` are skipped at job level. Eight currently required contexts therefore never report on a docs-only run: `poshqc / PowerShell QC shard 1`, `poshqc / PowerShell QC shard 2`, `poshqc / PowerShell QC shard 3`, `root-typescript-tests / Root TypeScript Tests (ubuntu-latest)`, `root-typescript-tests / Root TypeScript Tests (windows-latest)`, `NPM Audit Gate / npm audit (.)`, `NPM Audit Gate / npm audit (extensions/drm-copilot)`, and `NPM Audit Gate / npm audit (packages/mcp-server)`, so a docs-only head stays blocked under the 20-context ruleset. `CI Required Gate` passes on a docs-only run, because it accepts `skipped` for exactly those skipped callers. A `success` on a docs-only commit is therefore not evidence that the heavy suites pass for that commit; that evidence is the newest run whose `CI full run` job succeeded.
 - A commit that changes any path outside the allowlist (any code, workflow, configuration, script, test, or customization file) runs the full set of jobs, and its `CI full run` job marks it as a base for later docs-only decisions. A standalone `workflow_dispatch` of a reusable workflow, or a caller that omits `run-heavy`, also runs in full. `.github/workflows/README.md` (`## Change-Scope Decision (Issue #962)`) records the reason codes and the per-context behavior table.
-- Required contexts of ruleset 15241672, confirmed by the orchestrator through `gh api` on 2026-10-16: `drm-copilot-extension-tests / drm-copilot Extension Tests (ubuntu-latest)`, `drm-copilot-extension-tests / drm-copilot Extension Tests (windows-latest)`, `docs-validation / Documentation Validation`, `poshqc / PowerShell QC`, `shell-coverage / Shell Coverage (Bats + kcov)`, `security-scan / Security Scanning`, `quality-checks7 / Code Quality & Tests (3.11)`, `quality-checks7 / Code Quality & Tests (3.12)`, `quality-checks7 / Code Quality & Tests (3.13)`, `build-check / Build Package`.
-- Refresh rule: a change that renames a job, adds or removes a matrix entry, or changes the ruleset refreshes this list in the same change, and the orchestrator re-confirms the contexts with a read-only `gh api repos/drmoisan/drm-copilot/rulesets/15241672` call before relying on them.
-- Skipped-check semantics: a job skipped by an `if:` condition reports success to a required check; a workflow that does not run at all reports nothing, which leaves the required check pending.
+- Required contexts of ruleset 15241672, read through a read-only `gh api` call on 2026-11-04 (20 contexts, each with `integration_id` 15368): `drm-copilot-extension-tests / drm-copilot Extension Tests (ubuntu-latest)`, `drm-copilot-extension-tests / drm-copilot Extension Tests (windows-latest)`, `docs-validation / Documentation Validation`, `poshqc / PowerShell QC`, `shell-coverage / Shell Coverage (Bats + kcov)`, `security-scan / Security Scanning`, `quality-checks7 / Code Quality & Tests (3.11)`, `quality-checks7 / Code Quality & Tests (3.12)`, `quality-checks7 / Code Quality & Tests (3.13)`, `build-check / Build Package`, `NPM Audit Gate / npm audit (extensions/drm-copilot)`, `NPM Audit Gate / npm audit (.)`, `NPM Audit Gate / npm audit (packages/mcp-server)`, `root-typescript-tests / Root TypeScript Tests (ubuntu-latest)`, `root-typescript-tests / Root TypeScript Tests (windows-latest)`, `poshqc / PowerShell QC shard 1`, `poshqc / PowerShell QC shard 2`, `poshqc / PowerShell QC shard 3`, `poshqc / PowerShell QC static`, `poshqc / PowerShell hook suites (Linux)`. After the owner's post-merge ruleset edit (issue #1074 runbook), the single required context is `CI Required Gate` (`integration_id` 15368), and the individual job contexts remain visible but are no longer required.
+- Refresh rule: a change that renames a job, adds or removes a `ci.yml` job or a matrix entry, or changes the ruleset refreshes this list in the same change, and the orchestrator re-confirms the contexts with a read-only `gh api repos/drmoisan/drm-copilot/rulesets/15241672` call before relying on them. A new `ci.yml` job must also be added to the `needs:` list of `ci-required-gate`; `tests/scripts/workflows/CiRequiredGateWorkflow.Tests.ps1` fails until it is.
+- Skipped-check semantics: a job skipped by an `if:` condition reports success to a required check; a workflow that does not run at all reports nothing, which leaves the required check pending. A matrix job skipped at job level reports no expanded context (its matrix name is never expanded), and a reusable-workflow caller skipped in `ci.yml` reports no nested contexts, so each such required context stays pending.
 - A pull request into a branch other than `main`, `development`, or `epic/**` gets no CI run; dispatch `ci.yml` manually for it.
 
 ## CI-Only Failure Classes
@@ -78,7 +89,7 @@ Two separate mechanisms restrict Bash command text. They are kept apart here bec
 - `_shell-coverage.yml` checks out at depth one, so `origin/main` does not exist in that job; no test may diff against it.
 - The Linux hook-suite job runs `tests/scripts/claude-hooks` and `tests/scripts/codex-hooks` on a case-sensitive file system: use `Join-Path`, forward-slash relative paths, exact file-name case, and no drive letters or backslash literals.
 - The `.gitattributes` rule `* text=auto eol=lf` normalizes line endings on checkout, so a CRLF fixture committed as text is not CRLF in CI.
-- Shard and single-process Pester runs expose module-scope import visibility and leaked state that per-suite local runs hide.
+- Files in one shard share a process, so a leak surfaces when shard contents change.
 
 ## Contract Tests That Pin Mirrored Files
 
@@ -95,6 +106,7 @@ Run these after editing any mirrored or bundled file; each is under `tests/scrip
 - `test_push_down_issue_824_follow_ups.py`: pushed rules and skills name no consuming product.
 - `test_typescript_toolchain_instruction_contracts.py`: no reference to another test framework, and every backticked npm script token in the pinned mirrors exists in the root `package.json`.
 - `tests/scripts/claude-runtime/claude-architecture-doc.Tests.ps1` and `tests/scripts/claude-runtime/hook-dependency-guard-completeness.Tests.ps1`: agent tool names in the architecture document and the guarded dot-source pattern in hooks.
+- `tests/scripts/claude-runtime/parallel-gate-wording.Tests.ps1`: per-file required and forbidden gate wording in the mirrored skills, agents, and templates, and the sweep of those surfaces for removed test-suite baseline wording.
 
 ## Preflight Defect Classes the Validator Cannot See
 
@@ -125,6 +137,7 @@ These pass every validator rule and are found only by reading the plan against t
 - Python: measure a module with `--cov=<dotted.module>`, `--cov-branch`, `--cov-report=term-missing`, and `--cov-report=json:<path>`; read branch figures from the JSON report.
 - TypeScript: a new production file needs its own entry in the `coverageThreshold` map of `extensions/drm-copilot/jest.config.cjs`; Jest runs through `node run-jest.cjs` in `extensions/drm-copilot/`.
 - PowerShell: per-file line coverage is read from `artifacts/pester/powershell-coverage.xml` written by the self-hosted PoshQC module.
+- Per-file figures are read from the single gate run, and no earlier figure is compared.
 - File size follows three tiers for production, test, and reusable script files, counted in logical lines (a trailing terminator adds no line): at 500 lines look for a logical split (guidance); at 700 lines split more aggressively, and reviewers report a non-blocking Warning (advisory); above 800 lines a split is enforced regardless of logical separability (hard limit; exactly 800 passes). The hard limit is enforced by `tests/scripts/ci/FileSizePolicy.RepoGate.Tests.ps1` in the existing PowerShell shards against `config/file-size-baseline.json`, where legacy files above 800 may shrink (with the entry tightened) or stay equal but may not grow, and by the PreToolUse hook `.claude/hooks/enforce-file-size-limit.ps1` (`.codex/hooks/enforce-file-size-limit.ps1`). New logic in a file near a tier goes into a new module and a new test file. Markdown is exempt.
 
 ## Test Runtime
@@ -134,17 +147,19 @@ These pass every validator rule and are found only by reading the plan against t
 - Fix repeated production work first. An immutable structure, such as a schema registry that is rebuilt and re-verified on every call, is built once per owning instance. This speeds up the runtime as well as the tests.
 - Second, build an expensive immutable fixture once per session and hand each test its own copy wherever a test could mutate it, so test independence is unchanged.
 - Parallel workers reduce wall-clock time only: they are capped by the slowest test and leave the cost in the product.
-- pytest: pass `-n auto` (pytest-xdist) on the command line of the CI step `Run tests with Pytest` and of the parallel VS Code tasks, never in `addopts`, because the VS Code Test Explorer keys results to the wrong file when `addopts` carries it. `-n auto` counts physical cores, so a runner can start fewer workers than it has vCPUs; measure it against an explicit count such as `-n 4` before keeping it. pytest-cov combines the worker coverage into one report, and the serial `poetry run pytest` command remains the isolation reference.
-- Pester: Pester 5 has no in-process parallel mode, so parallel Pester runs are process-per-shard: `Invoke-PoshQCTest -ShardIndex -ShardCount` on the CI runners and `Invoke-PoshQCParallelTest` locally. Read the per-file `time` of the JUnit `testsuite` elements before changing the shard count or the weights in `config/poshqc-shard-weights.json`.
+- pytest: pass `-n auto` (pytest-xdist) on the command line of the CI step `Run tests with Pytest` and of the parallel VS Code tasks, never in `addopts`, because the VS Code Test Explorer keys results to the wrong file when `addopts` carries it. `-n auto` counts physical cores, so a runner can start fewer workers than it has vCPUs; measure it against an explicit count such as `-n 4` before keeping it. pytest-cov combines the worker coverage into one report.
+- Pester: parallel validation uses separate Pester 6 processes: `Invoke-PoshQCTest -ShardIndex -ShardCount` on the CI runners and `Invoke-PoshQCParallelTest` locally. Read the per-file `time` of the JUnit `testsuite` elements before changing the shard count or the weights in `config/poshqc-shard-weights.json`.
 - A candidate fix can be measured before the tree is edited by loading a pytest plugin module from `SCRATCH` with `-p <module>` and `PYTHONPATH`.
 
 ## Test Isolation Checks
 
 - Tests create no temporary files; file and transcript reads go through injected seams with in-memory content.
-- Before review, run each isolation check and record it under `<FEATURE>/evidence/regression-testing/`:
-  - a seeded shuffled Jest run (`node run-jest.cjs --randomize --seed=<n>` in `extensions/drm-copilot/`) with the seed recorded;
-  - a reversed-order run of the new or changed Python test modules in one process;
-  - a seeded shuffled file-order run of the touched Pester suites in one process, with at least three seeds and each seed and its file order recorded;
-  - a fresh single-process Pester run over `tests/scripts`, which is the CI shape;
-  - in addition to the serial runs, a concurrent-shard Pester run through `Invoke-PoshQCParallelTest` and a `pytest -n auto` run, both with zero failures.
-- An order dependence found by any run is fixed on both sides: the suite that leaves state behind (globals, functions, environment variables, mocks, imported modules, script-scope state) and the suite that assumes prior state. Every seed is then re-run.
+- The test gates are parallel:
+  - the Pester gate is one `Invoke-PoshQCParallelTest` run;
+  - the pytest gate is one `pytest -n auto` run;
+  - Jest runs through its normal parallel workers.
+- Each gate reaches zero failures and is re-run only after a fix.
+- A focused run of one test file to debug a specific failure is debugging only; it is never a gate or evidence.
+- Serial tasks remain for debugging one failure and are not gates.
+- A leak found by a gate is fixed on both sides: the suite that leaves state behind (globals, functions, environment variables, mocks, imported modules, script-scope state) and the suite that assumes prior state.
+- The parallel gates govern where a policy file names a toolchain test command.

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

@@ -42,12 +42,21 @@ Always apply:
   - `code-review-template` for `code-review.<timestamp>.md`
   - `feature-audit-template` for `feature-audit.<timestamp>.md`
 - The MCP-resolved asset is the authoritative template source for review artifacts in this workflow.
+- When an installed template older than this change carries baseline fields, each baseline field is recorded as `N/A - no pre-change run`, and the comparison line reads `Baseline: N/A - no pre-change run -> Post-change: <percent>. Change: N/A.`
 
 ### No silent fixes
 
 - Do not clean up code during review.
 - If checks fail, document the failure and include exact remediation guidance.
 
+### Process-reduction ledger
+
+- This rule applies only when `docs/engineering/process-reductions/` exists, so a repository without that folder is unaffected.
+- A change that reduces evidence, plan tasks, gates, or review process adds its ledger entry in the same commit, in the format of that folder's `README.md`.
+- A branch diff that makes such a reduction with no entry is a Blocking finding.
+- The reviewer confirms from the branch log that each reduction is its own commit, with the `reduction: NNNN` token in its subject.
+- One-off waivers for a single item are not entries.
+
 ### Work-mode acceptance-criteria contract
 
 - Read the persisted marker from `issue.md` using one of:
@@ -92,7 +101,7 @@ Always apply:
      2. lint check
      3. type check
      4. tests
-   - Run the smallest relevant subset first when the repo policy permits it.
+   - A focused run of one test file to debug a specific failure is debugging only; a review check does not rest on it.
    - If a tool cannot run in the environment, mark the affected section unverified or partial with a concrete reason.
 
 6. **Produce the code review**
@@ -123,7 +132,11 @@ Always apply:
      - toolchain checks fail
      - the code review contains blockers
      - required acceptance criteria are FAIL or PARTIAL
-     - coverage below the governing thresholds (the root `CLAUDE.md` thresholds when stated, otherwise the defaults: line 85%, branch 75% for branch-capable languages; repo-wide per language, modified files including any regression on changed lines, or new files)
+     - coverage below the governing thresholds (the root `CLAUDE.md` thresholds when stated, otherwise the defaults: line 85%, branch 75% for branch-capable languages; repo-wide per language, modified files, or new files)
+   - Choose the remediation path. Write one line `Remediation-Path: light` or `Remediation-Path: full` into the remediation inputs, and inside each blocking finding block one line `Finding-Scope: contained` or `Finding-Scope: design`. A missing path line reads as `full`, and a missing scope line reads as `design`. These lines never contain the substrings the orchestrator counts.
+   - Write `Remediation-Path: light` only when all of these hold: at most 3 blocking findings, every one `autonomous` with `Finding-Scope: contained`; no change to a spec acceptance criterion, a public interface, or the file inventory beyond the branch diff plus tests and mirrors; no change to a validator contract, hook decision, or production logic beyond the finding's named location; the cycle is opened by a review; and the prior cycle was not light. Otherwise write `Remediation-Path: full`. The orchestrator may move a cycle to a heavier path and never to a lighter one.
+   - With `Remediation-Path: light`, also write a `## Light Fix Tasks` section: one canonical `- [ ] [P0-T1] ...` line per fix, numbered in order, each naming the file and the finding it fixes. Write no checkbox line anywhere else in the file, because the executor stop hook counts every checkbox line of the file it executes.
+   - The remediation plan target stays for both paths, because this review contract requires it.
    - Create `remediation-inputs.<timestamp>.md` first.
    - Create the target remediation plan file from the canonical plan template.
    - Hand off plan creation through `remediation-handoff-atomic-planner`.

package/resources/feature-templates/bug/plan.yyyy-MM-ddTHH-mm.md

@@ -7,7 +7,7 @@
 - **Status:** <template>
 - **Version:** <version_number>
 
-**Fail-closed evidence rule:** Include explicit baseline artifact tasks, final-QA artifact tasks, and coverage-comparison tasks for each in-scope language when policy requires coverage. If any required baseline artifact, QA artifact, or coverage-comparison artifact is missing, the audit verdict must be BLOCKED or INCOMPLETE, never PASS.
+**Fail-closed evidence rule:** Include explicit static baseline tasks, final-QA tasks, and a per-file threshold task for each in-scope language when policy requires coverage. If any required static baseline artifact, QA artifact, or per-file coverage figure is missing, the audit verdict must be BLOCKED or INCOMPLETE, never PASS.
 
 **Evidence accounting rule:** Record the expected artifact path or location in each evidence-producing task. Do not mark evidence-backed work complete without the artifact.
 
@@ -33,15 +33,15 @@
 
 **Phase 2 — Regression Test (must fail first)**
 - [ ] [P2-T1] [expect-fail] Add a small, deterministic regression test in the standard module file (use `tests/bugs/<YYYY>/<issue>-<desc>.py` only if no clear home exists)
-- [ ] [P2-T2] [expect-fail] Run the regression to confirm it fails and captures the repro
+- [ ] [P2-T2] [expect-fail] Run the parallel test gate to confirm the new regression test fails and captures the repro
 
 **Phase 3 — Minimal Fix**
 - [ ] [P3-T1] Apply the smallest change needed to make the regression test pass; avoid opportunistic refactors
 
 **Phase 4 — Verification Loop**
-- [ ] [P4-T1] Re-run repro and regression test to confirm expected behavior
+- [ ] [P4-T1] Re-run the repro to confirm expected behavior
 - [ ] [P4-T2] Run formatter → linter → type checker → tests; restart loop if any step changes files or fails
-- [ ] [P4-T3] Record baseline, post-change, and comparison artifact paths for each in-scope language where coverage is required
+- [ ] [P4-T3] Record the static baseline and final-QA artifact paths and the per-file threshold results for each in-scope language where coverage is required
 
 **Phase 5 — Documentation & Status**
 - [ ] [P5-T1] Update spec/issue with outcomes, decisions, and any deviations from scope

package/resources/feature-templates/feature/plan.yyyy-MM-ddTHH-mm.md

@@ -23,9 +23,9 @@
 > - Start every task with a **strong verb** (Implement, Create, Update, Verify).
 > - No "bucket" tasks like "Refactor module" or "Write tests"; split them into specific, verifiable steps.
 > - **Self-Validating Phases:** Include necessary test creation/update tasks *within* the phase that implements the code. Do not defer verification to a final "Testing" phase.
-> - Include explicit baseline artifact tasks, final-QA artifact tasks, and coverage-comparison tasks for every language in scope when policy requires coverage.
+> - Include explicit static baseline tasks, final-QA tasks, and a per-file threshold task for every language in scope when policy requires coverage.
 > - Name the expected artifact path or location in each evidence-producing task's acceptance criteria.
-> - If any required baseline artifact, QA artifact, or coverage-comparison artifact is missing, the audit verdict must be BLOCKED or INCOMPLETE, never PASS.
+> - If any required static baseline artifact, QA artifact, or per-file coverage figure is missing, the audit verdict must be BLOCKED or INCOMPLETE, never PASS.
 
 ### Phase 0: Compliance & Context
 - [ ] [P0-T1] Confirm alignment with repo policies by reading `.github/instructions/general-code-change.instructions.md`, `.github/instructions/python-code-change.instructions.md`, `.github/instructions/general-unit-test.instructions.md`, and `.github/instructions/python-unit-test.instructions.md` before touching code
@@ -57,7 +57,7 @@
 - Unit: ...
 - Integration: ...
 - Manual/CLI: ...
-- Coverage evidence: list baseline artifact paths, post-change artifact paths, and comparison artifact paths for each in-scope language
+- Coverage evidence: list the static baseline artifact paths, the final-QA artifact paths, and the per-file threshold results from the single gate run for each in-scope language
 
 ## Open Questions / Notes
 

package/resources/feature-templates/refactor/plan.yyyy-MM-ddTHH-mm.md

@@ -16,7 +16,7 @@
 
 Brief approach to reach the target structure while keeping behavior stable.
 
-Fail-closed evidence rule: include explicit baseline artifact tasks, final-QA artifact tasks, and coverage-comparison tasks for each in-scope language when policy requires coverage. If any required baseline artifact, QA artifact, or coverage-comparison artifact is missing, the audit verdict must be BLOCKED or INCOMPLETE, never PASS.
+Fail-closed evidence rule: include explicit static baseline tasks, final-QA tasks, and a per-file threshold task for each in-scope language when policy requires coverage. If any required static baseline artifact, QA artifact, or per-file coverage figure is missing, the audit verdict must be BLOCKED or INCOMPLETE, never PASS.
 
 Evidence accounting rule: record the expected artifact path or location in each evidence-producing task. Do not mark evidence-backed work complete without the artifact.
 
@@ -52,7 +52,7 @@ Evidence accounting rule: record the expected artifact path or location in each
 - Unit/Integration: impacted modules and any regression tests for invariants
 - CLI/Workflow: end-to-end commands/tasks expected to remain stable
 - Tooling: lint/type checks after path updates
-- Coverage evidence: list baseline artifact paths, post-change artifact paths, and comparison artifact paths for each in-scope language
+- Coverage evidence: list the static baseline artifact paths, the final-QA artifact paths, and the per-file threshold results from the single gate run for each in-scope language
 
 ## Rollback / Contingency
 

package/resources/powershell/PoshQC/PoshQC.ScanConfig.psm1

@@ -93,7 +93,9 @@ function Get-PoshQCScanConfigFolder {
         if ([string]::IsNullOrWhiteSpace($folderText)) {
             throw "Scan configuration '$ConfigRelativePath' contains a blank 'test.scanFolders' entry."
         }
-        if ([IO.Path]::IsPathRooted($folderText)) {
+        # Host-independent rule: a drive-qualified entry or one beginning with '/' or '\' is
+        # rejected on every host; the .NET rooted-path test accepts 'C:/x' on Linux and rejects it on Windows.
+        if ($folderText -match '^(?:[A-Za-z]:|[\\/])') {
             throw "Scan configuration '$ConfigRelativePath' entry '$folderText' must be a workspace-relative path, not an absolute path."
         }
         # Reject parent-directory traversal in any path segment.