@danmoisan/drm-copilot-mcp 1.1.18 → 1.1.20

package/resources/codex-and-agents-customizations/.agents/skills/orchestrate/SKILL.md

@@ -27,6 +27,7 @@ Before proceeding, the orchestrator must:
 1. Read `AGENTS.md` for repository tone policy and architectural context.
 2. Read applicable `.agents/skills/` files for the languages in scope.
 3. Read the policy files listed in the compliance reading order section of `AGENTS.md`.
+4. Read the `execution-environment` skill (`.agents/skills/execution-environment/SKILL.md`) before delegating any worker. Delegation prompts and plans reference that brief instead of restating tool routes, command-text restrictions, the batch budget, hook context, or CI shape.
 
 ## Checkpoint Handling
 
@@ -121,7 +122,11 @@ route.
 - Copy the exact required agents, skills, and MCP tools from the central `preparation` route.
 - Perform promotion through the MCP surface, research, `spec.md`, `user-story.md`, atomic
   planning, and atomic-executor preflight only.
-- Iterate revisions against the same plan path until `PREFLIGHT: ALL CLEAR`.
+- Run single-pass preflight against the same plan path (`### Single-Pass Preflight` in
+  `atomic-plan-contract`): trivial defects are fixed in place, the plan returns to the planner at
+  most once with the full `PREFLIGHT-DEFECT:` list, and a second substantive result halts with
+  `blocked_reason: "validator_failed"`. The preflight directive goes in the delegation prompt,
+  never in the plan file.
 - Commit the prepared feature folder and approved plan to the worktree branch.
 - Stop with `completed_steps` containing `S3_promotion` and `S4_atomic_planning`,
   `next_step: "S5_atomic_execution"`, all execution-through-CI step statuses exactly
@@ -422,7 +427,7 @@ After each `feature-reviewer` delegation returns:
    Halt precedence: human_decision_required > policy_hold > external_dependency
 
 8. If the result is `REVIEW_STATUS: AWAITING_CI`, require `REMEDIATION_PLAN: NONE` and wait: set `blocked_reason: "awaiting_ci"`, set `next_step` to the step that re-checks (`S7_feature_review` for a review-time wait, `S9_ci_green` for a CI poll timeout), record no `human_interaction.requirements[]` entry for the wait, write no cycle, and create no remediation plan. Poll within the existing bounded CI interval and timeout; when the bound is exhausted, persist and stop. On resume, set `blocked_reason: "none"` and re-run the named step. For a review-time wait, the awaited workflow is named in the finding's `Remediability-Evidence:` line.
-9. A CI Green Gate poll timeout is recorded as a finding with `Remediability: awaiting_ci` and follows the wait path; a failed required check stays `autonomous` and enters the remediation loop.
+9. A CI Green Gate poll timeout is recorded as a finding with `Remediability: awaiting_ci` and follows the wait path; a failed check stays `autonomous` and enters the remediation loop.
 
 ## Remediation Loop (R1–R5)
 
@@ -430,8 +435,13 @@ A bounded loop consisting of five steps. The attempt count is `remediation_loop.
 
 Cycle accounting: a remediation attempt is complete when R3 execution finished (`execution_status: "complete"`) and the pre-R4 commit recorded a non-empty change set; only then set `candidate_applied: true` on that cycle and increment `completed_attempts`. A cycle that ends without a candidate (execution not started, execution failed, or an empty staged change set) records `candidate_applied: false` and consumes no number. It is followed by at most one re-plan under the same number when the executor output identifies an autonomous plan defect; otherwise reclassify the blocker (typically `external_dependency`) and halt. Two consecutive no-candidate cycles halt with `step6_status: "blocked_remediation_loop_limit"`.
 
+Remediation mode. Each cycle's `remediation-inputs.<timestamp>.md` carries exactly one line `Remediation-Mode: proportionate` or `Remediation-Mode: design`. A cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; otherwise it is design. CI-failure findings are normally proportionate.
+
+- **Proportionate cycle.** One `atomic-planner` delegation produces a short plan with a `## Pre-Mortem` section and a final self-review task; R2 and R3 then run as one `atomic-executor` delegation that performs single-pass preflight with in-place trivial fixes and executes the plan. Record `preflight: {iterations: 1, final_status: "clear"}` before `execution_status`. A substantive defect stops the run with `BLOCKED at preflight (before [P0-T1])` and no checked task; rewrite the mode line to `Remediation-Mode: design` and continue as a design cycle with one planner revision.
+- **Design cycle.** R1 to R5 run as listed below, with R2 under the single-pass preflight and at-most-one-return rule.
+
 - **R1 — Remediation plan of record:** Use the exact `REMEDIATION_PLAN: <path>` returned by the review as the starting plan of record for the loop.
-- **R2 — Preflight clearance:** Delegate to `atomic-executor` for precondition validation only (no implementation). If the executor does not return `PREFLIGHT: ALL CLEAR`, return to R1 by re-delegating to `atomic-planner` against the same remediation-plan path with the required-changes output from the executor. Only after `PREFLIGHT: ALL CLEAR` may the orchestrator advance to R3.
+- **R2 — Preflight clearance:** Delegate to `atomic-executor` for precondition validation only (no implementation), with the preflight directive in the delegation prompt. Trivial defects are fixed in place. If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, return to R1 once by re-delegating to `atomic-planner` against the same remediation-plan path with the full `PREFLIGHT-DEFECT:` list; if the following preflight still reports a substantive defect, record `final_status: "blocked_preflight_iteration_limit"` on the cycle and halt. Only after `PREFLIGHT: ALL CLEAR` may the orchestrator advance to R3.
 - **R3 — Remediation execution:** Delegate to `atomic-executor` with full execution authorization. Each task's toolchain loop (format → lint → type-check → test) is mandatory; no skipping.
 - **Pre-R4 commit:** Stage all changes (`git add -A`), run MCP tool `collect_commit_context`, delegate to `commit_steward` using the resulting artifact, and commit with the generated message. Advance to R4 only after a successful commit.
 - **R4 — Re-audit:** Refresh PR context via MCP tool `collect_pr_context`, then delegate to `feature-reviewer` with the same inputs as the original review (resolved base branch, feature folder, refreshed PR context artifacts, acceptance-criteria source). No scope narrowing. The canonical issue number line must be included.
@@ -453,11 +463,20 @@ If a subagent artifact references a different issue number, the orchestrator rej
 ## CI Green Gate
 
 Before PR/DONE completion, the orchestrator must observe the live PR head SHA
-and required GitHub checks through `gh`. The checkpoint must record the checked
-head SHA and CI result. DONE is blocked unless the required checks pass for the
-current PR head SHA.
+and every GitHub check on that head SHA through `gh`. The checkpoint must record
+the checked head SHA and CI result. DONE is blocked unless every check on the
+current PR head SHA passed or was skipped.
+
+Gate procedure:
+
+1. Resolve the live PR head SHA and the PR base branch with `gh pr view --json headRefOid,baseRefName`.
+2. Invoke `gh pr checks --json bucket,name,state,link,workflow` against that head SHA. The query covers every check on the head SHA for every PR, whether or not branch protection marks the check as required.
+3. Parse the JSON by running `pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-CiGateParser.ps1 -ChecksJson <checks-json> -HeadSha <head-sha>`, appending `-RequireWorkflow CI` when the PR base branch is an `epic/<slug>-integration` branch. The parser derives `ci_gate.conclusion` over every queried check: `success` when every check passed or was skipped, `failure` when any check failed or was cancelled, and `pending` when any check is still in progress.
+4. Epic-child rule: when the PR base branch is an `epic/<slug>-integration` branch, an empty check list is not accepted as green. Every check returned by the unfiltered query counts: a failing or cancelled non-`CI` check fails the gate, and a pending one keeps it pending. With `-RequireWorkflow CI`, the parser never returns `success` until at least one passing `CI` check is observed.
+5. No-checks rule: when `gh pr checks` fails with a `no checks reported` error, that error is never treated as green for any PR. On an epic child, the parser runs with `-ChecksJson '[]'` and `-RequireWorkflow CI`, which returns `pending`; on any other PR the gate stays `pending` within the bounded poll.
+6. Parser-absent rule: when `.claude/lib/ci-gate/Invoke-CiGateParser.ps1` does not exist in the repository, the orchestrator does not derive `success` by hand; it must stop and persist blocked state before PR/DONE completion.
 
-The checkpoint records the CI result in a top-level `ci_gate` object with the required keys `conclusion`, `head_sha`, and `verified_at`. `conclusion` is one of `success`, `failure`, or `pending`; `head_sha` is the PR head SHA the required checks were observed against; `verified_at` is the ISO-8601 time at which this gate (S9) recorded the result. DONE requires `ci_gate.conclusion` equal to `success` and `ci_gate.head_sha` equal to the current PR head SHA. The key set is defined by `CI_GATE_KEYS` in `scripts/dev_tools/validate_orchestrator_state.py`, and the TypeScript MCP validator used by the Codex runtime requires the same keys.
+The checkpoint records the CI result in a top-level `ci_gate` object with the required keys `conclusion`, `head_sha`, and `verified_at`. `conclusion` is one of `success`, `failure`, or `pending`; `head_sha` is the PR head SHA the queried checks were observed against; `verified_at` is the ISO-8601 time at which this gate (S9) recorded the result. DONE requires `ci_gate.conclusion` equal to `success` and `ci_gate.head_sha` equal to the current PR head SHA. The key set is defined by `CI_GATE_KEYS` in `scripts/dev_tools/validate_orchestrator_state.py`, and the TypeScript MCP validator used by the Codex runtime requires the same keys.
 
 The checkpoint records the pull request in a top-level `pr_gate` object with the keys `pr_number`, `pr_url`, `head_branch`, and `head_sha`. The key set is defined by `PR_GATE_KEYS` in `scripts/dev_tools/_orchestrator_state_routing.py`.
 
@@ -473,7 +492,7 @@ The orchestrator must not create a PR, push a branch for PR purposes, or report
 2. The AC verification artifact (`p14-acceptance-criteria-checkoff.md` or equivalent) confirms all acceptance criteria pass.
 3. The mandatory toolchain passed in its most recent run on the branch (no linting/type-check/test failures).
 4. The checkpoint `next_step` is `S8_create_pr`.
-5. The required CI checks pass for the current PR head SHA.
+5. Every check on the current PR head SHA passed or was skipped (`ci_gate.conclusion` is `success`).
 
 This gate is non-negotiable. Each condition is independently verified before PR creation proceeds.
 

package/resources/codex-and-agents-customizations/.agents/skills/orchestrator-workflow/SKILL.md

@@ -436,7 +436,7 @@ Do not claim mission completion until all of the following are true:
 - any required remediation loop run also includes a remediation execution receipt, a remediation commit receipt, and a final `REVIEW_STATUS: PASS`
 - validator-backed checks for the approved plan, policy audit, code review, feature audit, and checkpoint state pass
 - the canonical checkpoint passes `validate_orchestration_artifacts` with `artifact_type: "orchestrator-state"`, `require_complete: true`, `require_codex_topology: true`, and `require_codex_model_routing: true`
-- required GitHub checks pass for the current PR head SHA before PR/DONE completion
+- every GitHub check on the current PR head SHA passed or was skipped before PR/DONE completion
 
 ## Hard Constraints
 

package/resources/codex-and-agents-customizations/.agents/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.
 

package/resources/codex-and-agents-customizations/.agents/skills/python-change-budget-router/SKILL.md

@@ -40,7 +40,7 @@ When routed through the orchestrator, the small path still requires lifecycle sc
 - promote the potential item to a GitHub issue with `--work-mode minor-audit`,
 - create the 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 the reduced small-audit after implementation and QC.
 

package/resources/codex-and-agents-customizations/.agents/skills/quality-tiers/SKILL.md

@@ -9,19 +9,21 @@ Source: legacy Claude rule `quality-tiers`.
 
 # Module Rigor Tiers
 
-This rule defines the T1–T4 module rigor tier system used by all CI gates in this repository. The tier definitions and gate matrix in this document are the tier system's source of truth; the file `quality-tiers.yml` at the repository root maps every project to a tier. Adding a project without a tier classification fails CI.
+Applicability: this skill (`.agents/skills/quality-tiers/SKILL.md`) applies only when `quality-tiers.yml` exists at the repository root, which indicates that the repository has adopted module rigor tiers. When that file is absent, there is no tier classification requirement, no `tier-classification` CI stage, and no tier-dependent gate (the escape-hatch limits, property-test density, mutation score, contract-bump rule, determinism retry rate, golden tests, and E2E suite scope in the Tier-dependent table below), and the absence of `quality-tiers.yml` is not a defect. The coverage defaults listed under Uniform across all tiers do not depend on tier adoption; their precedence is stated in that section.
+
+When `quality-tiers.yml` exists, this skill defines the T1–T4 module rigor tier system used by the repository's CI gates, and the tier definitions and gate matrix in this document are the tier system's source of truth.
 
 ## Tiers
 
-- **T1 — Critical.** Behavior bugs cause silent data loss, model drift, or security holes. Examples (No-COM architecture): classifier engines (SpamBayes, Triage), ToDo ID allocator and hierarchy operations, Graph extended-properties adapter, auth/token handling, host-agnostic command bus.
-- **T2 — Core.** Bugs cause feature regressions but not data loss. Examples: `TaskMaster.Domain`, `TaskMaster.Application`, mail-item DTOs, settings store abstraction, schema definitions.
-- **T3 — Adapters & UI.** Glue around APIs the team does not own. Examples: Outlook task pane UI, Office.js wrappers, Microsoft Graph SDK wrappers, persistence I/O.
+- **T1 — Critical.** Behavior bugs cause silent data loss, model drift, or security holes. Examples: classifier and scoring engines, identifier allocators and hierarchy operations, adapters that write to an external system of record, authentication and token handling, command dispatch.
+- **T2 — Core.** Bugs cause feature regressions but not data loss. Examples: domain and application layers, data-transfer objects, settings store abstractions, schema definitions.
+- **T3 — Adapters & UI.** Glue around APIs the team does not own. Examples: user-interface surfaces, host-platform API wrappers, third-party API and SDK wrappers, persistence I/O.
 - **T4 — Scaffolding.** Examples: DI wiring, bootstrap, build scripts, dev tooling, generated code, manifests.
 
 ## Source of Truth
 
-- `quality-tiers.yml` at repo root maps every project to one tier.
-- The CI pipeline's `tier-classification` stage validates that every project entry has a tier and that no unclassified project exists. Adding a project without a tier classification fails CI.
+- When `quality-tiers.yml` exists at the repository root, it maps every project to one tier.
+- In a repository that runs a `tier-classification` CI stage, that stage validates that every project entry has a tier and that no unclassified project exists, and it fails CI for an unclassified project.
 
 ## Uniform-vs-Tier-Dependent Gate Matrix
 
@@ -29,6 +31,8 @@ Per Authoritative Decision #2, line and branch coverage thresholds are uniform a
 
 ### Uniform across all tiers (T1–T4)
 
+Threshold precedence: when the repository's root `AGENTS.md` states line or branch coverage thresholds, those thresholds govern; when `AGENTS.md` states none, thresholds stated in the repository's root `CLAUDE.md` govern. The 85% line and 75% branch figures are defaults that apply only when neither root `AGENTS.md` nor root `CLAUDE.md` states thresholds. This precedence applies to every restatement of these figures in other skills, agents, and rule files. Each metric falls back independently: when a root file states only a line threshold or only a branch threshold, that threshold governs its metric and the next source in this order, ending with the default, governs the other.
+
 - Format check: 100% pass.
 - Lint errors: 0.
 - Type errors: 0.
@@ -51,4 +55,4 @@ Per Authoritative Decision #2, line and branch coverage thresholds are uniform a
 
 ## Rationale (uniform coverage thresholds)
 
-High test coverage is a fundamental quality-control design choice that enables autonomous agentic development and trust in the work product. For that reason, line coverage >= 85% applies uniformly across T1–T4 to every coverage language, and branch coverage >= 75% applies uniformly across T1–T4 to every language whose coverage tooling measures branch coverage; tier-specific lower coverage floors are not used in this repository. The branch threshold is not applied to PowerShell or bash because Pester and kcov do not measure branch coverage. That exemption is a capability limit on an unevaluable threshold, not a licence to exclude files from measurement: PowerShell and bash production files remain in the coverage denominator under the Coverage Exclusion Policy in `.agents/skills/general-unit-test/SKILL.md`.
+High test coverage is a fundamental quality-control design choice that enables autonomous agentic development and trust in the work product. For that reason, line coverage >= 85% applies uniformly across T1–T4 to every coverage language, and branch coverage >= 75% applies uniformly across T1–T4 to every language whose coverage tooling measures branch coverage; tier-specific lower coverage floors are not used. These figures are defaults under the threshold precedence stated above: a root `AGENTS.md` or root `CLAUDE.md` that states coverage thresholds overrides them. Each metric falls back independently, so a root file that states only one of the two thresholds overrides only that one. The branch threshold is not applied to PowerShell or bash because Pester and kcov do not measure branch coverage. That exemption is a capability limit on an unevaluable threshold, not a licence to exclude files from measurement: PowerShell and bash production files remain in the coverage denominator under the Coverage Exclusion Policy in `.agents/skills/general-unit-test/SKILL.md`.

package/resources/codex-and-agents-customizations/.agents/skills/remediation-handoff-atomic-planner/SKILL.md

@@ -27,6 +27,9 @@ Remediation triggers only on blocking findings classified `autonomous`. Each blo
 Create `remediation/<timestamp>/remediation-inputs.md` (one timestamped `remediation/` folder per cycle; reaudit artifacts from a triggering or exit review live under the sibling `audit/<timestamp>/` folder, per the canonical pattern documented in the Claude-side `remediation-handoff-atomic-planner` skill) with:
 - Enumerated fix list with file paths, expected behavior, and verification commands.
 - A “do not do” list (no scope creep, no policy weakening, no silent skips).
+- Exactly one mode line, `Remediation-Mode: proportionate` or `Remediation-Mode: design`. The cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; otherwise it is design. CI-failure findings are normally proportionate.
+
+Proportionate cycle: one `atomic_planner` delegation writes a short plan with a `## Pre-Mortem` section and a final self-review task, and one `atomic_executor` delegation runs single-pass preflight with in-place trivial fixes and then executes it; `preflight: {iterations: 1, final_status: "clear"}` is recorded before `execution_status`. A substantive preflight defect stops that run with `BLOCKED at preflight (before [P0-T1])` and no checked task, and the cycle converts to design mode (the mode line is rewritten to `Remediation-Mode: design`) for one planner revision. Design cycle: the handoff below runs with the at-most-one-return rule.
 
 ## Plan Creation and Handoff
 
@@ -36,9 +39,10 @@ Create `remediation/<timestamp>/remediation-inputs.md` (one timestamped `remedia
    - `${file}` pointing to the remediation plan target file
 3) Require `atomic_planner` to output a deterministic, atomic plan with phases and `[P#-T#]` IDs.
 4) Require the same `${file}` path to be updated in place across all remediation-plan revisions in the same remediation loop.
-5) The caller owns the downstream clearance loop:
-   - hand the resulting remediation plan to `atomic_executor` in preflight-validation mode,
-   - if preflight returns `PREFLIGHT: REVISIONS REQUIRED`, re-delegate to `atomic_planner` against the same `${file}` path,
+5) The caller owns the downstream clearance step:
+   - hand the resulting remediation plan to `atomic_executor` in preflight-validation mode, with the preflight directive in the delegation prompt and never in the plan file; preflight is single-pass and fixes trivial defects in place,
+   - if preflight returns `PREFLIGHT: REVISIONS REQUIRED`, re-delegate to `atomic_planner` once against the same `${file}` path with the full `PREFLIGHT-DEFECT:` list, then run one confirming preflight,
+   - if the confirming preflight still reports a substantive defect, record `final_status: "blocked_preflight_iteration_limit"` and halt the cycle,
    - execute the remediation plan only after `PREFLIGHT: ALL CLEAR`.
 
 ## Context Package (When Required)

package/resources/codex-and-agents-customizations/.agents/skills/research-issue/SKILL.md

@@ -55,6 +55,12 @@ Create or update a single research file in the applicable tracked research root:
 - Propose a test strategy consistent with repository policy (unit tests for pure logic, integration seams).
 - Do not write test code; describe the strategy only.
 
+### 6. 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.
+- The `execution-environment` skill states the CI shape, contract tests, and isolation checks the section accounts for.
+
 ## Constraints
 
 - Research only. Do not implement changes.

package/resources/codex-and-agents-customizations/.agents/skills/translate-claude-to-codex/SKILL.md

@@ -282,7 +282,7 @@ Every completion response must include:
 | `.claude/agents/<name>.md` | `.codex/agents/<name>.toml` | model + sandbox OS-enforced; tools allowlist re-grounded |
 | `.claude/settings.json` `permissions` | `[permissions.<name>]` in `config.toml` | OS-enforced via sandbox; more expressive than Claude |
 | `.claude/hooks/*.ps1` (PreToolUse) | `[hooks] PreToolUse` + script | direct equivalent; exit 2 / permissionDecision deny |
-| `.claude/hooks/*.ps1` (SubagentStop, exit 1) | `[hooks] SubagentStop` + required CI check | degraded; CI status check is the hard gate |
+| `.claude/hooks/*.ps1` (SubagentStop, exit 2) | `[hooks] SubagentStop` + required CI check | degraded; CI status check is the hard gate |
 | `permissions.deny` (secrets) | `[permissions.<name>.filesystem]` deny | OS-enforced |
 
 ## Invocation Examples

package/resources/codex-and-agents-customizations/.agents-variants/csharp-legacy/skills/csharp/SKILL.md

@@ -15,8 +15,8 @@ This rule file summarizes the C#-specific policies for this repository.
 ## Toolchain
 
 1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Run `dotnet tool restore` first when the manifest tool has not been restored. Apply formatting with `dotnet tool run csharpier format .` and verify read-only with `dotnet tool run csharpier check .`. Always invoke through `dotnet tool run` so the manifest-pinned CSharpier version is used.
-2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`. `/t:Rebuild` is intentional for a warm local worktree: `/t:Build` can skip `CoreCompile` through MSBuild incrementality and exit 0 without running analyzers. CI may retain `/t:Build` on a cold checkout.
-3. **Type Checking — Nullable Analysis**: Compiler and nullable-flow diagnostics must pass with warnings as errors. Command: `msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:TreatWarningsAsErrors=true`. `/t:Rebuild` is required locally so compiler and nullable-flow diagnostics actually run. Projects opt into nullable per file with `#nullable enable`; do not pass `/p:Nullable=enable`, which opts every unannotated file in at once.
+2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild <solution>.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`. `/t:Rebuild` is intentional for a warm local worktree: `/t:Build` can skip `CoreCompile` through MSBuild incrementality and exit 0 without running analyzers. CI may retain `/t:Build` on a cold checkout.
+3. **Type Checking — Nullable Analysis**: Compiler and nullable-flow diagnostics must pass with warnings as errors. Command: `msbuild <solution>.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:TreatWarningsAsErrors=true`. `/t:Rebuild` is required locally so compiler and nullable-flow diagnostics actually run. Projects opt into nullable per file with `#nullable enable`; do not pass `/p:Nullable=enable`, which opts every unannotated file in at once.
 4. **Testing — MSTest + Moq + FluentAssertions**: Run tests with: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
 Run the toolchain in order: format → lint → type-check → test. Restart from step 1 if any step fails or changes files.

package/resources/codex-and-agents-customizations/.agents-variants/csharp-legacy/skills/csharp-qa-gate/SKILL.md

@@ -30,8 +30,8 @@ Before invoking this gate, the agent must have:
 Run the full toolchain in this exact order. If any step fails or modifies files, fix the issue and restart from step 1. Do not stop the loop until all four steps complete without errors in a single pass.
 
 1. `dotnet tool restore` (when the manifest tool has not been restored), then `dotnet tool run csharpier format .` to apply formatting and `dotnet tool run csharpier check .` to verify read-only.
-2. `msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. `msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:TreatWarningsAsErrors=true`
+2. `msbuild <solution>.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. `msbuild <solution>.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:TreatWarningsAsErrors=true`
 4. `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
 `/t:Rebuild /m` is intentional for the local gate: on a warm worktree `/t:Build` can skip `CoreCompile` through MSBuild incrementality and exit 0 without running analyzers or the compiler. CI may retain `/t:Build` on a cold checkout. Projects opt into nullable per file with `#nullable enable`; do not pass `/p:Nullable=enable`.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c1.toml

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - acceptance-criteria-tracking
+- execution-environment
 
 ---
 name: atomic-executor
@@ -35,11 +36,13 @@ tools:
   - "mcp__drm-copilot__run_poshqc_analyze"
   - "mcp__drm-copilot__run_poshqc_test"
   - "mcp__drm-copilot__run_poshqc_analyze_autofix"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
   - acceptance-criteria-tracking
+  - execution-environment
 memory: project
 hooks:
   SubagentStop:
@@ -93,21 +96,33 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
-When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.
+When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`. The preflight directive belongs in the delegation prompt, never in a plan file.
 
 - `PREFLIGHT: ALL CLEAR`
 - `PREFLIGHT: REVISIONS REQUIRED`
-- If revisions are required, include a precise plan delta that can be applied to the same plan file.
-- When returning `PREFLIGHT: REVISIONS REQUIRED`, automatically hand off back to `atomic-planner` and request that it apply the delta to the same plan file.
-- Continue the validate -> delta -> planner-revise -> validate loop until preflight can return `PREFLIGHT: ALL CLEAR`.
-- If the handoff loop cannot proceed or the required validator is unavailable, stop and report blocked state.
+- Review the entire plan in one pass and classify every defect as trivial or substantive, per `### Single-Pass Preflight` in `atomic-plan-contract`.
+- Fix trivial defects in place, in task text only; never add, remove, or reorder tasks. Report each fix as `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>` and name the fix record as `preflight-fix-record: <path>`.
+- If revisions are required, include a precise plan delta that can be applied to the same plan file, with one `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>` line per substantive defect.
+- Return the result to the caller. A plan returns to the planner at most once; the orchestrator routes the defect list for one revision and runs one confirming preflight.
+- If the required validator is unavailable, stop and report blocked state.
 - Before any `PREFLIGHT: ALL CLEAR` result is treated as approved, the target plan must pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`.
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`). When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c2.toml

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - acceptance-criteria-tracking
+- execution-environment
 
 ---
 name: atomic-executor
@@ -35,11 +36,13 @@ tools:
   - "mcp__drm-copilot__run_poshqc_analyze"
   - "mcp__drm-copilot__run_poshqc_test"
   - "mcp__drm-copilot__run_poshqc_analyze_autofix"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
   - acceptance-criteria-tracking
+  - execution-environment
 memory: project
 hooks:
   SubagentStop:
@@ -93,21 +96,33 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
-When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.
+When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`. The preflight directive belongs in the delegation prompt, never in a plan file.
 
 - `PREFLIGHT: ALL CLEAR`
 - `PREFLIGHT: REVISIONS REQUIRED`
-- If revisions are required, include a precise plan delta that can be applied to the same plan file.
-- When returning `PREFLIGHT: REVISIONS REQUIRED`, automatically hand off back to `atomic-planner` and request that it apply the delta to the same plan file.
-- Continue the validate -> delta -> planner-revise -> validate loop until preflight can return `PREFLIGHT: ALL CLEAR`.
-- If the handoff loop cannot proceed or the required validator is unavailable, stop and report blocked state.
+- Review the entire plan in one pass and classify every defect as trivial or substantive, per `### Single-Pass Preflight` in `atomic-plan-contract`.
+- Fix trivial defects in place, in task text only; never add, remove, or reorder tasks. Report each fix as `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>` and name the fix record as `preflight-fix-record: <path>`.
+- If revisions are required, include a precise plan delta that can be applied to the same plan file, with one `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>` line per substantive defect.
+- Return the result to the caller. A plan returns to the planner at most once; the orchestrator routes the defect list for one revision and runs one confirming preflight.
+- If the required validator is unavailable, stop and report blocked state.
 - Before any `PREFLIGHT: ALL CLEAR` result is treated as approved, the target plan must pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`.
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`). When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c3-elevated.toml

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - acceptance-criteria-tracking
+- execution-environment
 
 ---
 name: atomic-executor
@@ -35,11 +36,13 @@ tools:
   - "mcp__drm-copilot__run_poshqc_analyze"
   - "mcp__drm-copilot__run_poshqc_test"
   - "mcp__drm-copilot__run_poshqc_analyze_autofix"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
   - acceptance-criteria-tracking
+  - execution-environment
 memory: project
 hooks:
   SubagentStop:
@@ -93,21 +96,33 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
-When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.
+When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`. The preflight directive belongs in the delegation prompt, never in a plan file.
 
 - `PREFLIGHT: ALL CLEAR`
 - `PREFLIGHT: REVISIONS REQUIRED`
-- If revisions are required, include a precise plan delta that can be applied to the same plan file.
-- When returning `PREFLIGHT: REVISIONS REQUIRED`, automatically hand off back to `atomic-planner` and request that it apply the delta to the same plan file.
-- Continue the validate -> delta -> planner-revise -> validate loop until preflight can return `PREFLIGHT: ALL CLEAR`.
-- If the handoff loop cannot proceed or the required validator is unavailable, stop and report blocked state.
+- Review the entire plan in one pass and classify every defect as trivial or substantive, per `### Single-Pass Preflight` in `atomic-plan-contract`.
+- Fix trivial defects in place, in task text only; never add, remove, or reorder tasks. Report each fix as `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>` and name the fix record as `preflight-fix-record: <path>`.
+- If revisions are required, include a precise plan delta that can be applied to the same plan file, with one `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>` line per substantive defect.
+- Return the result to the caller. A plan returns to the planner at most once; the orchestrator routes the defect list for one revision and runs one confirming preflight.
+- If the required validator is unavailable, stop and report blocked state.
 - Before any `PREFLIGHT: ALL CLEAR` result is treated as approved, the target plan must pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`.
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`). When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c3.toml

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - acceptance-criteria-tracking
+- execution-environment
 
 ---
 name: atomic-executor
@@ -35,11 +36,13 @@ tools:
   - "mcp__drm-copilot__run_poshqc_analyze"
   - "mcp__drm-copilot__run_poshqc_test"
   - "mcp__drm-copilot__run_poshqc_analyze_autofix"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
   - acceptance-criteria-tracking
+  - execution-environment
 memory: project
 hooks:
   SubagentStop:
@@ -93,21 +96,33 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
-When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.
+When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`. The preflight directive belongs in the delegation prompt, never in a plan file.
 
 - `PREFLIGHT: ALL CLEAR`
 - `PREFLIGHT: REVISIONS REQUIRED`
-- If revisions are required, include a precise plan delta that can be applied to the same plan file.
-- When returning `PREFLIGHT: REVISIONS REQUIRED`, automatically hand off back to `atomic-planner` and request that it apply the delta to the same plan file.
-- Continue the validate -> delta -> planner-revise -> validate loop until preflight can return `PREFLIGHT: ALL CLEAR`.
-- If the handoff loop cannot proceed or the required validator is unavailable, stop and report blocked state.
+- Review the entire plan in one pass and classify every defect as trivial or substantive, per `### Single-Pass Preflight` in `atomic-plan-contract`.
+- Fix trivial defects in place, in task text only; never add, remove, or reorder tasks. Report each fix as `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>` and name the fix record as `preflight-fix-record: <path>`.
+- If revisions are required, include a precise plan delta that can be applied to the same plan file, with one `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>` line per substantive defect.
+- Return the result to the caller. A plan returns to the planner at most once; the orchestrator routes the defect list for one revision and runs one confirming preflight.
+- If the required validator is unavailable, stop and report blocked state.
 - Before any `PREFLIGHT: ALL CLEAR` result is treated as approved, the target plan must pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`.
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`). When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c4.toml

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - acceptance-criteria-tracking
+- execution-environment
 
 ---
 name: atomic-executor
@@ -35,11 +36,13 @@ tools:
   - "mcp__drm-copilot__run_poshqc_analyze"
   - "mcp__drm-copilot__run_poshqc_test"
   - "mcp__drm-copilot__run_poshqc_analyze_autofix"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
   - acceptance-criteria-tracking
+  - execution-environment
 memory: project
 hooks:
   SubagentStop:
@@ -93,21 +96,33 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
-When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.
+When the delegation prompt carries the directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`. The preflight directive belongs in the delegation prompt, never in a plan file.
 
 - `PREFLIGHT: ALL CLEAR`
 - `PREFLIGHT: REVISIONS REQUIRED`
-- If revisions are required, include a precise plan delta that can be applied to the same plan file.
-- When returning `PREFLIGHT: REVISIONS REQUIRED`, automatically hand off back to `atomic-planner` and request that it apply the delta to the same plan file.
-- Continue the validate -> delta -> planner-revise -> validate loop until preflight can return `PREFLIGHT: ALL CLEAR`.
-- If the handoff loop cannot proceed or the required validator is unavailable, stop and report blocked state.
+- Review the entire plan in one pass and classify every defect as trivial or substantive, per `### Single-Pass Preflight` in `atomic-plan-contract`.
+- Fix trivial defects in place, in task text only; never add, remove, or reorder tasks. Report each fix as `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>` and name the fix record as `preflight-fix-record: <path>`.
+- If revisions are required, include a precise plan delta that can be applied to the same plan file, with one `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>` line per substantive defect.
+- Return the result to the caller. A plan returns to the planner at most once; the orchestrator routes the defect list for one revision and runs one confirming preflight.
+- If the required validator is unavailable, stop and report blocked state.
 - Before any `PREFLIGHT: ALL CLEAR` result is treated as approved, the target plan must pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`.
 
 ## Blocking Protocol
 
-Blocking is permitted only during preflight validation (before `[P0-T1]`). When preflight-blocked:
+Blocking is permitted only during preflight validation (before `[P0-T1]`), including the preflight that opens a combined preflight-and-execute run of a proportionate remediation cycle. When preflight-blocked:
 
 1. State: `BLOCKED at preflight (before [P0-T1])`.
 2. Provide a short, concrete explanation of why.