@danmoisan/drm-copilot-mcp 1.1.18 → 1.1.20

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor.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-planner-c1.toml

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ---
 name: atomic-planner
@@ -23,10 +24,12 @@ tools:
   - "Edit(artifacts/**)"
   - "Write(docs/**)"
   - "Write(artifacts/**)"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
+  - execution-environment
 memory: project
 hooks:
   Stop:
@@ -66,6 +69,16 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files 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 plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- 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
 
 Before reporting completion, explicitly spawn the `atomic-executor` subagent for validation-only preflight. The delegated prompt MUST include the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
@@ -74,8 +87,8 @@ Before reporting completion, explicitly spawn the `atomic-executor` subagent for
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 - Treat executor preflight findings as binding plan defects.
-- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file using the executor's precise plan delta and re-run preflight.
-- Reuse the same target plan file for every preflight revision iteration in the same planning cycle.
+- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file once using the executor's precise plan delta and its full `PREFLIGHT-DEFECT:` list, and run one confirming preflight. Preflight is single-pass: trivial defects are fixed in place by the executor, and a plan returns to the planner at most once; a second substantive result halts with `blocked_reason: "validator_failed"`.
+- Reuse the same target plan file for the single permitted preflight revision in the same planning cycle.
 - 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>`.
 

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

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ---
 name: atomic-planner
@@ -23,10 +24,12 @@ tools:
   - "Edit(artifacts/**)"
   - "Write(docs/**)"
   - "Write(artifacts/**)"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
+  - execution-environment
 memory: project
 hooks:
   Stop:
@@ -66,6 +69,16 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files 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 plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- 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
 
 Before reporting completion, explicitly spawn the `atomic-executor` subagent for validation-only preflight. The delegated prompt MUST include the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
@@ -74,8 +87,8 @@ Before reporting completion, explicitly spawn the `atomic-executor` subagent for
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 - Treat executor preflight findings as binding plan defects.
-- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file using the executor's precise plan delta and re-run preflight.
-- Reuse the same target plan file for every preflight revision iteration in the same planning cycle.
+- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file once using the executor's precise plan delta and its full `PREFLIGHT-DEFECT:` list, and run one confirming preflight. Preflight is single-pass: trivial defects are fixed in place by the executor, and a plan returns to the planner at most once; a second substantive result halts with `blocked_reason: "validator_failed"`.
+- Reuse the same target plan file for the single permitted preflight revision in the same planning cycle.
 - 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>`.
 

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

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ---
 name: atomic-planner
@@ -23,10 +24,12 @@ tools:
   - "Edit(artifacts/**)"
   - "Write(docs/**)"
   - "Write(artifacts/**)"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
+  - execution-environment
 memory: project
 hooks:
   Stop:
@@ -66,6 +69,16 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files 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 plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- 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
 
 Before reporting completion, explicitly spawn the `atomic-executor` subagent for validation-only preflight. The delegated prompt MUST include the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
@@ -74,8 +87,8 @@ Before reporting completion, explicitly spawn the `atomic-executor` subagent for
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 - Treat executor preflight findings as binding plan defects.
-- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file using the executor's precise plan delta and re-run preflight.
-- Reuse the same target plan file for every preflight revision iteration in the same planning cycle.
+- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file once using the executor's precise plan delta and its full `PREFLIGHT-DEFECT:` list, and run one confirming preflight. Preflight is single-pass: trivial defects are fixed in place by the executor, and a plan returns to the planner at most once; a second substantive result halts with `blocked_reason: "validator_failed"`.
+- Reuse the same target plan file for the single permitted preflight revision in the same planning cycle.
 - 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>`.
 

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

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ---
 name: atomic-planner
@@ -23,10 +24,12 @@ tools:
   - "Edit(artifacts/**)"
   - "Write(docs/**)"
   - "Write(artifacts/**)"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
+  - execution-environment
 memory: project
 hooks:
   Stop:
@@ -66,6 +69,16 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files 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 plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- 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
 
 Before reporting completion, explicitly spawn the `atomic-executor` subagent for validation-only preflight. The delegated prompt MUST include the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
@@ -74,8 +87,8 @@ Before reporting completion, explicitly spawn the `atomic-executor` subagent for
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 - Treat executor preflight findings as binding plan defects.
-- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file using the executor's precise plan delta and re-run preflight.
-- Reuse the same target plan file for every preflight revision iteration in the same planning cycle.
+- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file once using the executor's precise plan delta and its full `PREFLIGHT-DEFECT:` list, and run one confirming preflight. Preflight is single-pass: trivial defects are fixed in place by the executor, and a plan returns to the planner at most once; a second substantive result halts with `blocked_reason: "validator_failed"`.
+- Reuse the same target plan file for the single permitted preflight revision in the same planning cycle.
 - 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>`.
 

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

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ---
 name: atomic-planner
@@ -23,10 +24,12 @@ tools:
   - "Edit(artifacts/**)"
   - "Write(docs/**)"
   - "Write(artifacts/**)"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
+  - execution-environment
 memory: project
 hooks:
   Stop:
@@ -66,6 +69,16 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files 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 plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- 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
 
 Before reporting completion, explicitly spawn the `atomic-executor` subagent for validation-only preflight. The delegated prompt MUST include the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
@@ -74,8 +87,8 @@ Before reporting completion, explicitly spawn the `atomic-executor` subagent for
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 - Treat executor preflight findings as binding plan defects.
-- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file using the executor's precise plan delta and re-run preflight.
-- Reuse the same target plan file for every preflight revision iteration in the same planning cycle.
+- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file once using the executor's precise plan delta and its full `PREFLIGHT-DEFECT:` list, and run one confirming preflight. Preflight is single-pass: trivial defects are fixed in place by the executor, and a plan returns to the planner at most once; a second substantive result halts with `blocked_reason: "validator_failed"`.
+- Reuse the same target plan file for the single permitted preflight revision in the same planning cycle.
 - 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>`.
 

package/resources/codex-and-agents-customizations/.codex/agents/atomic-planner.toml

@@ -11,6 +11,7 @@ Use the following repo-local skills as the canonical workflow source:
 - atomic-plan-contract
 - policy-compliance-order
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ---
 name: atomic-planner
@@ -23,10 +24,12 @@ tools:
   - "Edit(artifacts/**)"
   - "Write(docs/**)"
   - "Write(artifacts/**)"
+  - "mcp__drm-copilot__validate_orchestration_artifacts"
 skills:
   - policy-compliance-order
   - atomic-plan-contract
   - evidence-and-timestamp-conventions
+  - execution-environment
 memory: project
 hooks:
   Stop:
@@ -66,6 +69,16 @@ Generate plans using the atomic plan contract defined in the `atomic-plan-contra
 4. Do not add bucket tasks (e.g., "Refactor module" or "Write tests") that cannot be completed as a single binary outcome.
 5. Do not execute implementation; produce the plan only.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files 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 plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- 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
 
 Before reporting completion, explicitly spawn the `atomic-executor` subagent for validation-only preflight. The delegated prompt MUST include the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
@@ -74,8 +87,8 @@ Before reporting completion, explicitly spawn the `atomic-executor` subagent for
   - `PREFLIGHT: ALL CLEAR`
   - `PREFLIGHT: REVISIONS REQUIRED`
 - Treat executor preflight findings as binding plan defects.
-- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file using the executor's precise plan delta and re-run preflight.
-- Reuse the same target plan file for every preflight revision iteration in the same planning cycle.
+- If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same target plan file once using the executor's precise plan delta and its full `PREFLIGHT-DEFECT:` list, and run one confirming preflight. Preflight is single-pass: trivial defects are fixed in place by the executor, and a plan returns to the planner at most once; a second substantive result halts with `blocked_reason: "validator_failed"`.
+- Reuse the same target plan file for the single permitted preflight revision in the same planning cycle.
 - 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>`.
 

package/resources/codex-and-agents-customizations/.codex/agents/atomic-planning.toml

@@ -13,7 +13,7 @@ Core behavior:
 - Produce or revise only deterministic plan files.
 - Delegate validation-only preflight to `atomic-executor`.
 - Require the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY` in the delegated preflight handoff.
-- Reuse the same target plan file for every preflight revision iteration.
+- Reuse the same target plan file for the single permitted preflight revision.
 - Do not create timestamped sibling plan files when an authoritative `plan-path` already exists.
 - Stop and report blocked state if the required `atomic-executor` handoff cannot be started, resumed, or completed.
 

package/resources/codex-and-agents-customizations/.codex/agents/csharp-atomic-planning.toml

@@ -14,7 +14,7 @@ Core behavior:
 - Delegate validation-only preflight to `atomic-executor`.
 - Require the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY` in the delegated preflight handoff.
 - Require explicit C# baseline and final-QA tasks, including formatting, analyzer, type-safety, test, and coverage steps where policy requires coverage.
-- Reuse the same target plan file for every preflight revision iteration.
+- Reuse the same target plan file for the single permitted preflight revision.
 - Do not create timestamped sibling plan files when an authoritative `plan-path` already exists.
 - Stop and report blocked state if the required `atomic-executor` handoff cannot be started, resumed, or completed.
 

package/resources/codex-and-agents-customizations/.codex/agents/epic-orchestrator.toml

@@ -40,7 +40,8 @@ prompt, integration branch, child plan paths, preflight evidence, and Git state.
 and existing issues, folders, research, specifications, user stories, plans, and preflight
 receipts. Every child resumes at atomic execution. Drift returns control to `epic-planner`.
 Require `validate_orchestration_artifacts` to pass `epic-planner-state` with
-`require_ready_for_execution: true` and the explicit workspace root before execution. Copy its
+`require_ready_for_execution: true`, `require_codex_topology: true`,
+`require_codex_model_routing: true`, and the explicit workspace root before execution. Copy its
 validated `max_parallel_features` into this agent's checkpoint.
 
 ## Manual Epic
@@ -80,6 +81,8 @@ integration-to-main PR is merged with its merge SHA recorded, the status project
 acceptance criteria are checked, and `validate_orchestration_artifacts` passes
 `epic-orchestrator-state` with `require_complete: true`, `require_codex_topology: true`, and
 `require_codex_model_routing: true`.
+The final merge SHA is recorded only after the merge is confirmed by polling and ancestry check:
+under a merge queue on `main`, `gh pr merge` can return before the merge happens (issue #952).
 '''
 
 [skills]

package/resources/codex-and-agents-customizations/.codex/agents/feature-review.toml

@@ -118,9 +118,9 @@ Coverage metrics are mandatory for every language that has changed files in the
 
 ### Coverage Thresholds
 
-- **New code files** (files added in this feature, not previously existing): line coverage must be >= 90%.
-- **Modified files** (files that existed before and were changed): line coverage must show no regression relative to the baseline and must remain >= 80%.
-- **Repo-wide**: line coverage must remain >= 80% for each language.
+- **Governing thresholds**: when the repository's root `CLAUDE.md` states a line or branch coverage threshold, that threshold governs; otherwise the defaults govern (line 85%, branch 75% for branch-capable languages). Each metric falls back independently.
+- **New and modified files**: line coverage must meet the governing line threshold (and the branch threshold where measured); modified files must also show no regression on changed lines.
+- **Repo-wide**: coverage for each language must meet the governing thresholds.
 
 ### Verification Procedure
 
@@ -130,9 +130,9 @@ For each language that has changed files in the feature branch:
 2. Check whether the coverage artifact exists for that language.
 3. If the artifact exists:
    - Parse the repo-wide coverage percentage and report it in the policy audit.
-   - If repo-wide coverage is below 80%, flag as FAIL and add to remediation triggers.
-   - For each new file: if line coverage is below 90%, flag as FAIL and add to remediation triggers.
-   - For each modified file: if line coverage has regressed from baseline or is below 80%, flag as FAIL and add to remediation triggers.
+   - If repo-wide coverage is below the governing line threshold, flag as FAIL and add to remediation triggers.
+   - For each new file: if line coverage is below the governing line threshold, flag as FAIL and add to remediation triggers.
+   - For each modified file: if line coverage has regressed from baseline or is below the governing line threshold, flag as FAIL and add to remediation triggers.
 4. If no coverage artifact is found for a language that has changed files, flag as **FAIL** with reason: "coverage artifact absent for [language]; coverage verification is mandatory for all languages with changed files." Add to remediation triggers.
 
 The agent does NOT rerun coverage generation. Evidence verification from existing artifacts is the required model.

package/resources/codex-and-agents-customizations/.codex/agents/orchestrator-c1.toml

@@ -18,6 +18,7 @@ Use the following repo-local skills as the canonical workflow source:
 - pr-context-artifacts
 - pr-base-branch-merge-base
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ## Startup Protocol
 
@@ -60,8 +61,10 @@ entry path with `EPIC_INVOCATION_ORIGIN_BLOCKED`.
 
 When the parent prompt carries the literal `Preparation mode: true` marker, select only
 `route_id: preparation`. Perform promotion through the MCP surface, research, `spec.md`,
-`user-story.md`, atomic planning, and atomic-executor preflight. Iterate the same plan until
-`PREFLIGHT: ALL CLEAR`, commit the prepared feature folder and plan, then stop with
+`user-story.md`, atomic planning, and atomic-executor preflight. Run single-pass preflight on the
+same plan (trivial defects fixed in place, at most one return to the planner, a second substantive
+result halts with `blocked_reason: "validator_failed"`), commit the prepared feature folder and
+plan after `PREFLIGHT: ALL CLEAR`, then stop with
 `completed_steps` containing `S3_promotion` and `S4_atomic_planning`,
 `next_step: "S5_atomic_execution"`, execution-through-CI statuses exactly `not-applicable`, and
 `blocked_reason: "none"`. Do not implement, create a PR, run feature review, monitor CI, or claim
@@ -188,9 +191,9 @@ Do not report completion until:
 5. The checkpoint file reflects the final completed state.
 6. The checkpoint proves the selected routing matrix entry: all required agents have delegation receipts, all required skills have skill receipts, all required MCP tools have successful MCP receipts, and no local bypass list is populated.
 7. The deterministic MCP validator passes: `validate_orchestration_artifacts` with `artifact_type = "orchestrator-state"`, `artifact_path = "artifacts/orchestration/orchestrator-state.json"`, `require_complete = true`, `require_codex_topology = true`, and `require_codex_model_routing = true`.
-8. Required GitHub checks are green for the current PR head SHA before any PR/DONE transition.
+8. Every GitHub check on the current PR head SHA passed or was skipped before any PR/DONE transition.
 
-The MCP validator and required CI checks are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
+The MCP validator and every CI check on the current PR head SHA are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
 
 Do not claim mission completion unless all required delegations completed with receipts and the required orchestration artifacts exist on disk.
 '''

package/resources/codex-and-agents-customizations/.codex/agents/orchestrator-c2.toml

@@ -18,6 +18,7 @@ Use the following repo-local skills as the canonical workflow source:
 - pr-context-artifacts
 - pr-base-branch-merge-base
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ## Startup Protocol
 
@@ -60,8 +61,10 @@ entry path with `EPIC_INVOCATION_ORIGIN_BLOCKED`.
 
 When the parent prompt carries the literal `Preparation mode: true` marker, select only
 `route_id: preparation`. Perform promotion through the MCP surface, research, `spec.md`,
-`user-story.md`, atomic planning, and atomic-executor preflight. Iterate the same plan until
-`PREFLIGHT: ALL CLEAR`, commit the prepared feature folder and plan, then stop with
+`user-story.md`, atomic planning, and atomic-executor preflight. Run single-pass preflight on the
+same plan (trivial defects fixed in place, at most one return to the planner, a second substantive
+result halts with `blocked_reason: "validator_failed"`), commit the prepared feature folder and
+plan after `PREFLIGHT: ALL CLEAR`, then stop with
 `completed_steps` containing `S3_promotion` and `S4_atomic_planning`,
 `next_step: "S5_atomic_execution"`, execution-through-CI statuses exactly `not-applicable`, and
 `blocked_reason: "none"`. Do not implement, create a PR, run feature review, monitor CI, or claim
@@ -188,9 +191,9 @@ Do not report completion until:
 5. The checkpoint file reflects the final completed state.
 6. The checkpoint proves the selected routing matrix entry: all required agents have delegation receipts, all required skills have skill receipts, all required MCP tools have successful MCP receipts, and no local bypass list is populated.
 7. The deterministic MCP validator passes: `validate_orchestration_artifacts` with `artifact_type = "orchestrator-state"`, `artifact_path = "artifacts/orchestration/orchestrator-state.json"`, `require_complete = true`, `require_codex_topology = true`, and `require_codex_model_routing = true`.
-8. Required GitHub checks are green for the current PR head SHA before any PR/DONE transition.
+8. Every GitHub check on the current PR head SHA passed or was skipped before any PR/DONE transition.
 
-The MCP validator and required CI checks are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
+The MCP validator and every CI check on the current PR head SHA are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
 
 Do not claim mission completion unless all required delegations completed with receipts and the required orchestration artifacts exist on disk.
 '''

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

@@ -18,6 +18,7 @@ Use the following repo-local skills as the canonical workflow source:
 - pr-context-artifacts
 - pr-base-branch-merge-base
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ## Startup Protocol
 
@@ -60,8 +61,10 @@ entry path with `EPIC_INVOCATION_ORIGIN_BLOCKED`.
 
 When the parent prompt carries the literal `Preparation mode: true` marker, select only
 `route_id: preparation`. Perform promotion through the MCP surface, research, `spec.md`,
-`user-story.md`, atomic planning, and atomic-executor preflight. Iterate the same plan until
-`PREFLIGHT: ALL CLEAR`, commit the prepared feature folder and plan, then stop with
+`user-story.md`, atomic planning, and atomic-executor preflight. Run single-pass preflight on the
+same plan (trivial defects fixed in place, at most one return to the planner, a second substantive
+result halts with `blocked_reason: "validator_failed"`), commit the prepared feature folder and
+plan after `PREFLIGHT: ALL CLEAR`, then stop with
 `completed_steps` containing `S3_promotion` and `S4_atomic_planning`,
 `next_step: "S5_atomic_execution"`, execution-through-CI statuses exactly `not-applicable`, and
 `blocked_reason: "none"`. Do not implement, create a PR, run feature review, monitor CI, or claim
@@ -188,9 +191,9 @@ Do not report completion until:
 5. The checkpoint file reflects the final completed state.
 6. The checkpoint proves the selected routing matrix entry: all required agents have delegation receipts, all required skills have skill receipts, all required MCP tools have successful MCP receipts, and no local bypass list is populated.
 7. The deterministic MCP validator passes: `validate_orchestration_artifacts` with `artifact_type = "orchestrator-state"`, `artifact_path = "artifacts/orchestration/orchestrator-state.json"`, `require_complete = true`, `require_codex_topology = true`, and `require_codex_model_routing = true`.
-8. Required GitHub checks are green for the current PR head SHA before any PR/DONE transition.
+8. Every GitHub check on the current PR head SHA passed or was skipped before any PR/DONE transition.
 
-The MCP validator and required CI checks are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
+The MCP validator and every CI check on the current PR head SHA are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
 
 Do not claim mission completion unless all required delegations completed with receipts and the required orchestration artifacts exist on disk.
 '''

package/resources/codex-and-agents-customizations/.codex/agents/orchestrator-c3.toml

@@ -18,6 +18,7 @@ Use the following repo-local skills as the canonical workflow source:
 - pr-context-artifacts
 - pr-base-branch-merge-base
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ## Startup Protocol
 
@@ -60,8 +61,10 @@ entry path with `EPIC_INVOCATION_ORIGIN_BLOCKED`.
 
 When the parent prompt carries the literal `Preparation mode: true` marker, select only
 `route_id: preparation`. Perform promotion through the MCP surface, research, `spec.md`,
-`user-story.md`, atomic planning, and atomic-executor preflight. Iterate the same plan until
-`PREFLIGHT: ALL CLEAR`, commit the prepared feature folder and plan, then stop with
+`user-story.md`, atomic planning, and atomic-executor preflight. Run single-pass preflight on the
+same plan (trivial defects fixed in place, at most one return to the planner, a second substantive
+result halts with `blocked_reason: "validator_failed"`), commit the prepared feature folder and
+plan after `PREFLIGHT: ALL CLEAR`, then stop with
 `completed_steps` containing `S3_promotion` and `S4_atomic_planning`,
 `next_step: "S5_atomic_execution"`, execution-through-CI statuses exactly `not-applicable`, and
 `blocked_reason: "none"`. Do not implement, create a PR, run feature review, monitor CI, or claim
@@ -188,9 +191,9 @@ Do not report completion until:
 5. The checkpoint file reflects the final completed state.
 6. The checkpoint proves the selected routing matrix entry: all required agents have delegation receipts, all required skills have skill receipts, all required MCP tools have successful MCP receipts, and no local bypass list is populated.
 7. The deterministic MCP validator passes: `validate_orchestration_artifacts` with `artifact_type = "orchestrator-state"`, `artifact_path = "artifacts/orchestration/orchestrator-state.json"`, `require_complete = true`, `require_codex_topology = true`, and `require_codex_model_routing = true`.
-8. Required GitHub checks are green for the current PR head SHA before any PR/DONE transition.
+8. Every GitHub check on the current PR head SHA passed or was skipped before any PR/DONE transition.
 
-The MCP validator and required CI checks are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
+The MCP validator and every CI check on the current PR head SHA are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
 
 Do not claim mission completion unless all required delegations completed with receipts and the required orchestration artifacts exist on disk.
 '''

package/resources/codex-and-agents-customizations/.codex/agents/orchestrator-c4.toml

@@ -18,6 +18,7 @@ Use the following repo-local skills as the canonical workflow source:
 - pr-context-artifacts
 - pr-base-branch-merge-base
 - evidence-and-timestamp-conventions
+- execution-environment
 
 ## Startup Protocol
 
@@ -60,8 +61,10 @@ entry path with `EPIC_INVOCATION_ORIGIN_BLOCKED`.
 
 When the parent prompt carries the literal `Preparation mode: true` marker, select only
 `route_id: preparation`. Perform promotion through the MCP surface, research, `spec.md`,
-`user-story.md`, atomic planning, and atomic-executor preflight. Iterate the same plan until
-`PREFLIGHT: ALL CLEAR`, commit the prepared feature folder and plan, then stop with
+`user-story.md`, atomic planning, and atomic-executor preflight. Run single-pass preflight on the
+same plan (trivial defects fixed in place, at most one return to the planner, a second substantive
+result halts with `blocked_reason: "validator_failed"`), commit the prepared feature folder and
+plan after `PREFLIGHT: ALL CLEAR`, then stop with
 `completed_steps` containing `S3_promotion` and `S4_atomic_planning`,
 `next_step: "S5_atomic_execution"`, execution-through-CI statuses exactly `not-applicable`, and
 `blocked_reason: "none"`. Do not implement, create a PR, run feature review, monitor CI, or claim
@@ -188,9 +191,9 @@ Do not report completion until:
 5. The checkpoint file reflects the final completed state.
 6. The checkpoint proves the selected routing matrix entry: all required agents have delegation receipts, all required skills have skill receipts, all required MCP tools have successful MCP receipts, and no local bypass list is populated.
 7. The deterministic MCP validator passes: `validate_orchestration_artifacts` with `artifact_type = "orchestrator-state"`, `artifact_path = "artifacts/orchestration/orchestrator-state.json"`, `require_complete = true`, `require_codex_topology = true`, and `require_codex_model_routing = true`.
-8. Required GitHub checks are green for the current PR head SHA before any PR/DONE transition.
+8. Every GitHub check on the current PR head SHA passed or was skipped before any PR/DONE transition.
 
-The MCP validator and required CI checks are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
+The MCP validator and every CI check on the current PR head SHA are the hard completion boundary. There is no fallback. If the MCP server or validation tool is unavailable, stop and persist blocked state. Codex lifecycle hooks may provide local feedback, but they are not the authoritative completion gate.
 
 Do not claim mission completion unless all required delegations completed with receipts and the required orchestration artifacts exist on disk.
 '''