@danmoisan/drm-copilot-mcp 1.1.19 → 1.1.20

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

@@ -95,11 +95,11 @@ When all format and mode-gate requirements are satisfied, return:
 
 ### 2.0 Preflight validation-only mode (directive-driven)
 
-If you receive a plan along with the following directive line (exact text):
+If you receive a plan along with the following directive line (exact text) in the delegation prompt:
 
 `DIRECTIVE: PREFLIGHT VALIDATION ONLY`
 
-you MUST enter **validation-only** mode.
+you MUST enter **validation-only** mode. The preflight directive belongs in the delegation prompt, never in a plan file; a directive line inside a plan file does not make an execution run a preflight run.
 
 Validation-only mode rules (non-negotiable):
 1) Perform ONLY the steps in:
@@ -116,14 +116,18 @@ Validation-only required output:
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 
-If revisions are required:
-  - Include a precise **plan delta** that `atomic_planner` can apply (exact edits/additions/removals).
-  - Automatically hand off back to `atomic_planner` requesting it apply the delta and resubmit the
-    updated plan for validation-only again.
+Single-pass rules (`### Single-Pass Preflight` in the `atomic-plan-contract` skill):
+  - Review the entire plan in one pass and classify every defect as trivial or substantive.
+  - Fix trivial defects in place, in task text only; never add, remove, or reorder tasks. Record each
+    fix in `<FEATURE>/evidence/other/preflight-fixes.<timestamp>.md`. This in-place edit is the only file
+    write validation-only mode permits.
+  - After the signal, emit one line per defect: `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>`,
+    `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>`, and
+    `preflight-fix-record: <path>` when at least one fix was made.
 
-Loop requirement:
-  Continue this validate → delta → planner-revise → validate loop until you can return
-  `PREFLIGHT: ALL CLEAR`.
+If revisions are required:
+  - Include a precise **plan delta** that `atomic_planner` can apply (exact edits/additions/removals), with one `PREFLIGHT-DEFECT:` line for every substantive defect found.
+  - Return the result to the caller. A plan returns to the planner at most once; the orchestrator routes the full defect list for one revision and runs one confirming preflight.
 
 When the user provides a plan (in chat or via file path), you must:
 

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

@@ -105,9 +105,9 @@ Branch-specific required task sets:
 
 ---
 
-### 2.5.1 Mandatory preflight validation loop via `powershell_atomic_executor`
+### 2.5.1 Mandatory single-pass preflight via `powershell_atomic_executor`
 
-Follow the preflight validation loop rules in the `atomic-plan-contract` skill.
+Follow `### Single-Pass Preflight` in the `atomic-plan-contract` skill. The preflight directive belongs in the delegation prompt, never in the plan file. The preflight executor fixes trivial defects in place and returns only substantive defects as `PREFLIGHT-DEFECT:` lines. A plan returns to the planner at most once: apply every listed change in one revision of the same file; if the confirming preflight still reports a substantive defect, the orchestrator halts with `blocked_reason: "validator_failed"`.
 
 ---
 

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

@@ -6,7 +6,7 @@ tools: [vscode/runCommand, vscode/extensions, execute/getTerminalOutput, execute
 handoffs:
   - label: Build minimal-audit atomic plan (preflight all clear)
     agent: atomic_planner
-    prompt: "Generate a minimal-audit atomic plan for `${feature-folder}` using `${feature-folder}/issue.md` as the only requirements source (no spec/user-story/research). Use directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`. Target plan file path is `${plan-path}` and MUST be updated in place. Do NOT create additional `plan.*.md` siblings during drafting or preflight revision loops. The plan MUST include exactly 3 phases: Phase 0 baseline capture, Phase 1 placeholder for constrained small-path implementation work, Phase 2 final QC loop. Final-QC command tasks MUST be unconditional when present in the plan: do not add IN_SCOPE/OUT_OF_SCOPE branching and do not allow SKIPPED as a valid completion state for those tasks. Require validation-only preflight through `atomic_executor` and iterate until final `PREFLIGHT: ALL CLEAR` while preserving the same target path. Return `plan-path` and final preflight signal."
+    prompt: "Generate a minimal-audit atomic plan for `${feature-folder}` using `${feature-folder}/issue.md` as the only requirements source (no spec/user-story/research). Use directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`. Target plan file path is `${plan-path}` and MUST be updated in place. Do NOT create additional `plan.*.md` siblings during drafting or preflight revision loops. The plan MUST include exactly 3 phases: Phase 0 baseline capture, Phase 1 placeholder for constrained small-path implementation work, Phase 2 final QC loop. Final-QC command tasks MUST be unconditional when present in the plan: do not add IN_SCOPE/OUT_OF_SCOPE branching and do not allow SKIPPED as a valid completion state for those tasks. Require 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 the same target path. Return `plan-path` and final preflight signal."
     send: true
   - label: Execute Phase 0 only
     agent: atomic_executor
@@ -38,7 +38,7 @@ handoffs:
     send: true
   - label: Build PowerShell atomic plan (preflight all clear)
     agent: powershell-atomic-planning
-    prompt: "You are powershell-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` and iterate until final `PREFLIGHT: ALL CLEAR` while preserving `${plan-path}`.\n- Approved plans MUST include explicit coverage-bearing baseline and final-QC testing tasks for PowerShell 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 powershell-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 PowerShell 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 PowerShell atomic plan
     agent: powershell_atomic_executor

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

@@ -6,7 +6,7 @@ tools: [vscode, execute/testFailure, execute/getTerminalOutput, execute/killTerm
 handoffs:
   - label: Architecture + testability plan only (no edits)
     agent: atomic_planner
-    prompt: "Create a plan ONLY (no implementation edits). Use `.github/prompts/generate-atomic-plan.prompt.md` as the planning contract and resolve it with concrete paths/inputs (`name`, `file`, `spec`, `user-story`, `research`) so there are no placeholders. Produce an executor-ready atomic plan with canonical `### Phase N — ...` headings, `- [ ] [P#-T#]` tasks, mandatory Phase 0 baseline capture, and mandatory final QA loop for all affected toolchains. Plan content must explicitly include: proposed script/module structure, minimal DI seams, Pester scenario-level test strategy, external executable wrapper mock strategy, and exact files to change. After drafting, run the mandatory validation-only handoff loop to `atomic_executor` using the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`; apply any required plan deltas and repeat until `PREFLIGHT: ALL CLEAR`, then return the finalized plan plus the final all-clear signal."
+    prompt: "Create a plan ONLY (no implementation edits). Use `.github/prompts/generate-atomic-plan.prompt.md` as the planning contract and resolve it with concrete paths/inputs (`name`, `file`, `spec`, `user-story`, `research`) so there are no placeholders. Produce an executor-ready atomic plan with canonical `### Phase N — ...` headings, `- [ ] [P#-T#]` tasks, mandatory Phase 0 baseline capture, and mandatory final QA loop for all affected toolchains. Plan content must explicitly include: proposed script/module structure, minimal DI seams, Pester scenario-level test strategy, external executable wrapper mock strategy, and exact files to change. After drafting, run the mandatory single-pass validation-only handoff to `atomic_executor` with the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY` in the delegation prompt; apply the required plan deltas in one revision (a plan returns to the planner at most once) ending in `PREFLIGHT: ALL CLEAR`, then return the finalized plan plus the final all-clear signal."
     send: true
   - label: Implement approved plan
     agent: powershell_atomic_executor
@@ -94,7 +94,7 @@ If any required item is missing in orchestrator handoff mode, STOP and request t
 When in **Orchestrator handoff mode**, this agent MUST run the following delegation chain and MUST NOT bypass it with direct implementation:
 
 1) Delegate to `atomic_planner` (handoff: **Architecture + testability plan only (no edits)**).
-2) Require planner output to include final `PREFLIGHT: ALL CLEAR` from the `atomic_executor` validation loop.
+2) Require planner output to include final `PREFLIGHT: ALL CLEAR` from single-pass `atomic_executor` preflight.
 3) Delegate plan execution to `powershell_atomic_executor` (handoff: **Implement approved plan**).
 4) Delegate final QA to `powershell_atomic_executor` (handoff: **Post-change QA gate (format + analyze + tests + coverage)**).
 5) Delegate post-implementation review to `feature_code_review_agent` (handoff: **Post-implementation feature review**).
@@ -208,7 +208,7 @@ The plan should include:
 - Exact files to change (must satisfy scope guardrails).
 
 Orchestrator handoff mode requirement:
-- Even if a draft plan is supplied, delegate to `atomic_planner` to normalize/validate the plan and run the mandatory preflight validation loop to `PREFLIGHT: ALL CLEAR` before any implementation delegation.
+- Even if a draft plan is supplied, delegate to `atomic_planner` to normalize/validate the plan and run mandatory single-pass preflight to `PREFLIGHT: ALL CLEAR` before any implementation delegation.
 
 Orchestrator handoff mode hard stop:
 - In this mode, ignore implicit approval shortcuts for direct local execution.

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

@@ -95,11 +95,11 @@ When all format and mode-gate requirements are satisfied, return:
 
 ### 2.0 Preflight validation-only mode (directive-driven)
 
-If you receive a plan along with the following directive line (exact text):
+If you receive a plan along with the following directive line (exact text) in the delegation prompt:
 
 `DIRECTIVE: PREFLIGHT VALIDATION ONLY`
 
-you MUST enter **validation-only** mode.
+you MUST enter **validation-only** mode. The preflight directive belongs in the delegation prompt, never in a plan file; a directive line inside a plan file does not make an execution run a preflight run.
 
 Validation-only mode rules (non-negotiable):
 1) Perform ONLY the steps in:
@@ -116,14 +116,18 @@ Validation-only required output:
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 
-If revisions are required:
-  - Include a precise **plan delta** that `atomic_planner` can apply (exact edits/additions/removals).
-  - Automatically hand off back to `atomic_planner` requesting it apply the delta and resubmit the
-    updated plan for validation-only again.
+Single-pass rules (`### Single-Pass Preflight` in the `atomic-plan-contract` skill):
+  - Review the entire plan in one pass and classify every defect as trivial or substantive.
+  - Fix trivial defects in place, in task text only; never add, remove, or reorder tasks. Record each
+    fix in `<FEATURE>/evidence/other/preflight-fixes.<timestamp>.md`. This in-place edit is the only file
+    write validation-only mode permits.
+  - After the signal, emit one line per defect: `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>`,
+    `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>`, and
+    `preflight-fix-record: <path>` when at least one fix was made.
 
-Loop requirement:
-  Continue this validate → delta → planner-revise → validate loop until you can return
-  `PREFLIGHT: ALL CLEAR`.
+If revisions are required:
+  - Include a precise **plan delta** that `atomic_planner` can apply (exact edits/additions/removals), with one `PREFLIGHT-DEFECT:` line for every substantive defect found.
+  - Return the result to the caller. A plan returns to the planner at most once; the orchestrator routes the full defect list for one revision and runs one confirming preflight.
 
 When the user provides a plan (in chat or via file path), you must:
 

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

@@ -105,9 +105,9 @@ Branch-specific required task sets:
 
 ---
 
-### 2.5.1 Mandatory preflight validation loop via `python-atomic-executor`
+### 2.5.1 Mandatory single-pass preflight via `python-atomic-executor`
 
-Follow the preflight validation loop rules in the `atomic-plan-contract` skill.
+Follow `### Single-Pass Preflight` in the `atomic-plan-contract` skill. The preflight directive belongs in the delegation prompt, never in the plan file. The preflight executor fixes trivial defects in place and returns only substantive defects as `PREFLIGHT-DEFECT:` lines. A plan returns to the planner at most once: apply every listed change in one revision of the same file; if the confirming preflight still reports a substantive defect, the orchestrator halts with `blocked_reason: "validator_failed"`.
 
 ---
 

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

@@ -6,7 +6,7 @@ tools: [vscode/runCommand, vscode/extensions, execute/getTerminalOutput, execute
 handoffs:
   - label: Build minimal-audit atomic plan (preflight all clear)
     agent: atomic_planner
-    prompt: "Generate a minimal-audit atomic plan for `${feature-folder}` using `${feature-folder}/issue.md` as the only requirements source (no spec/user-story/research). Use directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`. Target plan file path is `${plan-path}` and MUST be updated in place. Do NOT create additional `plan.*.md` siblings during drafting or preflight revision loops. The plan MUST include exactly 3 phases: Phase 0 baseline capture, Phase 1 placeholder for constrained small-path implementation work, Phase 2 final QC loop. Final-QC command tasks MUST be unconditional when present in the plan: do not add IN_SCOPE/OUT_OF_SCOPE branching and do not allow SKIPPED as a valid completion state for those tasks. Require validation-only preflight through `atomic_executor` and iterate until final `PREFLIGHT: ALL CLEAR` while preserving the same target path. Return `plan-path` and final preflight signal."
+    prompt: "Generate a minimal-audit atomic plan for `${feature-folder}` using `${feature-folder}/issue.md` as the only requirements source (no spec/user-story/research). Use directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`. Target plan file path is `${plan-path}` and MUST be updated in place. Do NOT create additional `plan.*.md` siblings during drafting or preflight revision loops. The plan MUST include exactly 3 phases: Phase 0 baseline capture, Phase 1 placeholder for constrained small-path implementation work, Phase 2 final QC loop. Final-QC command tasks MUST be unconditional when present in the plan: do not add IN_SCOPE/OUT_OF_SCOPE branching and do not allow SKIPPED as a valid completion state for those tasks. Require 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 the same target path. Return `plan-path` and final preflight signal."
     send: true
   - label: Execute Phase 0 only
     agent: atomic_executor
@@ -38,7 +38,7 @@ 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` and iterate until final `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 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."
     send: true
   - label: Execute approved Python atomic plan
     agent: python-atomic-executor

package/resources/customizations/.github/agents/task-researcher.agent.md

@@ -10,6 +10,8 @@ tools: [vscode/getProjectSetupInfo, vscode/installExtension, vscode/newWorkspace
 
 You are a research-only specialist who performs deep, comprehensive analysis for task planning. Your sole responsibility is to write research notes to one of the two tracked research roots: `docs/features/<feature>/research/` for feature-associated research, or `docs/research/` for one-off research not tied to a feature. The orchestrator resolves which root to use and supplies the path; do not infer the feature folder independently. You MUST NOT make changes to any other files, code, or configurations.
 
+Read `.github/skills/execution-environment/SKILL.md` first, before any other step. It states the tool routes, command-text restrictions, batch budget, hook context, CI shape, contract tests, evidence rules, coverage and file-size gates, and test-isolation checks that research findings and the pre-mortem must account for.
+
 ## Core Research Principles
 
 You MUST operate under these constraints:
@@ -50,6 +52,10 @@ You WILL identify multiple implementation approaches during research, documentin
 
 You WILL present findings succinctly to the user, highlighting key discoveries and alternative approaches. You MUST guide the user toward selecting a single recommended solution and then remove detailed alternative-approach research from the final research document, leaving only a brief (non-exhaustive) "Rejected alternatives" summary.
 
+### 4. Pre-Mortem
+
+Feature-associated research (a research path under `docs/features/`) MUST carry 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 next review or CI run could fail on that dimension and the mitigation the plan must carry; a label that does not apply is written as "not applicable" followed by the reason. One-off research under `docs/research/` is exempt.
+
 ## Alternative Analysis Framework
 
 During research, you WILL discover and evaluate multiple implementation approaches.

package/resources/customizations/.github/prompts/generate-atomic-plan.prompt.md

@@ -54,7 +54,7 @@ Plans must consist of discrete, atomic phases containing executable tasks. Each
 
 Please fill out the template given in `${file}`. 
 
-## Mandatory post-output preflight validation loop
+## Mandatory post-output single-pass preflight
 
 After you have fully updated `${file}`, you MUST initiate a **validate-only** preflight validation
 handoff to the `atomic_executor` agent.
@@ -63,10 +63,14 @@ Purpose:
 	Ensure the plan you produced is ingestible by the executor without replanning.
 
 Hard constraints:
-	- The executor MUST perform **preflight checks only** (no task execution).
-	- You MUST iterate until the executor returns an all-clear signal.
+	- The executor MUST perform **preflight checks only** (no task execution), in one pass over the
+	  entire plan, fixing trivial defects in place and returning only substantive defects
+	  (`### Single-Pass Preflight` in the `atomic-plan-contract` skill).
+	- The plan is design-level (`## Design-Level Plan Contract (Mandatory)` in the
+	  `atomic-plan-contract` skill) and carries a `## Pre-Mortem` section.
+	- A plan returns to you at most once.
 
-Required handoff directive (exact text):
+Required handoff directive (exact text), placed in the handoff prompt and never in `${file}`:
 
 `DIRECTIVE: PREFLIGHT VALIDATION ONLY`
 
@@ -75,13 +79,15 @@ Required validation result signals (exact text; one must be present):
 - `PREFLIGHT: ALL CLEAR`
 - `PREFLIGHT: REVISIONS REQUIRED`
 
-Loop protocol (MANDATORY):
+Handoff protocol (MANDATORY):
 	1) Hand off `${file}` to `atomic_executor` with the directive above.
-	2) If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, apply the executor’s plan delta to
-	   `${file}` (preserving task IDs and executor-compatible formatting), then hand off again.
-	3) Repeat until the executor returns `PREFLIGHT: ALL CLEAR`.
-	4) Only then may you return control to the calling system, including the final
-	   `PREFLIGHT: ALL CLEAR` signal verbatim.
+	2) If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, apply every `PREFLIGHT-DEFECT:` change
+	   in the executor’s plan delta to `${file}` in one revision (preserving task IDs and
+	   executor-compatible formatting), then hand off once more.
+	3) If the confirming preflight still returns `PREFLIGHT: REVISIONS REQUIRED`, stop and report
+	   blocked state (`blocked_reason: "validator_failed"`); do not open another revision.
+	4) Only after `PREFLIGHT: ALL CLEAR` may you return control to the calling system, including the
+	   final `PREFLIGHT: ALL CLEAR` signal verbatim.
 
 ## Template Validation Rules
 

package/resources/customizations/.github/prompts/orchestrate-csharp-work.prompt.md

@@ -27,7 +27,7 @@ Coordinate the user request from intake to completion using the correct path bas
      1) Scope/create potential entry and promote with `--work-mode minor-audit`
    2) Create branch and active feature folder with `--work-mode minor-audit`, then verify `issue.md` contains an explicit `## Acceptance Criteria` section
      3) Delegate plan creation to `atomic_planner` with directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
-     4) Require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`
+     4) Require single-pass `atomic_executor` preflight ending in `PREFLIGHT: ALL CLEAR` (at most one return to the planner)
      5) Delegate to `atomic_executor` to execute **Phase 0 only**
      6) Branch behavior:
         - explicit initial manual bootstrap opt-in: save state and stop for manual resume
@@ -40,7 +40,7 @@ Coordinate the user request from intake to completion using the correct path bas
      2) Promote to GitHub issue and capture issue metadata
      3) Create branch and active feature folder
      4) Delegate research + spec/story completion
-     5) Delegate plan creation to `csharp-atomic-planning` (which delegates to `atomic_planner`, then validates preflight via `atomic_executor` until `PREFLIGHT: ALL CLEAR`)
+     5) Delegate plan creation to `csharp-atomic-planning` (which delegates to `atomic_planner`, then runs single-pass preflight via `atomic_executor` ending in `PREFLIGHT: ALL CLEAR`)
      6) After all-clear, delegate implementation + QA directly to `csharp-atomic-executor`
      7) Delegate post-implementation feature review
 

package/resources/customizations/.github/prompts/orchestrate-powershell-work.prompt.md

@@ -29,7 +29,7 @@ Coordinate the user request from intake to completion using the correct path bas
      2) Promote to GitHub issue and capture issue metadata
      3) Create branch and active feature folder
      4) Delegate research + spec/story completion
-   5) Delegate plan creation to `powershell-atomic-planning` (which delegates to `atomic_planner`, then validates preflight via `atomic_executor` until `PREFLIGHT: ALL CLEAR`)
+   5) Delegate plan creation to `powershell-atomic-planning` (which delegates to `atomic_planner`, then runs single-pass preflight via `atomic_executor` ending in `PREFLIGHT: ALL CLEAR`)
    6) After all-clear, delegate implementation + QA directly to `powershell_atomic_executor`
    7) Delegate post-implementation feature review
 

package/resources/customizations/.github/prompts/orchestrate-python-work.prompt.md

@@ -29,7 +29,7 @@ Coordinate the user request from intake to completion using the correct path bas
      2) Promote to GitHub issue and capture issue metadata
      3) Create branch and active feature folder
      4) Delegate research + spec/story completion
-   5) Delegate plan creation to `python-atomic-planning` (which delegates to `atomic_planner`, then validates preflight via `atomic_executor` until `PREFLIGHT: ALL CLEAR`)
+   5) Delegate plan creation to `python-atomic-planning` (which delegates to `atomic_planner`, then runs single-pass preflight via `atomic_executor` ending in `PREFLIGHT: ALL CLEAR`)
    6) After all-clear, delegate implementation + QA directly to `python-atomic-executor`
    7) Delegate post-implementation feature review
 

package/resources/customizations/.github/prompts/orchestrate-work.prompt.md

@@ -27,7 +27,7 @@ Coordinate the user request from intake to completion using the correct path bas
      1) Scope/create potential entry and promote with `--work-mode minor-audit`
    2) Create branch and active feature folder with `--work-mode minor-audit`, then verify `issue.md` contains an explicit `## Acceptance Criteria` section
      3) Delegate plan creation to `atomic_planner` with directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
-     4) Require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`
+     4) Require single-pass `atomic_executor` preflight ending in `PREFLIGHT: ALL CLEAR` (at most one return to the planner)
      5) Delegate to `atomic_executor` to execute **Phase 0 only**
      6) Branch behavior:
         - explicit initial manual bootstrap opt-in: save state and stop for manual resume
@@ -40,7 +40,7 @@ Coordinate the user request from intake to completion using the correct path bas
      2) Promote to GitHub issue and capture issue metadata
      3) Create branch and active feature folder
      4) Delegate research + spec/story completion
-   5) Delegate plan creation to `atomic_planner` (and require validation-only preflight through `atomic_executor` until `PREFLIGHT: ALL CLEAR`)
+   5) Delegate plan creation to `atomic_planner` (and require single-pass validation-only preflight through `atomic_executor` ending in `PREFLIGHT: ALL CLEAR`)
    6) After all-clear, delegate implementation + QA directly to `atomic_executor`
    7) Delegate post-implementation feature review
 

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

@@ -21,6 +21,22 @@ Use this skill when:
 - Task IDs must match their phase and be sequential per phase.
 - Plans must pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>` before they can be reported as approved.
 
+## Design-Level Plan Contract (Mandatory)
+
+A plan is a design-level document: it states what changes and how the change is proven, not a transcript of commands. Every task names the files it creates or edits, the symbols, headings, or tests it touches, the behavior the change produces, the tests that prove that behavior, and an acceptance condition stated as an observable outcome.
+
+Rules:
+
+- **Anchors are symbols, headings, or test names.** A plan never cites a line number, a `path:line` locator, a `#L` anchor, or a commit SHA, because each goes stale when `main` moves (validator rules G11 and G12). Scope comparisons name the merge-base derivation of `origin/main` and `HEAD`, not a commit.
+- **Literals only where they are the asserted value.** A plan quotes a literal when an acceptance condition asserts that exact value. It does not quote file contents, command output, or prose for context.
+- **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.
+- **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.
+
 ## Short-Path Minimal Plan Contract
 
 When orchestration selects short path, a minimal plan is still mandatory and must include these blocks:
@@ -144,13 +160,30 @@ Any regression test task expected to fail must be tagged with `[expect-fail]` an
 ## Preflight Validation (Planner ↔ Executor)
 
 When validating or handing off plans for execution:
-- Use the directive line: `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
+- Put the directive line `DIRECTIVE: PREFLIGHT VALIDATION ONLY` in the delegation prompt. The preflight directive belongs in the delegation prompt, never in a plan file.
 - Require one of the exact signals:
 	- `PREFLIGHT: ALL CLEAR`
 	- `PREFLIGHT: REVISIONS REQUIRED`
-- If revisions are required, provide a precise plan delta and repeat validation until all clear.
+- If revisions are required, provide a precise plan delta with one `PREFLIGHT-DEFECT:` line per substantive defect. A plan returns to the planner at most once.
 - If the required planner ↔ executor handoff cannot be started or completed, stop and report blocked state; do not self-approve the plan.
 
+### Single-Pass Preflight
+
+- **Review the entire plan in one pass.** The preflight executor checks every phase, task, and prose region and does not stop at the first defect.
+- **Classify every defect as trivial or substantive.** Trivial defects are a stale or misspelled anchor, symbol, heading, or path whose intent is unambiguous; a citation correction, including removal of a G11 line-number or G12 commit-SHA citation; a typo; a literal-formatting defect that does not change what is asserted; and an evidence filename spelling. Substantive defects are a missing or extra task; a wrong file set or design; an acceptance criterion with no implementing task; an acceptance condition whose correction changes what is asserted; a task-ordering error; and a scope-boundary violation.
+- **Fix trivial defects in place, in task text only.** The preflight executor edits task text and plan preamble in the same plan file and never adds, removes, or reorders tasks. Each fix is recorded in `<FEATURE>/evidence/other/preflight-fixes.<timestamp>.md`.
+- **Return substantive defects only, all of them.** `PREFLIGHT: REVISIONS REQUIRED` is returned only when at least one substantive defect remains, and it lists every one. `PREFLIGHT: ALL CLEAR` may follow in-place fixes.
+
+Output format. After the `PREFLIGHT:` signal, the return carries one line per defect:
+
+- `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>`
+- `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>`
+- `preflight-fix-record: <path>` when at least one fix was made.
+
+`PREFLIGHT: ALL CLEAR` carries no `PREFLIGHT-DEFECT:` line, and `PREFLIGHT: REVISIONS REQUIRED` carries at least one.
+
+At most one return. On `PREFLIGHT: REVISIONS REQUIRED`, the orchestrator delegates one planner revision carrying the full `PREFLIGHT-DEFECT:` list and runs one more preflight. If that preflight still reports a substantive defect, the orchestrator halts with `blocked_reason: "validator_failed"` during planning, or records `final_status: "blocked_preflight_iteration_limit"` in a remediation cycle.
+
 ## Validator Gate (Mandatory)
 
 Before a plan can be treated as approved:
@@ -159,15 +192,17 @@ Before a plan can be treated as approved:
 - reject the plan if that validator exits non-zero,
 - do not treat human-readable summaries as a substitute for validator success.
 
+The validator applies the acceptance-gate rules of `.claude/rules/plan-acceptance-gates.md`. G1 through G9 judge the commands a plan states as acceptance conditions; G10 reports a SCRATCH definition not namespaced by issue number; and the document-level rules G11, G12, and G13 report a line-number citation, a commit-SHA citation, and a plan above 40 tasks or 400 lines without a non-empty `## Size Justification` section. The complete shipped set is therefore G1 through G13. The installed MCP validator applies G11 through G13 only after the extension release that carries them is installed; until then, validate a plan with the repository's Python CLI `scripts/dev_tools/validate_orchestration_artifacts.py` and its `plan` subcommand, as the `execution-environment` skill states.
+
 ## Plan-Path Continuity Contract (Mandatory)
 
 When a caller provides an explicit target plan file path (for example `${plan-path}` or `${file}`):
 
 - Planner MUST update that exact file in place.
-- Planner MUST reuse the same file for all preflight revision iterations.
+- Planner MUST reuse the same file for the single permitted preflight revision.
 - Planner MUST NOT create additional timestamped sibling files (for example `plan.<timestamp>.md`) during the same planning cycle.
 
-If the provided path does not exist, it may be created once, then reused for all subsequent revisions in that cycle.
+If the provided path does not exist, it may be created once, then reused for the single permitted revision in that cycle.
 
 ## Mode source precedence (Mandatory)
 

package/resources/customizations/.github/skills/csharp-change-budget-router/SKILL.md

@@ -28,7 +28,7 @@ When routed through `csharp-orchestrator`, small path still requires lifecycle s
 - promote potential item to GitHub issue with `--work-mode minor-audit`,
 - create active feature folder with `--work-mode minor-audit`,
 - delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,
-- require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`,
+- require single-pass `atomic_executor` preflight ending in `PREFLIGHT: ALL CLEAR` (at most one return to the planner),
 - execute Phase 0 only via atomic_executor before branching,
 - run reduced small-audit after implementation and QC.
 

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

@@ -0,0 +1,134 @@
+---
+name: execution-environment
+description: 'Execution-environment brief for research, planning, preflight, execution, and orchestration. Use before planning or delegating work so tool routes, command-text restrictions, the batch budget, hook context, CI shape, contract tests, evidence rules, coverage and file-size gates, and test-isolation checks are known and are not restated in plans.'
+---
+
+# Execution-Environment Brief
+
+## Purpose and Maintenance
+
+This brief states the environment facts that every researcher, planner, preflight executor, executor, and orchestrator needs before work starts. Plans reference this brief instead of restating its content; a plan that restates a tool route, a launcher, or a command-text restriction duplicates text that goes stale when this brief changes.
+
+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/...`).
+
+## 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.
+- `atomic-planner` has no Bash. It has Read, Grep, Glob, Edit, Write, and `mcp__drm-copilot__validate_orchestration_artifacts`, so it can validate a plan with the installed validator before handoff but cannot run any toolchain command.
+- `task-researcher` has Read, Grep, Glob, WebFetch, and Write. It cannot run `git show` or `gh`; facts that need either are marked for the orchestrator to confirm.
+- `orchestrator` and the main session running the `orchestrate` skill have Bash, the PoshQC and validation MCP tools, and the `Agent` tool. Only they can delegate, so any step that needs a further agent run is orchestrator-owned.
+- PowerShell for the executor therefore runs through the `mcp__drm-copilot__run_poshqc_*` tools or through a `sh` launcher script stored under `SCRATCH` that invokes PowerShell 7 from inside the script file.
+
+## Command-Text Restrictions
+
+Two separate mechanisms restrict Bash command text. They are kept apart here because they have different causes and different fixes.
+
+- **Worktree isolation guard (Claude Code runtime behavior, not a repository hook).** Inside an agent-isolated worktree, the Claude Code runtime refuses Bash command text it cannot show stays inside the worktree. Observed refusals include text containing `pwsh`, `bash`, or `wsl`, heredocs, `printf --`, a `cd <path> &&` prefix before `git`, `git -C <other worktree>`, embedded `jq` filter strings, an unquoted shell variable in an option position, and loops or other compound constructs around `sh`. Text that passes includes `sh <file>.sh` with a literal path, `npx`, `poetry run python <script>`, `gh`, worktree-scoped `git`, and `git commit -F <file>`. No file under `.claude/hooks/` implements this guard, and no settings file registers it.
+- **Repository hooks.** `.claude/hooks/validate-bash.ps1` (`.codex/hooks/validate-bash.ps1` for Codex; functions `Get-BlockedBashPattern`, `Get-CdChainedReadCommandMatch`, `Get-BashBlockReason`) denies destructive patterns (`rm -rf`, forced pushes, `git reset --hard`, recursive forced removal) and a `cd` followed later in the same command by a file-reading command such as `grep`, `cat`, `head`, `tail`, `less`, `more`, `awk`, or `sed -n`. `.claude/hooks/enforce-parallel-worktree-removal-gate.ps1` denies the literal worktree-removal command anywhere in a command.
+- A multi-line `poetry run python -c` program exits 0 without running. Put Python helpers in a file under `SCRATCH` and run the file.
+
+## PowerShell Route and PoshQC MCP Limits
+
+- 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.
+- `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
+
+- In direct mode the batch-budget hooks allow at most three distinct production files per kind in one session: the fourth distinct non-test PowerShell file is denied with `POWERSHELL_LARGE_PATH_REQUIRED` and the fourth distinct non-test Python file with `PYTHON_LARGE_PATH_REQUIRED` (`.claude/hooks/enforce-powershell-batch-budget.ps1` and `.claude/hooks/enforce-python-batch-budget.ps1`; Codex copies under `.codex/hooks/`). Test files never count.
+- Exemption: the cap does not apply when `artifacts/orchestration/orchestrator-state.json` in the worktree that holds the hook script selects the `large`, `remediation`, or `preparation` route and is not terminal (`Test-BatchBudgetLargePathRoute` in `.claude/hooks/enforce-batch-budget-route.ps1`). An isolated subagent worktree has no checkpoint, because `artifacts/` is gitignored, so direct mode applies there.
+- Bundle mirror copies under `extensions/drm-copilot/resources/` are production files and count against the cap.
+- A scratch `.ps1` file counts when it resolves inside the worktree root. Files under `SCRATCH`, which is outside the worktree root, are discarded without consuming a slot.
+- Only `Write` and `Edit` calls are seen (the hook matcher is `Write|Edit`). Files written by Bash, by a copy script, or by a generator are not seen.
+- Budget state is kept per session under `.claude/state/`; there is no automatic reset.
+
+## Hook Execution Context
+
+- 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.
+- 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
+
+- Every `mcp__drm-copilot__*` tool runs the installed extension, not the branch. `validate_orchestration_artifacts` applies the installed rule set, so validator rules added on a branch apply through MCP only after the extension release that carries them is installed.
+- Branch-current plan validation runs the repository's Python CLI `scripts/dev_tools/validate_orchestration_artifacts.py` with its `plan` subcommand, through Poetry in module form.
+- A push-down served by the MCP tools writes the installed extension's bundled payload; a repository-side edit under `extensions/drm-copilot/resources/` changes that payload only after a rebuild and reinstall.
+
+## 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.10, 3.11, 3.12, and 3.13 (`_quality-checks.yml`: Black check, Ruff, Pyright, the Codex generator `--check`, the tier classification, Pytest with line and branch coverage, and the coverage-threshold check on the JSON report totals); `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.
+- 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 when 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 an ancestor of the current head, is on the allowlist `config/ci-docs-only-paths.json`. A path is allowlisted when it starts with `docs/features/active/`, `docs/features/completed/`, `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, a missing or non-ancestor base, 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.
+- 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.10)`, `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.
+- 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
+
+- A test that reads gitignored `artifacts/` state passes only on a worktree that holds that state; CI has none.
+- A fixture rooted at a drive letter or a `C:/workspace` path fails `path.isAbsolute` and path joins on Linux.
+- `_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.
+
+## Contract Tests That Pin Mirrored Files
+
+Run these after editing any mirrored or bundled file; each is under `tests/scripts/dev_tools/` unless named otherwise.
+
+- `test_push_down_claude_resource_contracts.py` and `test_push_down_codex_and_agents_resource_contracts.py`: every distributable `.claude`, `.agents`, and `.codex` file exists in the bundle with equal text.
+- `test_push_down_claude_pack_manifest_completeness.py` and `test_push_down_codex_and_agents_pack_manifest_completeness.py`: every bundled file is listed in a pack manifest.
+- The Codex generator check: `scripts/dev_tools/generate_codex_agent_variants.py` run in module form with `--check` (base agents are hand-edited; variants, bundle copies, and the Codex `core.json` are generated).
+- `test_codex_agent_wrapper_contracts.py` and `test_codex_handoff_contract_parity.py`: pinned Codex agent fragments and handoff parity.
+- `test_claude_rules_frontmatter.py`: rule `paths:` scopes and that every preloaded skill exists.
+- `parallel_orchestrator_surface_expectations.py` (`PINNED_FROZEN_SURFACE_HASHES`): byte hashes of frozen orchestration surfaces, including `.claude/skills/epic-orchestrate/SKILL.md` and `.claude/agents/epic-orchestrator.md`.
+- `test_quality_checks_workflow_contracts.py`: workflow step conditions.
+- `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.
+
+## Preflight Defect Classes the Validator Cannot See
+
+These pass every validator rule and are found only by reading the plan against the tree:
+
+- `git grep` against a file the plan creates (untracked, so invisible to `git grep`); a search pattern beginning with `-` that is not passed through `-e`.
+- A checkbox diff-pair assertion against a file the plan adds, and a CRLF fixture under the `eol=lf` attribute rule.
+- A new TypeScript production file without its own `coverageThreshold` entry in `extensions/drm-copilot/jest.config.cjs`, whose threshold map has per-file entries only and no `global` key.
+- A per-file coverage floor asserted for code that the tests replace with blanket mocks.
+- Batch-budget exhaustion across a session, and an acceptance condition that depends on a branch hook being exercised by an isolated subagent.
+- `origin/main` advancing during planning: scope diffs anchor on the merge base of `origin/main` and `HEAD`, never on `origin/main` itself.
+- `Measure-Object -Line` counts non-empty lines only; physical line counts use `wc -l` or `@(Get-Content -LiteralPath <path>).Count`.
+- A coverage argument written as a filesystem path measures nothing; the dotted module form is required, and branch figures come from the JSON report, not the combined terminal column.
+- A task that changes the observable behavior of an existing function, script, fixture, or test stub (signature, argv, output, exit status, or written files) while the tests that assert that behavior are outside the task's file set: those tests fail once the change lands, and the plan's own acceptance cannot be met. Preflight searches the test tree for the changed symbol, the file name, and the asserted output, and confirms that the task names each matching test with its disposition (unchanged because unaffected, or updated with the reason).
+- A plan that alters a fact this brief states (it adds or renames a CI job, changes a required status context, a tool route, or a batch-budget rule) with no task that updates the brief in the same change, in all six byte-identical copies: the plan then breaks the maintenance rule in `## Purpose and Maintenance`. Preflight compares each task's changes against the facts this brief states and confirms that a brief-update task exists and that the plan's `Mirror parity` Pre-Mortem bullet names it.
+
+## Evidence and Documentation Rules
+
+- Evidence lives under `<FEATURE>/evidence/<kind>/` with kinds `baseline`, `regression-testing`, `qa-gates`, `other`, `issue-updates`, and `remediation-baseline` (`.claude/skills/evidence-and-timestamp-conventions/SKILL.md`; enforced by `.claude/hooks/enforce-evidence-locations.ps1`).
+- Evidence filenames carry the UTC time of the write, read from the clock, in the `yyyy-MM-ddTHH-mm` shape; a consumer selects the lexicographically greatest `<name>.*.md`. Plan files are stamped by the feature-folder tooling in America/New_York.
+- Every command-step artifact carries `Timestamp:`, `Command:`, `EXIT_CODE:`, and `Output Summary:`. No artifact records an absolute path, a host name, or a session scratchpad path; scratch locations are recorded as the token `SCRATCH`.
+- `SCRATCH` is `<session scratchpad>/issue-<issue-num>/`, and scratch file names start with `issue-<issue-num>-`.
+- `.github/workflows/_docs-validation.yml` checks only that `README.md` is present and non-empty and that `LICENSE` exists, and it warns when two instruction files are missing. There is no Markdown lint or link check in CI.
+
+## Coverage and File-Size Gates
+
+- Line coverage of at least 85% and branch coverage of at least 75% apply per changed production file in Python and TypeScript. PowerShell has a line threshold of 85% and no branch gate, because Pester does not measure branch coverage. No production file may be excluded from measurement.
+- 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.
+- No production, test, or reusable script file exceeds 500 physical lines; Markdown is exempt. Files at or near the limit are not extended; new logic goes into a new module and a new test file.
+
+## 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.
+- 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.

package/resources/customizations/.github/skills/powershell-change-budget-router/SKILL.md

@@ -28,7 +28,7 @@ When routed through `powershell-orchestrator`, small path still requires lifecyc
 - promote potential item to GitHub issue with `--work-mode minor-audit`,
 - create active feature folder with `--work-mode minor-audit`,
 - delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,
-- require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`,
+- require single-pass `atomic_executor` preflight ending in `PREFLIGHT: ALL CLEAR` (at most one return to the planner),
 - execute Phase 0 only via `atomic_executor` before branching,
 - run reduced small-audit after implementation and QC.