@danmoisan/drm-copilot-mcp 1.1.18 → 1.1.19

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

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

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

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

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

@@ -93,6 +93,17 @@ 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`.

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

@@ -93,6 +93,17 @@ 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`.

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

@@ -93,6 +93,17 @@ 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`.

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

@@ -93,6 +93,17 @@ 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`.

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

@@ -93,6 +93,17 @@ 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`.

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

@@ -93,6 +93,17 @@ 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`.

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

@@ -66,6 +66,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`.

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

@@ -66,6 +66,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`.

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

@@ -66,6 +66,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`.

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

@@ -66,6 +66,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`.

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

@@ -66,6 +66,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`.

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

@@ -66,6 +66,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`.

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

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

@@ -188,9 +188,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

@@ -188,9 +188,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

@@ -188,9 +188,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

@@ -188,9 +188,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

@@ -188,9 +188,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.toml

@@ -188,9 +188,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.
 '''