@danmoisan/drm-copilot-mcp 1.1.18 → 1.1.19

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

@@ -46,7 +46,16 @@ 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.
+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
 

package/resources/claude-customizations/.claude/skills/feature-promotion-lifecycle/SKILL.md

@@ -45,7 +45,7 @@ Note: VS Code command-palette commands may exist for interactive extension use,
 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.
+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, when a promotion-entry tool is waived, `potential_record`). For that waiver `potential_record` is required when `origin` is `epic_decomposition`, optional when `origin` is `transferred` or `filed_before_orchestration`, and validated whenever it is present. 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)`.

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

@@ -70,7 +70,7 @@ Always apply:
 If the branch diff modifies any path matching `.github/workflows/**`, `scripts/benchmarks/**`, or `.github/actions/**`, the policy audit emits a Blocking finding unless evidence of a green workflow run against the branch head is present in the remediation inputs.
 
 - 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.
+- "Green workflow run against the branch head" means a run of the affected workflow whose conclusion is success and which satisfies either (a) or (b): (a) its head SHA equals the current branch head; or (b) all three predecessor-head conditions hold: (1) the run's head SHA is an ancestor of, or equal to, the current branch head and contains the latest commit that changes any path outside the active feature folder (`git merge-base --is-ancestor <commit> <run-sha>`); (2) every commit after the run's head SHA changes only paths inside the active feature folder (`git log <run-sha>..HEAD -- . ":!<feature-folder>"` returns no commits); (3) the policy audit states that the orchestrator's S9 CI green gate remains responsible for `ci_gate.conclusion == "success"` with `ci_gate.head_sha` equal to the final PR head before DONE. Condition (b) exists because an in-repo evidence artifact cannot name the SHA of the commit that contains it.
 - 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 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.
 
@@ -108,12 +108,13 @@ If the branch diff modifies any path matching `.github/workflows/**`, `scripts/b
         - Python: `poetry run pytest --cov` → artifact: `artifacts/python/lcov.info`
         - PowerShell: `mcp__drm-copilot__run_poshqc_test` → artifact: `artifacts/pester/powershell-coverage.xml`
         - C#: `dotnet test --collect:"XPlat Code Coverage"` → artifact: `artifacts/csharp/coverage.xml`
-        - Coverage thresholds (uniform tier rule per quality-tiers.md). The branch threshold applies only to branch-capable languages — TypeScript, Python, and C#. PowerShell is a coverage language and is fully subject to the line threshold and the no-regression requirement, but Pester measures command (instruction) coverage and line coverage only, so no branch percentage exists to evaluate and no branch threshold applies to it (see `.claude/rules/powershell.md`). Do not flag a missing PowerShell branch figure as FAIL:
+        - Coverage thresholds (threshold precedence per `.claude/rules/quality-tiers.md` and `.claude/rules/general-unit-test.md`: when the repository's root `CLAUDE.md` states line or branch coverage thresholds, those thresholds govern; otherwise the default thresholds below govern; each metric falls back independently, so a root `CLAUDE.md` that states only one of the two thresholds governs only that metric). The branch threshold applies only to branch-capable languages — TypeScript, Python, and C#. PowerShell is a coverage language and is fully subject to the line threshold and the no-regression requirement, but Pester measures command (instruction) coverage and line coverage only, so no branch percentage exists to evaluate and no branch threshold applies to it (see `.claude/rules/powershell.md`). Do not flag a missing PowerShell branch figure as FAIL:
           - New code files (added in this feature): line coverage >= 85%, and branch coverage >= 75% for branch-capable languages. Flag as FAIL otherwise.
           - Modified files (changed but previously existing): line coverage >= 85%, branch coverage >= 75% for branch-capable languages, and no regression on changed lines relative to baseline. Flag as FAIL otherwise.
           - Repo-wide per language: line coverage >= 85%, and branch coverage >= 75% for branch-capable languages. Flag as FAIL otherwise.
         - If coverage artifacts already exist from the executor run, inspect them instead of re-running.
         - If no coverage artifact exists for a language that has changed files, flag as FAIL — coverage verification is mandatory for all languages with changed files.
+        - Tier classification findings: report a missing or incomplete `quality-tiers.yml` only when the repository has adopted tiers, that is, when `quality-tiers.yml` exists at the repository root on the resolved base branch or the repository's CI runs a tier-classification check. Otherwise record tier classification as not applicable; it is not a finding.
    - Run the smallest relevant subset first when the repo policy permits it.
    - If a tool cannot run in the environment, mark the affected section unverified or partial with a concrete reason.
 
@@ -145,7 +146,7 @@ If the branch diff modifies any path matching `.github/workflows/**`, `scripts/b
      - toolchain checks fail
      - the code review contains blockers
      - 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 below the governing thresholds defined in step 5 (repo-wide per language, modified files including any regression on changed lines, or 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.

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

@@ -34,6 +34,7 @@ On every invocation, the main session must:
 2. If a valid checkpoint exists with a matching objective, resume from the recorded `next_step`.
 3. If no checkpoint exists or the objective is new, begin the orchestration lifecycle from the start.
 4. **Checkpoint hygiene (issue #673).** When the checkpoint at `artifacts/orchestration/orchestrator-state.json` records an `issue-num` other than the item this invocation is about, move it to `artifacts/orchestration/handoff/orchestrator-state.issue-<issue-num>.<yyyy-MM-ddTHH-mm>.json` before writing a new checkpoint, rather than overwriting it or leaving it in place. Apply the same move when this session hands an item whose checkpoint it holds to another session or worktree. A checkpoint left at a session root is read by gates that resolve against that root, so a foreign one there is state a gate can answer from.
+5. **Required checkpoint keys (issue #798).** Every checkpoint write carries each top-level key listed in `.claude/rules/orchestrator-state.md` under `## Required Top-Level Keys`; plain validation reports each absent key as `Checkpoint missing required key: <key>` under every flag combination. The list includes `last_updated`, an ISO-8601 UTC date-time string (for example `2026-10-08T17:28:00Z`) that is rewritten on every checkpoint write: after every completed step and every state transition, including halts.
 
 ## Prepared-State Portable Handoff Intake
 
@@ -189,6 +190,8 @@ The mandatory sequence is:
 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.
 
+When the pr-author agent runs outside the item worktree (its process directory is not the worktree that holds the item's `artifacts/` tree), it passes the absolute canonical path `<item worktree>/artifacts/pr_body_<N>.md` to `--body-file`. The `enforce-pr-author-skill.ps1` hook resolves the item worktree from `--head` and reads the PR context summary, the body, and the receipt beneath it; in that topology it denies a relative `--body-file` with `PR_BODY_PATH_NONCANONICAL`, because `gh` would read the relative path from its own process directory.
+
 `Agent(pr-author)` is the mandatory delegate for PR creation and PR body edits. Direct `gh pr create`/`gh pr edit --body*` from the main thread is prohibited and is blocked by the hook. Before the five receipt checks, the `enforce-pr-author-skill.ps1` PreToolUse hook independently re-validates the orchestrator-state checkpoint against `--require-pr-creation-ready` (via an injectable `$Invoker` subprocess seam) and blocks with `ORCHESTRATOR_STATE_PREFLIGHT_FAILED` when the checkpoint is missing or invalid — this is the local, hook-level enforcement mechanism that closes the bypass path (it runs inside the same hook that already intercepts `gh pr create`/`gh pr edit`, not as a CI check). The PreToolUse hook then verifies the receipt in five ordered checks: canonical body-file path, receipt present, `number` match, `sha256` match against the body bytes, and `created_at` strictly newer than the context summary last-write.
 
 The SHA-256 receipt is a policy-level integrity check, not a cryptographic or security boundary; any actor with `Write(/artifacts/**)` access can replace both the body file and its receipt together with a matching SHA-256. It binds the body bytes to the receipt, prevents accidental bypass, and requires a deliberate, documented act to circumvent.
@@ -267,7 +270,7 @@ Cycle accounting: a remediation attempt is complete when R3 execution finished (
 
 ## Issue Number Consistency
 
-The canonical issue number is derived once from the active feature folder name: extract the trailing integer from the folder base name (e.g., `2026-04-26-push-down-claude-customizations-162` yields `162`). Record as `issue_num` in the checkpoint.
+The canonical issue number is derived once from the active feature folder name: extract the trailing integer from the folder base name (e.g., `2026-04-26-push-down-claude-customizations-162` yields `162`). Record as `issue-num` in the checkpoint; the hyphenated key is the one listed in `.claude/rules/orchestrator-state.md` under `## Required Top-Level Keys`.
 
 Every delegation prompt to a receipt-gated subagent type — `atomic-planner`, `atomic-executor`, `feature-review`, `task-researcher`, `prd-feature`, and `pr-author` — must include the line:
 
@@ -286,8 +289,13 @@ If a subagent artifact references a different issue number, the orchestrator rej
 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.
+2. Invoke `gh pr checks --json bucket,name,state,link,workflow` (or an equivalent JSON-emitting command) against that head SHA. The query covers every check on the head SHA for every PR, whether or not branch protection marks the check as required. `gh` is the only sanctioned channel for querying GitHub Actions state.
+
+   No-checks rule: when `gh pr checks` fails with a `no checks reported` error, that error is never treated as green for any PR. On a non-epic PR the gate stays `pending` and step 4 continues the bounded poll. On an epic child, step 3 runs the parser with `-ChecksJson '[]'` and `-RequireWorkflow CI`, which returns `pending`. The parser is never run with `-ChecksJson '[]'` without `-RequireWorkflow CI`, because its default path returns `success` for an empty set.
+
+   Epic-child rule: when the PR base branch is an `epic/<slug>-integration` branch (checkpoint `epic_mode` is `true`), the step 2 query is the same unfiltered query; integration branches carry no required-status-check protection. An empty check list is not accepted as green for such a PR: the gate must observe at least one check whose `workflow` is `CI` against the child head SHA, and every observed `CI` check must succeed before `ci_gate.conclusion` is accepted as `success`. Every check returned by the unfiltered query counts: a failing or cancelled non-`CI` check fails the gate, and a pending one keeps it pending. Step 3 enforces this rule by passing `-RequireWorkflow CI` to the parser, which never returns `success` until at least one passing `CI` check is observed. When `gh pr checks` fails with a `no checks reported` error on the child branch, step 3 runs the parser with `-ChecksJson '[]'`; that error is never treated as green, and the parser returns `pending` for it.
+
+3. Parse the JSON by running `pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-CiGateParser.ps1 -ChecksJson <checks-json> -HeadSha <head-sha>`, appending `-RequireWorkflow CI` when `epic_mode` is `true`. The parser emits the `ci_gate` object defined below and derives `ci_gate.conclusion` over the queried checks (every check on the PR head SHA, for every PR): `success` when every queried check passed or was skipped, `failure` when any queried check failed or was cancelled, and `pending` when any queried check is still in progress. With `-RequireWorkflow CI`, the parser returns `pending` instead of `success` until at least one check whose `workflow` is `CI` has passed.
 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.
@@ -301,7 +309,7 @@ DONE is not written while `step9_status` is anything other than `passed`.
 The orchestrator checkpoint (`artifacts/orchestration/orchestrator-state.json`) is extended with:
 
 - a top-level `ci_gate` object containing:
-  - `head_sha` — the PR head SHA that the required checks were observed against.
+  - `head_sha` — the PR head SHA that the queried checks were observed against.
   - `pr_pipeline_run_id` — the GitHub Actions run id for the PR Pipeline.
   - `pr_pipeline_run_url` — the URL of that run.
   - `conclusion` — one of `success`, `failure`, `pending`.
@@ -336,7 +344,7 @@ 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; a poll timeout follows the wait branch per S9 step 4):
+When S9 records `step9_status: "failed_remediation_required"` (a failed 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` 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.
@@ -438,6 +446,6 @@ 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 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)`.
+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 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. For a promotion-entry waiver, `potential_record` (a markdown path under `docs/features/potential/`) is required when `origin` is `epic_decomposition`, optional when `origin` is `transferred` or `filed_before_orchestration`, and validated whenever it is present. 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-add/SKILL.md

@@ -56,7 +56,21 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    contract for parallel admission. Preparation yields the item's DECLARED blast radius, and only
    the planner-computed declared radius is authoritative for scheduling. The item's lifecycle
    advances `proposed` -> `admitted` -> `prepared` during this step, recorded as item-state updates in
-   `items[]` with the checkpoint's lifecycle timestamps.
+   `items[]` with the checkpoint's lifecycle timestamps. After the admitted item's preflight
+   clearance, perform the `parallel-plan` skill's `## Complexity Assessment` procedure for it, and
+   record the resulting `complexity_band` on the admitted orchestrator-checkpoint item so step 3's
+   edge derivation and the parent's model routing read the same band.
+   The admitted item records `complexity_band` and no `model_routing_receipt`; the parent resolves
+   the item's model from that band at spawn time per `parallel-orchestrate` `## Model Selection`.
+   For an issue-number item, the preparation delegation prompt carries the issue-adoption line used
+   by `/parallel-plan` `## Preparation Fan-Out`, quoted verbatim: `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.` The line is omitted for a
+   potential-entry item, whose child promotes it.
 
 3. **Compute conflict edges over ALL items, including in-flight ones.** Invoke the scheduling
    entry point Get-BlastRadiusConflictEdge from the destination-runtime PowerShell port
@@ -91,17 +105,28 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    barrier, and the later-merging item merges `origin/main` under the existing per-item
    merge-conflict handling and re-passes CI before it merges.
 
-4. **Decide admission.** Call
-   `decide_admission(candidate, conflict_edges, in_flight, current_cohort_members=current_cohort_members)`
-   from `scripts/dev_tools/parallel_mutation_protocol.py`.
-   - `ADMIT_CURRENT_COHORT` — the candidate shares no edge with any member of the current cohort,
+4. **Decide admission.** Call the bundled entry point, which needs no Python interpreter:
+
+   ```bash
+   bash .claude/lib/bash/mutate-parallel-run.sh admit --candidate <key> --edges "<a>:<b> ..." --in-flight "<k> ..." --current-cohort-members "<k> ..."
+   ```
+
+   `--edges` carries the step-3 conflict edges over ALL items, `--in-flight` the in-flight (pinned)
+   keys, and `--current-cohort-members` the full current-cohort membership. The command prints one
+   JSON object whose `outcome` field is one of:
+   - `admit_current_cohort` — the candidate shares no edge with any member of the current cohort,
      pinned or unstarted. Admit it into the current cohort. NO recompute occurs and
      `recolor_generation` is unchanged — precisely because the candidate conflicts with no
      current-cohort member, so no cohort assignment needs to change.
-   - `DEFER_AND_RECOLOR` — the candidate shares an edge with at least one member of the current
-     cohort, pinned or not-yet-launched. Defer it to a future cohort and recolor by calling
-     `recolor_unstarted(unstarted_items, conflict_edges, pinned, current_generation, current_cohort=current_cohort, highest_pinned_cohort=highest_pinned_cohort)`.
-     `highest_pinned_cohort` is derived from re-verified durable state: the highest
+   - `defer_and_recolor` — the candidate shares an edge with at least one member of the current
+     cohort, pinned or not-yet-launched. Defer it to a future cohort and recolor through the
+     bundled entry point:
+
+     ```bash
+     bash .claude/lib/bash/mutate-parallel-run.sh recolor --unstarted "<k> ..." --edges "<a>:<b> ..." --pinned "<k> ..." --generation <g> --current-cohort <c> --highest-pinned-cohort <h>
+     ```
+
+     `--highest-pinned-cohort` is derived from re-verified durable state: the highest
      current-generation cohort index occupied by any in-flight item.
      The recolor is a recompute: `recolor_generation` increments by exactly one, and it places every
      unstarted item at an index at or above `current_cohort`, strictly above
@@ -125,8 +150,9 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    with an unstarted item OUTSIDE the current cohort does not defer: the cohort barrier keeps the
    two from running concurrently, so the coloring's existing separation already resolves it.
 
-5. **Apply the recolor result.** Write `RecolorResult.cohort_assignments` into `cohorts[]` and set
-   the top-level `recolor_generation` to `RecolorResult.generation`. The result's key set equals the
+5. **Apply the recolor result.** Write the recolor output field `cohort_assignments` into
+   `cohorts[]` and set the top-level `recolor_generation` to the output field `generation`. The
+   result's key set equals the
    unstarted set exactly and contains no pinned key: no in-flight item changes cohort or state as a
    result of this admission. Verify that before writing, and stop rather than write a result that
    names a pinned key. The admit branch performs no recolor at all, precisely because the candidate
@@ -141,8 +167,17 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    values to be unique (`scripts/dev_tools/_parallel_state_structures.py:282-305` — duplicate-index
    detection at 282-293, error emission at 301-305).
 
-6. **Append exactly one `mutations[]` entry**, at admission-decision time, built by
-   `build_add_entry` from `scripts/dev_tools/parallel_mutation_protocol.py`:
+6. **Append exactly one `mutations[]` entry**, at admission-decision time, built by the bundled
+   entry point. Run the first line on the admit branch (`--deferred false`) and the second on the
+   defer branch (`--deferred true`):
+
+   ```bash
+   bash .claude/lib/bash/mutate-parallel-run.sh add-entry --item <key> --deferred false --generation <g> --at <timestamp>
+   bash .claude/lib/bash/mutate-parallel-run.sh add-entry --item <key> --deferred true --generation <g> --at <timestamp>
+   ```
+
+   `--generation` is the run's generation before this admission, read before any step-5 recolor;
+   the printed entry stamps it unchanged or plus one per the table below:
 
    | Case | `op` | `item_key` | `prior_state` | `new_state` | `disposition` | `recolor_generation` |
    | --- | --- | --- | --- | --- | --- | --- |
@@ -152,7 +187,8 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    `prior_state` is null on BOTH add rows. The accompanying `prepared` -> `scheduled` transition is
    not lost and is not recorded in the mutation entry: it is recorded as an item-state update in
    `items[]`, the same mechanism that records `proposed` -> `admitted` -> `prepared` in step 2. The
-   `at` timestamp comes from the engine's injected clock seam.
+   `at` timestamp is supplied through `--at`; when `--at` is omitted the entry point stamps the
+   current UTC minute.
 
 7. **Validate the checkpoint** before treating the admission as applied. Run the
    `validate_orchestration_artifacts` MCP tool with `artifact_type:
@@ -168,6 +204,8 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
   and `benefit` (tolerated-not-validated, returned by the scheduling entry point), and no reason
   member is added: the four `conflict_edges[].reason` members are unchanged. The nine parallel
   enums are owned by `.claude/rules/parallel-orchestration.md` and are consumed, never extended.
+  The `complexity_band` recorded in step 2 is not a new field: it is an existing scheduling field
+  read by drift re-scheduling.
 - This operation never moves, restates, or re-derives an in-flight item's cohort or state.
 - This operation performs no destructive side effect: it closes no pull request and removes no
   worktree. Those belong to `/parallel-remove` with `--disposition abandon`.

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

@@ -45,24 +45,37 @@ which is exactly what the gate exists to prevent. The re-derivation is mandatory
 
 1. Re-derive durable state as above and resolve the run's `items[]`.
 
-2. **Gate the close on no item being in flight.** Call `decide_close(items)` from
-   `scripts/dev_tools/parallel_mutation_protocol.py`. It raises the dedicated rejection exception
-   carrying EVERY in-flight key, so the rejection names all the work that must finish first rather
-   than one item at a time. On rejection: report the blocking keys and stop. A rejected close
-   appends NO `mutations[]` entry and makes NO state change — do not record the attempt.
+2. **Gate the close on no item being in flight.** Pass every re-derived item, as one
+   `<key>:<state>` token each, to the bundled entry point, which needs no Python interpreter:
 
-3. **Append exactly one run-scoped `mutations[]` entry** for a successful close, built by
-   `build_close_entry` from `scripts/dev_tools/parallel_mutation_protocol.py`:
+   ```bash
+   bash .claude/lib/bash/mutate-parallel-run.sh close --items "<k>:<state> ..."
+   ```
+
+   Exit 0 (stdout `{"close_permitted":true}`) permits the close. Exit 1 rejects it and prints one
+   stderr line naming EVERY in-flight key, so the rejection names all the work that must finish
+   first rather than one item at a time. On rejection: report the blocking keys and stop. A
+   rejected close appends NO `mutations[]` entry and makes NO state change — do not record the
+   attempt.
+
+3. **Append exactly one run-scoped `mutations[]` entry** for a successful close, built by the
+   bundled entry point:
+
+   ```bash
+   bash .claude/lib/bash/mutate-parallel-run.sh close-entry --generation <g> --at <timestamp>
+   ```
 
    | Case | `op` | `item_key` | `prior_state` | `new_state` | `disposition` | `recolor_generation` |
    | --- | --- | --- | --- | --- | --- | --- |
    | Close | `close` | null (run-scoped) | null | null | null | `g` (unchanged) |
 
    The entry is run-scoped, so `item_key` is null: the close acts on the run, not on an item. The
-   `at` timestamp comes from the engine's injected clock seam.
+   `at` timestamp is supplied through `--at`; when `--at` is omitted the entry point stamps the
+   current UTC minute.
 
 4. **Do not recompute.** Run termination changes no cohort assignment, so `recolor_generation` is
-   UNCHANGED and `cohorts[]` is not rewritten. Do not call `recolor_unstarted` as part of a close.
+   UNCHANGED and `cohorts[]` is not rewritten.
+   Do not run the `recolor` subcommand as part of a close.
 
 5. **Stop admitting.** After the close is recorded, the run accepts no further `/parallel-add`. The
    close record is the run's final mutation; nothing may be appended to `mutations[]` after it.

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

@@ -256,12 +256,40 @@ carries exactly these five elements.
    execution from that plan rather than re-running promotion, research, or planning. The item's
    prepared feature folder and approved atomic plan are already committed and preflight-clear on the
    item's own pushed feature branch.
+   The execution child starts a new checkpoint in its own worktree, and the preparation checkpoint
+   does not carry over, so the prompt also instructs the child to verify the item's GitHub issue
+   read-only (gh issue view), not to call `potential_to_issue` or the promotion-entry tool, and to
+   record its own top-level `issue_adoption` object per `.claude/rules/orchestrator-state.md`,
+   with origin `filed_before_orchestration` unless 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/`, the child cites
+   it as `potential_record`.
 5. The model-budget marker line `model_budget.fable_policy: <disabled|available|preferred>.`
 
 Spawn parameters, passed on the `Agent` call and never written into the prompt text:
 `isolation: "worktree"`, `run_in_background: true`, branch base `origin/main`, and `model` equal to
 that item's model routing receipt's resolved model.
 
+**Band and receipt source.** The parent reads each item's `complexity_band` and
+`model_routing_receipt` from the planner checkpoint `artifacts/orchestration/parallel-planner-state.json`.
+When the planner checkpoint is unavailable, the committed kickoff artifact's `## Item Summary`
+`complexity` column is the fallback band source. The parent passes `model` equal to the receipt's
+`model` when the run's `fable_policy` equals the receipt's `fable_policy`; otherwise it re-resolves
+with `Resolve-DelegationModel -Agent orchestrator -Band <band> -FablePolicy <run fable_policy>` and
+passes that result.
+An item admitted through `/parallel-add` appears neither in the planner checkpoint
+`artifacts/orchestration/parallel-planner-state.json` `items[]` nor in the kickoff
+`## Item Summary`; for such an item the band source is that item's `complexity_band` on the
+orchestrator checkpoint `artifacts/orchestration/parallel-orchestrator-state.json` `items[]`. An
+admitted item carries no `model_routing_receipt`, so the parent resolves `model` at spawn time as
+`model_policy.complexity_to_model[<band>]` from `config/orchestration-routing.json` under the
+run's `fable_policy`, with `fable` clamped to `opus` when `fable_policy` is `disabled`. That result
+equals `Resolve-DelegationModel -Agent orchestrator -Band <band> -FablePolicy <run fable_policy>`
+because `preferred_overlay.agents` does not include `orchestrator`. The parent passes that explicit
+`model` on the spawn rather than relying on the frontmatter default, and it stops rather than
+spawning without `model` when the admitted item has no `complexity_band` on the orchestrator
+checkpoint.
+
 Negative obligations on the prompt:
 
 - It never carries `Preparation mode: true`. Preparation fan-out belongs to `parallel-planner` and
@@ -301,6 +329,27 @@ omitted `model` falls back to the delegate's frontmatter default, `opus`, which
 `fable` resolution — and MUST NOT hard-code `model=opus` in a way that overrides the resolved
 routing model.
 
+The band and receipt for each item come from the planner checkpoint
+`artifacts/orchestration/parallel-planner-state.json`: the parent reads the item's `complexity_band`
+and `model_routing_receipt` there. When the planner checkpoint is unavailable, the committed kickoff
+artifact's `## Item Summary` `complexity` column is the fallback band source. The parent passes
+`model` equal to the receipt's `model` when the run's `fable_policy` equals the receipt's
+`fable_policy`; otherwise it re-resolves with
+`Resolve-DelegationModel -Agent orchestrator -Band <band> -FablePolicy <run fable_policy>` and
+passes that result.
+An item admitted through `/parallel-add` appears neither in the planner checkpoint
+`artifacts/orchestration/parallel-planner-state.json` `items[]` nor in the kickoff
+`## Item Summary`; for such an item the band source is that item's `complexity_band` on the
+orchestrator checkpoint `artifacts/orchestration/parallel-orchestrator-state.json` `items[]`. An
+admitted item carries no `model_routing_receipt`, so the parent resolves `model` at spawn time as
+`model_policy.complexity_to_model[<band>]` from `config/orchestration-routing.json` under the
+run's `fable_policy`, with `fable` clamped to `opus` when `fable_policy` is `disabled`. That result
+equals `Resolve-DelegationModel -Agent orchestrator -Band <band> -FablePolicy <run fable_policy>`
+because `preferred_overlay.agents` does not include `orchestrator`. The parent passes that explicit
+`model` on the spawn rather than relying on the frontmatter default, and it stops rather than
+spawning without `model` when the admitted item has no `complexity_band` on the orchestrator
+checkpoint.
+
 `route` is never an input to model selection. `route` remains file-count driven and governs only
 agents, skills, and MCP tools. A skill whose frontmatter `context` field holds the value `fork`
 inherits the parent model and ignores a model override, so model selection applies to agent
@@ -324,11 +373,16 @@ Procedure, per item:
 1. The item's child orchestration runs unmodified, with `epic_mode` `false` or absent, and finishes
    at its own DONE. The child's PR Creation Gate condition 6 already requires
    `ci_gate.conclusion == "success"`, so at child DONE the item's pull request is open against
-   `main` and its checks are green. The child is never instructed to merge its own pull request.
+   `main` and every check on its head SHA passed or was skipped. The child is never instructed to
+   merge its own pull request.
 2. On child completion, durably confirm pull-request state and check conclusion with
-   `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`.
+   `gh pr view --json state,mergedAt,headRefOid` and an unconditional re-read of every check on
+   that head, never from an in-memory completion notification or from the child's DONE report
+   alone. Run `gh pr checks <PR> --json bucket,name,state,link,workflow` and parse its output with
+   `pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-CiGateParser.ps1 -ChecksJson <checks-json> -HeadSha <headRefOid>`.
+   Record `merge_status: ci_green` only when that parser conclusion is `success`; on `failure` or
+   `pending`, or when `gh pr checks` fails with a "no checks reported" error, do not record
+   `merge_status: ci_green` and do not run `gh pr merge`.
    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
@@ -613,9 +667,10 @@ Every mutation re-derives durable state (`git worktree list --porcelain`, `git b
 `gh pr view`) before it is applied, because the checkpoint is a cache of durable state and not the
 source of truth. A rejected mutation appends no entry and changes no state.
 
-The decision logic for all three commands is the pure engine
-`scripts/dev_tools/parallel_mutation_protocol.py`. It decides; it never applies. Item keys are
-integers (`items[].issue_num`) everywhere on this surface.
+The decision logic for all three commands runs through the bundled bash entry points, which need no
+Python interpreter: `bash .claude/lib/bash/mutate-parallel-run.sh` for add, close, and requeue, and
+`bash .claude/lib/bash/remove-parallel-item.sh` for remove. They decide; they never apply. Item
+keys are integers (`items[].issue_num`) everywhere on this surface.
 
 ### Pinning invariant
 
@@ -719,8 +774,9 @@ lost and is not recorded in the mutation entry: it is recorded as an item-state
 with the checkpoint's lifecycle timestamps, the same mechanism that records
 `proposed` -> `admitted` -> `prepared` during preparation. `new_state` is null for `close` only, and
 `item_key` is null for `close` only. `disposition` is non-null only on a `remove` entry whose
-`prior_state` is `in_flight`. Every `at` timestamp comes from the engine's injected clock seam; the
-engine never reads the wall clock. No field and no enum member is added to `mutations[]`; the nine
+`prior_state` is `in_flight`. Every `at` timestamp is supplied by the caller through `--at`; an
+entry point reads the clock only when `--at` is omitted, and then stamps the current UTC minute. No
+field and no enum member is added to `mutations[]`; the nine
 parallel enums of `.claude/rules/parallel-orchestration.md` are consumed, never extended.
 
 Retrospective validation of the log is the helper
@@ -768,18 +824,25 @@ command to evade the match: that defeats the only mechanism protecting a destruc
 ### Drift-requeue append contract
 
 Radius drift detection consumes this protocol rather than reimplementing it. When drift halts the
-later-started item of a newly conflicting pair, the requeue is recorded through the mutation
-engine's `build_requeue_entry` constructor and the recolor through `recolor_unstarted`:
+later-started item of a newly conflicting pair, the requeue is recorded through the `requeue-entry`
+subcommand of the bundled entry point and the recolor through its `recolor` subcommand:
+
+```bash
+bash .claude/lib/bash/mutate-parallel-run.sh requeue-entry --item <key> --generation <g> --at <timestamp>
+```
 
 - Item state becomes `blocked` and per-item `merge_status` becomes `blocked_drift`.
 - Exactly one `mutations[]` entry is appended with `op: requeue`, `prior_state: in_flight`,
   `new_state: blocked`, `disposition: null`, and `recolor_generation` equal to `g` + 1 — the requeue
   is a recompute.
-- The recolor runs over the unstarted subgraph only, so no other in-flight item moves. Its call
-  shape is the six-argument form
-  `recolor_unstarted(unstarted_items, conflict_edges, pinned, current_generation, current_cohort=current_cohort, highest_pinned_cohort=highest_pinned_cohort)`,
-  where `current_cohort` and `highest_pinned_cohort` are both required and keyword-only.
-  `highest_pinned_cohort` is derived from re-verified durable state: the highest
+- The recolor runs over the unstarted subgraph only, so no other in-flight item moves. Run it as:
+
+  ```bash
+  bash .claude/lib/bash/mutate-parallel-run.sh recolor --unstarted "<k> ..." --edges "<a>:<b> ..." --pinned "<k> ..." --generation <g> --current-cohort <c> --highest-pinned-cohort <h>
+  ```
+
+  where `--current-cohort` and `--highest-pinned-cohort` are both required.
+  `--highest-pinned-cohort` is derived from re-verified durable state: the highest
   current-generation cohort index occupied by any in-flight item.
 
 The drift event itself is recorded in `drift_events[]`, which this protocol does not write. See

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.