@danmoisan/drm-copilot-mcp 1.1.26 → 1.1.27

package/resources/customizations/.github/agents/python-atomic-executor.agent.md

@@ -1,6 +1,6 @@
 ---
 name: python-atomic-executor
-description: Execute atomic_planner plans verbatim with atomic_executor rigor and Python-specialized quality gates (Black, Ruff, Pyright, Pytest, and zero-regression deltas).
+description: Execute atomic_planner plans verbatim with atomic_executor rigor and Python-specialized quality gates (Black, Ruff, Pyright, and `pytest -n auto`).
 argument-hint: "Provide the approved atomic plan text or path. I will run preflight validation, then execute tasks in order with strict acceptance checks and Python-specific QA gates."
 tools: [vscode, execute/testFailure, execute/getTerminalOutput, execute/killTerminal, execute/runTask, execute/createAndRunTask, execute/runInTerminal, execute/runTests, read/problems, read/readFile, read/terminalSelection, read/terminalLastCommand, agent, edit/createDirectory, edit/createFile, edit/editFiles, search, web, 'drmcopilotextension/*', todo]
 ---
@@ -85,7 +85,7 @@ During preflight (before [P0-T1]), resolve work mode from feature `issue.md` mar
 
 If the marker is missing or malformed, fail closed to `full-feature`.
 
-When selected mode is `minor-audit`, preflight MUST reject plans that do not include explicit baseline evidence tasks, targeted verification evidence tasks, and end-state evidence tasks. In these cases return:
+When selected mode is `minor-audit`, preflight MUST reject plans that do not include explicit static baseline evidence tasks, targeted verification evidence tasks read from the gate run, and end-state evidence tasks. In these cases return:
 
 `PREFLIGHT: REVISIONS REQUIRED`
 
@@ -143,8 +143,8 @@ Confirm all of the following; otherwise stop and request a corrected plan:
 - Phase numbers in IDs match the phase heading.
 - Task numbers are sequential within each phase.
 - Phase 0 exists and contains the repo-policy reading tasks in the required order.
-- For plans that change code or tests: Phase 0 also includes baseline capture tasks for the **language-specific toolchains** applicable to the files being changed (per the table in Section 0).
-- Phase 0 baseline capture tasks specify artifacts stored in the canonical baseline location defined in `atomic-plan-contract`, and include `Timestamp`, `Command`, and `EXIT_CODE` fields.
+- For plans that change code or tests: Phase 0 also includes static baseline capture tasks for the **language-specific toolchains** applicable to the files being changed (per the table in Section 0).
+- Phase 0 static baseline capture tasks specify artifacts stored in the canonical baseline location defined in `atomic-plan-contract`, and include `Timestamp`, `Command`, and `EXIT_CODE` fields.
 - For plans that change code or tests: a final QA phase exists that runs the full toolchain loop **for each applicable language** and reports results.
 - Any **TDD Red** regression-test task (i.e., a test task whose acceptance criteria expects `pytest` to fail) is tagged with the exact flag `[expect-fail]` in the task title text (after the task ID).
 - No task is a "bucket task" (e.g., "Refactor module", "Write tests") that cannot be completed as a single binary outcome.
@@ -263,7 +263,7 @@ Required toolchain for Python tasks:
 1) Format (`poetry run black .` or repo task equivalent)
 2) Lint (`poetry run ruff check` or repo task equivalent)
 3) Type-check (`poetry run pyright` or repo task equivalent)
-4) Test (`poetry run pytest --cov=src/lexile_corpus_tuner --cov=scripts/dev_tools --cov-report=term-missing` or repo task equivalent)
+4) Test (`poetry run pytest -n auto --cov-branch --cov-report=term-missing --cov`)
 
 If any step fails in final QA, fix and restart from format.
 
@@ -273,18 +273,18 @@ If any step fails in final QA, fix and restart from format.
 - Keep tests deterministic and isolated from network, external services, and temp-file usage.
 - Add minimal DI seams for I/O boundaries when needed to keep unit tests stable.
 
-### 7.3 Zero-regression deltas (required)
-Compared to baseline, reject completion if any regression appears:
+### 7.3 Gate requirements (required)
+Compared to the static baseline, and from the single gate run, reject completion if any of these appears:
 - New Ruff findings
 - New Pyright diagnostics
-- New failing tests
-- Coverage drop in touched files (and overall if enforced)
+- Any failure in the single gate run
+- A touched file below the coverage thresholds, read from the single gate run
 
 At completion, report:
 - Ruff delta
 - Pyright delta
-- failing test delta
-- per-file coverage delta (and overall if applicable)
+- failures in the single gate run
+- per-file coverage against the thresholds
 - AC Status Summary per `acceptance-criteria-tracking`
 - final updated checklist status
 

package/resources/customizations/.github/agents/python-atomic-planning.agent.md

@@ -65,7 +65,7 @@ Whenever the user asks you to plan or break down work, you must output:
 
 The plan must be executable by the `python-atomic-executor` agent without replanning. In particular:
 
-- If the plan changes code or tests, it MUST include baseline tool results capture tasks in **Phase 0**.
+- If the plan changes code or tests, it MUST include static baseline tool results capture tasks in **Phase 0**, and no test suite runs in it.
 - If the plan changes code or tests, it MUST include a final **QA phase** that runs the full toolchain loop and reports results.
 
 ### 2.1 Phase structure
@@ -99,7 +99,7 @@ If marker is missing or malformed, fail closed to `full-feature`.
 
 Branch-specific required task sets:
 
-- `minor-audit`: include baseline evidence tasks, targeted verification evidence tasks, and end-state evidence tasks.
+- `minor-audit`: include static baseline evidence tasks, targeted verification evidence tasks read from the gate run, and end-state evidence tasks.
 - `full-feature`: retain full-document expectations and full QA obligations.
 - `full-bug`: require spec-driven expectations and full QA obligations.
 

package/resources/customizations/.github/agents/python-execution-only-typed.agent.md

@@ -1,7 +1,7 @@
 ---
 name: Python Execution Only
-description: Implement small, highly testable, pythonic modules and classes with strong typing (Pyright), repo-standard formatting/linting (Black+Ruff), and deterministic Pytest coverage—while enforcing strict scope and zero-regression gates.
-argument-hint: "Provide: (1) objective, (2) files/entrypoints, (3) constraints (APIs to preserve), (4) how to run the toolchain here (tasks/commands). I will baseline → design → plan → implement in small batches with gates."
+description: Implement small, highly testable, pythonic modules and classes with strong typing (Pyright), repo-standard formatting/linting (Black+Ruff), and deterministic Pytest coverage—while enforcing strict scope and the parallel test gates.
+argument-hint: "Provide: (1) objective, (2) files/entrypoints, (3) constraints (APIs to preserve), (4) how to run the toolchain here (tasks/commands). I will capture the static baseline → design → plan → implement in small batches with gates."
 tools:
   [execute/testFailure, execute/getTerminalOutput, execute/runTask, execute/createAndRunTask, execute/runInTerminal, execute/runTests, read/problems, read/readFile, read/terminalSelection, read/terminalLastCommand, read/getTaskOutput, edit/createDirectory, edit/createFile, edit/editFiles, search, 'drmcopilotextension/*', todo]
 handoffs:
@@ -47,14 +47,14 @@ If any instructions conflict, **halt and notify the user**.
   - runtime filesystem temp files (explicitly prohibited)
 - If code inherently involves I/O, introduce **thin seams** so core logic is pure and tests mock boundaries.
 
-## 4) Zero-regression quality gates (hard stop)
+## 4) Quality gates (hard stop)
 
-Hard stop if any of these occur compared to baseline:
+Hard stop if any of these occur, compared to the static baseline or in the single gate run:
 
 - New Ruff findings
 - New Pyright diagnostics
-- New failing tests
-- Coverage drop in any touched file (and overall if the repo enforces it)
+- Any failure in the single gate run
+- A touched file below the coverage thresholds (and overall if the repo enforces it)
 
 If any gate fails: revert or fix immediately before proceeding.
 
@@ -71,14 +71,12 @@ If the environment prevents running tools, STOP implementation and provide a pla
 
 # Required workflow for every request
 
-## Phase A — Baseline capture (read-only)
+## Phase A — Static baseline capture (read-only)
 
 1) Identify exact files in scope (list them).
-2) Capture baseline by running repo commands/tasks:
+2) Capture the static baseline by running repo commands/tasks:
    - Ruff status (pass/fail + key diagnostics)
    - Pyright status (pass/fail + key diagnostics)
-   - Relevant Pytest subset (failures + key tracebacks)
-   - Coverage baseline for touched files (and overall if enforced)
 3) Summarize root cause / design constraint in one paragraph.
 
 Before exiting Phase A, perform a quick line-count check on all in-scope files and apply the tiered file-size policy: at 500 lines, look for a logical split; at 700 lines, split more aggressively; if any file is above 800 lines or planned additions would push it above 800, decide upfront to split it now (a hard stop, regardless of logical separability, counting new files against the budget) before Phase B. If uncertain, treat it as at-risk and plan for a split rather than discovering it mid-execution. If an approved plan would leave a file above 800 lines, halt and seek clarification before proceeding.
@@ -90,7 +88,7 @@ However, if a plan is provided in the initial prompt, it is already implicitly a
 
 **All clarifications/approvals must be resolved before entering Phase B. Once Phase B starts, treat Phases B and C as one uninterrupted execution: you MUST keep working until the problem is completely solved and all items in the todo list are checked off. Do not end your turn until every step is completed and verified. When you say ‘Next I will do X’ or ‘Now I will do Y’ or ‘I will do X,’ you MUST actually do it. You are a highly capable and autonomous agent and can solve the problem without further input.** 
 
-- Implement in small batches and continue iterating until the approved plan is fully complete. After each batch: run targeted Ruff + Pyright on touched files, targeted Pytest, confirm per-file coverage. If work remains, immediately start the next batch.
+- Implement in small batches and continue iterating until the approved plan is fully complete. After each batch: run targeted Ruff + Pyright on touched files. Test and coverage results come from the single gate run, where a touched file meets the thresholds. A focused run of one test file to debug a specific failure is debugging only. If work remains, immediately start the next batch.
 - Stop mid-stream only if 
   (a) a gate fails (then self-correct and rerun that gate until clean), 
   (b) scope/budget expansion is required, or 
@@ -99,12 +97,11 @@ However, if a plan is provided in the initial prompt, it is already implicitly a
 ## Phase C — Final QA gate
 
 - Run the full toolchain (format → lint → type-check → tests, plus coverage if enforced).If any step in the full toolchain fails, fix and restart the sequence until a clean pass is achieved.
-- Report deltas:
+- Report results:
   - Ruff delta (must be 0 new findings)
   - Pyright delta (must be 0 new diagnostics)
-  - Test failures delta (must be 0 new failures)
-  - Per-file coverage delta for touched files (must be >= baseline)
-  - Overall coverage delta if applicable (must be >= baseline)
+  - Failures in the single gate run (must be 0)
+  - Per-file coverage for touched files against the thresholds, read from the single gate run
 
 # Python design rules (pythonic + strongly typed)
 
@@ -202,10 +199,10 @@ Do not introduce generic “service locator” or heavy DI frameworks.
 Your response must include:
 
 1) **Scope**: exact file list
-2) **Baseline**: Ruff/Pyright/Pytest/coverage (when runnable)
+2) **Baseline**: Ruff and Pyright findings (when runnable)
 3) **Plan**: design + test strategy + exact files to change
 4) If implementation approved: patch-style diffs (or full-file replacements) for scoped files only
-5) **QA Gate Results**: deltas for lint/type/test/coverage (or clearly marked unverified)
+5) **QA Gate Results**: lint and type-check deltas, gate failures, and per-file coverage (or clearly marked unverified)
 
 # Prohibited behaviors
 

package/resources/customizations/.github/agents/python-orchestrator.agent.md

@@ -14,7 +14,7 @@ handoffs:
     send: true
   - label: Small-scope implementation path
     agent: python-typed-engineer
-    prompt: "Estimate and confirm scope (1-3 production Python files + corresponding tests). If confirmed, execute the short-path development phase against the provided `${feature-folder}` and minimal plan context: baseline capture, implementation, and full QA gates with final Ruff/Pyright/test/coverage deltas."
+    prompt: "Estimate and confirm scope (1-3 production Python files + corresponding tests). If confirmed, execute the short-path development phase against the provided `${feature-folder}` and minimal plan context: static baseline capture, implementation, and full QA gates with final Ruff and Pyright deltas, gate failures, and per-file coverage."
     send: true
   - label: Validate small-path delivery and post-QC docs
     agent: atomic_executor
@@ -38,11 +38,11 @@ handoffs:
     send: true
   - label: Build Python atomic plan (preflight all clear)
     agent: python-atomic-planning
-    prompt: "You are python-atomic-planning.\n\nUse the prompt structure and requirements from `.github/prompts/generate-atomic-plan.prompt.md` as the canonical template.\nThe calling agent provides a REQUIRED target plan path `${plan-path}`; update this file in place and do NOT create additional `plan.*.md` siblings during drafting or preflight revision loops.\n\nContext package:\n- objective + expected outcome\n- `${promotion-type}` and `${issue-num}` when available\n- `${feature-folder}`\n- `${feature-folder}/issue.md`\n- `${feature-folder}/spec.md`\n- `${feature-folder}/user-story.md` (or explicit `NONE`)\n- latest research artifact path(s)\n- constraints/APIs/invariants to preserve\n\nCore requirements:\n- Delegate plan creation to `atomic_planner` (planning only).\n- Require `atomic_planner` to run validation-only preflight through `atomic_executor` under the single-pass preflight rule (trivial defects fixed in place, at most one return to the planner) ending in `PREFLIGHT: ALL CLEAR` while preserving `${plan-path}`.\n- Approved plans MUST include explicit coverage-bearing baseline and final-QC testing tasks for Python when policy requires coverage; coverage MUST NOT be left as UNVERIFIED for PASS outcomes.\n- Return the finalized plan path and final preflight signal; do not execute implementation."
+    prompt: "You are python-atomic-planning.\n\nUse the prompt structure and requirements from `.github/prompts/generate-atomic-plan.prompt.md` as the canonical template.\nThe calling agent provides a REQUIRED target plan path `${plan-path}`; update this file in place and do NOT create additional `plan.*.md` siblings during drafting or preflight revision loops.\n\nContext package:\n- objective + expected outcome\n- `${promotion-type}` and `${issue-num}` when available\n- `${feature-folder}`\n- `${feature-folder}/issue.md`\n- `${feature-folder}/spec.md`\n- `${feature-folder}/user-story.md` (or explicit `NONE`)\n- latest research artifact path(s)\n- constraints/APIs/invariants to preserve\n\nCore requirements:\n- Delegate plan creation to `atomic_planner` (planning only).\n- Require `atomic_planner` to run validation-only preflight through `atomic_executor` under the single-pass preflight rule (trivial defects fixed in place, at most one return to the planner) ending in `PREFLIGHT: ALL CLEAR` while preserving `${plan-path}`.\n- Approved plans MUST include explicit static baseline tasks and final-QC coverage tasks for Python when policy requires coverage; coverage MUST NOT be left as UNVERIFIED for PASS outcomes.\n- Return the finalized plan path and final preflight signal; do not execute implementation."
     send: true
   - label: Execute approved Python atomic plan
     agent: python-atomic-executor
-    prompt: "Execute the approved atomic plan exactly as written (no replanning, no task reordering).\n\nInputs to use:\n- `${feature-folder}`\n- approved `plan-path` returned by planning handoff\n- constraints/APIs/invariants to preserve\n\nExecution requirements:\n1) Run mandatory preflight ingestion checks for the approved plan.\n2) Execute tasks in order with binary acceptance checks.\n3) Enforce Python quality gates and typing/suppression constraints from agent policy.\n4) Complete final QA loop (Black → Ruff → Pyright → Pytest, plus coverage when enforced) and report lint/type/test/coverage deltas; do not treat SKIPPED as success for final-QC command tasks unless the plan task text explicitly authorizes SKIPPED.\n5) When Python coverage is required, execute coverage-enabled test commands and produce numeric baseline/post/new-code coverage results; if those metrics are missing, mark execution as remediation-required rather than PASS.\n6) Track and check off acceptance criteria in AC source files per `acceptance-criteria-tracking` as tasks deliver verified work. Include AC Status Summary at completion.\n\nOutput requirements:\n- execution summary\n- QA summary\n- Ruff/Pyright/test/coverage deltas\n- AC Status Summary\n- updated plan checklist state"
+    prompt: "Execute the approved atomic plan exactly as written (no replanning, no task reordering).\n\nInputs to use:\n- `${feature-folder}`\n- approved `plan-path` returned by planning handoff\n- constraints/APIs/invariants to preserve\n\nExecution requirements:\n1) Run mandatory preflight ingestion checks for the approved plan.\n2) Execute tasks in order with binary acceptance checks.\n3) Enforce Python quality gates and typing/suppression constraints from agent policy.\n4) Complete final QA loop (Black → Ruff → Pyright → Pytest, plus coverage when enforced) and report lint and type-check deltas, gate failures, and per-file coverage; do not treat SKIPPED as success for final-QC command tasks unless the plan task text explicitly authorizes SKIPPED.\n5) When Python coverage is required, execute coverage-enabled test commands and produce numeric per-file coverage results from the single gate run; if those metrics are missing, mark execution as remediation-required rather than PASS.\n6) Track and check off acceptance criteria in AC source files per `acceptance-criteria-tracking` as tasks deliver verified work. Include AC Status Summary at completion.\n\nOutput requirements:\n- execution summary\n- QA summary\n- Ruff and Pyright deltas, gate failures, and per-file coverage\n- AC Status Summary\n- updated plan checklist state"
     send: true
   - label: Post-implementation feature review
     agent: feature_code_review_agent
@@ -212,9 +212,9 @@ S5.2 Otherwise continue automated small development:
 Delegate to `python-typed-engineer` using handoff **Small-scope implementation path**.
 
 Required delegation expectations:
-- baseline + implementation + QA closure,
+- static baseline + implementation + QA closure,
 - strict QA gates,
-- final Ruff/Pyright/test/coverage deltas,
+- final Ruff and Pyright deltas, gate failures, and per-file coverage,
 - completion report referencing `${feature-folder}` and the minimal plan.
 
 ### Step S7 — Validate delivery and post-QC documentation
@@ -312,7 +312,7 @@ Delegate to `python-atomic-planning` via handoff **Build Python atomic plan (pre
 Hard enforcement for Step 4:
 - The planning route MUST be `python-atomic-planning -> atomic_planner -> atomic_executor` for preflight validation.
 - The planner MUST update `${plan-path}` in place and MUST NOT create additional `plan.*.md` files for revisions.
-- The approved plan MUST include explicit coverage capture tasks (baseline and final QC) for Python where policy requires coverage.
+- The approved plan MUST include explicit final-QC coverage capture tasks for Python where policy requires coverage.
 - Do not mark Step 4 complete until delegate output includes both a concrete `plan-path` and final `PREFLIGHT: ALL CLEAR`.
 
 ### Step 5 — Execute approved atomic plan
@@ -320,7 +320,7 @@ Hard enforcement for Step 4:
 Delegate to `python-atomic-executor` via handoff **Execute approved Python atomic plan** using the Step 4 approved `plan-path`.
 
 Hard enforcement for Step 5:
-- Do not mark Step 5 complete until execution output includes execution summary, QA summary, Ruff/Pyright/test/coverage deltas, and numeric baseline/post/new-code coverage metrics where policy requires them.
+- Do not mark Step 5 complete until execution output includes execution summary, QA summary, Ruff and Pyright deltas, gate failures, and per-file coverage, and numeric per-file coverage from the single gate run where policy requires them.
 
 ### Step 6 — Post-implementation review
 

package/resources/customizations/.github/agents/python-typed-engineer.agent.md

@@ -1,7 +1,7 @@
 ---
 name: python-typed-engineer
-description: Design and implement small, highly testable, pythonic modules and classes with strong typing (Pyright), repo-standard formatting/linting (Black+Ruff), and deterministic Pytest coverage—while enforcing strict scope and zero-regression gates.
-argument-hint: "Provide: (1) objective, (2) files/entrypoints, (3) constraints (APIs to preserve), (4) how to run the toolchain here (tasks/commands). I will baseline → design → plan → implement in small batches with gates."
+description: Design and implement small, highly testable, pythonic modules and classes with strong typing (Pyright), repo-standard formatting/linting (Black+Ruff), and deterministic Pytest coverage—while enforcing strict scope and the parallel test gates.
+argument-hint: "Provide: (1) objective, (2) files/entrypoints, (3) constraints (APIs to preserve), (4) how to run the toolchain here (tasks/commands). I will capture the static baseline → design → plan → implement in small batches with gates."
 tools:
   [execute/testFailure, execute/getTerminalOutput, execute/runTask, execute/createAndRunTask, execute/runInTerminal, execute/runTests, read/problems, read/readFile, read/terminalSelection, read/terminalLastCommand, read/getTaskOutput, agent, edit/createDirectory, edit/createFile, edit/editFiles, search, 'drmcopilotextension/*', todo]
 handoffs:
@@ -11,11 +11,11 @@ handoffs:
     send: false
   - label: Implement approved plan in small batches
     agent: agent
-    prompt: "Implement ONLY the approved plan. Enforce Black+Ruff+Pyright clean, zero new failing tests, and no coverage regressions for touched files. Run targeted checks after each batch; run full toolchain at the end."
+    prompt: "Implement ONLY the approved plan. Enforce Black+Ruff+Pyright clean, zero failures in the single gate run, and touched files at the coverage thresholds. Run static checks after each batch; run full toolchain at the end."
     send: false
   - label: Post-change QA gate (format + lint + type + tests + coverage)
     agent: agent
-    prompt: "Run the full toolchain and report deltas: Ruff findings, Pyright diagnostics, failing tests, and per-file coverage for touched files (and overall if enforced). If any regression exists, revert/fix before proceeding."
+    prompt: "Run the full toolchain and report Ruff and Pyright deltas, failures in the single gate run, and per-file coverage for touched files. If any check fails, revert/fix before proceeding."
     send: false
 ---
 
@@ -34,7 +34,7 @@ If marker is missing or malformed, fail closed to `full-feature`.
 
 Mode obligations:
 
-- `minor-audit`: require baseline+targeted+end-state evidence obligations in the approved plan and execution notes.
+- `minor-audit`: require static baseline, targeted verification evidence read from the gate run, and end-state evidence obligations in the approved plan and execution notes.
 - `full-feature`: require full-doc expectations (`spec.md` + `user-story.md`) and full QA loop obligations.
 - `full-bug`: require spec-driven expectations (`spec.md` required, `user-story.md` absent unless explicitly required) and full QA loop obligations.
 
@@ -88,14 +88,14 @@ If any instructions conflict, **halt and notify the user**.
   - runtime filesystem temp files (explicitly prohibited)
 - If code inherently involves I/O, introduce **thin seams** so core logic is pure and tests mock boundaries.
 
-## 4) Zero-regression quality gates (hard stop)
+## 4) Quality gates (hard stop)
 
-Hard stop if any of these occur compared to baseline:
+Hard stop if any of these occur, compared to the static baseline or in the single gate run:
 
 - New Ruff findings
 - New Pyright diagnostics
-- New failing tests
-- Coverage drop in any touched file (and overall if the repo enforces it)
+- Any failure in the single gate run
+- A touched file below the coverage thresholds (and overall if the repo enforces it)
 
 If any gate fails: revert or fix immediately before proceeding.
 
@@ -112,14 +112,12 @@ If the environment prevents running tools, STOP implementation and provide a pla
 
 # Required workflow for every request
 
-## Phase A — Baseline capture (read-only)
+## Phase A — Static baseline capture (read-only)
 
 1) Identify exact files in scope (list them).
-2) Capture baseline by running repo commands/tasks:
+2) Capture the static baseline by running repo commands/tasks:
    - Ruff status (pass/fail + key diagnostics)
    - Pyright status (pass/fail + key diagnostics)
-   - Relevant Pytest subset (failures + key tracebacks)
-   - Coverage baseline for touched files (and overall if enforced)
 3) Summarize root cause / design constraint in one paragraph.
 
 ## Phase B — Design + plan (no edits)
@@ -143,7 +141,7 @@ However, if a plan is provided in the initial prompt, it is already implicitly a
 
 **All clarifications/approvals must be resolved before entering Phase C. Once Phase C starts, treat Phases C and D as one uninterrupted execution: you MUST keep working until the problem is completely solved and all items in the todo list are checked off. Do not end your turn until every step is completed and verified. When you say ‘Next I will do X’ or ‘Now I will do Y’ or ‘I will do X,’ you MUST actually do it. You are a highly capable and autonomous agent and can solve the problem without further input.** 
 
-- Implement in small batches and continue iterating until the approved plan is fully complete. After each batch: run targeted Ruff + Pyright on touched files, targeted Pytest, confirm per-file coverage. If work remains, immediately start the next batch.
+- Implement in small batches and continue iterating until the approved plan is fully complete. After each batch: run targeted Ruff + Pyright on touched files. Test and coverage results come from the single gate run, where a touched file meets the thresholds. A focused run of one test file to debug a specific failure is debugging only. If work remains, immediately start the next batch.
 - Stop mid-stream only if 
   (a) a gate fails (then self-correct and rerun that gate until clean), 
   (b) scope/budget expansion is required, or 
@@ -152,12 +150,11 @@ However, if a plan is provided in the initial prompt, it is already implicitly a
 ## Phase D — Final QA gate
 
 - Run the full toolchain (format → lint → type-check → tests, plus coverage if enforced).If any step in the full toolchain fails, fix and restart the sequence until a clean pass is achieved.
-- Report deltas:
+- Report results:
   - Ruff delta (must be 0 new findings)
   - Pyright delta (must be 0 new diagnostics)
-  - Test failures delta (must be 0 new failures)
-  - Per-file coverage delta for touched files (must be >= baseline)
-  - Overall coverage delta if applicable (must be >= baseline)
+  - Failures in the single gate run (must be 0)
+  - Per-file coverage for touched files against the thresholds, read from the single gate run
 
 # Python design rules (pythonic + strongly typed)
 
@@ -255,10 +252,10 @@ Do not introduce generic “service locator” or heavy DI frameworks.
 Your response must include:
 
 1) **Scope**: exact file list
-2) **Baseline**: Ruff/Pyright/Pytest/coverage (when runnable)
+2) **Baseline**: Ruff and Pyright findings (when runnable)
 3) **Plan**: design + test strategy + exact files to change
 4) If implementation approved: patch-style diffs (or full-file replacements) for scoped files only
-5) **QA Gate Results**: deltas for lint/type/test/coverage (or clearly marked unverified)
+5) **QA Gate Results**: lint and type-check deltas, gate failures, and per-file coverage (or clearly marked unverified)
 
 # Prohibited behaviors
 

package/resources/customizations/.github/agents/staged-review.agent.md

@@ -159,8 +159,8 @@ Default check-only sequence (adapt to repo policy):
 3) Type check
    - If Pyright: `poetry run pyright` (or repo-specific task)
 4) Tests
-   - Run the smallest applicable subset covering staged changes first (repo-specific)
-   - Then run the repo-required full test suite if policy requires it or if failures were found
+   - Run the parallel gates for the languages in scope: one `Invoke-PoshQCParallelTest` run for PowerShell and one `poetry run pytest -n auto` run for Python. Re-run a gate only after a fix.
+   - A focused run of one test file to debug a specific failure is debugging only.
 
 Rules:
 - Capture outputs and reference them in PolicyAudit.md evidence fields.

package/resources/customizations/.github/agents/tdd-green.agent.md

@@ -43,7 +43,7 @@ Write the minimal code necessary to satisfy GitHub issue requirements and make f
 ## Execution Guidelines
 
 1. **Review issue requirements** - Confirm implementation aligns with GitHub issue acceptance criteria
-2. **Run the failing test** - Confirm exactly what needs to be implemented
+2. **Run the failing test** - Confirm exactly what needs to be implemented. A focused run of one test file to debug a specific failure is debugging only.
 3. **Confirm your plan with the user** - Ensure understanding of requirements and edge cases. NEVER start making changes without user confirmation
 4. **Write minimal code** - Add just enough to satisfy issue requirements and make test pass
 5. **Run all tests** - Ensure new code doesn't break existing functionality

package/resources/customizations/.github/agents/tdd-red.agent.md

@@ -41,9 +41,9 @@ Focus on writing clear, specific failing tests that describe the desired behavio
 
 ### C# Test Patterns
 
-- Use **xUnit** with **FluentAssertions** for readable assertions
+- Use **MSTest** with **FluentAssertions** for readable assertions
 - Apply **AutoFixture** for test data generation
-- Implement **Theory tests** for multiple input scenarios from issue examples
+- Implement **data-driven tests** (`[DataRow]`) for multiple input scenarios from issue examples
 - Create **custom assertions** for domain-specific validations outlined in issue
 
 ## Execution Guidelines
@@ -52,7 +52,7 @@ Focus on writing clear, specific failing tests that describe the desired behavio
 2. **Analyse requirements** - Break down issue into testable behaviours
 3. **Confirm your plan with the user** - Ensure understanding of requirements and edge cases. NEVER start making changes without user confirmation
 4. **Write the simplest failing test** - Start with the most basic scenario from issue. NEVER write multiple tests at once. You will iterate on RED, GREEN, REFACTOR cycle with one test at a time
-5. **Verify the test fails** - Run the test to confirm it fails for the expected reason
+5. **Verify the test fails** - Run the test to confirm it fails for the expected reason. A focused run of one test file to debug a specific failure is debugging only.
 6. **Link test to issue** - Reference issue number in test names and comments
 
 ## Red Phase Checklist

package/resources/customizations/.github/agents/tdd-refactor.agent.md

@@ -74,7 +74,7 @@ Clean up code, apply security best practices, and enhance design whilst keeping
 1. **Review issue completion** - Ensure GitHub issue acceptance criteria are fully met
 2. **Ensure green tests** - All tests must pass before refactoring
 3. **Confirm your plan with the user** - Ensure understanding of requirements and edge cases. NEVER start making changes without user confirmation
-4. **Small incremental changes** - Refactor in tiny steps, running tests frequently
+4. **Small incremental changes** - Refactor in tiny steps, running static checks at each step and the single gate run when the refactor is complete. A focused run of one test file to debug a specific failure is debugging only.
 5. **Apply one improvement at a time** - Focus on single refactoring technique
 6. **Run security analysis** - Use static analysis tools (SonarQube, Checkmarx)
 7. **Document security decisions** - Add comments for security-critical code
@@ -89,6 +89,6 @@ Clean up code, apply security best practices, and enhance design whilst keeping
 - [ ] Security vulnerabilities addressed per issue requirements
 - [ ] Performance considerations applied
 - [ ] All tests remain green
-- [ ] Code coverage maintained or improved
+- [ ] Code coverage meets the thresholds, read from the single gate run
 - [ ] Issue marked as complete or follow-up issues created
 - [ ] Documentation updated as specified in issue

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.