@danmoisan/drm-copilot-mcp 1.1.18 → 1.1.20

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

@@ -42,6 +42,11 @@ identical forms.
 - **Promotion.** Unpromoted items are promoted by their own preparation-mode child, not by the
   planner. The `preparation` route already carries the promotion MCP tools (`new_potential_entry`,
   `potential_to_issue`, `new_active_feature_folder`).
+- **Issue adoption.** Issue-number items are adopted, not promoted. The item's GitHub issue
+  already exists, so its preparation child verifies the issue read-only and records a top-level
+  `issue_adoption` object in its checkpoint instead of calling `potential_to_issue` or the
+  promotion-entry tool. The delegation prompt carries that instruction as the issue-adoption line
+  under `## Preparation Fan-Out`.
 - **`issue_num` resolution.** `issue_num` is the primary key for every item reference. It is known
   at intake for issue-number items. For potential-entry items, record negative placeholders in
   intake order (`-1`, `-2`, ...) and back-fill the real number from each child's promotion receipt
@@ -102,11 +107,13 @@ invocations after the initial plan. Use `/parallel-plan` for intake and `/parall
 admit an item into a run that is already in flight.
 
 Each delegation prompt includes this literal kickoff line, followed by the model-budget marker
-line:
+line and, for an issue-number item only, the issue-adoption line:
 
 > `Preparation mode: true. route_id: preparation. parallel_slug: <slug>. Perform promotion, research, feature documents (spec.md, user-story.md), atomic planning, and preflight clearance only. Atomic execution, PR authoring, and CI monitoring are out of scope for this run and are executed later by parallel-orchestrator. After the atomic-executor preflight returns PREFLIGHT: ALL CLEAR, commit the feature folder and plan to the current branch, push the current branch to origin, set out-of-scope step statuses to not-applicable, set next_step to S5_atomic_execution, and stop, reporting the plan-path and preflight status.`
 >
 > `model_budget.fable_policy: <disabled|available|preferred>.`
+>
+> `Issue adoption: this item's GitHub issue already exists. Verify it read-only (gh issue view), do not call potential_to_issue or the promotion-entry tool, and record a top-level issue_adoption object in the checkpoint per .claude/rules/orchestrator-state.md with origin filed_before_orchestration (or transferred when the issue was transferred), waiving potential_to_issue and the promotion-entry tool for the checkpoint's promotion-type. When a lifecycle record for the item exists under docs/features/potential/promoted/, cite it as potential_record.`
 
 Properties of that line, each individually load-bearing:
 
@@ -128,6 +135,13 @@ does not apply to preparation. It contains no `Parallel mode: true`, so F7's fut
 hook, which matches that marker, will not gate preparation either. Both omissions are intentional
 and must be preserved verbatim when the line is emitted.
 
+**Issue-adoption line.** The issue-adoption line is emitted only for an issue-number item, after
+the model-budget marker line, and is omitted for a potential-entry item, whose child promotes it.
+The line carries no mode marker, no digits, and no active feature-folder path, so hook target
+resolution and mode classification are unchanged. The preparation checkpoint does not carry over
+to execution, so the execution child records its own adoption (see
+`.claude/skills/parallel-orchestrate/SKILL.md`, kickoff element 4).
+
 **No edit to shared surfaces.** No edit is made to `.claude/skills/orchestrate/SKILL.md` or to
 `config/orchestration-routing.json`, including the `preparation` route. The route mechanism is
 marker-driven; the child contract's "commit ... to the current branch" wording is satisfied by a
@@ -135,8 +149,9 @@ branch created off `origin/main`; and `routes.preparation` declares no epic-spec
 agent, skill, or MCP tool.
 
 **Collected per child at termination:** `plan-path`, preflight status, the promotion receipt (the
-`issue_num` back-fill source), the model-routing receipt with `logical_agent: "orchestrator"`, the
-topology receipt, `branch_name`, and `worktree_path`. There is no fan-in merge step: the planner
+`issue_num` back-fill source for a potential-entry item) or, for an issue-number item, the
+`issue_adoption` record from the child checkpoint, the model-routing receipt with
+`agent: "orchestrator"`, the topology receipt, `branch_name`, and `worktree_path`. There is no fan-in merge step: the planner
 fetches and records each pushed item branch, back-fills `issue_num` into the manifest on
 `parallel/<slug>-plan`, and updates the checkpoint.
 
@@ -276,6 +291,44 @@ concurrently.
 Derivation, the V1-V3 rules, and the contention relation are implemented upstream. This skill calls
 them; it defines none of them.
 
+## Complexity Assessment
+
+**Assessment point.** Assess each item's complexity band after the item is `prepared` — its
+preflight status is `PREFLIGHT: ALL CLEAR` and its `declared` radius is V1/V2-clear — and before
+cohort seeding, which consumes the band through the scheduling entry point. The parallel parent
+reads the same band to choose the `model` of that item's `Agent(orchestrator)` spawn, so an item
+without a band cannot be routed.
+
+**Signals and scale.** Read the signal catalog and the band scale from `model_policy` in
+`config/orchestration-routing.json`. Record every signal the item's approved plan and spec exhibit
+in `signals_present`, then choose a band from the scale.
+
+**Floor.** Compute the floor with `Get-ComplexityFloor -SignalsPresent <signals>` from
+`.claude/lib/model-routing/ModelRouting.psm1` in PowerShell, or `compute_complexity_floor(signals)`
+in Python. The chosen band must be at or above the floor; the floor is a lower bound only.
+
+**Model resolution.** Resolve the child model with
+`Resolve-DelegationModel -Agent orchestrator -Band <band> -FablePolicy <fable_policy>` from the same
+module, or `resolve_delegation_model("orchestrator", band, fable_policy)` in Python, using the
+run's `model_budget.fable_policy`.
+
+**Per-item record.** Write three fields on the item:
+
+- `complexity_band` — one of `C1`, `C2`, `C3`, `C4`.
+- `complexity_assessment` — `{ band, floor, signals_present, rationale, assessed_at }`, where `band`
+  equals `complexity_band`, `floor` is the computed floor, `rationale` is a non-empty string, and
+  `assessed_at` is a non-empty ISO-8601 string.
+- `model_routing_receipt` — `{ agent: "orchestrator", phase, complexity_band, fable_policy,
+  table_model, clamped_from, model }`, copied from the resolver output, with `complexity_band`
+  equal to the item's band.
+
+The kickoff artifact's `## Item Summary` `complexity` cell for the item equals its
+`complexity_band`.
+
+**Routing input, not a verdict.** The band is a routing input for model selection and edge
+derivation. It is distinct from the deliberately absent worthiness verdict: assessing a band never
+admits, rejects, or reorders an item.
+
 ## Cohort Seeding
 
 Reach cohort computation through the **destination-runtime bash entry point** under
@@ -448,7 +501,8 @@ Top-level fields: `objective`, `parallel_slug`, `parallel_manifest_path`, `mode`
 `last_updated`. F3's landed required-key set (planner invariant P1) is a strict subset of this
 list, and `plan_home_branch` is a permitted additional field.
 
-Per item: `issue_num`, `feature_folder`, `kind`, `state`, `complexity_band`, `preparation_status`,
+Per item: `issue_num`, `feature_folder`, `kind`, `state`, `complexity_band`, `complexity_assessment`,
+`preparation_status`,
 `research_path`, `plan_path`, `preflight_status`, `branch_name`, `worktree_path`, `blast_radius`
 (with `source: "declared"`), `radius_validation` (the `v1`, `v2`, and `v3` results with their
 severities), `model_routing_receipt`, and `topology_receipt`.
@@ -461,8 +515,10 @@ blast-radius overlap.
 `require_ready_for_execution` gate: at least two items (invariant P6); every item
 `preparation_status: prepared` with `preflight_status` exactly `PREFLIGHT: ALL CLEAR`, non-empty
 `research_path` and `plan_path`, and `blast_radius.source == "declared"` (P7); `next_step` exactly
-the ready sentinel `PARALLEL_EXECUTION_READY` (P8); and `kickoff_prompt_path` exactly
-`artifacts/orchestration/parallel-kickoff-<slug>.md` (P9).
+the ready sentinel `PARALLEL_EXECUTION_READY` (P8); `kickoff_prompt_path` exactly
+`artifacts/orchestration/parallel-kickoff-<slug>.md` (P9); and every item carries a valid
+`complexity_band`, a `complexity_assessment`, and a `model_routing_receipt` with
+`agent: "orchestrator"` that agree with the band (P10).
 
 **Git integrity is F4-owned.** F3's `require_ready_for_execution` gate is structural only, so
 verifying that each item's committed plan blob exists on that item's pushed branch ref — and that
@@ -595,7 +651,7 @@ With no ready feature checkpoint, the exemption admits two attribution-trailer f
 - The trailer option: `git commit -m 'docs: plan' --trailer 'Co-Authored-By: Name <email>' --trailer 'Claude-Session: <url>' -- <exempt paths>`. The separate-value form and the `--trailer=<value>` form are both admitted, any number of times, on `git commit` only; `git add --trailer` and a trailer option with no value are denied. Git writes every trailer value into one trailer block.
 - The one-paragraph multi-message form: the subject in the first `-m` and every trailer in one single-quoted second `-m` value, separated by a literal newline. Each `-m` value becomes its own paragraph and git parses only the last paragraph as the trailer block, so trailers split across separate `-m` values do not form one trailer block.
 
-Quoting rules: `$` and backtick are literal and admitted inside single quotes, and denied outside quotes and inside double quotes, where the shell expands them. `<` and `>` are admitted inside single or double quotes and denied outside quotes. An unquoted `#` is denied anywhere, because it starts a shell comment that the exemption does not model; a `#` inside quotes is admitted. A typographic quote character (U+2018 to U+201E) anywhere in the command line is denied, because a PowerShell host reads it as a quote.
+Quoting rules: `$` and backtick are literal and admitted inside single quotes, and denied outside quotes and inside double quotes, where the shell expands them. `<` and `>` are admitted inside single or double quotes and denied outside quotes. An unquoted `#` is denied anywhere, because it starts a shell comment that the exemption does not model; a `#` inside quotes is admitted. A typographic quote character (U+2018 to U+201E) anywhere in the command line is denied, because a PowerShell host reads it as a quote. Because the executing shell is undetermined (issue #735), a shape whose meaning differs between a POSIX shell and PowerShell is denied: a backslash anywhere in the command line is denied, and `{`, `}`, `,`, `(`, `)`, and `@` are denied outside quotes. Every staging operand must be a plain forward-slash repository-relative path that uses only the characters `A-Z a-z 0-9 . _ / -`.
 
 Not admitted: heredoc-fed messages, including `git commit -m "$(cat <<'EOF' ... EOF)"` and `git commit -F - <<'EOF'`, and message files supplied through `-F <file>` or `--file=<file>`. Use one of the two forms above instead.
 

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

@@ -73,17 +73,28 @@ Do not record a partial removal, and do not record the rejection itself in `muta
 
 1. Re-derive durable state as above and resolve the item key against `items[]`.
 
-2. Decide the removal by calling `decide_removal(item_key, items, disposition)` from
-   `scripts/dev_tools/parallel_mutation_protocol.py`. The engine raises the dedicated rejection
-   exception for every rejected row; surface its message and stop.
+2. Decide the removal through the bundled entry point:
+
+   ```shell
+   bash .claude/lib/bash/remove-parallel-item.sh decide --item <key> --state <state> --removal-disposition <detach|abandon>
+   ```
+
+   `--state` is the state re-derived in step 1; omit it when the key resolves to no `items[]`
+   entry. Pass the caller's disposition as `--removal-disposition`, and omit the option when none
+   was supplied. Exit 0 prints the decision object (`item_key`, `prior_state`, `new_state`,
+   `disposition`, `triggers_recompute`) as one JSON line on stdout. Exit 1 is a rejected row:
+   surface its single stderr line and stop. Exit 2 is a usage error in the invocation itself.
 
 3. **Unstarted removal (recompute).** Set the item's state to `withdrawn`, drop its vertex, and
-   recolor by calling `recolor_unstarted(unstarted_items, conflict_edges, pinned,
-   current_generation, current_cohort=current_cohort,
-   highest_pinned_cohort=highest_pinned_cohort)`. Write
-   `RecolorResult.cohort_assignments` into `cohorts[]` and set the top-level `recolor_generation`
-   to `RecolorResult.generation`; the generation increments by exactly one. The result names no
-   pinned key, so no in-flight item moves.
+   recolor through the bundled entry point:
+
+   ```shell
+   bash .claude/lib/bash/remove-parallel-item.sh recolor --unstarted "<k> ..." --edges "<a>:<b> ..." --pinned "<k> ..." --generation <g> --current-cohort <c> --highest-pinned-cohort <h>
+   ```
+
+   Write the output field `cohort_assignments` into `cohorts[]` and set the top-level
+   `recolor_generation` to the output field `generation`; the generation increments by exactly
+   one. The result names no pinned key, so no in-flight item moves.
 
    `current_cohort` is F3's top-level field, read from the re-verified durable state: the lowest
    current-generation cohort index still holding a non-terminal item. Under the per-edge barrier an
@@ -117,8 +128,18 @@ Do not record a partial removal, and do not record the rejection itself in `muta
    invocation above, so an ad hoc command is not matchable and would bypass the confirmation
    contract entirely. One invocation, one item, both side effects.
 
-6. **Append exactly one `mutations[]` entry** for a successful removal, built by
-   `build_remove_entry` from `scripts/dev_tools/parallel_mutation_protocol.py`:
+6. **Append exactly one `mutations[]` entry** for a successful removal, built through the
+   bundled entry point:
+
+   ```shell
+   bash .claude/lib/bash/remove-parallel-item.sh entry --item <key> --prior-state <state> --removal-disposition <detach|abandon> --recompute <true|false> --generation <g> --at <timestamp>
+   ```
+
+   `--recompute` equals the decision's `triggers_recompute`. `--generation` is the generation
+   before the removal. Omit `--removal-disposition` for an unstarted item. `--at` is the mutation
+   timestamp in `yyyy-MM-ddTHH-mm` form; when it is omitted the entry point uses the current UTC
+   minute. Exit 0 prints the entry as one JSON line on stdout; exit 1 is a contract rejection whose
+   single stderr line is surfaced before stopping; exit 2 is a usage error.
 
    | Case | `op` | `item_key` | `prior_state` | `new_state` | `disposition` | `recolor_generation` |
    | --- | --- | --- | --- | --- | --- | --- |
@@ -127,7 +148,9 @@ Do not record a partial removal, and do not record the rejection itself in `muta
    | Remove, `abandon` | `remove` | item key | `in_flight` | `withdrawn` | `abandon` | `g` (unchanged) |
 
    `disposition` is non-null only on an in-flight removal and is null on the unstarted row. The `at`
-   timestamp comes from the engine's injected clock seam.
+   timestamp comes from the `--at` value, or from the current UTC minute when `--at` is omitted.
+   The repository-local module `scripts/dev_tools/parallel_mutation_protocol.py` is retained as the
+   parity reference for this entry point and is not invoked on this path.
 
 7. **Validate the checkpoint** before treating the removal as applied. Run the
    `validate_orchestration_artifacts` MCP tool with `artifact_type:

package/resources/claude-customizations/.claude/skills/powershell-change-budget-router/SKILL.md

@@ -28,7 +28,7 @@ When routed through `/orchestrate`, small path still requires lifecycle scaffold
 - promote potential item to GitHub issue with `--work-mode minor-audit`,
 - create active feature folder with `--work-mode minor-audit`,
 - delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,
-- require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`,
+- require single-pass `atomic_executor` preflight ending in `PREFLIGHT: ALL CLEAR` (at most one return to the planner),
 - execute Phase 0 only via `atomic_executor` before branching,
 - run reduced small-audit after implementation and QC.
 

package/resources/claude-customizations/.claude/skills/pr-author/SKILL.md

@@ -49,7 +49,7 @@ PreToolUse hook can verify the body passed to `gh pr create --body-file` is the
 produced:
 
 1. Write the body text to `artifacts/pr_body_<N>.md`, where `<N>` is the target issue or PR number.
-2. Compute the SHA-256 of the body file bytes and render it as lowercase hexadecimal.
+2. Compute the SHA-256 of the body file by running `sha256sum artifacts/pr_body_<N>.md` as a single command (no chaining) and take the lowercase hexadecimal digest.
 3. Write the sibling receipt `artifacts/pr_body_<N>.receipt.json` with the shape:
 
    ```json
@@ -63,6 +63,8 @@ produced:
    }
    ```
 
+   Obtain it by running `date -u +%Y-%m-%dT%H:%M:%SZ` as a single command.
+
 4. Pass the body to the pull request via `--body-file artifacts/pr_body_<N>.md`; do not use inline
    `--body`.
 

package/resources/claude-customizations/.claude/skills/python-change-budget-router/SKILL.md

@@ -40,7 +40,7 @@ When routed through `/orchestrate`, the small path still requires lifecycle scaf
 - promote the potential item to a GitHub issue with `--work-mode minor-audit`,
 - create the active feature folder with `--work-mode minor-audit`,
 - delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,
-- require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`,
+- require single-pass `atomic_executor` preflight ending in `PREFLIGHT: ALL CLEAR` (at most one return to the planner),
 - execute Phase 0 only via `atomic_executor` before branching,
 - run the reduced small-audit after implementation and QC.
 

package/resources/claude-customizations/.claude/skills/quota-throttling/SKILL.md

@@ -6,7 +6,7 @@ description: 'Quota throttling and account-switching policy for multi-agent orch
 # Quota Throttling and Account-Switching Policy
 
 Policy for keeping long-running, multi-agent orchestration inside account usage limits without
-losing work. Derived from about five days of continuous multi-agent orchestration (TaskMaster runs
+losing work. Derived from about five days of continuous multi-agent orchestration (consumer-repository runs
 `bugs-2026-09-11` and `bugs-2026-09-17`).
 
 Every figure marked **MEASURED** was observed; figures marked **ESTIMATE** are extrapolations.

package/resources/claude-customizations/.claude/skills/remediation-handoff-atomic-planner/SKILL.md

@@ -5,7 +5,7 @@ description: 'Remediation handoff chain from orchestrator through atomic-planner
 
 # Remediation Handoff to atomic-planner
 
-Strict handoff chain for orchestrator-initiated remediation cycles. The chain enforces that an `atomic-planner`-authored plan is preflighted by `atomic-executor`, revised through a preflight sub-loop if needed, executed by `atomic-executor` task-by-task, and reaudited by `feature-review`. Workers are never invoked directly by the orchestrator.
+Strict handoff chain for orchestrator-initiated remediation cycles. The chain enforces that an `atomic-planner`-authored plan is preflighted by `atomic-executor`, revised at most once through the preflight sub-loop if needed, executed by `atomic-executor` task-by-task, and reaudited by `feature-review`. Workers are never invoked directly by the orchestrator.
 
 ## When to Use This Skill
 
@@ -14,7 +14,7 @@ Use this skill when:
 - Audit findings require remediation (FAIL or material PARTIAL findings).
 - Toolchain checks fail.
 - Acceptance criteria are unmet.
-- A required CI check fails after the pull request is open.
+- A CI check fails after the pull request is open.
 - Any new finding surfaces during execution of an active cycle (in which case begin a new cycle, do not extend the active one).
 
 ## Full Handoff Chain
@@ -30,7 +30,7 @@ orchestrator
              PREFLIGHT: ALL CLEAR        -> proceed to execution
              PREFLIGHT: REVISIONS REQUIRED -> route back to atomic-planner
                 with a precise plan delta; planner revises in place and
-                orchestrator re-runs preflight (sub-loop until clear)
+                orchestrator re-runs preflight once (at most one return)
      -> atomic-executor executes the cleared plan task-by-task
         (workers are invoked by atomic-executor only)
      -> orchestrator delegates to feature-review
@@ -52,7 +52,7 @@ Trigger remediation when any of these are true:
 - Audit artifacts contain FAIL or meaningful PARTIAL findings.
 - Toolchain checks fail (format, lint, type-check, test, contract, or integration stages).
 - 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`).
+- A 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.
 
@@ -63,6 +63,11 @@ The orchestrator authors `remediation/<entry-ts>/remediation-inputs.md` with:
 - Enumerated fix list with file paths, expected behavior, and verification commands.
 - A "do not do" list (no scope creep, no policy weakening, no silent skips).
 - A pointer to the audit artifacts that produced the findings.
+- Exactly one mode line, `Remediation-Mode: proportionate` or `Remediation-Mode: design`. The cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; otherwise it is design. CI-failure findings are normally proportionate.
+
+Proportionate cycle. One `atomic-planner` delegation writes a short plan; one `atomic-executor` delegation then runs single-pass preflight with in-place trivial fixes and executes the plan in the same run. The orchestrator records `preflight: {iterations: 1, final_status: "clear"}` on the cycle before `execution_status`. When that preflight finds a substantive defect, the executor stops with `BLOCKED at preflight (before [P0-T1])`, a plan delta, and no checked task, and the orchestrator converts the cycle to design mode by rewriting the mode line to `Remediation-Mode: design` before one planner revision.
+
+Design cycle. The full chain above runs with the preflight sub-loop below, bounded by the at-most-one-return rule.
 
 ## Required Artifacts
 
@@ -96,25 +101,28 @@ A comprehensive or final sweep in a remediation cycle covers that cycle's own pl
 - Phase 0 captures policy reads and baseline toolchain results per `policy-compliance-order` and `evidence-and-timestamp-conventions`.
 - Final phase runs the full toolchain QA loop in the order specified by `atomic-plan-contract` and records numeric coverage values where the repository policy requires coverage.
 - Evidence paths resolve to `<FEATURE>/evidence/<kind>/` per the non-overridable evidence path clause.
+- The plan is design-level per `## Design-Level Plan Contract (Mandatory)` in `atomic-plan-contract`, carries a `## Pre-Mortem` section, and ends with the final-phase self-review task. A proportionate plan covers only the listed findings and stays short.
 
 The plan must pass the `mcp__drm-copilot__validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>` before `atomic-executor` runs preflight against it.
 
 ## Preflight Sub-Loop
 
-After the plan is authored, `atomic-executor` runs preflight under the directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`. The exact signal returned is either:
+After the plan is authored, `atomic-executor` runs preflight under the directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, which the orchestrator places in the delegation prompt and never in the plan file. Preflight is single-pass: trivial defects are fixed in place and recorded as `PREFLIGHT-FIX:` lines with a `preflight-fix-record:` path. The exact signal returned is either:
 
 - `PREFLIGHT: ALL CLEAR` — the plan proceeds to execution.
-- `PREFLIGHT: REVISIONS REQUIRED` — `atomic-executor` returns a precise plan delta. The orchestrator routes the delta to `atomic-planner` for revision. `atomic-planner` updates the same plan file in place (per the plan-path continuity contract in `atomic-plan-contract`). The orchestrator then re-runs preflight. The sub-loop repeats until `PREFLIGHT: ALL CLEAR` is returned.
+- `PREFLIGHT: REVISIONS REQUIRED` — `atomic-executor` returns a precise plan delta with one `PREFLIGHT-DEFECT:` line per substantive defect. The orchestrator routes the full defect list to `atomic-planner` for one revision. `atomic-planner` updates the same plan file in place (per the plan-path continuity contract in `atomic-plan-contract`). The orchestrator then re-runs preflight once.
+
+At most one return. The sub-loop returns to `atomic-planner` at most once per cycle: when the second preflight still reports a substantive defect, the iteration ceiling below applies.
 
 The orchestrator records the preflight outcome in `remediation_loop.cycles[current_cycle].preflight` with `iterations` (counter) and `final_status` (`clear|changes_requested|pending`).
 
 For a well-scoped item where `preflight.iterations > 1`, record a process-defect investigation that identifies the incomplete planner internal-review dimension. Treat excess rounds as a process signal, not routine iteration.
 
-The exhaustive-pass, defect-enumeration, and delta-self-check rules that govern how `atomic-executor` conducts preflight are defined in the `## Preflight Validation (Planner ↔ Executor)` section of `.claude/skills/atomic-plan-contract/SKILL.md` and are not restated here.
+The exhaustive-pass, defect-classification, in-place-fix, and fix-self-check rules that govern how `atomic-executor` conducts preflight are defined in the `## Preflight Validation (Planner ↔ Executor)` section of `.claude/skills/atomic-plan-contract/SKILL.md` and are not restated here.
 
 Alongside `iterations` and `final_status`, the orchestrator also records in `remediation_loop.cycles[current_cycle].preflight` the convergence line `atomic-executor` returned on that round, which is one of `CONVERGENCE: NO FURTHER ROUNDS EXPECTED` or `CONVERGENCE: FURTHER ROUNDS LIKELY`. This convergence field extends the field set already recorded at `remediation_loop.cycles[current_cycle].preflight` rather than replacing it: `iterations` and `final_status` continue to be recorded exactly as stated above, and the convergence field is written in addition to them.
 
-Iteration ceiling. When a cycle's `iterations` would exceed 2, the orchestrator records `final_status: "blocked_preflight_iteration_limit"`, halts the preflight sub-loop, and escalates to the caller, rather than continuing the sub-loop indefinitely. `blocked_preflight_iteration_limit` is a fourth `final_status` value extending the `clear|changes_requested|pending` enumeration stated above. This ceiling bounds the repeat-until-clear behavior stated above it: the sub-loop still repeats until `PREFLIGHT: ALL CLEAR` is returned, and the ceiling supplies the terminating condition for the case where that signal is not reached within two iterations.
+Iteration ceiling. When a cycle's `iterations` would exceed 2, the orchestrator records `final_status: "blocked_preflight_iteration_limit"`, halts the preflight sub-loop, and escalates to the caller. `blocked_preflight_iteration_limit` is a fourth `final_status` value extending the `clear|changes_requested|pending` enumeration stated above. Under the at-most-one-return rule the ceiling is reached after one planner revision: the first preflight and the confirming preflight are the two permitted iterations.
 
 ## Execution and Reaudit
 

package/resources/claude-customizations/.claude/skills/research-issue/SKILL.md

@@ -63,6 +63,12 @@ Create or update a single research file at one of the two tracked research roots
 - Propose a test strategy consistent with repository policy (unit tests for pure logic, integration seams).
 - Do not write test code; describe the strategy only.
 
+### 6. Pre-Mortem
+
+- Feature-associated research (a research path under `docs/features/`) MUST carry a `## Pre-Mortem` section with one bullet beginning with each of the seven labels `Review checklists`, `Coverage`, `Mirror parity`, `File size`, `Test isolation`, `CI-only behavior`, and `Evidence`. Each bullet states how the next review or CI run could fail on that dimension and the mitigation the plan must carry; a label that does not apply is written as "not applicable" followed by the reason.
+- One-off research under `docs/research/` is exempt.
+- The researcher SubagentStop hook blocks feature research without a complete section. The `execution-environment` skill states the CI shape, contract tests, and isolation checks the section accounts for.
+
 ## Constraints
 
 - Research only. Do not implement changes.

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

@@ -30,6 +30,7 @@
     ".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-merge-gate-command.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",
@@ -40,25 +41,43 @@
     ".claude/hooks/enforce-orchestration-preimplementation-gate-epic-scope.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-helpers.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-modes.ps1",
+    ".claude/hooks/enforce-orchestration-preimplementation-gate-targets.ps1",
     ".claude/hooks/enforce-parallel-abandon-gate.ps1",
     ".claude/hooks/enforce-parallel-cohort-barrier.ps1",
     ".claude/hooks/enforce-parallel-cohort-barrier-helpers.ps1",
     ".claude/hooks/enforce-parallel-drift-gate.ps1",
     ".claude/hooks/enforce-parallel-drift-gate-helpers.ps1",
     ".claude/hooks/enforce-parallel-worktree-removal-gate.ps1",
+    ".claude/hooks/enforce-pr-author-command-allowlist.ps1",
+    ".claude/hooks/enforce-pr-author-skill.artifact-root.ps1",
+    ".claude/hooks/enforce-pr-author-skill.docs-only.ps1",
     ".claude/hooks/enforce-pr-author-skill.epic-base-branch.ps1",
     ".claude/hooks/enforce-pr-author-skill.ps1",
     ".claude/hooks/enforce-pr-author-skill-helpers.ps1",
     ".claude/hooks/enforce-prd-feature-before-planner-helpers.ps1",
     ".claude/hooks/enforce-prd-feature-before-planner.ps1",
     ".claude/hooks/enforce-promotion-mcp-only.ps1",
+    ".claude/hooks/feature-folder-resolution.ps1",
+    ".claude/hooks/feature-review-coverage-thresholds.ps1",
+    ".claude/hooks/hook-command-heredoc.ps1",
     ".claude/hooks/hook-command-invocation.ps1",
+    ".claude/hooks/hook-command-invocation-operands.ps1",
+    ".claude/hooks/hook-command-payload.ps1",
+    ".claude/hooks/hook-command-payload-powershell.ps1",
     ".claude/hooks/hook-command-scanner.ps1",
+    ".claude/hooks/hook-dependency-guard.ps1",
+    ".claude/hooks/hook-docs-only-diff.ps1",
     ".claude/hooks/persist-session-id.ps1",
+    ".claude/hooks/premortem-section.ps1",
+    ".claude/hooks/subagentstop-envelope.ps1",
     ".claude/hooks/validate-bash.ps1",
     ".claude/hooks/validate-discovery-artifact-gate.ps1",
     ".claude/hooks/validate-executor-output.ps1",
+    ".claude/hooks/validate-feature-review-coverage-metrics.ps1",
+    ".claude/hooks/validate-feature-review-coverage-rules.ps1",
     ".claude/hooks/validate-feature-review-coverage.ps1",
+    ".claude/hooks/validate-orchestrator-output-resolution.ps1",
+    ".claude/hooks/validate-orchestrator-output-routing.ps1",
     ".claude/hooks/validate-orchestrator-output.ps1",
     ".claude/hooks/validate-planner-output.ps1",
     ".claude/hooks/validate-prd-feature-output.ps1",
@@ -100,6 +119,7 @@
     ".claude/skills/epic-run/SKILL.md",
     ".claude/skills/evidence-and-timestamp-conventions/SKILL.md",
     ".claude/skills/execute-hard-lock/SKILL.md",
+    ".claude/skills/execution-environment/SKILL.md",
     ".claude/skills/feature-promotion-lifecycle/SKILL.md",
     ".claude/skills/feature-review-workflow/SKILL.md",
     ".claude/skills/fill-feature-docs/SKILL.md",
@@ -145,6 +165,7 @@
     ".claude/lib/orchestrator-state/OrchestratorStateRoutingContract.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateIssueAdoption.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateUnconditional.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateEpicWaveBarrier.psm1",
     ".claude/lib/discovery-validation/DiscoveryValidation.psm1",
     ".claude/lib/codex-routing/CodexDeployment.psm1",
     ".claude/lib/codex-routing/CodexTopology.psm1",
@@ -163,6 +184,7 @@
     ".claude/lib/project-file-merge/ProjectFileMerge.psm1",
     ".claude/lib/project-file-merge/Resolve-MergeableConflict.ps1",
     ".claude/lib/ci-gate/Invoke-CiGateParser.ps1",
+    ".claude/lib/ci-gate/Invoke-MergeConfirmationParser.ps1",
     ".claude/lib/parallel-drift/ParallelDriftHalt.psm1",
     ".claude/lib/parallel-drift/ParallelDrift.psm1",
     ".claude/lib/parallel-drift/Invoke-ParallelDriftDetection.ps1",
@@ -171,13 +193,18 @@
     ".claude/lib/bash/abandon-parallel-item.sh",
     ".claude/lib/bash/compute-cohorts.sh",
     ".claude/lib/bash/compute-concurrency-batches.sh",
+    ".claude/lib/bash/mutate-parallel-run.sh",
     ".claude/lib/bash/parallel-cohorts.sh",
     ".claude/lib/bash/parallel-common.sh",
     ".claude/lib/bash/parallel-items-validate.sh",
     ".claude/lib/bash/parallel-lane-assertion.sh",
     ".claude/lib/bash/parallel-manifest-validate.sh",
+    ".claude/lib/bash/parallel-mutation-cli.sh",
+    ".claude/lib/bash/parallel-mutation-ops.sh",
+    ".claude/lib/bash/parallel-mutation.sh",
     ".claude/lib/bash/parallel-yaml-emit.sh",
     ".claude/lib/bash/parallel-yaml-scan.sh",
+    ".claude/lib/bash/remove-parallel-item.sh",
     ".claude/lib/bash/report-lane-assertion.sh",
     ".claude/lib/bash/validate-parallel-manifest.sh",
     "config/orchestration-routing.json",

package/resources/codex-and-agents-customizations/.agents/skills/README.md

@@ -9,6 +9,7 @@ Repository-local Codex skills live under `.agents/skills/<skill-name>/SKILL.md`.
   - `atomic-plan-contract`
   - `acceptance-criteria-tracking`
   - `evidence-and-timestamp-conventions`
+  - `execution-environment`
   - `skill-canonical-location-audit`
 
 - Integration

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

@@ -86,7 +86,7 @@ During feature review (feature-audit phase):
 
 ### When Orchestrators Enforce AC Tracking
 
-Orchestrators do not directly check off AC items. Instead:
+Orchestrators do not directly check off AC items. The one exception is a CI-dependent criterion, which the item's own orchestrator run checks off at S9 as described in `### CI-Dependent Criteria` above. For every other criterion, orchestrators instead:
 
 1. Ensure delegated executors and reviewers reference this skill.
 2. After executor or reviewer completion, verify that AC source files reflect delivered work (spot-check; do not re-execute verification).

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

@@ -1,6 +1,6 @@
 ---
 name: architecture-boundaries
-description: Architecture boundary enforcement rules for the No-COM architecture.
+description: Architecture boundary enforcement rules for a host-neutral layered architecture.
 ---
 
 # Converted rule
@@ -16,7 +16,7 @@ Architecture boundary enforcement is a uniform gate across all tiers (T1–T4).
 - **TypeScript:** `dependency-cruiser`. Configuration file pattern: `.dependency-cruiser.cjs`.
 - **.NET (when the backend exists):** `NetArchTest.Rules`. Test project naming pattern: `*.ArchitectureTests`.
 
-## No-COM Architecture Rules (enforceable assertions)
+## Host-Neutral Architecture Rules (enforceable assertions)
 
 Production code in this repository must satisfy each of the following assertions. Each assertion is enforced by `dependency-cruiser` (TypeScript) or `NetArchTest.Rules` (.NET) where applicable; legacy import utilities, when added, must satisfy the same assertions.
 
@@ -39,9 +39,9 @@ Production code in this repository must satisfy each of the following assertions
 
 ## Layer Boundary Assertions (.NET, applies once the backend exists)
 
-- `TaskMaster.Domain` must have zero references to Outlook PIA, VSTO, or Office.js types.
-- `TaskMaster.Application` may depend on `TaskMaster.Domain` only.
-- Adapter projects may depend on `TaskMaster.Domain` and `TaskMaster.Application`; domain may not depend on adapters.
+- `<Product>.Domain` must have zero references to Outlook PIA, VSTO, or Office.js types.
+- `<Product>.Application` may depend on `<Product>.Domain` only.
+- Adapter projects may depend on `<Product>.Domain` and `<Product>.Application`; domain may not depend on adapters.
 
 ## Enforcement Outcome
 

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

@@ -13,6 +13,7 @@ Always apply:
 - `policy-compliance-order`
 - `atomic-plan-contract`
 - `acceptance-criteria-tracking`
+- `execution-environment`
 
 ## Role
 
@@ -33,17 +34,17 @@ Blocking is allowed only during preflight.
 
 ### Validation-Only Mode Contract
 
-If the incoming handoff includes the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`:
+If the incoming handoff includes the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY` (the directive belongs in the delegation prompt, never in a plan file):
 
-1. Perform preflight validation only.
+1. Perform preflight validation only, in one pass over the entire plan, under `### Single-Pass Preflight` in `atomic-plan-contract`.
 2. Do not execute tasks, establish execution state, or run implementation commands.
-3. Return exactly one of:
+3. Fix trivial defects in place in task text only (never add, remove, or reorder tasks), record each fix in `<FEATURE>/evidence/other/preflight-fixes.<timestamp>.md`, and report it as a `PREFLIGHT-FIX:` line with a `preflight-fix-record:` path.
+4. Return exactly one of:
    - `PREFLIGHT: ALL CLEAR`
    - `PREFLIGHT: REVISIONS REQUIRED`
-4. If revisions are required, include a precise plan delta that `atomic-planner` can apply to the same plan file.
-5. If revisions are required, automatically hand off back to `atomic-planner` and request that it apply the delta to the same plan file and resubmit that file for validation-only again.
-6. Continue the validate -> delta -> planner-revise -> validate loop until preflight can return `PREFLIGHT: ALL CLEAR`.
-7. If the planner-return handoff cannot be started or completed, stop and report blocked state; do not convert the failure into `PREFLIGHT: ALL CLEAR`.
+5. If revisions are required, include a precise plan delta that `atomic-planner` can apply to the same plan file, with one `PREFLIGHT-DEFECT:` line per substantive defect and every substantive defect listed.
+6. Return the result to the caller. A plan returns to the planner at most once; the orchestrator routes the defect list for one revision and runs one confirming preflight.
+7. If the required handoff cannot be started or completed, stop and report blocked state; do not convert the failure into `PREFLIGHT: ALL CLEAR`.
 
 ## Execution Rules
 
@@ -55,6 +56,17 @@ For each task:
 4. Check off the plan file on disk immediately after verification passes.
 5. Check off satisfied acceptance criteria in the authoritative requirement source file per `acceptance-criteria-tracking`.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Non-Negotiable Constraints
 
 - Do not invent new phases or tasks.