@danmoisan/drm-copilot-mcp 1.1.24 → 1.1.26

package/resources/claude-customizations/.claude/skills/execution-environment/SKILL.md

@@ -11,6 +11,14 @@ This brief states the environment facts that every researcher, planner, prefligh
 
 Maintenance rule: this brief is updated in the same change that alters any fact it states. It carries no line numbers and no commit identifiers; it cites files, symbols, headings, job names, and test names. The same text is byte-identical in six locations: `.claude/skills/execution-environment/SKILL.md`, `.agents/skills/execution-environment/SKILL.md`, `.github/skills/execution-environment/SKILL.md`, and their bundled copies under `extensions/drm-copilot/resources/`. Where the Claude and Codex runtimes differ, both paths are named (`.claude/hooks/...` and `.codex/hooks/...`).
 
+## Development Toolchain Baseline
+
+The host manifest, both devcontainer Dockerfiles, and development CI use Python 3.13.17, Node.js 26.13.0/npm 11.20.0, PowerShell 7.6.9, and Poetry 2.3.2. Shell validation pins shfmt 3.14.1, ShellCheck 0.11.0, and actionlint 1.7.12. Host bootstrap treats manifest versions as minima and preserves equal/newer installations; the container verifier accepts later Python patches within 3.13 and checks the other selected pins.
+
+The devcontainer minor image can lag the Python patch, so both Dockerfiles copy the verified official Python runtime stage and select it and NodeSource ahead of older base-feature shims. Full configuration builds include the selected devcontainer features; a raw Dockerfile image alone does not prove feature-provided commands. Runtime verification uses an isolated Linux virtual environment rather than the host Windows environment.
+
+Python 3.11/3.12 compatibility jobs, consumer package engines, and independent release-publishing runtime pins remain unchanged. The shared version predicate lives in `scripts/bash/container_versions.sh`; `.devcontainer/verify-container.sh` resolves it relative to its own repository location.
+
 ## Tool Routes by Agent
 
 - `atomic-executor` has no PowerShell tool. Its `tools:` list is Read, Grep, Glob, Edit, Write, several `Bash(...)` entries, the four `mcp__drm-copilot__run_poshqc_*` tools, and `mcp__drm-copilot__validate_orchestration_artifacts`. A `(pattern)` suffix on a `tools:` entry admits the bare tool, so the executor has Bash, subject to the repository hooks and the runtime guard described under Command-Text Restrictions.
@@ -50,6 +58,8 @@ Two separate mechanisms restrict Bash command text. They are kept apart here bec
 - Hooks for an isolated subagent run inside the subagent's worktree with that worktree's hook scripts, which are `main`'s copies. A hook change on a branch is not exercised by isolated subagents until it merges.
 - Hook behavior on a branch is therefore proven by Pester suites, not by a live subagent run. A live check of a branch hook needs a non-isolated delegation from the item worktree.
 - The batch-budget hooks evaluate the checkpoint of the target worktree that `Resolve-HookTargetWorktree` resolves for the edited file, so an edit made from a coordinating session into an item worktree is evaluated against the item worktree's checkpoint. The preimplementation gate (#1010) resolves the file path of a Write or Edit call and the `-C` values and absolute operands of `git add` and `git commit` through the same resolver, and denies when the worktree listing fails or names no worktree; its delegation checks still resolve by portable identity. The PR authoring gate (#1011) resolves the branch that a `gh pr create` or `gh pr edit` command names (`--head`, `--branch`, or a `branch:` label) through the same resolver when the command carries no canonical issue number line, and otherwise keeps its portable-identity and current-branch resolution. The other gates that read `artifacts/orchestration/orchestrator-state.json` are unchanged and still use the root that holds the hook script.
+- Cleanup legs (#1026): a `cleanup-merged-worktrees` run writes no checkpoint, so the preimplementation gate (`.claude/hooks/enforce-orchestration-preimplementation-gate-cleanup.ps1` and its `.codex/hooks/` twin), the PR-authoring gate (`.claude/hooks/enforce-pr-author-skill.cleanup.ps1`), and the model-routing gate (`.claude/hooks/enforce-model-routing-receipt.ps1`) carry allow-side cleanup legs, evaluated only where each gate would otherwise deny, that share the pure predicates of `hook-cleanup-context.ps1`. The legs admit a Write of the session-root manifest `artifacts/orchestration/cleanup-worktrees-manifest.json` with valid content (an Edit stays denied), Write or Edit of paths under `docs/` or `.claude/agent-memory/` and of the pr-author receipt inside the consolidation worktree on branch `documentationandmemories`, `git -C <consolidation root> add` and `commit` of those paths, `Agent(pr-author)` with `branch: documentationandmemories`, and `gh pr create --head documentationandmemories --base main` while a fresh valid manifest exists at the session root and the pushed `refs/remotes/origin/documentationandmemories` resolves to the same commit as the consolidation worktree `HEAD`. A preimplementation-gate denial appends a cleanup sub-code (`Cleanup leg not applied`) only after a cleanup leg has identified the consolidation worktree as the target and a later condition fails; a call rejected by a prefilter keeps the unchanged deny text even when its target is the consolidation worktree, as does every other call.
+- Scratch rule (#1026): the preimplementation gate allows a Write or Edit of an absolute local path that lies outside every registered worktree and the session root and under a temporary root, read through the seam `Get-OrchestrationGateTemporaryRoot` (the long-name `GetTempPath()` value and the `TEMP`, `TMP`, and `TMPDIR` values, which can carry the 8.3 short-name spelling). The rule fails closed when any registered worktree lies under a temporary root.
 - Enforcement hooks do not invoke Python; bash is preferred and PowerShell is acceptable (`tests/scripts/claude-runtime/enforcement-hooks-no-python-invocation.Tests.ps1`).
 
 ## MCP Surfaces Run the Installed Extension
@@ -61,14 +71,14 @@ Two separate mechanisms restrict Bash command text. They are kept apart here bec
 ## CI Shape and Required Checks
 
 - `.github/workflows/ci.yml` triggers on `push` to `main` and `development`, on `pull_request` to `main`, `development`, and `epic/**`, on `workflow_dispatch`, and on `merge_group` (`types: [checks_requested]`, added by issue #952), with no path filters. When the merge queue on `main` is enabled, every required check is produced by a `merge_group` run of `ci.yml` as well as by the pull-request run; `.github/workflows/README.md` (`## Triggers`) records the trigger set.
-- Jobs in `ci.yml` and their check names: `Change scope` (job `changes`, the change-scope decision below); `CI full run` (job `full-run-marker`, which runs only on a full run, marks that run as a valid base for later decisions, and is not a required check); `quality-checks7 / Code Quality & Tests (<python-version>)` on Python 3.11, 3.12, and 3.13 (`_quality-checks.yml`: Black check, Ruff, Pyright, the Codex generator `--check`, the tier classification, and Pytest on every version; Pytest with line and branch coverage and the coverage-threshold check on the JSON report totals run on 3.13 only); `security-scan / Security Scanning` (its `safety check` step carries `continue-on-error: true` and does not fail the check); `docs-validation / Documentation Validation`; `build-check / Build Package`; `shell-coverage / Shell Coverage (Bats + kcov)`; `drm-copilot-extension-tests / drm-copilot Extension Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `root-typescript-tests / Root TypeScript Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `NPM Audit Gate / npm audit (<manifest>)` (the calling job carries the name `NPM Audit Gate`); and the `poshqc` group below.
+- Jobs in `ci.yml` and their check names: `Change scope` (job `changes`, the change-scope decision below); `CI full run` (job `full-run-marker`, which runs only on a full run, marks that run as a valid base for later decisions, and is not a required check); `quality-checks7 / Code Quality & Tests (<python-version>)` on Python 3.11, 3.12, and 3.13 (`_quality-checks.yml`: Black check, Ruff, Pyright, the Codex generator `--check`, the tier classification, and Pytest on every version; Pytest with line and branch coverage and the coverage-threshold check on the JSON report totals run on 3.13 only); `security-scan / Security Scanning` (its `safety check` step carries `continue-on-error: true` and does not fail the check); `docs-validation / Documentation Validation`; `build-check / Build Package`; `shell-coverage / Shell Coverage (Bats + kcov)`; `drm-copilot-extension-tests / drm-copilot Extension Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `root-typescript-tests / Root TypeScript Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `NPM Audit Gate / npm audit (<manifest>)` (the calling job carries the name `NPM Audit Gate`); the `poshqc` group below; and `CI Required Gate` (job `ci-required-gate`, issue #1074), which needs every other `ci.yml` job, runs under `if: always()` on `ubuntu-latest`, and passes `toJSON(needs)` to `scripts/ci/Invoke-CiRequiredGate.ps1`. The gate is green on a full run only when every needed job is `success`, and on a docs-only run only when `CI full run`, `root-typescript-tests`, and `NPM Audit Gate` are `success` or `skipped` and every other needed job is `success`; a `failure`, `cancelled`, or unknown result, a `Change scope` result other than `success`, and unreadable input are red. `tests/scripts/workflows/CiRequiredGateWorkflow.Tests.ps1` pins its `needs:` set against the other job ids of `ci.yml`.
 - PowerShell CI (`_poshqc.yml`): `poshqc / PowerShell QC static` (format and analyze on `windows-latest`); the shard matrix `poshqc / PowerShell QC shard 1`, `shard 2`, and `shard 3` (`Invoke-PoshQCTest -ShardIndex -ShardCount` over the scan folders of `config/poshqc-scan.json`, with coverage, on `windows-latest`); the aggregator `poshqc / PowerShell QC`, which requires the static and shard jobs to succeed, verifies shard completeness against a Pester discovery count, and merges shard coverage; and `poshqc / PowerShell hook suites (Linux)`, which runs only `tests/scripts/claude-hooks` and `tests/scripts/codex-hooks` on `ubuntu-latest` with coverage disabled. A new test file under a scanned folder is assigned to a shard automatically and is counted by the completeness check.
 - Change-scope decision (issue #962): the `Change scope` job runs `scripts/ci/Invoke-CiChangeScope.ps1` and publishes the job output `code`. The decision is `code=false` (docs-only) only on a `pull_request` event from this repository, through one of two comparisons. Green-run base: every file changed since the newest successful `ci.yml` run on the pull-request branch whose `CI full run` job succeeded, and whose head commit is present and an ancestor of the current head, is on the allowlist `config/ci-docs-only-paths.json`; the reason is `DOCS_ONLY_SINCE_<green head sha>`. Merge-base fallback (issue #973): when the green-run step ends with no earlier full green run (`NO_FULL_GREEN_RUN`), a missing base (`BASE_NOT_PRESENT`), or a non-ancestor base (`BASE_NOT_ANCESTOR`), and the pull request's base ref is exactly `main`, the script computes `git merge-base` of the payload base SHA (`BASE_SHA`, from `github.event.pull_request.base.sha`; the base ref arrives as `BASE_REF`) and the head, lists the files changed since that merge base with the same diff arguments, and decides `DOCS_ONLY_SINCE_MERGE_BASE_<merge base sha>` when every changed file is allowlisted. Both comparisons run the diff with rename detection off, so both the old and the new path of a rename are classified. A path is allowlisted when it starts with `docs/features/active/`, `docs/features/archive/`, `docs/features/completed/`, `docs/features/epics/`, `docs/features/parallel/`, `docs/features/potential/`, or `docs/research/`, does not start with `docs/features/templates/` or `docs/features/potential/template.md`, and ends in `.md`, `.txt`, `.log`, `.json`, or `.xml`; the allowlist file itself is not allowlisted. Every other case is a full run (`code=true`): `push`, `merge_group`, and `workflow_dispatch` events, a fork pull request, unreadable run or job data, no earlier full green run or a missing or non-ancestor base when the base ref is not `main`, a merge base that cannot be resolved (`MERGE_BASE_UNRESOLVED`, for example a blank base SHA or a base commit missing from the checkout), a failed ancestry check, an empty diff, any path outside the allowlist, and any error. The decision step carries `continue-on-error: true` and the callers compare the output with `!= 'false'`, so a failed or missing decision also gives a full run.
-- Docs-only behavior (`code=false`): `ci.yml` passes `run-heavy: false` to `_quality-checks.yml`, `_security-scan.yml`, `_build-check.yml`, `_poshqc.yml`, `_shell-coverage.yml`, and `_drm-copilot-extension-tests.yml`. Each required job still starts under its full-run check name with every step skipped, so every required context reports `success` without running its suite. In `_poshqc.yml` the aggregator `poshqc / PowerShell QC` runs with every step gated, and `poshqc / PowerShell QC static`, the shard jobs, and `poshqc / PowerShell hook suites (Linux)` are skipped at job level. `docs-validation / Documentation Validation` runs in full. `root-typescript-tests`, `NPM Audit Gate`, and `CI full run` are skipped at job level. A `success` on a docs-only commit is therefore not evidence that the heavy suites pass for that commit; that evidence is the newest run whose `CI full run` job succeeded.
+- Docs-only behavior (`code=false`): `ci.yml` passes `run-heavy: false` to `_quality-checks.yml`, `_security-scan.yml`, `_build-check.yml`, `_poshqc.yml`, `_shell-coverage.yml`, and `_drm-copilot-extension-tests.yml`. Each job that runs with its steps gated still starts under its full-run check name with every step skipped, so it reports `success` without running its suite. In `_poshqc.yml` the aggregator `poshqc / PowerShell QC` runs with every step gated, and `poshqc / PowerShell QC static`, the shard jobs, and `poshqc / PowerShell hook suites (Linux)` are skipped at job level. `docs-validation / Documentation Validation` runs in full. `root-typescript-tests`, `NPM Audit Gate`, and `CI full run` are skipped at job level. Eight currently required contexts therefore never report on a docs-only run: `poshqc / PowerShell QC shard 1`, `poshqc / PowerShell QC shard 2`, `poshqc / PowerShell QC shard 3`, `root-typescript-tests / Root TypeScript Tests (ubuntu-latest)`, `root-typescript-tests / Root TypeScript Tests (windows-latest)`, `NPM Audit Gate / npm audit (.)`, `NPM Audit Gate / npm audit (extensions/drm-copilot)`, and `NPM Audit Gate / npm audit (packages/mcp-server)`, so a docs-only head stays blocked under the 20-context ruleset. `CI Required Gate` passes on a docs-only run, because it accepts `skipped` for exactly those skipped callers. A `success` on a docs-only commit is therefore not evidence that the heavy suites pass for that commit; that evidence is the newest run whose `CI full run` job succeeded.
 - A commit that changes any path outside the allowlist (any code, workflow, configuration, script, test, or customization file) runs the full set of jobs, and its `CI full run` job marks it as a base for later docs-only decisions. A standalone `workflow_dispatch` of a reusable workflow, or a caller that omits `run-heavy`, also runs in full. `.github/workflows/README.md` (`## Change-Scope Decision (Issue #962)`) records the reason codes and the per-context behavior table.
-- Required contexts of ruleset 15241672, confirmed by the orchestrator through `gh api` on 2026-10-16: `drm-copilot-extension-tests / drm-copilot Extension Tests (ubuntu-latest)`, `drm-copilot-extension-tests / drm-copilot Extension Tests (windows-latest)`, `docs-validation / Documentation Validation`, `poshqc / PowerShell QC`, `shell-coverage / Shell Coverage (Bats + kcov)`, `security-scan / Security Scanning`, `quality-checks7 / Code Quality & Tests (3.11)`, `quality-checks7 / Code Quality & Tests (3.12)`, `quality-checks7 / Code Quality & Tests (3.13)`, `build-check / Build Package`.
-- Refresh rule: a change that renames a job, adds or removes a matrix entry, or changes the ruleset refreshes this list in the same change, and the orchestrator re-confirms the contexts with a read-only `gh api repos/drmoisan/drm-copilot/rulesets/15241672` call before relying on them.
-- Skipped-check semantics: a job skipped by an `if:` condition reports success to a required check; a workflow that does not run at all reports nothing, which leaves the required check pending.
+- Required contexts of ruleset 15241672, read through a read-only `gh api` call on 2026-11-04 (20 contexts, each with `integration_id` 15368): `drm-copilot-extension-tests / drm-copilot Extension Tests (ubuntu-latest)`, `drm-copilot-extension-tests / drm-copilot Extension Tests (windows-latest)`, `docs-validation / Documentation Validation`, `poshqc / PowerShell QC`, `shell-coverage / Shell Coverage (Bats + kcov)`, `security-scan / Security Scanning`, `quality-checks7 / Code Quality & Tests (3.11)`, `quality-checks7 / Code Quality & Tests (3.12)`, `quality-checks7 / Code Quality & Tests (3.13)`, `build-check / Build Package`, `NPM Audit Gate / npm audit (extensions/drm-copilot)`, `NPM Audit Gate / npm audit (.)`, `NPM Audit Gate / npm audit (packages/mcp-server)`, `root-typescript-tests / Root TypeScript Tests (ubuntu-latest)`, `root-typescript-tests / Root TypeScript Tests (windows-latest)`, `poshqc / PowerShell QC shard 1`, `poshqc / PowerShell QC shard 2`, `poshqc / PowerShell QC shard 3`, `poshqc / PowerShell QC static`, `poshqc / PowerShell hook suites (Linux)`. After the owner's post-merge ruleset edit (issue #1074 runbook), the single required context is `CI Required Gate` (`integration_id` 15368), and the individual job contexts remain visible but are no longer required.
+- Refresh rule: a change that renames a job, adds or removes a `ci.yml` job or a matrix entry, or changes the ruleset refreshes this list in the same change, and the orchestrator re-confirms the contexts with a read-only `gh api repos/drmoisan/drm-copilot/rulesets/15241672` call before relying on them. A new `ci.yml` job must also be added to the `needs:` list of `ci-required-gate`; `tests/scripts/workflows/CiRequiredGateWorkflow.Tests.ps1` fails until it is.
+- Skipped-check semantics: a job skipped by an `if:` condition reports success to a required check; a workflow that does not run at all reports nothing, which leaves the required check pending. A matrix job skipped at job level reports no expanded context (its matrix name is never expanded), and a reusable-workflow caller skipped in `ci.yml` reports no nested contexts, so each such required context stays pending.
 - A pull request into a branch other than `main`, `development`, or `epic/**` gets no CI run; dispatch `ci.yml` manually for it.
 
 ## CI-Only Failure Classes

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

@@ -1,7 +1,7 @@
 ---
 name: parallel-add
 description: Admit one new item into a running parallel run — preparation via a preparation-mode child orchestrator run, conflict-edge computation against all items including in-flight ones, and the admission decision that either places the item in the current cohort or defers it and recolors the unstarted subgraph. Appends exactly one mutations[] entry. In-flight items are never moved.
-argument-hint: "[issue|potential-entry]"
+argument-hint: "[issue|potential-entry] [--after <earlier>] [--band <Cn>]"
 context: fork
 agent: parallel-orchestrator
 ---
@@ -28,7 +28,9 @@ this operation may and may not disturb. Read that section before applying anythi
   `/parallel-run` for that.
 - `$ARGUMENTS` names exactly one item: a GitHub issue number or reference, or a path to an entry
   under `docs/features/potential/`. An argument naming more than one item is rejected; admit one
-  item per invocation so each admission decision and its mutation entry stay attributable.
+  item per invocation so each admission decision and its mutation entry stay attributable. The
+  `--after <earlier>` and `--band <Cn>` flags are not items, so the multi-item rejection applies to
+  positional items only.
 - The run-existence check is evaluated first, before any argument-shape check: a pending or
   not-started run, and a run whose `parallel_slug` no checkpoint tracks, are rejected before the
   argument is examined.
@@ -37,6 +39,15 @@ this operation may and may not disturb. Read that section before applying anythi
   the run's slug is known, put the line `parallel_slug: <slug>` before the signal, and end the
   final output with the literal line `PARALLEL_MUTATION_REJECTED: run_not_started` as its last
   line, with no formatting and no trailing text.
+- After the run-existence check passes, apply the closed-run guard in code. Read the manifest mode
+  with `bash .claude/lib/bash/validate-parallel-manifest.sh --print-mode <manifest-path>`, then run
+  `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 guard-run -CheckpointPath artifacts/orchestration/parallel-orchestrator-state.json -ManifestMode <mode>`.
+  The guard rejects when either mode is `closed`, when a `mutations[]` entry has `op` `close`, or
+  when the two modes disagree. On exit 1, stop with the helper's stderr line
+  (`PARALLEL_ADMISSION_REJECTED: run_closed: <detail>`) as the reported reason, change no state,
+  and emit no mutation rejection signal: `run_closed` is an admission rejection code defined in
+  `## Prepared-Item Admission (issue #1047)` of `.claude/rules/parallel-orchestration.md`, not a
+  mutation rejection code.
 - A closed run and an argument naming more than one item are rejected only after the run-existence
   check, while the run's checkpoint exists; each of these rejections emits no rejection signal, and
   the stop validates against that checkpoint.
@@ -61,13 +72,39 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
 1. **Enter `proposed`.** Add the item to `items[]` in state `proposed` with its `issue_num` as the
    primary key. Item keys are integers throughout this surface; there is no string key.
 
-2. **Prepare the item.** Run preparation through a preparation-mode child `Agent(orchestrator)`
+2. **Prepare the item.** First assess how far the item's pushed branch is already prepared:
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 assess -Branch origin/<item branch> -FeatureFolder <feature folder> -PlannerCheckpointPath artifacts/orchestration/parallel-planner-state.json`,
+   adding `-Band <Cn>` when the operator passed `--band`. The helper reads the branch by ref, selects
+   the newest preparation receipt or infers the stage from the branch files, compares the files the
+   plan cites against `origin/main` since the base commit, and prints `next_action`.
+   - When `next_action` is `admit_prepared` (stage `cleared`, verdict `fresh`), run no preparation
+     child, no preflight, and no plan revision. Record the output's `preparation_status`,
+     `plan_hash`, `base_commit`, `complexity_band` (the `band.value`), and `band_source` (the
+     `band.source`) on the item, and continue with step 3.
+   - Otherwise delegate the preparation child described below on the item's pushed branch, not on
+     a new branch, and append after the unchanged kickoff line the resume line
+     `Preparation resume: stage <stage>. Existing artifacts: <paths>. Do not repeat a completed stage; supersede with new timestamped files.`
+     with `<stage>` set to the output's `resume_stage` and `<paths>` listing the existing
+     `research_path`, `spec_path`, and `plan_path` relative to the feature folder. A stale item
+     (verdict `stale`) resumes at preflight with the output's `changed_cited_paths` as the findings,
+     under the single-pass rule of `.claude/skills/orchestrate/SKILL.md` `## Delegation Model`
+     (trivial defects fixed in place, one planner revision for substantive defects, and a halt with
+     the defect list when a second round still fails). A plan that never cleared preflight always
+     runs preflight. A contract change found by that preflight, or a `premise_falsified` verdict
+     (a cited path removed on `main`), resumes at `plan`: the new plan is a new timestamped file,
+     and no superseded artifact is deleted.
+   - The band source order is `--band` (`band_source: caller`), then the planner checkpoint item's
+     `complexity_band` (`planner_checkpoint`), then the `## Complexity Assessment` procedure below
+     (`assessment`).
+
+   Otherwise run preparation through a preparation-mode child `Agent(orchestrator)`
    run, reusing the existing `route_id: preparation` contract UNCHANGED: promotion, research,
    `spec.md`, `user-story.md`, the atomic plan, and preflight clearance. Do not fork a variant
    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. After the admitted item's preflight
+   `items[]` with the checkpoint's lifecycle timestamps. When the band source is `assessment`, 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.
@@ -125,6 +162,11 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    `qualifies for combination; not combined (combination applies at planning time only)`. This
    step never combines items: it adds no checkpoint field and makes no `mutations[]` change for a
    qualifying pair.
+   Record each `--after <earlier>` flag as one top-level `precedence[]` entry
+   `{before, after, source, recorded_at}` with `before` the earlier item, `after` the candidate,
+   `source` `operator`, and `recorded_at` the current UTC minute. Each precedence pair is a
+   separating input, never a dependency key: add it to the edges passed to steps 4 and 5 as one
+   more `<a>:<b>` edge with `a < b`, so the coloring always separates the pair.
 
 4. **Decide admission.** Call the bundled entry point, which needs no Python interpreter:
 
@@ -166,12 +208,23 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    `.claude/skills/parallel-orchestrate/SKILL.md` — so the current cohort durably holds `scheduled`
    members that a candidate can contend with.
 
+   A candidate with an active unmerged predecessor (a `precedence[]` entry whose `before` item has a
+   `merge_status` other than `merged` or `worktree_removed` and a `state` other than `withdrawn`) is
+   forced to `defer_and_recolor` even when `admit` prints `admit_current_cohort`.
+
    A conflict with an unstarted member of the CURRENT cohort defers the candidate and recolors,
    because the next `max_concurrency` batch would otherwise launch the two concurrently. A conflict
    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 the recolor output field `cohort_assignments` into
+5. **Apply the recolor result.** Before writing, pass the recolor result through the precedence
+   lift: `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 order-cohorts -Cohorts <table-json> -Edges "<a>:<b> ..." -Precedence "<before>:<after> ..." -Pinned "<k> ..." -Floor <current_cohort>`,
+   which moves an unstarted `after` item above its `before` items and never moves a pinned item.
+   After writing, and before step 6 appends the mutation entry, run
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 test-cohorts -CheckpointPath artifacts/orchestration/parallel-orchestrator-state.json`;
+   on exit 1 (`precedence_violated`, `precedence_cycle`, or `precedence_unknown_item`), restore the
+   prior `cohorts[]` and `recolor_generation` and stop with the helper's stderr line.
+   Write the recolor output field `cohort_assignments` (as lifted) 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
@@ -216,12 +269,23 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    "parallel-orchestrator-state"`. A non-empty error list means the admission was applied
    incorrectly; correct the checkpoint rather than proceeding.
 
+8. **Rewrite the durable scheduling record.** Build the record content with
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 record -RunFolder docs/features/parallel/<slug> -Entry <entry-json>`,
+   where the entry carries the checkpoint's `conflict_edges`, `tolerated_overlaps`, `precedence`,
+   and `items`. The helper prints the content and makes no git write. Write it to
+   `docs/features/parallel/<slug>/parallel-scheduling.json` on `parallel/<slug>-plan` and commit it
+   with a pathspec under `docs/features/parallel/`, so a re-seed from another checkout reads the
+   recorded edges and plan hashes by ref.
+
 ## Constraints
 
 - One admission per invocation, one `mutations[]` entry per successful admission. A failed
   preparation appends no entry and leaves `items[]` without the candidate.
-- No field and no enum member is added to `mutations[]`, `items[]`, or any state or merge-status
-  enum. A `conflict_edges[]` entry may carry only the three tolerated extra fields `hard`, `cost`,
+- No field and no enum member is added to `mutations[]` or any state or merge-status enum. The only
+  fields added to `items[]` are the four tolerated fields `preparation_status`, `plan_hash`,
+  `base_commit`, and `band_source` declared in `## Prepared-Item Admission (issue #1047)` of
+  `.claude/rules/parallel-orchestration.md`, which also declares the top-level `precedence[]` list
+  this skill records. A `conflict_edges[]` entry may carry only the three tolerated extra fields `hard`, `cost`,
   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.

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

@@ -129,6 +129,16 @@ completion notification. A blocked item (`blocked_ci_loop_limit` or `blocked_dri
 `merged` nor `worktree_removed`, so it holds every conflicting later-cohort neighbour and,
 transitively, the tail of its own conflict component; items outside that component are unaffected.
 
+**Precedence.** An item named as `after` in an active `precedence[]` entry (the operator ordering
+input declared in `## Prepared-Item Admission (issue #1047)` of
+`.claude/rules/parallel-orchestration.md`) may start only when its `before` item has `merge_status`
+`merged` or `worktree_removed`, whatever the two items' cohorts. A `withdrawn` predecessor releases
+the constraint, and a `blocked` predecessor holds its dependent. Layer 1 enforces this rule through
+`Test-ParallelCohortBarrierClear` in `.claude/hooks/enforce-parallel-cohort-barrier-helpers.ps1`,
+which denies a target whose predecessor is not released and fails closed on a missing predecessor
+record. Layer 2 does not check precedence: the Python orchestrator-state validator reads
+`conflict_edges[]` only.
+
 **`current_cohort` is a progress indicator, not a gate.** `current_cohort` is the LOWEST
 current-generation cohort index that still contains a non-terminal, non-withdrawn item. It is
 recomputed and written only on durable confirmation from `git worktree list --porcelain`,
@@ -265,6 +275,10 @@ 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 prompt also carries the item's admitted plan hash as `plan-hash: <hex>` and instructs the child, before any other step, to run `git rev-parse HEAD:<plan-path>` and to stop with `blocked_reason: premise_falsified` when the printed hash differs from `<hex>`.
+   The `<hex>` value is the item's `plan_hash` from the orchestrator checkpoint item, else the
+   kickoff `## Integrity` row for its plan path. The check runs before the child reconciles with
+   `origin/main`, so a plan that changed after admission never reaches atomic execution.
    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
@@ -404,6 +418,15 @@ Procedure, per item:
    CI-dependent acceptance criteria. When either check fails, do not record
    `merge_status: ci_green` and do not run `gh pr merge`; the item waits until its child pushes
    the check-off and re-runs S9, and the parent does not commit the check-off itself.
+   **Turn gap.** A child can end its turn with its pull request open and its CI green gate still
+   pending. On every child completion, read the child checkpoint
+   `<worktree>/artifacts/orchestration/orchestrator-state.json`, with the worktree path located by
+   `git worktree list --porcelain`. When its `step9_status` is not `passed` or its `blocked_reason`
+   is `awaiting_ci`, keep `merge_status: pr_open` and treat the item as not done: poll
+   `gh pr checks` through the parser above until the conclusion is terminal, then
+   re-delegate the child once to resume at the CI green gate, by the same re-delegation mechanism as
+   `## Per-Item Merge-Conflict Handling`; a CI-failure cycle counts toward `remediation_loop`.
+   Record `ci_green` only after that resumed run reports its CI green gate `passed`.
 3. Execute `gh pr merge --merge <PR>` for that item's pull request, whose base is `main`.
    Do not pass `--delete-branch` or `--auto`. A zero exit status does not prove a merge: when
    `main` uses a merge queue, `gh pr merge` exits 0 after it enqueues the pull request or enables
@@ -711,8 +734,9 @@ This section is consumption documentation only. The checkpoint schema is owned b
 as prose invariants in `.claude/rules/parallel-orchestration.md`, and enforced by
 `scripts/dev_tools/validate_parallel_orchestrator_state.py`. Consume that schema;
 add no field to it that `.claude/rules/parallel-orchestration.md` does not declare,
-and extend no enum in it. `mergeable_conflicts_resolved` is the one declared optional item
-field.
+and extend no enum in it. The declared optional item fields are `mergeable_conflicts_resolved`,
+`preparation_status`, `plan_hash`, `base_commit`, and `band_source`, and the declared optional
+top-level field is `precedence[]` (`## Prepared-Item Admission (issue #1047)` of the rule).
 
 Fields `parallel-orchestrator` writes to `artifacts/orchestration/parallel-orchestrator-state.json`:
 `objective`, `route_id: "parallel"`, `parallel_slug`, `parallel_manifest_path`,

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

@@ -1,7 +1,7 @@
 ---
 name: parallel-plan
 description: Prepare a set of thematically unrelated items for concurrent execution before any execution begins - item intake over issue numbers and potential-entry paths, concurrent preparation-mode child orchestrator delegations, blast-radius computation and V1-V3 validation, cohort seeding with a recomputation-parity check, run-manifest and planner-checkpoint authoring, and the parallel-orchestrator kickoff artifact.
-argument-hint: "[items: issue numbers and/or potential-entry paths]"
+argument-hint: "[items: issue numbers and/or potential-entry paths] [--after <later>:<earlier> ...]"
 context: fork
 agent: parallel-planner
 ---
@@ -16,7 +16,8 @@ $ARGUMENTS
 This skill frames work for the `parallel-planner` agent, parallel to how
 `.claude/skills/epic-plan/SKILL.md` frames work for `epic-planner`. The `parallel` surface
 schedules thematically unrelated items by computed blast-radius contention: there is no worthiness
-assessment, no operator-supplied ordering, and no shared branch into which item work merges.
+assessment, no operator-supplied ordering beyond the optional `--after <later>:<earlier>`
+precedence flags, and no shared branch into which item work merges.
 Planning ends at preflight clearance and cohort seeding; no atomic execution, PR authoring, or CI
 monitoring occurs under this skill.
 
@@ -62,13 +63,29 @@ identical forms.
 - **`kind`.** Record `kind: feature | bug` at intake from the item source (issue labels, or the
   potential entry's declared kind). When the source is indeterminate, default to `feature` and note
   the choice `[recommendation, not upstream-constrained]`.
+- **Admission assessment.** Run the same `assess` subcommand `/parallel-add` step 2 runs for every
+  item whose branch is pushed:
+  `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 assess -Branch origin/<item branch> -FeatureFolder <feature folder>`.
+  An item with no pushed branch (an unpromoted potential entry) takes `full_preparation`. Fan-out
+  takes only the items whose `next_action` is not `admit_prepared`. An item whose `next_action` is
+  `admit_prepared` (stage `cleared`, verdict `fresh`) runs no preparation child: record its
+  `plan_path`, `research_path`, `plan_hash`, `base_commit`, `branch_name`, and
+  `preflight_status: PREFLIGHT: ALL CLEAR` from the branch, set `preparation_status: prepared`
+  (the planner ready value that corresponds to the admission stage `cleared`), and record
+  `topology_receipt` as not applicable, because no preparation child ran for it.
+- **Precedence input.** Record each `--after <later>:<earlier>` flag as one top-level
+  `precedence[]` entry `{before, after, source, recorded_at}` with `source` `operator`, as
+  declared in `## Prepared-Item Admission (issue #1047)` of `.claude/rules/parallel-orchestration.md`.
+  The flags are optional and are never requested.
 
 The operator is never asked for ordering edges, cohort assignments, or a worthiness verdict.
 Intake proceeds directly to preparation fan-out.
 
 ## Preparation Fan-Out
 
-One preparation-mode `Agent(orchestrator)` run per item. Preparation produces documents and plans
+One preparation-mode `Agent(orchestrator)` run per incomplete item, that is, per item whose
+`assess` `next_action` is not `admit_prepared`; the waves below cover the incomplete items only.
+Preparation produces documents and plans
 rather than code, and items carry no ordering constraint, so preparations may run concurrently —
 but they are BOUNDED, not unbounded.
 
@@ -84,6 +101,8 @@ JSON array of arrays, returns the batches in order, and sorts the keys itself, s
 does not depend on caller ordering. Launch wave *k* as one message carrying that wave's `Agent`
 calls, each `isolation: "worktree"` and `run_in_background: true`.
 Create each preparation worktree's branch from `origin/main`.
+A resumed item (`next_action` `resume_preparation`) instead runs on its pushed branch, as
+`## Issue Combination` step 3 does, so its completed stages stay on that branch.
 Launch wave *k+1* only after every child of wave *k* has TERMINATED — not merely reported
 progress. All of this happens inside a single `/parallel-plan` invocation with no operator action
 between waves.
@@ -107,13 +126,18 @@ 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 and, for an issue-number item only, the issue-adoption line:
+line, for an issue-number item only, the issue-adoption line, for a resumed item only, the
+preparation-resume line, and the preparation-receipt 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.`
+>
+> `Preparation resume: stage <stage>. Existing artifacts: <paths>. Do not repeat a completed stage; supersede with new timestamped files.`
+>
+> `Preparation receipt: before the commit, write <feature folder>/evidence/other/preparation-receipt.<yyyy-MM-ddTHH-mm>.json with schema_version, stage, research_path, spec_path, plan_path, plan_hash, base_commit, preflight_status, and recorded_at.`
 
 Properties of that line, each individually load-bearing:
 
@@ -144,6 +168,21 @@ to execution, so the execution child records its own adoption (see
 creates and commits the feature folder, the execution child's adoption also waives
 `new_active_feature_folder` and records `feature_folder_record` for that committed folder.
 
+**Preparation-resume line.** The preparation-resume line is emitted only for a resumed item, after
+the issue-adoption line (or after the model-budget marker line for a potential-entry item). Its
+`<stage>` is the `assess` `resume_stage`, and its `<paths>` are the existing `research_path`,
+`spec_path`, and `plan_path` written relative to the feature folder. The line carries no mode
+marker and no active feature-folder path and does not match the hook issue-number pattern, so hook
+target resolution and mode classification are unchanged. A stale item resumes at preflight with
+the `assess` `changed_cited_paths` as findings under the unchanged single-pass rule of
+`.claude/skills/orchestrate/SKILL.md` `## Delegation Model`; a falsified premise resumes at `plan`,
+and a superseded artifact is replaced by a new timestamped file and never deleted.
+
+**Preparation-receipt line.** The preparation-receipt line is emitted for every delegated item. The
+child resolves `<feature folder>` to its own folder and writes the receipt declared in
+`## Prepared-Item Admission (issue #1047)` of `.claude/rules/parallel-orchestration.md` before its
+commit, so a later `assess` reads the stage, plan hash, and base commit from the branch.
+
 **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
@@ -437,7 +476,13 @@ The library returns the partition; the planner supplies the record fields.
    (hard classes, integer cost, pairwise benefit, and the configured `conflict_tolerance`). It
    returns `edges` and `tolerated_overlaps`. The -Relation argument is required; pass the facade's
    Test-BlastRadiusConflict function object as shown. Pass the returned `edges` pairs as
-   `--edges "<a>:<b> ..."` and the item keys as `--keys "<k1> <k2> ..."`.
+   `--edges "<a>:<b> ..."` and the item keys as `--keys "<k1> <k2> ..."`. Add each recorded
+   `precedence[]` pair to `--edges` as one more separating `<a>:<b>` edge with `a < b`, so the
+   coloring always separates the pair. Then pass the coloring through the precedence lift:
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 order-cohorts -Cohorts <compute-cohorts output> -Edges "<a>:<b> ..." -Precedence "<before>:<after> ..."`.
+   No item has started at seeding, so the call passes no option that holds an item in place, and
+   its `cohorts` output is the table steps 3 and 5 record. A `precedence_cycle` or
+   `precedence_unknown_item` rejection (exit 1) stops the run with the helper's stderr line.
    The detection relation inside the entry point contributes no `path_overlap` edge for a path
    matching the truth table's optional `mergeable_paths` list, and the path stays in the declared
    radius. When `Test-BlastRadiusConflict` is called directly (for example, while investigating a
@@ -482,6 +527,18 @@ The library returns the partition; the planner supplies the record fields.
    (the bash port of `compute_concurrency_batches(cohort_item_keys, max_concurrency)`), which fills
    slots in ascending item-key order. Recoloring under add, remove, or drift mutation is F6 and F8
    scope. This skill performs seeding only.
+7. **Durable scheduling record.** Build the record content with
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 record -RunFolder docs/features/parallel/<slug> -Entry <entry-json>`
+   from the recorded `conflict_edges`, `tolerated_overlaps`, `precedence`, and `items`; the helper
+   prints the content and makes no git write. Write it to
+   `docs/features/parallel/<slug>/parallel-scheduling.json` and commit it on `parallel/<slug>-plan`
+   with the manifest. A re-seed applies the reuse rule per item with
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 reuse-edges -Slug <slug> -IssueNum <issue> -PlanHash <plan_hash>`,
+   where `<plan_hash>` is the item's `plan_hash` from its `assess` output. The helper reads the
+   committed record by ref from `origin/parallel/<slug>-plan`, runs no fetch, and prints
+   `{action, edges, reason}`. On `action` `reuse` the printed `edges` are that item's recorded
+   edges and are reused; on `action` `recompute` (reason `record_missing`, `unknown_item`, or
+   `plan_hash_changed`) that item's edges are recomputed.
 
 ### Recomputation parity (planner-owned check)
 
@@ -492,12 +549,18 @@ skill discharges that obligation as documented procedure, not as a new module:
 
 1. After writing `cohorts[]` into the checkpoint and **before** emitting the kickoff artifact,
    re-invoke `compute_cohorts` over exactly the `item_keys` and `conflict_edges` recorded in the
-   checkpoint.
+   checkpoint (through `compute-cohorts.sh`), plus the separating edges of the recorded
+   `precedence[]` pairs, and pass the result through `order-cohorts` with the recorded precedence,
+   exactly as `### Seeding procedure` step 1 does.
 2. Assert that the recomputed list of lists maps to exactly the recorded `cohorts[]` at
    `generation: 0`: the same partition, the same `index` assignment, and the same ascending
-   `item_keys[]` ordering.
-3. A mismatch is a **Blocking** condition. Stop the run and report the mismatch. Do not
-   auto-correct the recorded cohorts, and do not emit the kickoff artifact.
+   `item_keys[]` ordering. Then run
+   `pwsh -NoProfile -NonInteractive -File .claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1 test-cohorts -CheckpointPath artifacts/orchestration/parallel-planner-state.json`,
+   which rejects with `precedence_violated` when a cohort places an `after` item at or before an
+   active `before` item.
+3. A mismatch is a **Blocking** condition, and so is a `test-cohorts` rejection. Stop the run and
+   report the mismatch or the rejection. Do not auto-correct the recorded cohorts, and do not emit
+   the kickoff artifact.
 
 No production module is added for this check; it is a re-invocation of the landed library.
 
@@ -558,20 +621,22 @@ Write `artifacts/orchestration/parallel-planner-state.json` after every complete
 
 Top-level fields: `objective`, `parallel_slug`, `parallel_manifest_path`, `mode`,
 `max_concurrency`, `plan_home_branch` (`parallel/<slug>-plan`), `items[]`, `cohorts[]`,
-`conflict_edges[]`, `recolor_generation`, `kickoff_prompt_path`
+`conflict_edges[]`, `precedence[]` (the operator precedence entries, declared in
+`## Prepared-Item Admission (issue #1047)` of the rule), `recolor_generation`, `kickoff_prompt_path`
 (`artifacts/orchestration/parallel-kickoff-<slug>.md`), `completed_steps`, `next_step`, and
 `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`, `complexity_assessment`,
 `preparation_status`,
-`research_path`, `plan_path`, `preflight_status`, `branch_name`, `worktree_path`, `blast_radius`
+`research_path`, `plan_path`, `plan_hash`, `base_commit`, `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`.
 
 **Deliberately absent:** any `epic_worthiness` analogue, any `depends_on` field, and any `wave`
 field. The parallel surface renders no worthiness verdict and expresses ordering only as
-blast-radius overlap.
+blast-radius overlap and as the operator `precedence[]` input, which is a separating input and not
+a dependency field.
 
 **Readiness contract.** Before reporting completion the checkpoint must satisfy F3's
 `require_ready_for_execution` gate: at least two items (invariant P6); every item
@@ -674,6 +739,11 @@ Structural requirements enforced by the contract module:
   commit of `parallel/<slug>-plan` as run-level provenance and a per-item `plan-path | plan-hash`
   table whose hashes are 40 to 64 hex characters with no repeated plan path.
 
+The planner writes the `## Integrity` section with one row per item, whose `plan-hash` is that
+item's `assess` `plan_hash` (the plan blob hash at the item branch head), the same value recorded
+on the checkpoint item and in the durable scheduling record. The parallel orchestrator passes it to
+the item's execution child in kickoff element 4, which verifies it before any other step.
+
 Validate the artifact through `mcp__drm-copilot__validate_orchestration_artifacts` with
 `artifact_type: "parallel-kickoff"`. That artifact type dispatches to
 `scripts/dev_tools/parallel_kickoff_contract.py`, which this feature delivers.

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

@@ -47,6 +47,7 @@
     ".claude/hooks/enforce-file-size-limit.ps1",
     ".claude/hooks/enforce-model-routing-receipt.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate.ps1",
+    ".claude/hooks/enforce-orchestration-preimplementation-gate-cleanup.ps1",
     ".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",
@@ -60,6 +61,7 @@
     ".claude/hooks/enforce-powershell-batch-budget.ps1",
     ".claude/hooks/enforce-pr-author-command-allowlist.ps1",
     ".claude/hooks/enforce-pr-author-skill.artifact-root.ps1",
+    ".claude/hooks/enforce-pr-author-skill.cleanup.ps1",
     ".claude/hooks/enforce-pr-author-skill.current-branch.ps1",
     ".claude/hooks/enforce-pr-author-skill.docs-only.ps1",
     ".claude/hooks/enforce-pr-author-skill.epic-base-branch.ps1",
@@ -71,6 +73,7 @@
     ".claude/hooks/enforce-python-batch-budget.ps1",
     ".claude/hooks/feature-folder-resolution.ps1",
     ".claude/hooks/feature-review-coverage-thresholds.ps1",
+    ".claude/hooks/hook-cleanup-context.ps1",
     ".claude/hooks/hook-command-heredoc.ps1",
     ".claude/hooks/hook-command-invocation.ps1",
     ".claude/hooks/hook-command-invocation-operands.ps1",
@@ -122,6 +125,7 @@
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_lib.sh",
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_preserve_eol_lib.sh",
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_preserve_lib.sh",
+    ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_preserve_merge_lib.sh",
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_report_records_lib.sh",
     ".claude/skills/cleanup-merged-worktrees/scripts/cleanup_worktrees_scan_helper.sh",
     ".claude/skills/commit-message/SKILL.md",
@@ -231,6 +235,10 @@
     ".claude/lib/parallel-drift/ParallelDriftHalt.psm1",
     ".claude/lib/parallel-drift/ParallelDrift.psm1",
     ".claude/lib/parallel-drift/Invoke-ParallelDriftDetection.ps1",
+    ".claude/lib/parallel-admission/ParallelAdmission.psm1",
+    ".claude/lib/parallel-admission/ParallelAdmissionPrecedence.psm1",
+    ".claude/lib/parallel-admission/Invoke-ParallelAdmission.ps1",
+    ".claude/lib/parallel-admission/ParallelAdmissionJson.psm1",
     ".claude/rules/parallel-orchestration.md",
     ".claude/rules/shell.md",
     ".claude/lib/bash/abandon-parallel-item.sh",

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

@@ -11,6 +11,14 @@ This brief states the environment facts that every researcher, planner, prefligh
 
 Maintenance rule: this brief is updated in the same change that alters any fact it states. It carries no line numbers and no commit identifiers; it cites files, symbols, headings, job names, and test names. The same text is byte-identical in six locations: `.claude/skills/execution-environment/SKILL.md`, `.agents/skills/execution-environment/SKILL.md`, `.github/skills/execution-environment/SKILL.md`, and their bundled copies under `extensions/drm-copilot/resources/`. Where the Claude and Codex runtimes differ, both paths are named (`.claude/hooks/...` and `.codex/hooks/...`).
 
+## Development Toolchain Baseline
+
+The host manifest, both devcontainer Dockerfiles, and development CI use Python 3.13.17, Node.js 26.13.0/npm 11.20.0, PowerShell 7.6.9, and Poetry 2.3.2. Shell validation pins shfmt 3.14.1, ShellCheck 0.11.0, and actionlint 1.7.12. Host bootstrap treats manifest versions as minima and preserves equal/newer installations; the container verifier accepts later Python patches within 3.13 and checks the other selected pins.
+
+The devcontainer minor image can lag the Python patch, so both Dockerfiles copy the verified official Python runtime stage and select it and NodeSource ahead of older base-feature shims. Full configuration builds include the selected devcontainer features; a raw Dockerfile image alone does not prove feature-provided commands. Runtime verification uses an isolated Linux virtual environment rather than the host Windows environment.
+
+Python 3.11/3.12 compatibility jobs, consumer package engines, and independent release-publishing runtime pins remain unchanged. The shared version predicate lives in `scripts/bash/container_versions.sh`; `.devcontainer/verify-container.sh` resolves it relative to its own repository location.
+
 ## Tool Routes by Agent
 
 - `atomic-executor` has no PowerShell tool. Its `tools:` list is Read, Grep, Glob, Edit, Write, several `Bash(...)` entries, the four `mcp__drm-copilot__run_poshqc_*` tools, and `mcp__drm-copilot__validate_orchestration_artifacts`. A `(pattern)` suffix on a `tools:` entry admits the bare tool, so the executor has Bash, subject to the repository hooks and the runtime guard described under Command-Text Restrictions.
@@ -50,6 +58,8 @@ Two separate mechanisms restrict Bash command text. They are kept apart here bec
 - Hooks for an isolated subagent run inside the subagent's worktree with that worktree's hook scripts, which are `main`'s copies. A hook change on a branch is not exercised by isolated subagents until it merges.
 - Hook behavior on a branch is therefore proven by Pester suites, not by a live subagent run. A live check of a branch hook needs a non-isolated delegation from the item worktree.
 - The batch-budget hooks evaluate the checkpoint of the target worktree that `Resolve-HookTargetWorktree` resolves for the edited file, so an edit made from a coordinating session into an item worktree is evaluated against the item worktree's checkpoint. The preimplementation gate (#1010) resolves the file path of a Write or Edit call and the `-C` values and absolute operands of `git add` and `git commit` through the same resolver, and denies when the worktree listing fails or names no worktree; its delegation checks still resolve by portable identity. The PR authoring gate (#1011) resolves the branch that a `gh pr create` or `gh pr edit` command names (`--head`, `--branch`, or a `branch:` label) through the same resolver when the command carries no canonical issue number line, and otherwise keeps its portable-identity and current-branch resolution. The other gates that read `artifacts/orchestration/orchestrator-state.json` are unchanged and still use the root that holds the hook script.
+- Cleanup legs (#1026): a `cleanup-merged-worktrees` run writes no checkpoint, so the preimplementation gate (`.claude/hooks/enforce-orchestration-preimplementation-gate-cleanup.ps1` and its `.codex/hooks/` twin), the PR-authoring gate (`.claude/hooks/enforce-pr-author-skill.cleanup.ps1`), and the model-routing gate (`.claude/hooks/enforce-model-routing-receipt.ps1`) carry allow-side cleanup legs, evaluated only where each gate would otherwise deny, that share the pure predicates of `hook-cleanup-context.ps1`. The legs admit a Write of the session-root manifest `artifacts/orchestration/cleanup-worktrees-manifest.json` with valid content (an Edit stays denied), Write or Edit of paths under `docs/` or `.claude/agent-memory/` and of the pr-author receipt inside the consolidation worktree on branch `documentationandmemories`, `git -C <consolidation root> add` and `commit` of those paths, `Agent(pr-author)` with `branch: documentationandmemories`, and `gh pr create --head documentationandmemories --base main` while a fresh valid manifest exists at the session root and the pushed `refs/remotes/origin/documentationandmemories` resolves to the same commit as the consolidation worktree `HEAD`. A preimplementation-gate denial appends a cleanup sub-code (`Cleanup leg not applied`) only after a cleanup leg has identified the consolidation worktree as the target and a later condition fails; a call rejected by a prefilter keeps the unchanged deny text even when its target is the consolidation worktree, as does every other call.
+- Scratch rule (#1026): the preimplementation gate allows a Write or Edit of an absolute local path that lies outside every registered worktree and the session root and under a temporary root, read through the seam `Get-OrchestrationGateTemporaryRoot` (the long-name `GetTempPath()` value and the `TEMP`, `TMP`, and `TMPDIR` values, which can carry the 8.3 short-name spelling). The rule fails closed when any registered worktree lies under a temporary root.
 - Enforcement hooks do not invoke Python; bash is preferred and PowerShell is acceptable (`tests/scripts/claude-runtime/enforcement-hooks-no-python-invocation.Tests.ps1`).
 
 ## MCP Surfaces Run the Installed Extension
@@ -61,14 +71,14 @@ Two separate mechanisms restrict Bash command text. They are kept apart here bec
 ## CI Shape and Required Checks
 
 - `.github/workflows/ci.yml` triggers on `push` to `main` and `development`, on `pull_request` to `main`, `development`, and `epic/**`, on `workflow_dispatch`, and on `merge_group` (`types: [checks_requested]`, added by issue #952), with no path filters. When the merge queue on `main` is enabled, every required check is produced by a `merge_group` run of `ci.yml` as well as by the pull-request run; `.github/workflows/README.md` (`## Triggers`) records the trigger set.
-- Jobs in `ci.yml` and their check names: `Change scope` (job `changes`, the change-scope decision below); `CI full run` (job `full-run-marker`, which runs only on a full run, marks that run as a valid base for later decisions, and is not a required check); `quality-checks7 / Code Quality & Tests (<python-version>)` on Python 3.11, 3.12, and 3.13 (`_quality-checks.yml`: Black check, Ruff, Pyright, the Codex generator `--check`, the tier classification, and Pytest on every version; Pytest with line and branch coverage and the coverage-threshold check on the JSON report totals run on 3.13 only); `security-scan / Security Scanning` (its `safety check` step carries `continue-on-error: true` and does not fail the check); `docs-validation / Documentation Validation`; `build-check / Build Package`; `shell-coverage / Shell Coverage (Bats + kcov)`; `drm-copilot-extension-tests / drm-copilot Extension Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `root-typescript-tests / Root TypeScript Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `NPM Audit Gate / npm audit (<manifest>)` (the calling job carries the name `NPM Audit Gate`); and the `poshqc` group below.
+- Jobs in `ci.yml` and their check names: `Change scope` (job `changes`, the change-scope decision below); `CI full run` (job `full-run-marker`, which runs only on a full run, marks that run as a valid base for later decisions, and is not a required check); `quality-checks7 / Code Quality & Tests (<python-version>)` on Python 3.11, 3.12, and 3.13 (`_quality-checks.yml`: Black check, Ruff, Pyright, the Codex generator `--check`, the tier classification, and Pytest on every version; Pytest with line and branch coverage and the coverage-threshold check on the JSON report totals run on 3.13 only); `security-scan / Security Scanning` (its `safety check` step carries `continue-on-error: true` and does not fail the check); `docs-validation / Documentation Validation`; `build-check / Build Package`; `shell-coverage / Shell Coverage (Bats + kcov)`; `drm-copilot-extension-tests / drm-copilot Extension Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `root-typescript-tests / Root TypeScript Tests (<os>)` on `ubuntu-latest` and `windows-latest`; `NPM Audit Gate / npm audit (<manifest>)` (the calling job carries the name `NPM Audit Gate`); the `poshqc` group below; and `CI Required Gate` (job `ci-required-gate`, issue #1074), which needs every other `ci.yml` job, runs under `if: always()` on `ubuntu-latest`, and passes `toJSON(needs)` to `scripts/ci/Invoke-CiRequiredGate.ps1`. The gate is green on a full run only when every needed job is `success`, and on a docs-only run only when `CI full run`, `root-typescript-tests`, and `NPM Audit Gate` are `success` or `skipped` and every other needed job is `success`; a `failure`, `cancelled`, or unknown result, a `Change scope` result other than `success`, and unreadable input are red. `tests/scripts/workflows/CiRequiredGateWorkflow.Tests.ps1` pins its `needs:` set against the other job ids of `ci.yml`.
 - PowerShell CI (`_poshqc.yml`): `poshqc / PowerShell QC static` (format and analyze on `windows-latest`); the shard matrix `poshqc / PowerShell QC shard 1`, `shard 2`, and `shard 3` (`Invoke-PoshQCTest -ShardIndex -ShardCount` over the scan folders of `config/poshqc-scan.json`, with coverage, on `windows-latest`); the aggregator `poshqc / PowerShell QC`, which requires the static and shard jobs to succeed, verifies shard completeness against a Pester discovery count, and merges shard coverage; and `poshqc / PowerShell hook suites (Linux)`, which runs only `tests/scripts/claude-hooks` and `tests/scripts/codex-hooks` on `ubuntu-latest` with coverage disabled. A new test file under a scanned folder is assigned to a shard automatically and is counted by the completeness check.
 - Change-scope decision (issue #962): the `Change scope` job runs `scripts/ci/Invoke-CiChangeScope.ps1` and publishes the job output `code`. The decision is `code=false` (docs-only) only on a `pull_request` event from this repository, through one of two comparisons. Green-run base: every file changed since the newest successful `ci.yml` run on the pull-request branch whose `CI full run` job succeeded, and whose head commit is present and an ancestor of the current head, is on the allowlist `config/ci-docs-only-paths.json`; the reason is `DOCS_ONLY_SINCE_<green head sha>`. Merge-base fallback (issue #973): when the green-run step ends with no earlier full green run (`NO_FULL_GREEN_RUN`), a missing base (`BASE_NOT_PRESENT`), or a non-ancestor base (`BASE_NOT_ANCESTOR`), and the pull request's base ref is exactly `main`, the script computes `git merge-base` of the payload base SHA (`BASE_SHA`, from `github.event.pull_request.base.sha`; the base ref arrives as `BASE_REF`) and the head, lists the files changed since that merge base with the same diff arguments, and decides `DOCS_ONLY_SINCE_MERGE_BASE_<merge base sha>` when every changed file is allowlisted. Both comparisons run the diff with rename detection off, so both the old and the new path of a rename are classified. A path is allowlisted when it starts with `docs/features/active/`, `docs/features/archive/`, `docs/features/completed/`, `docs/features/epics/`, `docs/features/parallel/`, `docs/features/potential/`, or `docs/research/`, does not start with `docs/features/templates/` or `docs/features/potential/template.md`, and ends in `.md`, `.txt`, `.log`, `.json`, or `.xml`; the allowlist file itself is not allowlisted. Every other case is a full run (`code=true`): `push`, `merge_group`, and `workflow_dispatch` events, a fork pull request, unreadable run or job data, no earlier full green run or a missing or non-ancestor base when the base ref is not `main`, a merge base that cannot be resolved (`MERGE_BASE_UNRESOLVED`, for example a blank base SHA or a base commit missing from the checkout), a failed ancestry check, an empty diff, any path outside the allowlist, and any error. The decision step carries `continue-on-error: true` and the callers compare the output with `!= 'false'`, so a failed or missing decision also gives a full run.
-- Docs-only behavior (`code=false`): `ci.yml` passes `run-heavy: false` to `_quality-checks.yml`, `_security-scan.yml`, `_build-check.yml`, `_poshqc.yml`, `_shell-coverage.yml`, and `_drm-copilot-extension-tests.yml`. Each required job still starts under its full-run check name with every step skipped, so every required context reports `success` without running its suite. In `_poshqc.yml` the aggregator `poshqc / PowerShell QC` runs with every step gated, and `poshqc / PowerShell QC static`, the shard jobs, and `poshqc / PowerShell hook suites (Linux)` are skipped at job level. `docs-validation / Documentation Validation` runs in full. `root-typescript-tests`, `NPM Audit Gate`, and `CI full run` are skipped at job level. A `success` on a docs-only commit is therefore not evidence that the heavy suites pass for that commit; that evidence is the newest run whose `CI full run` job succeeded.
+- Docs-only behavior (`code=false`): `ci.yml` passes `run-heavy: false` to `_quality-checks.yml`, `_security-scan.yml`, `_build-check.yml`, `_poshqc.yml`, `_shell-coverage.yml`, and `_drm-copilot-extension-tests.yml`. Each job that runs with its steps gated still starts under its full-run check name with every step skipped, so it reports `success` without running its suite. In `_poshqc.yml` the aggregator `poshqc / PowerShell QC` runs with every step gated, and `poshqc / PowerShell QC static`, the shard jobs, and `poshqc / PowerShell hook suites (Linux)` are skipped at job level. `docs-validation / Documentation Validation` runs in full. `root-typescript-tests`, `NPM Audit Gate`, and `CI full run` are skipped at job level. Eight currently required contexts therefore never report on a docs-only run: `poshqc / PowerShell QC shard 1`, `poshqc / PowerShell QC shard 2`, `poshqc / PowerShell QC shard 3`, `root-typescript-tests / Root TypeScript Tests (ubuntu-latest)`, `root-typescript-tests / Root TypeScript Tests (windows-latest)`, `NPM Audit Gate / npm audit (.)`, `NPM Audit Gate / npm audit (extensions/drm-copilot)`, and `NPM Audit Gate / npm audit (packages/mcp-server)`, so a docs-only head stays blocked under the 20-context ruleset. `CI Required Gate` passes on a docs-only run, because it accepts `skipped` for exactly those skipped callers. A `success` on a docs-only commit is therefore not evidence that the heavy suites pass for that commit; that evidence is the newest run whose `CI full run` job succeeded.
 - A commit that changes any path outside the allowlist (any code, workflow, configuration, script, test, or customization file) runs the full set of jobs, and its `CI full run` job marks it as a base for later docs-only decisions. A standalone `workflow_dispatch` of a reusable workflow, or a caller that omits `run-heavy`, also runs in full. `.github/workflows/README.md` (`## Change-Scope Decision (Issue #962)`) records the reason codes and the per-context behavior table.
-- Required contexts of ruleset 15241672, confirmed by the orchestrator through `gh api` on 2026-10-16: `drm-copilot-extension-tests / drm-copilot Extension Tests (ubuntu-latest)`, `drm-copilot-extension-tests / drm-copilot Extension Tests (windows-latest)`, `docs-validation / Documentation Validation`, `poshqc / PowerShell QC`, `shell-coverage / Shell Coverage (Bats + kcov)`, `security-scan / Security Scanning`, `quality-checks7 / Code Quality & Tests (3.11)`, `quality-checks7 / Code Quality & Tests (3.12)`, `quality-checks7 / Code Quality & Tests (3.13)`, `build-check / Build Package`.
-- Refresh rule: a change that renames a job, adds or removes a matrix entry, or changes the ruleset refreshes this list in the same change, and the orchestrator re-confirms the contexts with a read-only `gh api repos/drmoisan/drm-copilot/rulesets/15241672` call before relying on them.
-- Skipped-check semantics: a job skipped by an `if:` condition reports success to a required check; a workflow that does not run at all reports nothing, which leaves the required check pending.
+- Required contexts of ruleset 15241672, read through a read-only `gh api` call on 2026-11-04 (20 contexts, each with `integration_id` 15368): `drm-copilot-extension-tests / drm-copilot Extension Tests (ubuntu-latest)`, `drm-copilot-extension-tests / drm-copilot Extension Tests (windows-latest)`, `docs-validation / Documentation Validation`, `poshqc / PowerShell QC`, `shell-coverage / Shell Coverage (Bats + kcov)`, `security-scan / Security Scanning`, `quality-checks7 / Code Quality & Tests (3.11)`, `quality-checks7 / Code Quality & Tests (3.12)`, `quality-checks7 / Code Quality & Tests (3.13)`, `build-check / Build Package`, `NPM Audit Gate / npm audit (extensions/drm-copilot)`, `NPM Audit Gate / npm audit (.)`, `NPM Audit Gate / npm audit (packages/mcp-server)`, `root-typescript-tests / Root TypeScript Tests (ubuntu-latest)`, `root-typescript-tests / Root TypeScript Tests (windows-latest)`, `poshqc / PowerShell QC shard 1`, `poshqc / PowerShell QC shard 2`, `poshqc / PowerShell QC shard 3`, `poshqc / PowerShell QC static`, `poshqc / PowerShell hook suites (Linux)`. After the owner's post-merge ruleset edit (issue #1074 runbook), the single required context is `CI Required Gate` (`integration_id` 15368), and the individual job contexts remain visible but are no longer required.
+- Refresh rule: a change that renames a job, adds or removes a `ci.yml` job or a matrix entry, or changes the ruleset refreshes this list in the same change, and the orchestrator re-confirms the contexts with a read-only `gh api repos/drmoisan/drm-copilot/rulesets/15241672` call before relying on them. A new `ci.yml` job must also be added to the `needs:` list of `ci-required-gate`; `tests/scripts/workflows/CiRequiredGateWorkflow.Tests.ps1` fails until it is.
+- Skipped-check semantics: a job skipped by an `if:` condition reports success to a required check; a workflow that does not run at all reports nothing, which leaves the required check pending. A matrix job skipped at job level reports no expanded context (its matrix name is never expanded), and a reusable-workflow caller skipped in `ci.yml` reports no nested contexts, so each such required context stays pending.
 - A pull request into a branch other than `main`, `development`, or `epic/**` gets no CI run; dispatch `ci.yml` manually for it.
 
 ## CI-Only Failure Classes

package/resources/codex-and-agents-customizations/.codex/config.toml

@@ -2,7 +2,7 @@ default_permissions = ":danger-full-access"
 
 [mcp_servers.drm-copilot]
 command = "npx"
-args = ["-y", "@danmoisan/drm-copilot-mcp@1.1.24"]
+args = ["-y", "@danmoisan/drm-copilot-mcp@1.1.26"]
 required = true
 enabled_tools = [
     "collect_commit_context",