@danmoisan/drm-copilot-mcp 1.1.16 → 1.1.18

package/resources/claude-customizations/pack-manifests/core.json

@@ -22,14 +22,17 @@
     ".claude/agents/staged-review.md",
     ".claude/agents/status-updater.md",
     ".claude/agents/task-researcher.md",
+    ".claude/hooks/enforce-batch-budget-route.ps1",
     ".claude/hooks/enforce-checkpoint-monotonic.ps1",
     ".claude/hooks/enforce-completion-consistency.ps1",
     ".claude/hooks/enforce-discovery-artifact-gate.ps1",
     ".claude/hooks/enforce-epic-invocation-origin.ps1",
     ".claude/hooks/enforce-epic-merge-gate.ps1",
     ".claude/hooks/enforce-epic-merge-gate-authorization.ps1",
+    ".claude/hooks/enforce-epic-merge-gate-resolution.ps1",
     ".claude/hooks/enforce-epic-wave-barrier.ps1",
     ".claude/hooks/enforce-epic-worktree-removal-gate.ps1",
+    ".claude/hooks/enforce-epic-worktree-removal-gate-resolution.ps1",
     ".claude/hooks/enforce-evidence-locations.ps1",
     ".claude/hooks/enforce-feature-folder-order.ps1",
     ".claude/hooks/enforce-model-routing-receipt.ps1",
@@ -133,12 +136,14 @@
     ".claude/lib/orchestrator-state/OrchestratorStateCompletion.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCheckpointValue.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateReceipts.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateRemediationAccounting.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateModelReceipts.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCodexModelReceipts.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCodexTopologyReceipts.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateRoutingMatrix.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCompletionChecks.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateRoutingContract.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateIssueAdoption.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateUnconditional.psm1",
     ".claude/lib/discovery-validation/DiscoveryValidation.psm1",
     ".claude/lib/codex-routing/CodexDeployment.psm1",
@@ -158,8 +163,12 @@
     ".claude/lib/project-file-merge/ProjectFileMerge.psm1",
     ".claude/lib/project-file-merge/Resolve-MergeableConflict.ps1",
     ".claude/lib/ci-gate/Invoke-CiGateParser.ps1",
+    ".claude/lib/parallel-drift/ParallelDriftHalt.psm1",
+    ".claude/lib/parallel-drift/ParallelDrift.psm1",
+    ".claude/lib/parallel-drift/Invoke-ParallelDriftDetection.ps1",
     ".claude/rules/parallel-orchestration.md",
     ".claude/rules/shell.md",
+    ".claude/lib/bash/abandon-parallel-item.sh",
     ".claude/lib/bash/compute-cohorts.sh",
     ".claude/lib/bash/compute-concurrency-batches.sh",
     ".claude/lib/bash/parallel-cohorts.sh",
@@ -185,6 +194,7 @@
     ".claude/lib/worktree-resolution/WorktreeItemResolution.psm1",
     ".claude/lib/worktree-resolution/EpicScopeResolution.psm1",
     ".claude/lib/worktree-resolution/EpicScopeReadiness.psm1",
+    ".claude/lib/worktree-resolution/WorktreeRunResolution.psm1",
     ".claude/skills/mermaid-diagram/references/flowchart.md",
     ".claude/skills/mermaid-diagram/references/sequence.md",
     ".claude/skills/mermaid-diagram/references/class.md",

package/resources/claude-customizations/pack-manifests/powershell.json

@@ -6,7 +6,6 @@
     ".claude/agents/powershell-typed-engineer.md",
     ".claude/hooks/check-powershell-test-purity.ps1",
     ".claude/hooks/enforce-powershell-batch-budget.ps1",
-    ".claude/hooks/enforce-powershell-batch-budget-route.ps1",
     ".claude/skills/invoke-powershell-engineer/SKILL.md",
     ".claude/skills/powershell-change-budget-router/SKILL.md",
     ".claude/skills/powershell-orchestration-state-machine/SKILL.md",

package/resources/codex-and-agents-customizations/.agents/skills/acceptance-criteria-tracking/SKILL.md

@@ -68,6 +68,14 @@ During plan execution, after completing a task whose work satisfies an acceptanc
 
 Timing: Check off AC items as soon as the corresponding plan task passes verification — do not defer all AC updates to the end of plan execution.
 
+### CI-Dependent Criteria
+
+A CI-dependent criterion is one whose verification requires the result of CI on the PR head. It cannot be verified before the pull request exists, so it stays unchecked and is listed as pending-CI in the AC verification artifact until CI has run.
+
+- Owner: the item's own orchestrator run owns the check-off and performs it at S9; this is the one case in which an orchestrator run checks off AC. A parent or coordinating session never commits the check-off from its own root.
+- Timing: after the CI green gate (S9) records `ci_gate.conclusion` as `success`, and before the run reports DONE.
+- Push and re-verify: the check-off is committed in the item's own worktree and pushed to the PR branch, and the CI green gate is re-run against the new head SHA so that `ci_gate.head_sha` equals the final PR head before DONE.
+
 ### When Reviewers Check Off AC
 
 During feature review (feature-audit phase):

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

@@ -112,9 +112,11 @@ authoritative backstop.
 
 Each child owns its implementation, review, PR, CI-green gate, and merge into the integration
 branch. A merge conflict enters that child's existing remediation loop with a blocking
-`remediation-inputs.<timestamp>.md`. After three unresolved passes, record
-`blocked_conflict_loop_limit` and stop that edge. The epic agent must not resolve child conflicts
-locally.
+`remediation-inputs.<timestamp>.md`. Conflict cycles share the child's attempt count,
+`remediation_loop.completed_attempts`. The active cycle number is `completed_attempts + 1`, and a
+cycle without an applied candidate consumes no number. After three completed attempts without a
+`PASS` review, record `blocked_conflict_loop_limit` and stop that edge. The epic agent must not
+resolve child conflicts locally.
 
 ## Worktree Cleanup
 

package/resources/codex-and-agents-customizations/.agents/skills/evidence-and-timestamp-conventions/SKILL.md

@@ -48,6 +48,8 @@ Use this skill when:
 Use `yyyy-MM-ddTHH-mm` for all audit, remediation, and evidence artifacts.
 Example: `2026-02-06T14-30`.
 
+The `Timestamp` value is local time read from the host system clock when the recorded command runs (for example `Get-Date -Format yyyy-MM-ddTHH-mm`); the agent never composes or estimates it.
+
 ## Canonical Evidence Locations
 
 - Baseline evidence: `evidence/baseline/`
@@ -112,6 +114,8 @@ When evidence artifacts are used for automated checking or plan reconciliation,
 - `Command: <exact command>`
 - `EXIT_CODE: <int>`
 
+The first occurrence of `Timestamp`, `Command`, `EXIT_CODE`, and `ExpectedExitCode` forms the record in both the Python and the TypeScript parser; later occurrences, including empty later values, are ignored. An artifact that records several gates therefore reports its first gate.
+
 One optional field may also be declared:
 - `ExpectedExitCode: <int>` — the exit code the gate is expected to produce.
 

package/resources/codex-and-agents-customizations/.agents/skills/feature-promotion-lifecycle/SKILL.md

@@ -83,7 +83,7 @@ Lifecycle guardrails:
 
 4) Create the potential entry through `mcp__drm-copilot__new_potential_entry` or `mcp__drm-copilot__new_potential_bug_entry`.
 
-5) Promote the potential document through `mcp__drm-copilot__potential_to_issue` with the selected `${work-mode}` and capture the numeric `${issue-num}`.
+5) Promote the potential document through `mcp__drm-copilot__potential_to_issue` with the selected `${work-mode}` and capture the numeric `${issue-num}`. When the issue already exists, do not call `potential_to_issue`; verify the issue read-only and record `issue_adoption` with the existing number as `${issue-num}`.
 
 6) Rename the branch to the final branch:
 - `${final-branch}`

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

@@ -34,11 +34,11 @@ Write timestamped artifacts into the active feature folder:
 - `policy-audit.<timestamp>.md`
 - `code-review.<timestamp>.md`
 - `feature-audit.<timestamp>.md`
-- `remediation-inputs.<timestamp>.md` when remediation is required
-- `remediation-plan.<timestamp>.md` when remediation is required
+- `remediation-inputs.<timestamp>.md` for every review with at least one blocking finding, including `HALT_NON_REMEDIABLE` and `AWAITING_CI` reviews
+- `remediation-plan.<timestamp>.md` only when the verdict is `REMEDIATION_REQUIRED`
 
 The final review report MUST end with these exact single-line fields:
-- `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`
+- `REVIEW_STATUS: PASS`, `REVIEW_STATUS: REMEDIATION_REQUIRED`, `REVIEW_STATUS: HALT_NON_REMEDIABLE`, or `REVIEW_STATUS: AWAITING_CI`
 - `FEATURE_FOLDER: <path>`
 - `POLICY_AUDIT: <path>`
 - `CODE_REVIEW: <path>`
@@ -46,6 +46,28 @@ The final review report MUST end with these exact single-line fields:
 - `REMEDIATION_INPUTS: <path-or-NONE>`
 - `REMEDIATION_PLAN: <path-or-NONE>`
 
+`HALT_NON_REMEDIABLE` and `AWAITING_CI` require `REMEDIATION_PLAN: NONE`.
+
+### Remediability Contract
+
+Every blocking finding receives exactly one remediability class (exact, case-sensitive):
+- `autonomous`: repository remediation can resolve the finding without a human decision. This is the default when a finding block carries no remediability line.
+- `external_dependency`: a system, service, runtime, or published artifact outside the repository is unavailable or mismatched.
+- `policy_hold`: proceeding requires a policy decision, exception, or authorization the orchestrator may not grant.
+- `awaiting_ci`: the finding resolves when a CI result that has not completed becomes available.
+- `human_decision_required`: a human must choose between alternatives or approve a direction.
+
+A published MCP runtime that lags the repository contract is classified `external_dependency`.
+
+The verdict follows from the classes of all blocking findings: no blocking findings is `PASS`; at least one `autonomous` finding is `REMEDIATION_REQUIRED`; otherwise at least one `external_dependency`, `policy_hold`, or `human_decision_required` finding is `HALT_NON_REMEDIABLE`; otherwise every finding is `awaiting_ci` and the verdict is `AWAITING_CI`.
+
+The remediation inputs file carries these line formats:
+- one line `Review-Verdict: <VERDICT>` for the review,
+- inside each blocking finding block, one line `Remediability: <class>`,
+- inside each blocking finding block, one line `Remediability-Evidence: <text>` stating why the class applies.
+
+These lines, including the evidence text, never contain the substrings the orchestrator counts when it counts blocking findings, so their presence does not change the blocking count.
+
 Each required review artifact MUST pass the matching validator command before review can be reported as complete:
 - the `validate_orchestration_artifacts` MCP tool with `artifact_type: "policy-audit"` and `artifact_path: <path>`
 - the `validate_orchestration_artifacts` MCP tool with `artifact_type: "code-review"` and `artifact_path: <path>`
@@ -63,10 +85,12 @@ Each required review artifact MUST pass the matching validator command before re
 5. Create the policy audit, code review, and feature audit.
    - validate each artifact immediately after writing it
 6. Check off passing acceptance criteria in the authoritative requirement sources per `acceptance-criteria-tracking`.
-7. If remediation is required, create remediation inputs first and then hand off plan creation using `remediation-handoff-atomic-planner`.
+7. Classify every blocking finding per the Remediability Contract. Remediation is required only when at least one blocking finding is `autonomous`. If remediation is required, create remediation inputs first and then hand off plan creation using `remediation-handoff-atomic-planner`. When every blocking finding is non-remediable, write the remediation inputs, report `HALT_NON_REMEDIABLE` or `AWAITING_CI` with `REMEDIATION_PLAN: NONE`, create no remediation plan target, and do not hand off to `atomic-planner`.
 8. In the final report:
-   - set `REVIEW_STATUS: PASS` only when no remediation artifact is required,
-   - set `REVIEW_STATUS: REMEDIATION_REQUIRED` when remediation inputs or a remediation plan were required,
+   - set `REVIEW_STATUS: PASS` only when no blocking finding exists,
+   - set `REVIEW_STATUS: REMEDIATION_REQUIRED` when at least one blocking finding is `autonomous`,
+   - set `REVIEW_STATUS: HALT_NON_REMEDIABLE` when no blocking finding is `autonomous` and at least one is `external_dependency`, `policy_hold`, or `human_decision_required`,
+   - set `REVIEW_STATUS: AWAITING_CI` when every blocking finding is `awaiting_ci`,
    - include every required artifact-path field exactly once.
 
 ### Enforced Remediation Handoff Contract

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

@@ -136,6 +136,8 @@ Always apply:
      - required acceptance criteria are FAIL or PARTIAL
      - coverage regression below policy threshold (< 80% repo-wide per language, < 80% or regression for modified files, or < 90% for new files)
      - coverage artifact absent for any language that has changed files
+   - Classify each blocking finding before triggering remediation: every blocking finding receives one `Remediability` class (`autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, or `human_decision_required`; `autonomous` when no class is stated).
+   - Trigger remediation only for `autonomous` findings. When no blocking finding is `autonomous`, write the remediation inputs, report `HALT_NON_REMEDIABLE` (at least one `external_dependency`, `policy_hold`, or `human_decision_required` finding) or `AWAITING_CI` (every finding `awaiting_ci`) with `REMEDIATION_PLAN: NONE`, create no remediation plan target, and do not hand off to `atomic-planner`.
    - Create `remediation-inputs.<timestamp>.md` first.
    - Create the target remediation plan file from the canonical plan template.
    - Hand off plan creation through `remediation-handoff-atomic-planner`.
@@ -145,7 +147,7 @@ Always apply:
    - Verify every reported artifact exists on disk before reporting completion.
    - Report artifact paths and a concise go/no-go recommendation for PR readiness.
    - End the final report with these exact single-line fields:
-     - `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`
+     - `REVIEW_STATUS: PASS`, `REVIEW_STATUS: REMEDIATION_REQUIRED`, `REVIEW_STATUS: HALT_NON_REMEDIABLE`, or `REVIEW_STATUS: AWAITING_CI`
      - `FEATURE_FOLDER: <path>`
      - `POLICY_AUDIT: <path>`
      - `CODE_REVIEW: <path>`

package/resources/codex-and-agents-customizations/.agents/skills/invoke-powershell-engineer/SKILL.md

@@ -23,7 +23,6 @@ If the estimated scope exceeds the direct-mode budget, this skill defers to the
 - Files or entrypoints in scope (exact script or module paths and corresponding `*.Tests.ps1` paths).
 - Constraints, including public function or module contracts that must be preserved.
 - Optional approved plan. If none is supplied, the worker delegates plan authoring to `atomic_planner` before any edits.
-- Optional budget override in the form `budget: prod=<N>, test=<M>` subject to repo policy compliance.
 
 ## Output Paths
 

package/resources/codex-and-agents-customizations/.agents/skills/invoke-python-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-python-engineer
-description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black, Ruff, Pyright, and Pytest with a three-production plus three-test per-batch budget and zero-regression quality gates.
+description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black, Ruff, Pyright, and Pytest with a 1-3 production-file direct-mode budget, routing to the orchestrated large path above it, and zero-regression quality gates.
 ---
 
 # Implement Python Skill
@@ -15,7 +15,7 @@ Use this skill when:
 - Estimated scope fits the small path (1-3 production files plus corresponding tests).
 - The toolchain (Black, Ruff, Pyright, Pytest) can be run in the current environment, or the user has explicitly authorized an unverified plan-only response.
 
-If the estimated scope exceeds the small-path budget, this skill defers to the orchestrated flow via `python-change-budget-router` instead of proceeding directly.
+If the estimated scope is more than 3 production files, this skill defers to the orchestrated large path (`.codex/prompts/orchestrate-work.md`) via `python-change-budget-router` instead of proceeding directly. The large path has no production-file cap, and test files are not counted toward the routing threshold.
 
 ## Inputs
 
@@ -23,7 +23,6 @@ If the estimated scope exceeds the small-path budget, this skill defers to the o
 - Files or entrypoints in scope.
 - Constraints, including public APIs that must be preserved.
 - Optional approved plan. If none is supplied, the worker delegates plan authoring to `atomic_planner` before any edits.
-- Optional budget override in the form `budget: prod=<N>, test=<M>` subject to repo policy compliance.
 
 ## Output Paths
 

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

@@ -128,6 +128,11 @@ route.
   `not-applicable`, and `blocked_reason: "none"`.
 - Do not edit production code, execute the plan, author or edit a PR, run feature review, monitor
   CI, set `next_step: "complete"`, record `S12_complete`, or claim feature completion.
+- Premise-falsified halt: use `blocked_reason: "premise_falsified"` when every delegation and
+  validator succeeded but evidence gathered during execution falsified the plan's premise. Still
+  record the evidence path in free-form checkpoint keys; `blocked_reason` carries only the
+  classification. The preparation terminal checkpoint above still sets `blocked_reason: "none"`.
+  The full `blocked_reason` vocabulary and its partition are in `.claude/rules/orchestrator-state.md`.
 
 Only the literal JSON Boolean `false` in the route configuration disables the CI requirement.
 Missing, malformed, string-valued, or unknown route data fails closed. The preparation mutation
@@ -290,10 +295,12 @@ skill use. The checkpoint must include:
 - `required_mcp_tools`: exactly the selected route's `required_mcp_tools`
 - `delegation_receipts`: one receipt for each required agent
 - `skill_receipts`: one required receipt for each required skill, with evidence
-- `mcp_call_receipts`: one successful receipt for each required MCP tool
+- `mcp_call_receipts`: one successful receipt for each required MCP tool unless a valid `issue_adoption` record waives it
 - `local_execution_overrides`: an empty list at completion
 - `delegation_bypasses`: an empty list at completion
 - `lifecycle_operations`: any lifecycle operation must record `surface: "mcp"`
+- `ci_gate`: the CI result object defined in `## CI Green Gate`, with keys `conclusion`, `head_sha`, and `verified_at`
+- `pr_gate`: the pull-request object defined in `## CI Green Gate`, with keys `pr_number`, `pr_url`, `head_branch`, and `head_sha`
 
 If any required handoff, skill receipt, MCP receipt, or empty bypass list is
 missing, `validate_orchestration_artifacts --require-complete` fails and the
@@ -405,22 +412,32 @@ The review subagent compares against a base branch; uncommitted changes are invi
 After each `feature-reviewer` delegation returns:
 
 1. Read the exact terminal status lines from the review result.
-2. If the result does not include `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`, stop and record blocked state.
-3. If the result is `REVIEW_STATUS: PASS`, advance to the PR creation gate.
-4. If the result is `REVIEW_STATUS: REMEDIATION_REQUIRED`, require both `REMEDIATION_INPUTS: <path>` and `REMEDIATION_PLAN: <path>` and then enter the remediation loop.
+2. If the result does not include `REVIEW_STATUS: PASS`, `REVIEW_STATUS: REMEDIATION_REQUIRED`, `REVIEW_STATUS: HALT_NON_REMEDIABLE`, or `REVIEW_STATUS: AWAITING_CI`, stop and record blocked state.
+3. When the remediation inputs carry a `Review-Verdict:` line, recompute the verdict from the finding classes (a blocking finding block without a remediability line counts as `autonomous`). A mismatch between the declared and recomputed verdicts is a reviewer contract error: record it under `artifact_errors`, re-request the review once, and halt with `blocked_reason: "delegate_contract_incomplete"` if it persists.
+4. Append a `remediation_loop.review_outcomes[]` entry (`verdict` plus one `findings[]` object with `remediability` per blocking finding) for every review, including `PASS`.
+5. If the result is `REVIEW_STATUS: PASS`, advance to the PR creation gate.
+6. If the result is `REVIEW_STATUS: REMEDIATION_REQUIRED`, require both `REMEDIATION_INPUTS: <path>` and `REMEDIATION_PLAN: <path>` and then enter the remediation loop with the plan scoped to the `autonomous` findings; non-remediable findings carry forward unchanged.
+7. If the result is `REVIEW_STATUS: HALT_NON_REMEDIABLE`, require `REMEDIATION_PLAN: NONE` and halt: set `blocked_reason` to the highest-precedence halt class present, append one `human_interaction.requirements[]` entry with `response: "halt"` for each halt class present (`external_dependency`, `policy_hold`, `human_decision_required`) describing the human action needed, leave `remediation_loop.completed_attempts` unchanged, write no cycle, create no remediation plan, and stop. The precedence is:
+
+   Halt precedence: human_decision_required > policy_hold > external_dependency
+
+8. If the result is `REVIEW_STATUS: AWAITING_CI`, require `REMEDIATION_PLAN: NONE` and wait: set `blocked_reason: "awaiting_ci"`, set `next_step` to the step that re-checks (`S7_feature_review` for a review-time wait, `S9_ci_green` for a CI poll timeout), record no `human_interaction.requirements[]` entry for the wait, write no cycle, and create no remediation plan. Poll within the existing bounded CI interval and timeout; when the bound is exhausted, persist and stop. On resume, set `blocked_reason: "none"` and re-run the named step. For a review-time wait, the awaited workflow is named in the finding's `Remediability-Evidence:` line.
+9. A CI Green Gate poll timeout is recorded as a finding with `Remediability: awaiting_ci` and follows the wait path; a failed required check stays `autonomous` and enters the remediation loop.
 
 ## Remediation Loop (R1–R5)
 
-A bounded loop consisting of five steps. The loop variable `remediation_pass` starts at 1 and increments at R5 before returning to R1.
+A bounded loop consisting of five steps. The attempt count is `remediation_loop.completed_attempts`, and `remediation_pass` equals `remediation_loop.completed_attempts`. The active cycle number is `completed_attempts + 1`; `remediation_loop.current_cycle` is a record position in `cycles[]`, not a count. A halt or wait verdict never opens a cycle, and every cycle opened from a review records `opened_by_review`, the zero-based index of that `review_outcomes[]` entry.
+
+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"`.
 
 - **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.
 - **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.
-- **R5 — Loop-exit decision:** If the re-audit returns `REVIEW_STATUS: PASS`, exit the loop and advance to the PR creation gate. Otherwise, record `remediation_pass` increment in the checkpoint and return to R1.
+- **R5 — Loop-exit decision:** Evaluate the re-audit per Post-Review Outcome Evaluation. If it returns `REVIEW_STATUS: PASS`, exit the loop and advance to the PR creation gate. If it returns `REVIEW_STATUS: HALT_NON_REMEDIABLE` or `REVIEW_STATUS: AWAITING_CI`, follow the halt or wait branch instead of opening the next cycle. Otherwise, record the cycle's `candidate_applied` value and the resulting `completed_attempts` in the checkpoint and return to R1.
 
-**Termination guard:** If `remediation_pass` reaches 3 without resolution, the orchestrator records `step6_status: "blocked_remediation_loop_limit"` in the checkpoint and halts. No further automation is attempted.
+**Termination guard:** Halt after three completed attempts: when `remediation_loop.completed_attempts` equals 3 and the latest verdict is not `PASS`, the orchestrator records `step6_status: "blocked_remediation_loop_limit"` in the checkpoint and halts. No further automation is attempted.
 
 ## Issue Number Consistency
 
@@ -440,6 +457,12 @@ and required GitHub checks through `gh`. The checkpoint must record the checked
 head SHA and CI result. DONE is blocked unless the required checks pass for the
 current PR head SHA.
 
+The checkpoint records the CI result in a top-level `ci_gate` object with the required keys `conclusion`, `head_sha`, and `verified_at`. `conclusion` is one of `success`, `failure`, or `pending`; `head_sha` is the PR head SHA the required checks were observed against; `verified_at` is the ISO-8601 time at which this gate (S9) recorded the result. DONE requires `ci_gate.conclusion` equal to `success` and `ci_gate.head_sha` equal to the current PR head SHA. The key set is defined by `CI_GATE_KEYS` in `scripts/dev_tools/validate_orchestrator_state.py`, and the TypeScript MCP validator used by the Codex runtime requires the same keys.
+
+The checkpoint records the pull request in a top-level `pr_gate` object with the keys `pr_number`, `pr_url`, `head_branch`, and `head_sha`. The key set is defined by `PR_GATE_KEYS` in `scripts/dev_tools/_orchestrator_state_routing.py`.
+
+CI-dependent acceptance criteria are criteria whose verification requires the result of CI on the PR head. The item's own orchestrator run owns their check-off. After `ci_gate.conclusion` is `success`, check off each CI-dependent criterion in the item's own worktree, commit, push to the PR branch, and re-run this gate against the new head SHA, so that `ci_gate.head_sha` equals the final PR head before DONE. A failed re-run enters the Remediation Loop (R1–R5) as a blocking finding; the shared `remediation_loop.completed_attempts` count and its halt after three completed attempts are unchanged. A parent or coordinating session never commits these check-offs from its own root.
+
 ## PR Creation Gate
 
 The orchestrator must not create a PR, push a branch for PR purposes, or report work complete until all four conditions are simultaneously true:

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

@@ -9,7 +9,7 @@ Source: legacy Claude rule `orchestrator-state`.
 
 # Orchestrator-State Remediation-Cycle and Human-Interaction Invariants
 
-This rule governs remediation-cycle records and the optional `human_interaction` block in the orchestrator-state checkpoint at `artifacts/orchestration/orchestrator-state.json`. It documents three invariants that must hold for each remediation cycle, plus three invariants for the `human_interaction` block, so that resume and review workflows do not depend on a structurally invalid checkpoint.
+This rule governs remediation-cycle records and the optional `human_interaction` block in the orchestrator-state checkpoint at `artifacts/orchestration/orchestrator-state.json`. It documents the invariants that must hold for each remediation cycle and for the remediation-loop review outcomes and attempt count, plus three invariants for the `human_interaction` block, so that resume and review workflows do not depend on a structurally invalid checkpoint.
 
 ## Foreign Schema Warning (do not copy verbatim)
 
@@ -60,7 +60,7 @@ completion authority.
 
 ## Scope and Backward Compatibility
 
-These invariants apply only when the checkpoint contains a top-level `remediation_loop` with a `cycles` array. A checkpoint with no `remediation_loop` (the existing step-based checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive.
+These invariants apply only when the checkpoint contains a top-level `remediation_loop`; the per-cycle invariants apply when it has a `cycles` array, and the review-outcome and attempt-count invariants apply when their keys are present. A checkpoint with no `remediation_loop` (the existing step-based checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive.
 
 ## Invariants (per remediation cycle)
 
@@ -70,6 +70,45 @@ These invariants apply only when the checkpoint contains a top-level `remediatio
 
 3. **Exit gate requires zero blocking findings.** When a cycle's `exit_condition_met == true`, its `blocking_count` must be `0`. A non-zero `blocking_count` with `exit_condition_met == true` is a malformed cycle (the exit gate was marked satisfied while blocking findings remained).
 
+4. **`candidate_applied` is a boolean (R5).** When a cycle object carries `candidate_applied`, its value must be a JSON boolean, and any other value is a malformed cycle.
+
+5. **A completed attempt requires completed execution (R6).** A cycle whose `candidate_applied == true` must have `execution_status == "complete"`, and `candidate_applied == true` with any other execution status is a malformed cycle.
+
+6. **`opened_by_review` references a remediation review (R11).** When a cycle object carries `opened_by_review`, its value must be a non-negative integer (not a boolean) that indexes an object entry of the `remediation_loop.review_outcomes` list whose `verdict` is `REMEDIATION_REQUIRED`, and a value that is not such an integer, is out of range, or references an outcome with any other verdict is a malformed cycle.
+
+7. **`completed_attempts` counts completed attempts (R7).** When `remediation_loop.completed_attempts` is present, it must be a non-negative integer (not a boolean) equal to the number of object cycles whose `candidate_applied` is `true` (zero when `cycles` is absent or not a list), and any other value is a malformed loop.
+
+## Invariants (remediation_loop.review_outcomes)
+
+These invariants apply only when `remediation_loop` contains a `review_outcomes` key. The orchestrator appends one entry per review, including a `PASS` review, in the shape `{"verdict": <verdict>, "findings": [{"remediability": <class>}, ...]}`, where `findings` lists the review's blocking findings only. A halt or wait verdict records no remediation cycle.
+
+Review verdicts (exact, case-sensitive):
+
+| Verdict | Condition over the classes of the review's blocking findings |
+|---|---|
+| `PASS` | No blocking findings. |
+| `REMEDIATION_REQUIRED` | At least one `autonomous` finding. |
+| `HALT_NON_REMEDIABLE` | No `autonomous` finding, and at least one `external_dependency`, `policy_hold`, or `human_decision_required` finding. |
+| `AWAITING_CI` | At least one finding, and every finding is `awaiting_ci`. |
+
+Remediability classes (exact, case-sensitive) and the `blocked_reason` member (#523) that a halt or wait records for each class:
+
+| Class | Meaning | `blocked_reason` member |
+|---|---|---|
+| `autonomous` | Repository remediation can resolve the finding without a human decision. | none (remediation loop) |
+| `external_dependency` | A system, service, runtime, or published artifact outside the repository is unavailable or mismatched. | `external_dependency` |
+| `policy_hold` | Proceeding requires a policy decision, exception, or authorization that the orchestrator may not grant. | `policy_hold` |
+| `awaiting_ci` | The finding resolves when a CI result that has not completed becomes available. | `awaiting_ci` |
+| `human_decision_required` | A human must choose between alternatives or approve a direction. | `human_decision_required` |
+
+Derivation order. The verdict is a pure function of the findings' classes, evaluated in this order: no findings yields `PASS`; any `autonomous` finding yields `REMEDIATION_REQUIRED`; any `external_dependency`, `policy_hold`, or `human_decision_required` finding yields `HALT_NON_REMEDIABLE`; otherwise the verdict is `AWAITING_CI`.
+
+1. **`review_outcomes` is a list of objects (R8).** `review_outcomes` must be a list, and each entry must be an object. A non-list value or a non-object entry is malformed.
+
+2. **Verdict and class membership (R9).** Each outcome's `verdict` must be a string among the four verdicts, its `findings` must be a list (a missing key is not a list), and each finding must be an object whose `remediability` is a string among the five classes. Comparisons are case-sensitive, so a case variant such as `Pass` or `Autonomous` is malformed.
+
+3. **Verdict matches its findings (R10).** When an outcome passes the membership checks, its `verdict` must equal the verdict that the derivation order yields for its findings' classes. A mismatch is a malformed outcome.
+
 ## Human-Interaction Scope and Backward Compatibility
 
 These invariants apply only when the checkpoint contains a top-level `human_interaction` block. A checkpoint with no `human_interaction` key (the existing checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive and support the autonomous-execution mandate documented in `.agents/skills/orchestrate/SKILL.md`.

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

@@ -157,6 +157,13 @@ Blocked-reason enum:
   - `commit_context_missing`
   - `no_staged_changes`
   - `pre_implementation_gate_violation`
+  - `premise_falsified` — Every delegation and validator succeeded, but evidence gathered during execution falsified the premise on which the plan was built, so continuing would implement an invalid plan.
+  - `external_dependency` — The run cannot proceed because a system, service, runtime, or artifact outside the repository's control is unavailable or mismatched, and no in-repository remediation can resolve it.
+  - `policy_hold` — The run is stopped because proceeding requires a policy decision, exception, or authorization that the orchestrator is not permitted to grant autonomously.
+  - `awaiting_ci` — The run is waiting for a CI result that has not yet completed, and no remediation is warranted until that result is available.
+  - `human_decision_required` — The run requires a human to choose between alternatives or approve a direction before it can continue.
+
+Blocked-reason partition: `none` (or JSON `null`) means the run is not blocked. The six validator-enforced members `spawn_agent_unavailable`, `delegation_launch_failed`, `delegate_no_receipt`, `delegate_contract_incomplete`, `validator_failed`, and `user_requested_stop` form the mechanical partition. The five members `premise_falsified`, `external_dependency`, `policy_hold`, `awaiting_ci`, and `human_decision_required` form the non-mechanical partition. The full vocabulary is published in `.claude/rules/orchestrator-state.md`.
 
 Pre-implementation violation schema:
 - `pre-implementation-violation` MUST be either `null` or an object with:
@@ -198,7 +205,8 @@ Completion-state invariants:
 - every required skill MUST have a matching required `skill_receipts[].skill`
   with non-empty evidence.
 - every required MCP tool MUST have a successful `mcp_call_receipts[].tool`
-  receipt with non-empty evidence.
+  receipt with non-empty evidence, unless a valid `issue_adoption` record
+  waives the tool.
 - `local_execution_overrides` and `delegation_bypasses` MUST be empty lists at
   completion.
 - every recorded `lifecycle_operations[]` item MUST use `surface: "mcp"`.
@@ -228,6 +236,8 @@ Do not advance on summaries alone when an exact result signal is required.
 - feature review result:
   - `REVIEW_STATUS: PASS`
   - `REVIEW_STATUS: REMEDIATION_REQUIRED`
+  - `REVIEW_STATUS: HALT_NON_REMEDIABLE`
+  - `REVIEW_STATUS: AWAITING_CI`
   - `FEATURE_FOLDER: <path>`
   - `POLICY_AUDIT: <path>`
   - `CODE_REVIEW: <path>`
@@ -382,18 +392,23 @@ Required behavior:
 
 Apply this loop after any required review returns `REVIEW_STATUS: REMEDIATION_REQUIRED`.
 
+Attempt accounting: `remediation-pass` equals `remediation_loop.completed_attempts`, the number of cycles whose `candidate_applied` is `true`. A cycle records `candidate_applied: true` only when remediation execution completed and the remediation commit recorded a non-empty change set. The active cycle number is `completed_attempts + 1`, and a cycle without a candidate consumes no number. Cap: halt after three completed attempts, that is, when `completed_attempts` equals 3 and the latest review is not `REVIEW_STATUS: PASS`, with `step6_status: "blocked_remediation_loop_limit"`.
+
+Halt and wait branches: a review that returns `REVIEW_STATUS: HALT_NON_REMEDIABLE` or `REVIEW_STATUS: AWAITING_CI` never enters or continues this loop and opens no cycle. On `HALT_NON_REMEDIABLE`, set `blocked_reason` to the highest-precedence halt class present (`human_decision_required`, then `policy_hold`, then `external_dependency`), append one `human_interaction.requirements[]` entry with `response: "halt"` per halt class present, and stop. On `AWAITING_CI`, set `blocked_reason: "awaiting_ci"`, set `next_step` to the step that re-checks, persist, and stop; on resume, set `blocked_reason: "none"` and re-run that step.
+
 1. Persist `review-status`, `remediation-inputs-path`, `remediation-plan-path`, and `remediation-pass` in the checkpoint.
 2. Delegate `atomic-executor` in validation-only mode against the exact `remediation-plan-path`.
 3. If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, delegate `atomic-planner` to update the same `remediation-plan-path` in place and then repeat preflight clearance.
 4. Only after `PREFLIGHT: ALL CLEAR`, delegate `atomic-executor` to execute the remediation plan exactly as written.
 5. Stage all files with `git add -A`.
 6. If staging is empty after execution, set `blocked_reason` to `no_staged_changes` and stop.
+   - Record `candidate_applied: false` for that cycle; it consumes no attempt number.
 7. Use `repo-automation-adapter` to run MCP tool `collect_commit_context`, capture the returned on-disk artifact path as `commit-context-path`, and stop with `blocked_reason: commit_context_missing` if that path is unavailable.
 8. Delegate `commit-steward` using `commit-context-path` as the authoritative staged-change input.
 9. Commit the staged work with the exact message returned by `commit-steward`.
 10. Use `repo-automation-adapter` to refresh PR-context artifacts through MCP tool `collect_pr_context` with the resolved base branch.
 11. Delegate `feature-reviewer` again with the refreshed PR context.
-12. If the new review still returns `REVIEW_STATUS: REMEDIATION_REQUIRED`, increment `remediation-pass` and repeat the loop. Exit only when the latest review returns `REVIEW_STATUS: PASS`.
+12. Record `candidate_applied: true` for the cycle and set `remediation_loop.completed_attempts` and `remediation-pass` to the new count. If the new review still returns `REVIEW_STATUS: REMEDIATION_REQUIRED`, repeat the loop under the cap. Exit only when the latest review returns `REVIEW_STATUS: PASS`, or follow the halt or wait branch.
 
 ## Completion Gates
 
@@ -404,7 +419,7 @@ Do not claim mission completion until all of the following are true:
 - small-path implementation has a receipt from the exact language-specific generated
   typed-engineer deployment profile
 - all required skills have `skill_receipts` with evidence
-- all required MCP tools have successful `mcp_call_receipts`
+- all required MCP tools have successful `mcp_call_receipts`, unless a valid `issue_adoption` record waives the tool
 - no local execution override or delegation bypass is recorded
 - the checkpoint is updated with the final state
 - the canonical checkpoint path was used without sidecar replacement or backup substitution

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

@@ -1,11 +1,11 @@
 ---
 name: python-change-budget-router
-description: Budget-first routing and batch-scope contract for Python work. Estimate production-file scope, choose small vs large path, enforce the 3 production + 3 test per-batch cap, and halt the agent for scope expansion approval when the estimate exceeds the budget.
+description: Budget-first routing contract for Python work. Estimate production-file scope, choose small vs large path, and route direct-mode work of more than 3 production files to the orchestrated large path.
 ---
 
 # Python Change Budget Router
 
-Canonical guidance for deciding whether Python work stays on the small path (`python-typed-engineer` direct mode) or escalates to the full orchestration workflow, and for enforcing per-batch change budgets during execution.
+Canonical guidance for deciding whether Python work stays on the small path (`python-typed-engineer` direct mode) or escalates to the orchestrated large path through `.codex/prompts/orchestrate-work.md`.
 
 ## When to Use This Skill
 
@@ -14,46 +14,23 @@ Use this skill when:
 - Intake starts from a natural-language Python request.
 - An agent must decide the execution path before planning or implementation.
 - A direct-mode route must reject over-budget requests and switch to orchestrated flow.
-- An executor must confirm a batch fits within the 3 production + 3 test file cap before editing.
 
 ## Canonical Routing Rules
 
 1. Estimate rough change budget first based on likely **production Python files** touched.
 2. Route:
    - `1-3` production files (plus corresponding tests) → **small path** (`python-typed-engineer` direct mode).
-   - `>3` production files → **large path** (orchestration workflow with promotion, research, spec, planning, execution, and review).
-
-## Per-Batch Change Budget (Hard Gate)
-
-During Phase C execution:
-
-- A single batch may change at most **3 production files** and **3 test files**.
-- The default cap applies unless the user supplies an override of the form `budget: prod=<N>, test=<M>` in the initiating prompt.
-- A user override may be honored only if it complies with repo policy and approved scope. If the requested scope exceeds 3 production files overall, stop before execution and seek explicit approval.
-- If an override is requested, confirm compliance with repo policy before entering Phase C.
-
-## Scope Expansion Protocol
-
-When in-scope work is required beyond 3 production files, stop and return:
-
-- a one-paragraph justification for the additional files,
-- the exact additional file paths,
-- the smallest alternative that avoids expanding scope,
-
-and wait for explicit user approval before proceeding.
-
-Allowed minimal-seam exceptions (still within the 3-file cap) are:
-
-- introducing a minimal seam for testability (I/O boundary isolation, dependency injection),
-- typing changes required for Pyright cleanliness in the slice,
-- updating the smallest set of call sites needed to preserve a stable public API.
+   - More than 3 production files → **large path** (`.codex/prompts/orchestrate-work.md`). The large path has no production-file cap.
+3. Test files are not counted toward the routing threshold.
 
 ## Direct-Mode Rejection Rule
 
-If `python-typed-engineer` is invoked directly and estimated scope is `>3` production files:
+If `python-typed-engineer` is invoked directly and the estimated scope, or the scope discovered during implementation, is more than 3 production files:
 
-- Stop before implementation.
-- Return an explicit routing instruction to invoke the orchestrated workflow.
+- Stop before editing the 4th production file.
+- Report the production files already changed and the production files still required.
+- Return an explicit routing instruction to invoke `.codex/prompts/orchestrate-work.md`.
+- Do not request an exception to the threshold; routing is the only path past it.
 
 ## Orchestrated Small-Path Requirements
 
@@ -75,5 +52,4 @@ Record in the agent response or logs:
 
 - estimated production file count,
 - chosen path (`small` or `large`),
-- rationale summary (1-3 bullets),
-- any requested budget override and its approval state.
+- rationale summary (1-3 bullets).

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

@@ -9,7 +9,7 @@ Source: legacy Claude rule `quality-tiers`.
 
 # Module Rigor Tiers
 
-This rule defines the T1–T4 module rigor tier system used by all CI gates in this repository. The tier system source of truth is `docs/ci.research.md` section 1; the file `quality-tiers.yml` at the repository root maps every project to a tier. Adding a project without a tier classification fails CI.
+This rule defines the T1–T4 module rigor tier system used by all CI gates in this repository. The tier definitions and gate matrix in this document are the tier system's source of truth; the file `quality-tiers.yml` at the repository root maps every project to a tier. Adding a project without a tier classification fails CI.
 
 ## Tiers
 

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

@@ -20,6 +20,8 @@ Trigger remediation when any of these are true:
 - Toolchain checks fail.
 - Acceptance criteria are not met.
 
+Remediation triggers only on blocking findings classified `autonomous`. Each blocking finding carries one remediability class (`autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, or `human_decision_required`). Non-remediable findings halt (`HALT_NON_REMEDIABLE`) or wait (`AWAITING_CI`): they receive remediation inputs but no remediation plan target and no `atomic_planner` handoff.
+
 ## Required Remediation Inputs
 
 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:

package/resources/codex-and-agents-customizations/.codex/agents/feature-reviewer-c1.toml

@@ -46,6 +46,7 @@ Review constraints:
 
 Acceptance and remediation rules:
 - Trigger remediation if policy audit has FAIL or meaningful PARTIAL findings, toolchain checks fail, blockers exist in code review, or required acceptance criteria are not fully met.
+- When every blocking finding is non-remediable (remediability external_dependency, policy_hold, awaiting_ci, or human_decision_required, with no autonomous finding), report REVIEW_STATUS: HALT_NON_REMEDIABLE or REVIEW_STATUS: AWAITING_CI with REMEDIATION_PLAN: NONE, create no remediation plan target, and do not delegate to atomic-planner.
 - When remediation is triggered, generate remediation-inputs first.
 - Then automatically delegate remediation planning to the atomic-planner agent; do not leave remediation as a manual follow-up.
 - Create the remediation plan target file on disk before the planning handoff.

package/resources/codex-and-agents-customizations/.codex/agents/feature-reviewer-c2.toml

@@ -46,6 +46,7 @@ Review constraints:
 
 Acceptance and remediation rules:
 - Trigger remediation if policy audit has FAIL or meaningful PARTIAL findings, toolchain checks fail, blockers exist in code review, or required acceptance criteria are not fully met.
+- When every blocking finding is non-remediable (remediability external_dependency, policy_hold, awaiting_ci, or human_decision_required, with no autonomous finding), report REVIEW_STATUS: HALT_NON_REMEDIABLE or REVIEW_STATUS: AWAITING_CI with REMEDIATION_PLAN: NONE, create no remediation plan target, and do not delegate to atomic-planner.
 - When remediation is triggered, generate remediation-inputs first.
 - Then automatically delegate remediation planning to the atomic-planner agent; do not leave remediation as a manual follow-up.
 - Create the remediation plan target file on disk before the planning handoff.

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

@@ -46,6 +46,7 @@ Review constraints:
 
 Acceptance and remediation rules:
 - Trigger remediation if policy audit has FAIL or meaningful PARTIAL findings, toolchain checks fail, blockers exist in code review, or required acceptance criteria are not fully met.
+- When every blocking finding is non-remediable (remediability external_dependency, policy_hold, awaiting_ci, or human_decision_required, with no autonomous finding), report REVIEW_STATUS: HALT_NON_REMEDIABLE or REVIEW_STATUS: AWAITING_CI with REMEDIATION_PLAN: NONE, create no remediation plan target, and do not delegate to atomic-planner.
 - When remediation is triggered, generate remediation-inputs first.
 - Then automatically delegate remediation planning to the atomic-planner agent; do not leave remediation as a manual follow-up.
 - Create the remediation plan target file on disk before the planning handoff.

package/resources/codex-and-agents-customizations/.codex/agents/feature-reviewer-c3.toml

@@ -46,6 +46,7 @@ Review constraints:
 
 Acceptance and remediation rules:
 - Trigger remediation if policy audit has FAIL or meaningful PARTIAL findings, toolchain checks fail, blockers exist in code review, or required acceptance criteria are not fully met.
+- When every blocking finding is non-remediable (remediability external_dependency, policy_hold, awaiting_ci, or human_decision_required, with no autonomous finding), report REVIEW_STATUS: HALT_NON_REMEDIABLE or REVIEW_STATUS: AWAITING_CI with REMEDIATION_PLAN: NONE, create no remediation plan target, and do not delegate to atomic-planner.
 - When remediation is triggered, generate remediation-inputs first.
 - Then automatically delegate remediation planning to the atomic-planner agent; do not leave remediation as a manual follow-up.
 - Create the remediation plan target file on disk before the planning handoff.