@danmoisan/drm-copilot-mcp 1.1.16 → 1.1.18

package/resources/claude-customizations/.claude/skills/epic-orchestrate/SKILL.md

@@ -123,6 +123,8 @@ checkpoint write, and on CI-green (S9 step 6) merges its own PR into the integra
 recording `epic_merge: { merge_commit_sha, target_branch, merged_at }`. Standalone (non-epic)
 orchestration is unchanged: `epic_mode` absent or `false` makes S9 step 6 a no-op.
 
+The run gates `enforce-orchestration-preimplementation-gate.ps1` and `enforce-epic-wave-barrier.ps1` locate the epic checkpoint by the `integration_branch:` value of this line. They select the live worktree whose `artifacts/orchestration/epic-orchestrator-state.json` records `route_id` `epic` and that integration branch, prefer the worktree that has the branch checked out when more than one records it, and deny the delegation with `TARGET_WORKTREE_NOT_DERIVABLE` or `TARGET_WORKTREE_AMBIGUOUS` when none or more than one remains. A stale copy of the epic checkpoint is moved to `artifacts/orchestration/handoff/` rather than left at a worktree root. The child run's own delegations to implementation agents carry the canonical issue-number line and `branch:` label defined in `.claude/skills/orchestrate/SKILL.md` `## Issue Number Consistency`.
+
 ## Bounded Child Return Contract
 
 A child `orchestrator`'s final report is consumed as a fixed eight-field shape and nothing else:
@@ -219,9 +221,10 @@ Procedure, triggered by S9 step 6's merge failure:
 3. The existing R1–R5 loop processes this finding exactly as a local blocking finding:
    `atomic-planner` (R1) plans the resolution, `atomic-executor` performs preflight (R2) then
    resolves the conflict markers, stages, and commits (R3), `feature-review` re-audits (R4).
-4. The child's own `remediation_pass` counter is shared with local-finding and CI-failure passes
-   (cap 3), unmodified.
-5. On the third conflict pass without resolution, the child's `orchestrator` records
+4. Conflict cycles share the child's own `remediation_loop.completed_attempts` count with
+   local-finding and CI-failure cycles. The active cycle number is `completed_attempts + 1`, and a
+   cycle without an applied candidate consumes no number.
+5. After three completed attempts without resolution, the child's `orchestrator` records
    `step9_status: "blocked_conflict_loop_limit"` (parallel to `blocked_ci_loop_limit`), does not
    write DONE, and halts. It reports this status to `epic-orchestrator`, which mirrors it into
    the epic checkpoint's per-feature `merge_status: "blocked_conflict_loop_limit"` field.
@@ -240,9 +243,15 @@ cross-call/conversation-state visibility.
   dependency's `merge_status` is `merged` or `worktree_removed`.
 - **Layer 2 — retrospective backstop:** the wave-barrier ordering invariant inside
   `validate_epic_orchestrator_state_text`, enforced at `epic-orchestrator` `SubagentStop` time via
-  the parameterized `validate-orchestrator-output.ps1` hook. It appends
-  `EPIC_WAVE_BARRIER_VIOLATION: <f> started before dependency <d> merged` when a dependency edge's
-  timing invariant is violated.
+  the parameterized `validate-orchestrator-output.ps1` hook. It checks only a dependent feature
+  that is treated as started: one with a string `worktree_created_at`, or with a `merge_status`
+  other than `not_started` (a missing or non-string `merge_status` counts as started). It appends
+  exactly one error per violated dependency edge. When the dependency's `merge_status` is not
+  `merged` or `worktree_removed`, the error is
+  `EPIC_WAVE_BARRIER_VIOLATION: <f> is treated as started while dependency <d> is not merged`.
+  Otherwise, when the dependency's `merge_confirmed_at` is later than the dependent's
+  `worktree_created_at`, the error is
+  `EPIC_WAVE_BARRIER_VIOLATION: <f> worktree_created_at precedes dependency <d> merge_confirmed_at`.
 
 Both layers are required; neither alone closes the gap. `epic-orchestrator` does not launch wave
 N+1 until every wave-N feature's dependency edges are durably confirmed merged, verified against

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

@@ -46,6 +46,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/`
@@ -110,6 +112,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/claude-customizations/.claude/skills/feature-promotion-lifecycle/SKILL.md

@@ -40,6 +40,16 @@ Each `delegation_receipts.promotion.*` field stores the raw MCP receipt payload
 
 Note: VS Code command-palette commands may exist for interactive extension use, but this note is non-authoritative for agent sessions.
 
+## Pre-Existing Issue Path
+
+When the GitHub issue already exists (it was transferred, filed before orchestration, or created by epic decomposition), do not call `potential_to_issue`: that tool creates a new issue and would duplicate the existing one. Instead:
+
+1. Verify the issue read-only with `gh issue view`, a `gh api` GET request, or a GitHub MCP issue read, and use its number as `${issue-num}`.
+2. Record a top-level `issue_adoption` object in the orchestrator checkpoint (`issue_num`, `issue_url`, `origin`, `verified_via`, `verified_at`, `evidence`, `waived_tools`, and `potential_record` when a promotion-entry tool is waived). A valid record waives the `potential_to_issue` receipt requirement at completion.
+3. `delegation_receipts.promotion.issue` may be omitted, because no promotion receipt exists for an adopted issue.
+
+The field rules, the closed set of waivable tools, and the fail-closed behavior are defined in `.claude/rules/orchestrator-state.md` under `## Invariants (issue_adoption object)`.
+
 ## Canonical Variables
 
 - `${promotion-type}`: `feature` or `bug`

package/resources/claude-customizations/.claude/skills/feature-review-workflow/SKILL.md

@@ -72,7 +72,7 @@ If the branch diff modifies any path matching `.github/workflows/**`, `scripts/b
 - The rule provides a second, independent line of defense for CI-gate-modifying features, separate from and prior to the orchestrator's S9 CI green gate.
 - "Green workflow run against the branch head" means a workflow run whose head SHA matches the current branch head and whose conclusion is success for the affected workflow.
 - A green `workflow_dispatch` run against the branch head also satisfies the rule, not only a PR-context run. This mitigates the chicken-and-egg case where a feature must land its CI gate before the gate can run in PR context (see spec.md Risks & Mitigations).
-- When the rule fires and no qualifying green-run evidence is present, record a Blocking finding and route it through the standard remediation handoff. The supporting validator `scripts/feature-review/Test-ModifiedWorkflowNeedsGreenRun.ps1` implements the trigger-path and evidence-presence logic.
+- When the rule fires and no qualifying green-run evidence is present, record a Blocking finding classified `awaiting_ci` (the remediation inputs carry `Remediability: awaiting_ci` and a `Remediability-Evidence:` line naming the awaited workflow) and route it to the wait path (`AWAITING_CI` when no other class is present) instead of the remediation handoff.
 
 ## Ordered Procedure
 
@@ -147,6 +147,8 @@ If the branch diff modifies any path matching `.github/workflows/**`, `scripts/b
      - 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: each receives one remediability class (`autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, or `human_decision_required`; `autonomous` when no class is stated). A published MCP runtime that lags the repository contract is classified `external_dependency`.
+   - Trigger the remediation handoff only when at least one blocking finding is `autonomous`. When every blocking finding is non-remediable, write the remediation inputs with the `HALT_NON_REMEDIABLE` or `AWAITING_CI` verdict and create no remediation plan target.
    - 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`.

package/resources/claude-customizations/.claude/skills/invoke-csharp-engineer/SKILL.md

@@ -42,6 +42,10 @@ The worker must return the following reporting block:
 4. Diffs (patch-style or full-file replacements).
 5. QA Gate Results (CSharpier, .NET Analyzers, Nullable Analysis, xUnit, and coverage deltas, or clearly marked **unverified**).
 
+## Delegation Identity Lines
+
+Every delegation prompt this skill sends to `csharp-typed-engineer` carries the canonical issue-number line (`Canonical issue number for this feature is <issue_num>. All artifact content, file paths, and cross-references must use this number.`) and a `branch: <name>` label naming the branch checked out in the item's worktree, written as the first `branch:` occurrence in the prompt. `enforce-orchestration-preimplementation-gate.ps1` resolves the item's worktree from these two lines and denies a delegation that carries neither with `TARGET_WORKTREE_NOT_DERIVABLE`.
+
 ## Worker Routing
 
 - Worker: `csharp-typed-engineer`

package/resources/claude-customizations/.claude/skills/invoke-powershell-engineer/SKILL.md

@@ -41,6 +41,10 @@ The worker must return the `powershell-qa-gate` reporting block:
 4. Diffs (patch-style or full-file replacements).
 5. QA Gate Results (PSScriptAnalyzer, Pester, and coverage deltas, or clearly marked **unverified**).
 
+## Delegation Identity Lines
+
+Every delegation prompt this skill sends to `powershell-typed-engineer` carries the canonical issue-number line (`Canonical issue number for this feature is <issue_num>. All artifact content, file paths, and cross-references must use this number.`) and a `branch: <name>` label naming the branch checked out in the item's worktree, written as the first `branch:` occurrence in the prompt. `enforce-orchestration-preimplementation-gate.ps1` resolves the item's worktree from these two lines and denies a delegation that carries neither with `TARGET_WORKTREE_NOT_DERIVABLE`.
+
 ## Worker Routing
 
 - Worker: `powershell-typed-engineer`

package/resources/claude-customizations/.claude/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 -> Pytest toolchain, the 3-production + 3-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 -> Pytest toolchain, the 1-3 production-file direct-mode budget with 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 (`/orchestrate`) 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
 
@@ -42,6 +41,10 @@ The worker must return the `python-qa-gate` reporting block:
 4. Diffs (patch-style or full-file replacements).
 5. QA Gate Results (Ruff, Pyright, Pytest, and coverage deltas, or clearly marked **unverified**).
 
+## Delegation Identity Lines
+
+Every delegation prompt this skill sends to `python-typed-engineer` carries the canonical issue-number line (`Canonical issue number for this feature is <issue_num>. All artifact content, file paths, and cross-references must use this number.`) and a `branch: <name>` label naming the branch checked out in the item's worktree, written as the first `branch:` occurrence in the prompt. `enforce-orchestration-preimplementation-gate.ps1` resolves the item's worktree from these two lines and denies a delegation that carries neither with `TARGET_WORKTREE_NOT_DERIVABLE`.
+
 ## Worker Routing
 
 - Worker: `python-typed-engineer`

package/resources/claude-customizations/.claude/skills/orchestrate/SKILL.md

@@ -81,7 +81,7 @@ blocked result before launch.
 
 Because model selection is required once delegation occurs (see `## Model Selection`), a resuming orchestrator must repair a missing model choice deterministically before delegating at a delegating `next_step`. When the resumed `next_step` is a delegating step:
 
-a. **Preflight the checkpoint.** Run the orchestrator-state validator with `--require-model-routing` (via `mcp__drm-copilot__validate_orchestration_artifacts` or the local CLI) against `artifacts/orchestration/orchestrator-state.json` before the first delegation. Record the result in a `model_routing_preflight` block `{ status ("pass"|"fail"), checked_at (ISO-8601 UTC), validator_command, output_summary }`.
+a. **Preflight the checkpoint.** Run the orchestrator-state validator with `--require-model-routing` (via `mcp__drm-copilot__validate_orchestration_artifacts` or the repository-local validator CLI documented in `.claude/rules/orchestrator-state.md`) against `artifacts/orchestration/orchestrator-state.json` before the first delegation. Record the result in a `model_routing_preflight` block `{ status ("pass"|"fail"), checked_at (ISO-8601 UTC), validator_command, output_summary }`.
 b. **Recompute the floor.** For the upcoming phase, recompute the complexity floor with `Get-ComplexityFloor -SignalsPresent <names>` (`.claude/lib/model-routing/ModelRouting.psm1`); do not reimplement the formula.
 c. **Record the assessment.** Write a `complexity_assessments[]` entry `{ phase, band, floor, signals_present[], rationale, assessed_at }` with `floor` equal to the recomputed value and `band >= floor`.
 d. **Resolve and record the receipt.** Resolve the model with `Resolve-DelegationModel -Agent <agent> -Band <complexity_band> -FablePolicy <fable_policy>` (`.claude/lib/model-routing/ModelRouting.psm1`) and write a `model_routing_receipts[]` entry `{ agent, phase, complexity_band, fable_policy, table_model, clamped_from | null, model }`.
@@ -137,6 +137,7 @@ A delegation prompt carrying the literal marker `Preparation mode: true` (issued
 - **Route.** Select `route_id: preparation`. The route's routing-matrix entry requires receipts for `task-researcher`, `prd-feature`, `atomic-planner`, and `atomic-executor`; the skills `orchestrate`, `feature-promotion-lifecycle`, and `atomic-plan-contract`; and the promotion plus validator MCP tools.
 - **Scope.** Run promotion (MCP surface), research, feature documents (`spec.md`, `user-story.md`), atomic planning, and the atomic-executor preflight (precondition validation only, R2 semantics: iterate plan revisions until `PREFLIGHT: ALL CLEAR`). Atomic execution, PR authoring, CI monitoring, and feature review are out of scope and are executed later by `epic-orchestrator`.
 - **Terminal checkpoint.** Stop with `completed_steps` containing `S3_promotion` and `S4_atomic_planning`, `next_step: "S5_atomic_execution"`, out-of-scope step statuses set to `not-applicable`, and `blocked_reason: "none"`. Do NOT assert completion (`next_step: "complete"`, `S12_complete`, or a `completed` step8/9/10 status): the run has no PR or CI evidence, and the route's `requires_ci_gate: false` exempts it from `ci_gate` at the completion validator instead.
+- **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`.
 - **Commit.** Commit the prepared feature folder and plan to the current branch (the worktree branch created off the epic integration branch) before stopping, and report the `plan-path` and preflight status in the final output.
 
 ## Epic Mode Bounded Return
@@ -184,7 +185,7 @@ PR creation and PR body edits are delegated work, not orchestrator work. The orc
 The mandatory sequence is:
 
 1. The orchestrator first refreshes the PR-context artifact via `mcp__drm-copilot__collect_pr_context` (or the equivalent context-collection mechanism), which writes `artifacts/pr_context.summary.txt`.
-2. The orchestrator runs the orchestrator-state validator (`mcp__drm-copilot__validate_orchestration_artifacts` or the equivalent local CLI call) against `artifacts/orchestration/orchestrator-state.json --require-pr-creation-ready` and records the pass/fail result under a new `pr_author_preflight` field in the checkpoint, alongside `pr_author_receipt`: `{status ("pass"|"fail"), checked_at (ISO-8601 UTC), checkpoint_path, validator_command, output_summary}`. The orchestrator must not delegate to `Agent(pr-author)` when this preflight fails. The validator's full-lifecycle completion flag (`ci_gate`/`pr_gate`/routing-contract receipts) remains reserved for the post-PR/CI completion context (Step S9 / PR Creation Gate condition 6), not this pre-PR-creation preflight, because those values cannot exist before the first `gh pr create` of a branch.
+2. The orchestrator runs the orchestrator-state validator (`mcp__drm-copilot__validate_orchestration_artifacts` or the equivalent repository-local validator CLI documented in `.claude/rules/orchestrator-state.md`) against `artifacts/orchestration/orchestrator-state.json --require-pr-creation-ready` and records the pass/fail result under a new `pr_author_preflight` field in the checkpoint, alongside `pr_author_receipt`: `{status ("pass"|"fail"), checked_at (ISO-8601 UTC), checkpoint_path, validator_command, output_summary}`. The orchestrator must not delegate to `Agent(pr-author)` when this preflight fails. The validator's full-lifecycle completion flag (`ci_gate`/`pr_gate`/routing-contract receipts) remains reserved for the post-PR/CI completion context (Step S9 / PR Creation Gate condition 6), not this pre-PR-creation preflight, because those values cannot exist before the first `gh pr create` of a branch.
 3. The orchestrator then delegates PR creation and any PR body edits to `Agent(pr-author)`. The `pr-author` agent runs the `pr-author` skill to author the body, writes the body file `artifacts/pr_body_<N>.md` and the sibling receipt `artifacts/pr_body_<N>.receipt.json` with the shape `{skill, pr_body_path, number, sha256 (lowercase hex of the body bytes), context_summary_path, created_at (ISO-8601 UTC, strictly newer than `artifacts/pr_context.summary.txt` last-write)}`, issues `gh pr create --body-file artifacts/pr_body_<N>.md` (or `gh pr edit --body-file ...`), and reports the resulting PR URL or PR number.
 4. The orchestrator records `pr_author_receipt` in the checkpoint, citing the body-file path and the receipt path that were verified.
 
@@ -237,20 +238,32 @@ After each `feature-review` delegation returns:
 
 1. Locate `remediation-inputs.<timestamp>.md` in the active feature folder (match the highest ISO-8601 timestamp).
 2. If no such file exists, treat as zero blocking findings and advance to the PR creation gate.
-3. If the file exists, count lines matching `BLOCKING` or `Severity: Blocking` (case-sensitive). If count >= 1, enter the remediation loop. If count = 0, advance to the PR creation gate.
+3. If the file exists, count lines matching `BLOCKING` or `Severity: Blocking` (case-sensitive). If count >= 1, enter the remediation loop. If count = 0, advance to the PR creation gate. This count rule applies unchanged when the file carries no `Review-Verdict:` line: a count of at least 1 is `REMEDIATION_REQUIRED` and every finding is treated as `autonomous`.
+4. If the file carries a `Review-Verdict:` line, recompute the verdict from the `Remediability:` lines of the blocking findings (a blocking finding block without a `Remediability:` line counts as `autonomous`): no blocking finding is `PASS`; any `autonomous` finding is `REMEDIATION_REQUIRED`; otherwise any `external_dependency`, `policy_hold`, or `human_decision_required` finding is `HALT_NON_REMEDIABLE`; otherwise `AWAITING_CI`. The `remediation-inputs` file is authoritative; the optional `review-status:` token in the review result is a cross-check.
+5. 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.
+6. Append a `remediation_loop.review_outcomes[]` entry (`verdict` plus one `findings[]` object with `remediability` per blocking finding) for every review, including `PASS`.
+7. Act on the verdict: `PASS` advances to the PR creation gate; `REMEDIATION_REQUIRED` enters the remediation loop with the plan scoped to the `autonomous` findings, carrying the non-remediable findings forward unchanged; `HALT_NON_REMEDIABLE` follows the halt branch; `AWAITING_CI` follows the wait branch.
+
+Halt branch (`HALT_NON_REMEDIABLE`): 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
+
+Wait branch (`AWAITING_CI`): set `blocked_reason: "awaiting_ci"` and set `next_step` to the step that re-checks (`S7_feature_review` for a review-time wait, `S9_ci_green` for an S9 poll timeout). Record no `human_interaction.requirements[]` entry for a wait, write no cycle, and create no remediation plan. Poll within the existing bounded S9 interval and timeout; when the bound is exhausted, persist and stop. On resume, set `blocked_reason: "none"` and re-run the named step. For S9, the awaited run is identified by `ci_gate.head_sha` and `ci_gate.pr_pipeline_run_id` with `conclusion: "pending"`; for a review-time wait, the awaited workflow is named in the finding's `Remediability-Evidence:` line.
 
 ## 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`, and `remediation.cycle_N` in `next_step` uses that number; `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"`. Local, CI-failure, merge-conflict, and parallel-drift cycles share the one count.
 
 - **R1 — Remediation planning:** Delegate to `atomic-planner` with `remediation-inputs.<timestamp>.md` path as primary context. Receive `remediation-plan.<timestamp>.md` in the active feature folder.
 - **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 and re-delegate to `atomic-planner` 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`), delegate to `Agent(commit-message)` to generate a commit message from the staged diff (the agent returns message text only and does not commit), then commit with the generated message. The `git commit` action remains on the orchestrator. Advance to R4 only after a successful commit.
 - **R4 — Re-audit:** Delegate to `feature-review` 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 produces zero blocking findings, 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 produces zero blocking findings, exit the loop and advance to the PR creation gate. If its verdict is `HALT_NON_REMEDIABLE` or `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
 
@@ -260,7 +273,9 @@ Every delegation prompt to a receipt-gated subagent type — `atomic-planner`, `
 
 > `Canonical issue number for this feature is <issue_num>. All artifact content, file paths, and cross-references must use this number.`
 
-Each such prompt also carries a `branch: <name>` label naming the branch checked out in the item's worktree, written as the first `branch:` occurrence in the prompt. Before promotion assigns an issue number, the branch label alone is required. Two gates, `enforce-model-routing-receipt.ps1` and `enforce-prd-feature-before-planner.ps1`, identify the item from these two lines: they deny a gated delegation they cannot identify rather than checking it against whichever checkpoint occupies the calling session's root, and they never use a feature-folder path to choose the worktree, because a merged feature folder exists in every checkout branched from main.
+Each such prompt also carries a `branch: <name>` label naming the branch checked out in the item's worktree, written as the first `branch:` occurrence in the prompt. Before promotion assigns an issue number, the branch label alone is required. Three gates, `enforce-model-routing-receipt.ps1`, `enforce-prd-feature-before-planner.ps1`, and `enforce-orchestration-preimplementation-gate.ps1`, identify the item from these two lines: they deny a gated delegation they cannot identify rather than checking it against whichever checkpoint occupies the calling session's root, and they never use a feature-folder path to choose the worktree, because a merged feature folder exists in every checkout branched from main.
+
+The same two lines are required on every delegation to an implementation agent (`python-typed-engineer`, `powershell-typed-engineer`, `typescript-engineer`, `csharp-typed-engineer`, and `atomic-executor`) and on every `Agent(orchestrator)` delegation that carries no epic-mode, parallel-mode, or preparation-mode kickoff marker. `enforce-orchestration-preimplementation-gate.ps1` resolves such a delegation's worktree from these lines and denies it with `TARGET_WORKTREE_NOT_DERIVABLE` when neither line is present, or with `TARGET_WORKTREE_AMBIGUOUS` when the lines disagree or match more than one live worktree.
 
 If a subagent artifact references a different issue number, the orchestrator rejects it, requests correction, and records the discrepancy under `artifact_errors` in the checkpoint.
 
@@ -273,10 +288,12 @@ S9 procedure:
 1. Resolve the live PR head SHA for the feature branch (`gh pr view --json headRefOid` or equivalent).
 2. Invoke `gh pr checks --required --json bucket,name,state,link,workflow` (or an equivalent JSON-emitting command) against that head SHA. `gh` is the only sanctioned channel for querying GitHub Actions state.
 3. Parse the JSON by running `pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-CiGateParser.ps1 -ChecksJson <checks-json> -HeadSha <head-sha>`, which emits the `ci_gate` object defined below and derives `ci_gate.conclusion` as `success` when all required checks pass, `failure` when any required check failed, and `pending` when any required check is still in progress.
-4. Poll with a bounded interval and a documented total timeout while `conclusion == "pending"`. When the timeout is exhausted, set `step9_status: "failed_remediation_required"` and enter the remediation-loop CI-failure handling below with a timeout log.
+4. Poll with a bounded interval and a documented total timeout while `conclusion == "pending"`. When the timeout is exhausted, record the timeout as a finding with `Remediability: awaiting_ci` in `remediation-inputs.<timestamp>.md` and follow the wait branch in Post-Review Outcome Evaluation (`blocked_reason: "awaiting_ci"`, `next_step: "S9_ci_green"`); `step9_status` stays `pending`. A poll timeout does not enter the remediation loop.
 5. Write the `ci_gate` object and `last_verified_ci_sha` to the checkpoint, and set `step9_status` to `passed` only when `ci_gate.conclusion == "success"` AND `ci_gate.head_sha` equals the current PR head SHA.
 6. If the checkpoint's `epic_mode` is `true`, execute `gh pr merge --merge <PR>` merging the feature branch into `epic_context.integration_branch` (already the PR's base branch per the epic-mode `--base` override applied at S8). On success, record `epic_merge: { merge_commit_sha, target_branch, merged_at }` in the checkpoint. On failure due to merge conflict (non-mergeable PR), do not retry blindly: convert the conflict into a synthetic Blocking finding per "Merge-Conflict Remediation" below and re-enter the standard R1–R5 remediation loop; do not proceed to DONE.
 
+CI-dependent acceptance criteria: when the item has acceptance criteria whose verification requires the result of CI on the PR head, the item's own orchestrator run owns their check-off, and a parent or coordinating session never commits them from its own root. After step 5 records `ci_gate.conclusion == "success"`, check off each CI-dependent criterion in the item's own worktree, commit, push to the PR branch, and re-run S9 from step 1 against the new head SHA, so that `ci_gate.head_sha` equals the final PR head before DONE. In epic mode this completes before step 6 merges. A failed re-run enters `## Remediation Loop — CI-Failure Handling` below; the shared `remediation_loop.completed_attempts` count and its halt after three completed attempts are unchanged.
+
 DONE is not written while `step9_status` is anything other than `passed`.
 
 ## Checkpoint Schema — CI Gate Fields
@@ -319,13 +336,13 @@ A checkpoint that predates this schema and has no `ci_gate` object (or no `step9
 
 ## Remediation Loop — CI-Failure Handling
 
-When S9 records `step9_status: "failed_remediation_required"` (a failed required check or an exhausted poll timeout):
+When S9 records `step9_status: "failed_remediation_required"` (a failed required check; a poll timeout follows the wait branch per S9 step 4):
 
-1. The failed-check log from `gh run view <run-id> --log-failed` (or the timeout log) is written as `remediation-inputs.<timestamp>.md` in the active feature folder.
+1. The failed-check log from `gh run view <run-id> --log-failed` is written as `remediation-inputs.<timestamp>.md` in the active feature folder.
 2. The failure is converted to a synthetic finding with severity `Blocking` that identifies the failing check by name and the failing job by URL.
 3. The existing R1-R5 remediation loop processes that finding exactly as it processes a local blocking finding. No new loop is introduced.
-4. The `remediation_pass` counter is shared with local-finding passes; the cap is 3.
-5. On the third CI-failure pass without resolution, the orchestrator records `step9_status: "blocked_ci_loop_limit"`, does not write DONE, and halts. No further automation is attempted.
+4. CI-failure cycles share `remediation_loop.completed_attempts` with local-finding cycles; a CI-failure finding stays `autonomous`, and the active cycle number is `completed_attempts + 1`.
+5. The shared guard applies: after three completed attempts without a passing result, the orchestrator records `step9_status: "blocked_ci_loop_limit"`, does not write DONE, and halts. No further automation is attempted.
 
 ## PR Creation Gate
 
@@ -333,6 +350,7 @@ The orchestrator must not create a PR, push a branch for PR purposes, or report
 
 1. `blocking_findings_resolved: true` — the most recent `feature-review` produced zero blocking findings.
 2. The AC verification artifact (`p14-acceptance-criteria-checkoff.md` or equivalent) confirms all acceptance criteria pass.
+   A CI-dependent acceptance criterion, one whose verification requires the result of CI on the PR head, cannot pass before CI exists: condition 2 is satisfied when every other criterion passes and each CI-dependent criterion is listed as pending-CI in the AC verification artifact. Pending-CI criteria are checked off under S9 before DONE. This clarifies condition 2 and adds no condition.
 3. The mandatory toolchain passed in its most recent run on the branch (no linting/type-check/test failures).
 4. The checkpoint `next_step` is `S8_create_pr` (precondition to entering S9).
 5. PR body produced via the pr-author handoff: `artifacts/pr_body_<N>.md` exists with a matching `artifacts/pr_body_<N>.receipt.json`, created with `--body-file`.
@@ -418,6 +436,8 @@ Example:
 ]
 ```
 
-The validator counts an MCP receipt as successful only when `tool` is a non-empty string, `ok` is exactly `true`, and `evidence` is a non-empty string. Every `required_mcp_tools` entry must have such a receipt.
+The validator counts an MCP receipt as successful only when `tool` is a non-empty string, `ok` is exactly `true`, and `evidence` is a non-empty string. Every `required_mcp_tools` entry must have such a receipt unless a valid `issue_adoption` record waives it.
+
+When the GitHub issue already exists before orchestration starts (transferred, filed by hand, or created by epic decomposition) and has been verified read-only (`gh issue view`, a `gh api` GET, or a GitHub MCP issue read), do not call `potential_to_issue`. Record a top-level `issue_adoption` object in the checkpoint instead of a `potential_to_issue` receipt. It may waive only `potential_to_issue` and, with a valid `potential_record` under `docs/features/potential/`, the checkpoint's promotion-entry tool (`new_potential_entry`, or `new_potential_bug_entry` for a bug-type checkpoint); `potential_to_issue` must always be listed. Every other required tool still needs a successful receipt. Any adoption error waives nothing. The field rules, the closed waivable set, and the error placement are defined in `.claude/rules/orchestrator-state.md` under `## Invariants (issue_adoption object)`.
 
 These three receipt arrays, populated with the retained required names of the selected route, are what allow the routing-contract validation under `require_complete: true` to pass.

package/resources/claude-customizations/.claude/skills/parallel-orchestrate/SKILL.md

@@ -277,6 +277,8 @@ Negative obligations on the prompt:
 Excluded from the prompt as parent-side concerns: the item's declared blast radius,
 `max_concurrency`, and `mode`. Keeping the prompt minimal preserves the child contract unchanged.
 
+The run gates `enforce-orchestration-preimplementation-gate.ps1`, `enforce-parallel-cohort-barrier.ps1`, and `enforce-parallel-drift-gate.ps1` locate the parallel checkpoint by the `parallel_slug:` value of the marker line. They select the single live worktree whose `artifacts/orchestration/parallel-orchestrator-state.json` records `route_id` `parallel` and that slug, and deny the delegation with `TARGET_WORKTREE_NOT_DERIVABLE` or `TARGET_WORKTREE_AMBIGUOUS` when none or more than one matches. The child run's own delegations to implementation agents carry the canonical issue-number line and `branch:` label defined in `.claude/skills/orchestrate/SKILL.md` `## Issue Number Consistency`.
+
 ## Model Selection
 
 When `parallel-orchestrator` delegates an item to `Agent(orchestrator)`, the prompt appends the
@@ -311,6 +313,12 @@ unchanged: `.claude/skills/orchestrate/SKILL.md` is **not modified by this featu
 `parallel_mode` clause in its step 9, no `parallel_merge` object in the child checkpoint, and no
 additional condition on the child's PR Creation Gate.
 
+Issue #744 later amended two parts of that child contract for CI-dependent acceptance criteria,
+whose verification requires the result of CI on the item's pull-request head: PR Creation Gate
+condition 2 and step S9 of `.claude/skills/orchestrate/SKILL.md`. The child checks those criteria
+off in its own worktree, pushes the check-off commit to its pull-request branch, and re-runs S9
+before DONE. The parent never commits acceptance-criteria check-offs from the coordinator root.
+
 Procedure, per item:
 
 1. The item's child orchestration runs unmodified, with `epic_mode` `false` or absent, and finishes
@@ -321,6 +329,11 @@ Procedure, per item:
    `gh pr view --json state,mergedAt,headRefOid`, and with `gh pr checks` when the check conclusion
    must be re-read — never from an in-memory completion notification — then record
    `merge_status: ci_green`.
+   Before recording `merge_status: ci_green`, confirm that the `headRefOid` value equals the
+   `ci_gate.head_sha` the child reported at DONE and that the child reported no pending
+   CI-dependent acceptance criteria. When either check fails, do not record
+   `merge_status: ci_green` and do not run `gh pr merge`; the item waits until its child pushes
+   the check-off and re-runs S9, and the parent does not commit the check-off itself.
 3. Execute `gh pr merge --merge <PR>` for that item's pull request, whose base is `main`.
 4. On success, record `merge_commit_sha`, `merged_at`, and `merge_status: merged`, then regenerate
    `docs/features/parallel/<slug>/parallel-status.md`.
@@ -415,8 +428,10 @@ the escalation path.
 2. The parent re-delegates that item's child orchestration. The child processes the finding through
    its unmodified R1 through R5 remediation loop exactly as it processes any local Blocking
    finding. No new remediation loop is introduced by this procedure.
-3. The child's `remediation_pass` counter is shared with its local-finding and CI-failure passes,
-   with the cap of 3, unmodified.
+3. Drift cycles share the child's `remediation_loop.completed_attempts` count with its
+   local-finding and CI-failure cycles, and the child halts after three completed attempts. The
+   active cycle number is `completed_attempts + 1`, and a cycle without an applied candidate
+   consumes no number.
 4. Each remediated pass ends again at child DONE with the pull request open and CI green, after
    which the parent retries the merge per `## Per-Item Merge to Main (Merge-on-Green)`. During
    remediation the item's `merge_status` legitimately remains `pr_open` or `ci_green`: the
@@ -565,6 +580,8 @@ hold:
    `artifact_type: "parallel-orchestrator-state"`.
 4. Each item's acceptance criteria have been checked off in that item's own acceptance-criteria
    source files by that item's own run, per the `acceptance-criteria-tracking` skill.
+   A CI-dependent criterion is checked off and pushed by that item's own run before its DONE, so
+   the head the parent merges already contains the check-off; the parent never commits it.
 
 In `open` mode there is no automatic completion. The run is a standing queue and terminates only via
 `/parallel-close`, which is owned by F6 and is neither specified nor shipped by this feature. Do not
@@ -729,8 +746,8 @@ a detached item.
 ### Abandon confirmation-marker contract
 
 The `abandon` disposition is destructive: it closes the item's pull request and removes its
-worktree. Both side effects run through ONE deterministic CLI invocation of
-`scripts/dev_tools/parallel_mutation_abandon_cli.py`, documented in full in
+worktree. Both side effects run through ONE deterministic invocation of the bundled bash entry
+point `.claude/lib/bash/abandon-parallel-item.sh`, documented in full in
 `.claude/skills/parallel-remove/SKILL.md`. Executing the abandon disposition through ad hoc `gh` or
 `git` commands is prohibited, because an ad hoc command is not matchable and would bypass the
 confirmation contract.
@@ -875,25 +892,35 @@ carries no such marker, evaluates no drift, and is unaffected.
 
 #### CLI Invocation
 
-Detection logic is pure and lives in `scripts/dev_tools/parallel_drift_detection.py` (escape
-detection, `drift_events[]` construction, the derived quiesce predicate, and conflict recomputation)
-and `scripts/dev_tools/parallel_drift_halt.py` (halt selection and the requeue seam). All I/O is
-confined to the thin wrapper `scripts/dev_tools/parallel_drift_detection_cli.py`, invoked as:
+Detection logic is pure and lives in `.claude/lib/parallel-drift/ParallelDrift.psm1` (escape
+detection, `drift_events[]` construction, and conflict recomputation) and
+`.claude/lib/parallel-drift/ParallelDriftHalt.psm1` (halt selection). The first calls the bundled
+blast-radius library under `.claude/lib/blast-radius/` rather than re-deriving it. All I/O is confined
+to the destination-runtime entry point `.claude/lib/parallel-drift/Invoke-ParallelDriftDetection.ps1`,
+which needs PowerShell 7 and no Python interpreter, invoked as:
 
 ```
-poetry run python -m scripts.dev_tools.parallel_drift_detection_cli \
-  --item-key <issue_num> \
-  [--checkpoint artifacts/orchestration/parallel-orchestrator-state.json] \
-  [--config config/blast-radius.json] \
-  [--at <yyyy-MM-ddTHH-mm>] [--computed-at <yyyy-MM-ddTHH-mm>] \
+pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-drift/Invoke-ParallelDriftDetection.ps1 \
+  -ItemKey <issue_num> \
+  [-CheckpointPath artifacts/orchestration/parallel-orchestrator-state.json] \
+  [-ConfigPath config/blast-radius.json] \
+  [-At <yyyy-MM-ddTHH-mm>] [-ComputedAt <yyyy-MM-ddTHH-mm>] \
   <CHANGED_PATH>...
 ```
 
-Argument surface: `--item-key` is the only required argument and is the item's `issue_num`;
-`--checkpoint` and `--config` default to the two paths shown; `--at` is the timestamp recorded on
-the `drift_events[]` entry and `--computed-at` the timestamp recorded on the observed radius, each
-defaulting at the I/O boundary so the pure functions never read a clock; and the changed paths are
-positional and variadic. An empty changed-path list is legal and yields `no_escape`.
+The Python modules `scripts/dev_tools/parallel_drift_detection.py` and
+`scripts/dev_tools/parallel_drift_halt.py`, with their thin wrapper
+`scripts/dev_tools/parallel_drift_detection_cli.py`, remain the repository authority and the parity
+reference; the shared corpus under `tests/fixtures/parallel_drift/` binds the two, and the Python
+modules are not invoked on the destination-runtime path.
+
+Argument surface: `-ItemKey` is the only required argument and is the item's `issue_num`;
+`-CheckpointPath` and `-ConfigPath` default to the two paths shown and resolve against the caller's
+working directory; `-At` is the timestamp recorded on the `drift_events[]` entry and `-ComputedAt` the
+timestamp recorded on the observed radius, each defaulting at the I/O boundary so the pure functions
+never read a clock; and the changed paths are positional and variadic. No parameter is mandatory, so
+a missing `-ItemKey` exits `2` instead of prompting. An empty changed-path list is legal and yields
+`no_escape`.
 
 The changed-path list is an argument, not something the module derives: the caller produces it with
 `git diff --name-only <merge-base(origin/main, HEAD)> HEAD` at the child's pre-review commit, and
@@ -930,7 +957,8 @@ escaped paths is not a drift event. `observed_radius` is the serialized observed
 parent writes back in step 7 of `#### Seven-Step Procedure`: it carries the six invariant-9 keys with
 `source: observed`, is built by F1's library rather than by hand, and is `null` exactly when `result`
 is `no_escape`, on the same precondition as `drift_event`. Exit status is `0` on success, `1` on
-missing or malformed input, and argparse's `2` on a usage error.
+missing or malformed input (one stderr line prefixed "parallel drift detection failed: "), and `2`
+on a usage error, such as a missing or non-integer `-ItemKey` or an unrecognized parameter.
 
 #### Synthetic Blocking Finding
 
@@ -958,7 +986,8 @@ on its own R1 through R5 loop for the drift finding, so halting it would deadloc
 that resolves the drift.
 
 The exclusion is applied **at the call site, before the later-started comparator runs**:
-`halted_item_keys` in `scripts/dev_tools/parallel_drift_detection_cli.py` drops the drifting key from
+`Get-ParallelDriftHaltedItemKey` in `.claude/lib/parallel-drift/ParallelDriftHalt.psm1` (the port of
+`halted_item_keys` in `scripts/dev_tools/parallel_drift_detection_cli.py`) drops the drifting key from
 each pair's candidate list, then halts the single remaining candidate, or applies the comparator when
 two remain. Because a recomputed pair holds two distinct canonical keys, the candidate list is always
 one or two entries and can never be empty. It remains true, and remains a real structural guarantee,
@@ -1099,7 +1128,7 @@ R5 loop that drives the remediation preceding either write is **reused
 unmodified**: `atomic-planner` plans the resolution, `atomic-executor` performs preflight then
 resolves, `feature-review` re-audits, and the loop exits on zero blocking findings. No new
 remediation loop is authored, no line of the existing loop is modified, and the shared
-`remediation_pass` cap of 3 applies. `.claude/skills/orchestrate/SKILL.md` is not modified by this
+`remediation_loop.completed_attempts` count applies, with the halt after three completed attempts. `.claude/skills/orchestrate/SKILL.md` is not modified by this
 feature.
 
 #### Layer-1 Narrowing — a Documented Limitation

package/resources/claude-customizations/.claude/skills/parallel-remove/SKILL.md

@@ -108,8 +108,8 @@ Do not record a partial removal, and do not record the rejection itself in `muta
    removing the worktree — through the single deterministic CLI invocation below and through nothing
    else:
 
-   ```bash
-   poetry run python scripts/dev_tools/parallel_mutation_abandon_cli.py --item <key> --disposition abandon --confirm-abandon --pr <pr-number> --worktree <worktree-path>
+   ```shell
+   bash .claude/lib/bash/abandon-parallel-item.sh --item <key> --disposition abandon --confirm-abandon --pr <pr-number> --worktree <worktree-path>
    ```
 
    Executing the abandon disposition through ad hoc `gh pr close` or `git worktree remove` commands
@@ -146,14 +146,14 @@ The abandon path is guarded by the PreToolUse hook
 - A command carrying both tokens is allowed.
 - A command carrying neither is out of scope and is allowed unchanged.
 
-The two token values are declared once each in
-`scripts/dev_tools/parallel_mutation_abandon_cli.py` (the producer) and once each in the hook (the
-consumer), and the seam test
-`tests/scripts/dev_tools/test_parallel_abandon_token_seam.py` parses all three artifacts — the CLI,
-the hook, and the invocation line in step 5 above — at run time to prove they still agree. Renaming
-a token in one artifact without the identical rename in the other two fails that test. The
-invocation in step 5 is the file's only executable abandon command line, and the seam test parses
-that one line; do not add a second one.
+The two token values are declared once each in `.claude/lib/bash/abandon-parallel-item.sh` (the
+pushed-down producer), once each in `scripts/dev_tools/parallel_mutation_abandon_cli.py` (the retained
+Python parity reference), and once each in the hook (the consumer). The seam test
+`tests/scripts/dev_tools/test_parallel_abandon_token_seam.py` parses all four artifacts — the bundled
+entry point, the Python reference, the hook, and the invocation line in step 5 above — at run time
+to prove they still agree. Renaming a token in one artifact without the identical rename in the
+others fails that test. The invocation in step 5 is the file's only executable abandon command
+line, and the seam test parses that one line; do not add a second one.
 
 When the gate denies a command, the correct response is to add the confirmation marker
 deliberately, not to reformulate the command to evade the match. Reformulating to evade the gate

package/resources/claude-customizations/.claude/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 `/orchestrate` (the `orchestrator` agent).
 
 ## When to Use This Skill
 
@@ -14,50 +14,27 @@ 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** (`/orchestrate`, the `orchestrator` agent). 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 `/orchestrate`.
+- Do not request an exception to the threshold; routing is the only path past it.
 
 ## Orchestrated Small-Path Requirements
 
-When routed through the orchestrator, the small path still requires lifecycle scaffolding before implementation:
+When routed through `/orchestrate`, the small path still requires lifecycle scaffolding before implementation:
 
 - invoke promotion and folder lifecycle steps through `vscode/runCommand` and extension access per `feature-promotion-lifecycle` when available. Use script or CLI fallback only when direct extension command execution is unavailable.
 - promote the potential item to a GitHub issue with `--work-mode minor-audit`,
@@ -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/claude-customizations/.claude/skills/remediation-handoff-atomic-planner/SKILL.md

@@ -54,6 +54,8 @@ Trigger remediation when any of these are true:
 - Acceptance criteria are not met.
 - A required CI check fails after the PR is open (workflow-file changes specifically must enter the loop and trigger the `modified-workflow-needs-green-run` rule defined in `.claude/skills/feature-review-workflow/SKILL.md`).
 
+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`; `autonomous` when no class is stated). When no blocking finding is `autonomous`, the review verdict is `HALT_NON_REMEDIABLE` or `AWAITING_CI`: the orchestrator halts or waits, and no cycle, remediation plan, or `atomic-planner` handoff is created.
+
 ## Required Remediation Inputs
 
 The orchestrator authors `remediation/<entry-ts>/remediation-inputs.md` with:
@@ -118,11 +120,13 @@ Iteration ceiling. When a cycle's `iterations` would exceed 2, the orchestrator
 
 When preflight is clear, `atomic-executor` executes the plan task-by-task. The executor invokes workers (`python-typed-engineer`, `typescript-engineer`, `csharp-typed-engineer`, `powershell-typed-engineer`) internally as needed. The orchestrator does not call workers.
 
+Before the reaudit, the orchestrator records `candidate_applied` on the current cycle: `true` only when execution finished with `execution_status: "complete"` and the pre-reaudit commit recorded a non-empty change set, and `false` otherwise (execution not started, execution failed, or an empty staged change set). `remediation_loop.completed_attempts` equals the number of cycles whose `candidate_applied` is `true`, and a cycle with `candidate_applied: false` consumes no attempt number.
+
 When execution is complete, the orchestrator delegates to `feature-review`. `feature-review` produces the three reaudit artifacts under `docs/features/active/<slug>/audit/<exit-ts>/` using the exit timestamp.
 
 ## Exit Gate
 
-The orchestrator reads the latest cycle's three reaudit artifacts and computes `blocking_count` as the total number of FAIL findings plus material PARTIAL findings flagged as blocking. Only when `blocking_count == 0` does the orchestrator set `exit_condition_met = true` on the current cycle and mark the remediation loop complete. Otherwise, the orchestrator opens cycle N+1 with a new `remediation/<new-ts>/remediation-inputs.md` and runs the full chain again.
+The orchestrator reads the latest cycle's three reaudit artifacts and computes `blocking_count` as the total number of FAIL findings plus material PARTIAL findings flagged as blocking. Only when `blocking_count == 0` does the orchestrator set `exit_condition_met = true` on the current cycle and mark the remediation loop complete. Otherwise, when at least one remaining blocking finding is `autonomous`, the orchestrator opens cycle N+1 with a new `remediation/<new-ts>/remediation-inputs.md` and runs the full chain again. When the remaining blocking findings are all non-remediable, the orchestrator does not open the next cycle: it halts on `HALT_NON_REMEDIABLE` or waits on `AWAITING_CI`.
 
 ## Context Package (When Required)