@danmoisan/drm-copilot-mcp 1.1.17 → 1.1.19

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/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/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

@@ -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
@@ -52,7 +52,9 @@ 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.
 
 ## Required Remediation Inputs
 
@@ -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)
 

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

@@ -40,25 +40,42 @@
     ".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/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",
@@ -136,13 +153,16 @@
     ".claude/lib/orchestrator-state/OrchestratorStateCompletion.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCheckpointValue.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateReceipts.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateRemediationAccounting.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateModelReceipts.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCodexModelReceipts.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCodexTopologyReceipts.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateRoutingMatrix.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCompletionChecks.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateRoutingContract.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateIssueAdoption.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateUnconditional.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateEpicWaveBarrier.psm1",
     ".claude/lib/discovery-validation/DiscoveryValidation.psm1",
     ".claude/lib/codex-routing/CodexDeployment.psm1",
     ".claude/lib/codex-routing/CodexTopology.psm1",
@@ -169,13 +189,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/acceptance-criteria-tracking/SKILL.md

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

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

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

@@ -117,6 +117,10 @@ For short-path/minimal-audit plans, Phase 0 evidence is incomplete unless both a
 
 `Output Summary:` is mandatory for each command-step artifact and must concisely summarize the essential result signal (for example: pass/fail status, key counts, coverage headline, or primary diagnostic).
 
+## Evidence Filename Timestamps in Plans
+
+Plans name evidence artifacts `<name>.<timestamp>.md` and never fix a plan-time stamp in an evidence filename. An acceptance condition identifies a consumed evidence artifact by the derivation in `evidence-and-timestamp-conventions` (`### Evidence Filename Timestamp`): the lexicographically greatest file matching `<name>.*.md`, not a pre-stamped literal path. This section governs artifact paths only: asserted search tokens remain concrete.
+
 ## Coverage Evidence Contract (Mandatory when policy requires coverage)
 
 For any language in scope where repository policy requires coverage validation:

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

@@ -34,6 +34,16 @@ Each task must be:
 - independently verifiable,
 - free of placeholder text.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number. Every plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Mandatory Preflight Loop
 
 Before a plan is finalized:

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

@@ -10,8 +10,8 @@ This rule file summarizes the C#-specific policies for this repository.
 ## Toolchain
 
 1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Command: `dotnet tool run csharpier .` or `csharpier .`
-2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. **Type Checking — Nullable Analysis**: Enable nullable reference types and fail on warnings. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. **Type Checking — Nullable Analysis**: Enable nullable reference types and fail on warnings. Command: `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
 4. **Testing — MSTest + Moq + FluentAssertions**: Run tests with: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
 Run the toolchain in order: format → lint → type-check → test. Restart from step 1 if any step fails or changes files.

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

@@ -28,8 +28,8 @@ Before invoking this gate, the agent must have:
 Run the full toolchain in this exact order. If any step fails or modifies files, fix the issue and restart from step 1. Do not stop the loop until all four steps complete without errors in a single pass.
 
 1. `dotnet tool run csharpier .`
-2. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+2. `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
 4. `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.

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

@@ -68,6 +68,14 @@ Create a missing integration branch from current `origin/main` and push it. Befo
 fetch the current remote integration tip. Create every child worktree from that tip, never from
 `main`, and set each feature PR base explicitly to the integration branch.
 
+Before each wave launches, run `git fetch origin main` and then
+`git rev-list --count <integration>..origin/main`. A zero count proceeds directly to the wave.
+A non-zero count runs the main-sync as a dedicated chore child item (the `epic-852-main-sync` /
+PR #882 pattern) whose branch starts from the integration tip, merges `origin/main` with a merge
+commit, and opens a PR into the integration branch; that PR must merge before the wave launches.
+Record the sync child's `features[]` row before its launch, and do not reuse a manifest child's
+issue number for it. Run at most one main-sync child per wave, then re-fetch the integration tip.
+
 Launch all ready children in one bounded parallel wave. Before each launch, persist the
 epic-child topology receipt, reviewed complexity assessment, delegation receipt, and Codex
 model-routing receipt with the same `delegation_id`, then select the generated deployment agent.
@@ -112,9 +120,11 @@ authoritative backstop.
 
 Each child owns its implementation, review, PR, CI-green gate, and merge into the integration
 branch. A merge conflict enters that child's existing remediation loop with a blocking
-`remediation-inputs.<timestamp>.md`. After three unresolved passes, record
-`blocked_conflict_loop_limit` and stop that edge. The epic agent must not resolve child conflicts
-locally.
+`remediation-inputs.<timestamp>.md`. Conflict cycles share the child's attempt count,
+`remediation_loop.completed_attempts`. The active cycle number is `completed_attempts + 1`, and a
+cycle without an applied candidate consumes no number. After three completed attempts without a
+`PASS` review, record `blocked_conflict_loop_limit` and stop that edge. The epic agent must not
+resolve child conflicts locally.
 
 ## Worktree Cleanup
 

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

@@ -63,6 +63,21 @@ must never use placeholders.
 Create or reuse `epic/<epic-slug>-integration` from `origin/main`, push it, and commit the epic
 home before preparation. All prepared child outputs must fan into this branch.
 
+## Integration Commit Form
+
+The epic planner's own commits of the epic manifest, the fanned-in child feature folders and approved plans, and the kickoff copy are orchestration bookkeeping. `.codex/hooks/enforce-orchestration-preimplementation-gate.ps1` exempts them without a ready feature checkpoint only when the invocation is pathspec-bearing and every path operand lies inside `docs/features/epics/`, `docs/features/parallel/`, `docs/features/active/`, `docs/features/potential/`, or `artifacts/orchestration/`. A pathless commit, a whole-tree operand, or any operand outside those trees is denied.
+
+Admitted commit forms, each followed by `--` and the exempt path operands:
+
+- A single-quoted message containing `$`, for example `git commit -m 'docs: costs $5' -- <exempt paths>`.
+- A single-quoted message containing a backtick, for example ``git commit -m 'docs: fix `Foo`' -- <exempt paths>``.
+- The trailer option on `git commit` only, in the separate-value form `--trailer 'Co-Authored-By: Name <email>'` or the `--trailer=<value>` form, any number of times.
+- 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 admitted only inside single quotes. `<`, `>`, and `#` are admitted only inside quotes. A typographic quote character (U+2018 to U+201E) is denied anywhere. 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, and message files supplied through `-F <file>` or `--file=<file>` (issue #732, decision D5).
+
 ## Concurrent Preparation
 
 Place all child preparations in one preparation batch, regardless of execution-wave
@@ -181,7 +196,8 @@ byte-identical; the manifest, durable kickoff, plans, and planning commits must
 repository-aware readiness validator without worktree drift.
 
 Invoke `validate_orchestration_artifacts` for `epic-planner-state` with
-`require_ready_for_execution: true` and the explicit workspace root. Do not write or delegate the
+`require_ready_for_execution: true`, `require_codex_topology: true`,
+`require_codex_model_routing: true`, and the explicit workspace root. Do not write or delegate the
 kickoff until this canonical gate succeeds.
 
 ## Kickoff Artifacts

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

@@ -22,7 +22,8 @@ Use the epic slug or path supplied in the invoking user request.
    per-feature plan paths, preflight evidence, and current Git state. Derive optional missing
    hashes from Git; fail closed on actual drift.
    Invoke `validate_orchestration_artifacts` for `epic-planner-state` with
-   `require_ready_for_execution: true` and the explicit workspace root. Do not delegate until
+   `require_ready_for_execution: true`, `require_codex_topology: true`,
+   `require_codex_model_routing: true`, and the explicit workspace root. Do not delegate until
    that canonical repository-aware gate succeeds.
 4. Delegate the invocation prompt to `epic-orchestrator` and apply `epic-orchestrate`.
 5. Reuse the existing integration branch. Every child resumes at atomic execution from its

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

@@ -48,6 +48,17 @@ 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 UTC read from the host system clock when the recorded command runs (for example `Get-Date -AsUTC -Format yyyy-MM-ddTHH-mm` in PowerShell 7, `(Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH-mm')` in Windows PowerShell 5.1, or `date -u +%Y-%m-%dT%H-%M` in a POSIX shell); the agent never composes or estimates it. The value is written without a zone suffix.
+
+### Evidence Filename Timestamp
+
+The stamp in the filename of every artifact under `<FEATURE>/evidence/<kind>/` is the UTC time at which that file is written, read from the host system clock immediately before the write, in the same `yyyy-MM-ddTHH-mm` shape with no zone suffix. It is never a plan-time stamp, a plan-cycle identifier, or any other value fixed before the write.
+
+- Plans name such an artifact `<name>.<timestamp>.md`, and the executor substitutes the write time. A later loop pass writes a new file with a new stamp.
+- A task that consumes an evidence artifact selects the lexicographically greatest file matching `<name>.*.md`. The fixed-width UTC shape sorts in chronological order, so that file is the most recently written one.
+- Plan files (`plan.<timestamp>.md`, stamped by the feature-folder tooling in America/New_York) and the review artifact set (`policy-audit`, `code-review`, `feature-audit`, `remediation-inputs`, which share one stamp) are outside this rule.
+- Existing evidence files whose names carry a plan-time stamp are not renamed.
+
 ## Canonical Evidence Locations
 
 - Baseline evidence: `evidence/baseline/`
@@ -112,6 +123,8 @@ When evidence artifacts are used for automated checking or plan reconciliation,
 - `Command: <exact command>`
 - `EXIT_CODE: <int>`
 
+The first occurrence of `Timestamp`, `Command`, `EXIT_CODE`, and `ExpectedExitCode` forms the record in both the Python and the TypeScript parser; later occurrences, including empty later values, are ignored. An artifact that records several gates therefore reports its first gate.
+
 One optional field may also be declared:
 - `ExpectedExitCode: <int>` — the exit code the gate is expected to produce.
 

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

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