@danmoisan/drm-copilot-mcp 1.1.19 → 1.1.20

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

@@ -12,6 +12,7 @@ Planning-only workflow skill for generating executor-ready plans.
 Always apply:
 - `policy-compliance-order`
 - `atomic-plan-contract`
+- `execution-environment`
 
 ## Role
 
@@ -26,7 +27,8 @@ Use `atomic-plan-contract` as the source of truth for:
 - Phase 0 requirements,
 - baseline evidence tasks,
 - final QA requirements,
-- preflight validation loop behavior.
+- the design-level plan contract and the `## Pre-Mortem` section,
+- single-pass preflight behavior.
 
 Each task must be:
 - atomic,
@@ -49,10 +51,10 @@ Concurrent child runs in one session share one session scratchpad, so every plan
 Before a plan is finalized:
 
 1. Hand the current plan to `atomic-executor` in preflight-validation-only mode.
-2. If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same file.
-3. Repeat until preflight returns `PREFLIGHT: ALL CLEAR`.
+2. If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, apply every listed `PREFLIGHT-DEFECT:` change to the same file in one revision.
+3. A plan returns to the planner at most once. If the confirming preflight still reports a substantive defect, the orchestrator halts with `blocked_reason: "validator_failed"`; do not open another revision.
 
-Do not finalize a plan before preflight clears it.
+Do not finalize a plan before preflight clears it. Every plan follows `## Design-Level Plan Contract (Mandatory)` in `atomic-plan-contract`, including the `## Pre-Mortem` section and the final-phase self-review task.
 
 ### Enforced Handoff Contract
 
@@ -62,7 +64,7 @@ Do not finalize a plan before preflight clears it.
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 - If revisions are required, `atomic-executor` MUST provide a precise plan delta that can be applied to the same plan file.
-- Continue the validate -> revise -> validate loop until `PREFLIGHT: ALL CLEAR`.
+- Preflight is single-pass: trivial defects are fixed in place by `atomic-executor`, and only substantive defects return, at most once.
 - Do not treat a partial summary as a valid substitute for the exact preflight signal.
 - If the required `atomic-executor` handoff cannot be started or completed, stop and report blocked state; do not self-approve the plan.
 - Before reporting completion, the target plan MUST pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`.
@@ -84,7 +86,7 @@ Forbidden writes:
 When a caller provides an explicit target plan path:
 
 - update that exact file in place,
-- reuse that same file for all preflight revision iterations,
+- reuse that same file for the single permitted preflight revision,
 - do not create additional sibling `plan.*.md` files during the same planning cycle.
 
 ## Determinism Gates

package/resources/codex-and-agents-customizations/.agents/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.
 
@@ -69,7 +69,7 @@ In all modes, per-batch budget remains: at most **3 production files** and **3 t
 When `csharp-typed-engineer` runs in orchestrator handoff mode, it must execute the following delegation chain and must not bypass it with direct implementation:
 
 1. Delegate to `atomic_planner` for an architecture plus testability plan only (no edits).
-2. Require planner output to include final `PREFLIGHT: ALL CLEAR` from the preflight validation loop.
+2. Require planner output to include final `PREFLIGHT: ALL CLEAR` from single-pass preflight (at most one return to the planner).
 3. Delegate plan execution to `atomic_executor`.
 4. Delegate the final QA gate to `atomic_executor` per `csharp-qa-gate`.
 5. Delegate post-implementation review to `feature-review` per `feature-review-workflow`.

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

@@ -169,7 +169,14 @@ On resume, reconcile the checkpoint against `git worktree list --porcelain`, bra
 After every child is merged or its worktree removed, delegate final PR authoring to the routed
 `pr-author` profile, refresh PR context through the MCP surface, run the CI-green procedure,
 record the current head SHA and successful conclusion, and merge the integration branch to
-`main` only through the merge gate.
+`main` only through the merge gate. A zero exit from `gh pr merge` does not prove a merge when
+`main` uses a merge queue: read the pull-request state (`state`, `mergeCommit`, `mergedAt`,
+`isInMergeQueue`, and `autoMergeRequest`) every 30 seconds for at most 90 minutes until it is
+`MERGED`, then run `git fetch origin main` and
+`git merge-base --is-ancestor <merge-commit-oid> origin/main`. The final merge SHA is recorded
+only after the merge is confirmed by polling and ancestry check. When the 90 minutes are
+exhausted, report `awaiting_merge_queue` and do not record a merge; never re-issue the merge in
+a loop (issue #952).
 
 ## Completion
 

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

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/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/.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:
@@ -106,19 +109,20 @@ Concurrent child runs in one session share one session scratchpad, so every scra
 
 ## 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:
@@ -106,19 +109,20 @@ Concurrent child runs in one session share one session scratchpad, so every scra
 
 ## 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:
@@ -106,19 +109,20 @@ Concurrent child runs in one session share one session scratchpad, so every scra
 
 ## 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:
@@ -106,19 +109,20 @@ Concurrent child runs in one session share one session scratchpad, so every scra
 
 ## 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:
@@ -106,19 +109,20 @@ Concurrent child runs in one session share one session scratchpad, so every scra
 
 ## 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.