@danmoisan/drm-copilot-mcp 1.1.23 → 1.1.24

package/resources/claude-customizations/.claude/skills/inventory-legacy-system/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: inventory-legacy-system
+description: 'Inventory selected legacy repository surfaces with explicit analyzer scope and truthful coverage dispositions. Use when asked to inventory a legacy system or refresh selected discovery coverage.'
+---
+
+# Inventory Legacy System
+
+## When to Use This Skill
+
+Use for an explicit selected repository inventory or an incremental inventory refresh. Detection identifies candidates; it does not establish inspected behavior.
+
+## Inputs
+
+These are human-facing workflow selections, not additional service-request fields.
+Supply explicit selections; neither omitted inputs nor profile roots create authority.
+
+| Input | Required contract |
+| --- | --- |
+| profile | Required validated profile and trusted workspace binding. |
+| scope | Required confirmed or draft scope with selected component IDs and roots. |
+| analyzer_ids | Required explicit supported analyzer selection; no arbitrary plugin or module. |
+| write | Required explicit publication intent; it grants no paths by itself. |
+| dry_run | Required explicit preview intent; preserve the request's no-write result. |
+
+## Routing
+
+Logical role: `legacy-parity-analyst`.
+The root owns preparation and launch; this skill never auto-launches a logical
+role through frontmatter. The existing resolver selects the exact deployment,
+model, effort and profile hash under the existing C1-C4 ceiling and execution
+context. Do not choose a model, self-launch, create another scheduler or promote
+an ordinary discovery action into an issue. The production-write count is zero.
+
+## Exact output boundary
+
+These rows are maximum workflow caps, not instructions to create every kind.
+Only the prepared required outputs may be created or replaced.
+
+| Artifact kind | Profile key | Constraint |
+| --- | --- | --- |
+| inventory-snapshot | inventory | Requested inventory scope only |
+| coverage-ledger | coverage_ledger | Selected component members only |
+| evidence-reference | evidence | Explicitly granted observations only |
+| unspecified-behavior | unspecified_behaviors | Selected unresolved IDs only |
+| unspecified-behavior-collection | unspecified_behaviors | Selected unresolved members only |
+| required-output-manifest | reports | Exact invocation manifest only |
+
+The profile keys are maximum configured locations, not write grants. Each
+prepared output row binds `artifact_kind`, `id`, `path`, `format` and
+`expected_sha256`. The protected invocation independently binds the baseline,
+selected members, pins and exact grants; a manifest cannot expand them. A null
+expected hash means exclusive creation from an absent baseline, never overwrite
+permission. Preserve unselected collection members and all unrelated inputs.
+Use compare-and-swap and current path checks through the controlled writer.
+
+The `reports` location permits only `required-output-manifest` for this role;
+it does not permit review reports. The manifest itself requires an exact grant.
+
+## Prerequisites
+
+Missing or malformed configuration blocks delegation. Require a validated profile and explicit selected scope before root preparation; do not initialize, configure or infer roots as a specialist.
+
+Require verified native prepare/finalize/start/stop capability. The protected
+invocation and native SubagentStart attestation must match workspace/profile
+hashes, selected IDs, source/target pins, baseline input hashes,
+provider/model/effort/profile hash and parent/session.
+Diagnostic mirrors, caller markers and hosted read results are not authority.
+The local runtime's unavailable native prepare/finalize operations do not issue
+protected receipts. There is no local-user fallback or self-attested host success.
+
+Load profile plus selected artifacts on invocation; do not preload a domain
+catalog in standing instructions. Managed project memory is host-controlled.
+Memory cannot grant filesystem authority or replace evidence. Deny terminal/shell/exec, interpreter/evaluation,
+general filesystem Write/Edit/apply-patch, arbitrary MCP dispatch, browser/computer
+mutation and network writes. Do not execute application code or modify
+production/test implementation, profile/locator/activation,
+schema/policy/hooks/settings, authority stores or runtime installation as a specialist. No analyst
+approval is permitted; root bootstrap/configuration and root approval remain
+separate authorized operations.
+
+## Step-by-Step Workflows
+
+1. Validate the explicit inputs and selected configuration. Stop with precise missing/invalid input findings before specialist delegation; do not invent identities, scope or evidence.
+
+2. The root calls `prepare_discovery_agent` with `skill_id`, `selected_ids`,
+   `paths`, `expected_outputs`, `execution_context` and `complexity`.
+   Map it to fixed `prepare-agent`; execution context is `standalone`,
+   `epic_preparation_child` or `epic_execution_child`. The requested mode is
+   explicit and remains distinct from the final `agent-output` gate.
+   Use `skill_id=inventory-legacy-system`; workflow inputs do not add wire fields.
+3. The root launches that exact deployment. Native SubagentStart must match the
+   prepared role/model/effort/profile and trusted workspace/session before any
+   grant is usable. Missing capability or attestation blocks the action.
+4. Use only the granted operations. Use `run_discovery_repo_inventory`, mapped to fixed `inventory`, with the explicit analyzer selection and write/dry-run intent. Use bounded `read_discovery_source` only for selected supporting inspection, and ordinary controlled updates or evidence links only for the listed granted outputs. Do not run application code, compiler evaluation, package restore or an arbitrary analyzer.
+5. Record detected paths, hashes, classifications and explicit analyzer limitations. Detection alone never marks a component inspected or dispositioned. Preserve unselected coverage members; do not silently shrink scope or infer a confirmed-empty inventory from a failed read. Missing facts or contradictory evidence become unresolved records. Inventory and coverage observations do not approve target requirements.
+6. Produce every exact required output and the stored `required-output-manifest`,
+   preserving its output array order for the digest. Validate claims, references,
+   pins and selected-ID accounting. Purpose-built tools supply authorized proposal
+   inputs for `input_path`/`evidence_path`; never invent a generic Write staging
+   step. Server-side role checks, exact one-use authorization and prospective
+   validation remain mandatory. Bounded source reads preserve content identity
+   and line ranges; truncation requires a narrower selection, not a completeness
+   claim or filesystem fallback.
+7. Call `finalize_discovery_agent` as the specialist, mapped to `finalize-agent`
+   with `mode=agent-output`, non-null `invocation_ref` and no operation inputs.
+   It validates the protected invocation's outputs, not final-message paths.
+   Native SubagentStop then verifies current output authority.
+   Missing final text cannot skip native stop validation.
+8. After native stop, the root records the explicit result, content-addressed artifact references,
+   selected-ID accounting and all findings. A successful tool call or generated
+   path alone is not evidence of completed discovery.
+
+## Stop and result
+
+Account for each selected component and requested analyzer. If a dry-run leaves required stored outputs absent, finalization remains blocked; never fabricate writes or receipts. A valid incremental inventory is not discovery-complete, parity-complete or planning authority.
+
+Structural success is not discovery, parity or planning completion.
+Missing prepare/finalize/start/stop capability, missing outputs, invalid claims,
+unresolved required work, wrong role/model/start context or a stale/missing
+receipt blocks successful completion. Return explicit
+PASS, FAIL or BLOCKED, distinguishing valid incremental outputs from a passing
+completion gate. Missing native enforcement remains BLOCKED even when ordinary
+local-user operations can run; do not substitute CLI success for native authority.
+
+## References
+
+- [Canonical legacy-parity-analyst contract](../../../.claude/agents/legacy-parity-analyst.md)
+- Installed v2 `service-request` and `required-output-manifest` schema contracts;
+  consume them through the authoritative runtime, with no checkout-schema fallback.
+- The selected profile and pinned local artifacts supplied for this invocation;
+  references do not preload catalogs or grant access to unselected paths.

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

@@ -26,6 +26,7 @@ Before proceeding, the orchestrator must:
 2. Read applicable `.claude/rules/` files for the languages in scope.
 3. Read the policy files listed in the compliance reading order section of `CLAUDE.md`.
 4. Read the `execution-environment` skill (`.claude/skills/execution-environment/SKILL.md`) before delegating any worker. Delegation prompts and plans reference that brief instead of restating tool routes, command-text restrictions, the batch budget, hook context, or CI shape.
+5. In a workspace with an active discovery activation, expect the native planning gate (`.claude/hooks/enforce-discovery-planning-gate.ps1`) on every `atomic-planner` or orchestrator delegation: it admits the launch only when the session holds a current `planning`-mode validation receipt satisfying the profile's `completion_gates.planning_prerequisite`. A `DISCOVERY_PLANNING_GATE_BLOCKED:` denial means the discovery criteria are not current; run `validate-all --mode planning` through the installed gateway and re-delegate rather than bypassing. Discovery criteria gate planning and never substitute for the plan's own tests (`docs/engineering/legacy-discovery-and-parity/enforcement.md`).
 
 ## Checkpoint Handling
 
@@ -192,12 +193,12 @@ PR creation and PR body edits are delegated work, not orchestrator work. The orc
 
 The mandatory sequence is:
 
-1. The orchestrator first refreshes the PR-context artifact via `mcp__drm-copilot__collect_pr_context` (or the equivalent context-collection mechanism), which writes `artifacts/pr_context.summary.txt`.
+1. The orchestrator first refreshes the PR-context artifact via `mcp__drm-copilot__collect_pr_context` (or the equivalent context-collection mechanism), which writes `artifacts/pr_context.summary.txt`. It calls the tool with `workspace_root` set to the item worktree and `target_ref` set to the head branch, so the summary is written beneath the item worktree even when the orchestrator runs in a coordinator session.
 2. The orchestrator runs the orchestrator-state validator (`mcp__drm-copilot__validate_orchestration_artifacts` or the equivalent repository-local validator CLI documented in `.claude/rules/orchestrator-state.md`) against `artifacts/orchestration/orchestrator-state.json --require-pr-creation-ready` and records the pass/fail result under a new `pr_author_preflight` field in the checkpoint, alongside `pr_author_receipt`: `{status ("pass"|"fail"), checked_at (ISO-8601 UTC), checkpoint_path, validator_command, output_summary}`. The orchestrator must not delegate to `Agent(pr-author)` when this preflight fails. The validator's full-lifecycle completion flag (`ci_gate`/`pr_gate`/routing-contract receipts) remains reserved for the post-PR/CI completion context (Step S9 / PR Creation Gate condition 6), not this pre-PR-creation preflight, because those values cannot exist before the first `gh pr create` of a branch.
-3. The orchestrator then delegates PR creation and any PR body edits to `Agent(pr-author)`. The `pr-author` agent runs the `pr-author` skill to author the body, writes the body file `artifacts/pr_body_<N>.md` and the sibling receipt `artifacts/pr_body_<N>.receipt.json` with the shape `{skill, pr_body_path, number, sha256 (lowercase hex of the body bytes), context_summary_path, created_at (ISO-8601 UTC, strictly newer than `artifacts/pr_context.summary.txt` last-write)}`, issues `gh pr create --body-file artifacts/pr_body_<N>.md` (or `gh pr edit --body-file ...`), and reports the resulting PR URL or PR number. The delegation prompt MUST carry, on its own line, `Author-asserted autoclose issues: #<issue-num>`, where `<issue-num>` is the checkpoint `issue-num`, so the PR body emits `- Closes #<issue-num>` and the issue closes on merge. The line is omitted only when the checkpoint records no `issue-num`, or when `epic_mode` is true (an epic child whose integration PR owns the closing keyword). In every other case the `enforce-model-routing-receipt.ps1` Agent PreToolUse hook denies the `Agent(pr-author)` delegation with `MODEL_ROUTING_RECEIPT_BLOCKED: AUTHOR_ASSERTED_AUTOCLOSE_MISSING`.
+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. The delegation prompt MUST carry, on its own line, `Author-asserted autoclose issues: #<issue-num>`, where `<issue-num>` is the checkpoint `issue-num`, so the PR body emits `- Closes #<issue-num>` and the issue closes on merge. When the parallel kickoff that started this run carries a `Combined issues:` line (a combined parallel item, issue #1013), the same author-asserted line also lists every issue named on that `Combined issues:` line, after `#<issue-num>`, so the one PR closes every member issue. The line is omitted only when the checkpoint records no `issue-num`, or when `epic_mode` is true (an epic child whose integration PR owns the closing keyword). In every other case the `enforce-model-routing-receipt.ps1` Agent PreToolUse hook denies the `Agent(pr-author)` delegation with `MODEL_ROUTING_RECEIPT_BLOCKED: AUTHOR_ASSERTED_AUTOCLOSE_MISSING`.
 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.
+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. In this coordinator-session topology the delegation prompt carries the line `branch: <branch>` naming the head branch, and pr-author derives the item worktree root itself from `git worktree list --porcelain` (the prompt carries no absolute path), following the `## Coordinator-Session Topology (issue #1011)` section of the pr-author agent and skill. The delegation runs without worktree isolation, because an isolated agent worktree refuses command text that names another worktree.
 
 `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.
 
@@ -293,7 +294,7 @@ Each such prompt also carries a `branch: <name>` label naming the branch checked
 
 The same two lines are required on every delegation to an implementation agent (`python-typed-engineer`, `powershell-typed-engineer`, `typescript-engineer`, `csharp-typed-engineer`, and `atomic-executor`) and on every `Agent(orchestrator)` delegation that carries no epic-mode, parallel-mode, or preparation-mode kickoff marker. `enforce-orchestration-preimplementation-gate.ps1` resolves such a delegation's worktree from these lines and denies it with `TARGET_WORKTREE_NOT_DERIVABLE` when neither line is present, or with `TARGET_WORKTREE_AMBIGUOUS` when the lines disagree or match more than one live worktree.
 
-If a subagent artifact references a different issue number, the orchestrator rejects it, requests correction, and records the discrepancy under `artifact_errors` in the checkpoint.
+If a subagent artifact references a different issue number, the orchestrator rejects it, requests correction, and records the discrepancy under `artifact_errors` in the checkpoint. Issue numbers named on a `Combined issues:` line of a parallel kickoff (issue #1013) are permitted cross-references to the combined item's member issues, not discrepancies.
 
 ## Step S9 — CI Green Gate
 

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

@@ -29,6 +29,17 @@ this operation may and may not disturb. Read that section before applying anythi
 - `$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.
+- 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.
+- On either run-existence rejection, change no state and emit the rejection signal defined in
+  `## Mutation Rejection Signal (issue #1012)` of `.claude/rules/parallel-orchestration.md`: when
+  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.
+- 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.
 
 ## Re-Derive Durable State Before Applying Anything
 
@@ -106,7 +117,14 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    unstarted subset only: an in-flight conflict is precisely what the admission decision turns on.
    A tolerated overlap is not an edge: the two items run in the same or adjacent cohorts without a
    barrier, and the later-merging item merges `origin/main` under the existing per-item
-   merge-conflict handling and re-passes CI before it merges.
+   merge-conflict handling and re-passes CI before it merges. The entry point applies the aggregate
+   cost cap (issue #1013) inside the same call, so the edges this step records are capped edges.
+   After the edges are computed, call Get-BlastRadiusCombination from the same facade over the
+   candidate plus the unstarted items, with the same `-Config` and `-Relation`, and report each
+   qualifying pair that involves the candidate with the text
+   `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.
 
 4. **Decide admission.** Call the bundled entry point, which needs no Python interpreter:
 
@@ -212,6 +230,8 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
 - 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`.
+- The step 5 stop and a failed preparation each emits no rejection signal: the run's checkpoint
+  already exists and state is already written, so the stop validates against that checkpoint.
 
 ## Completion Requirements
 

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

@@ -25,6 +25,14 @@ an `open`-mode run never auto-completes. Read that section before applying anyth
 - The run's `mode` is `open`. A `closed`-mode run completes through its completion predicate — every
   non-withdrawn item `merged` or `worktree_removed` — and needs no close. Report that and stop
   rather than closing a `closed`-mode run to force completion.
+- The run-existence check is evaluated first. When no checkpoint tracks the `parallel_slug` named
+  in `$ARGUMENTS`, stop without changing state and emit the rejection signal defined in
+  `## Mutation Rejection Signal (issue #1012)` of `.claude/rules/parallel-orchestration.md`: 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.
+- The `closed`-mode stop follows the run-existence check while the run's checkpoint exists, so it
+  emits no rejection signal and validates against that checkpoint.
 
 ## Re-Derive Durable State Before Applying Anything
 
@@ -56,7 +64,9 @@ which is exactly what the gate exists to prevent. The re-derivation is mandatory
    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.
+   attempt. On that rejection, put the line `parallel_slug: <slug>` before the signal and end the
+   final output with the literal line `PARALLEL_MUTATION_REJECTED: items_in_flight` as its last
+   line, with no formatting and no trailing text, per `## Mutation Rejection Signal (issue #1012)`.
 
 3. **Append exactly one run-scoped `mutations[]` entry** for a successful close, built by the
    bundled entry point:

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

@@ -256,6 +256,11 @@ carries exactly these five elements.
    The child needs it for its own operation, and F7's Layer 1 hook resolves the target item by
    scanning the prompt for exactly that path shape, so the path is emitted as a bare path token.
 3. The canonical issue number line, which is the item key.
+   For a combined item (issue #1013), element 3 is followed by the line `Combined issues: #A #B`,
+   naming every other member issue of the combination recorded in the item's
+   `combined_issue_nums`, and the prompt instructs the child to carry every member on its pr-author
+   line, `Author-asserted autoclose issues: #A #B`, so the one pull request closes every member
+   issue. The added line is part of element 3, not a further element.
 4. The item's committed `plan-path`, together with the resume instruction: resume at atomic
    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
@@ -483,6 +488,16 @@ unattended. When `main` uses a merge queue, the queue replaces that `gh pr updat
 step 3 enqueues each green pull request, the queue validates it against the latest `main`
 together with the entries ahead of it, and step 3's confirmation polling waits for the merge.
 
+**Resolution telemetry write (issue #1013).** When step 4 records `merge_status: merged` for an
+item that is the later-merging item of a tolerated pair (an entry of the checkpoint's
+`tolerated_overlaps` whose peer is already `merged` or `worktree_removed`), complete that entry's
+`observed_resolution` object in the same checkpoint write. When a conflict was detected for the
+pair, set `resolved_at` to the first `ci_green` confirmation that followed the detection,
+`resolution_minutes` to the whole minutes between `conflict_detected_at` and `resolved_at`, and
+`recorded_at`. When no conflict occurred, set `later_item`, `conflicted: false`,
+`conflict_detected_at` and `resolved_at` to null, `resolution_minutes: 0`, and `recorded_at`.
+Nothing reads `observed_resolution`; it is recorded for measurement only.
+
 ## Per-Item Merge-Conflict Handling
 
 Remediation is child-owned and parent-initiated. The conflict is always between one item's own
@@ -551,6 +566,19 @@ blast radius under-reported, and this feature records the child's blocked or rem
 only, leaving drift recording in `drift_events[]`, quiesce of admission, conflict recomputation
 against the observed radius, and requeue of the later-started item to F8.
 
+**Detection telemetry write (issue #1013).** When the item whose merge conflicted is the
+later-merging item of a tolerated pair whose peer is already `merged` or `worktree_removed`, set
+`later_item`, `conflicted: true`, and `conflict_detected_at` on that `tolerated_overlaps` entry's
+`observed_resolution` object, unless they are already set. Attribution is non-exclusive: the one
+conflict episode is recorded on every such tolerated pair. The resolution fields are written in
+`## Per-Item Merge to Main (Merge-on-Green)`.
+
+**Combined item remediation (issue #1013).** A combined item, whose checkpoint entry carries
+`combined_issue_nums`, remediates as one unit: one child, one `remediation_loop`, and one pull
+request. A combined item that fails review or CI is remediated within that one child and pull
+request, never splits back into separate pull requests, and is merged, blocked, or removed as a
+whole.
+
 ## Worktree Cleanup
 
 After an item reaches `merge_status: merged` and that state is durably confirmed by
@@ -657,6 +685,11 @@ commit message, the pull-request body, and an evidence artifact at
 `docs/features/parallel/<slug>/evidence/other/mergeable-conflicts.<yyyy-MM-ddTHH-mm>.md` carrying
 `Timestamp`, `Command`, `EXIT_CODE`, and the script's JSON output verbatim.
 
+The projection's `## Tolerated Overlaps` heading (issue #1013) renders `tolerated_overlaps[]`: one
+row per entry with `a`, `b`, `reasons`, `cost`, `benefit`, and, from the entry's
+`observed_resolution` object when present, `later_item`, `conflicted`, and `resolution_minutes`.
+An entry without `observed_resolution` renders those three cells empty.
+
 Regeneration boundaries — regenerate at each of the following, not only at final completion:
 
 - Run kickoff, seeding the initial projection from the manifest and the seeded cohorts.
@@ -666,6 +699,7 @@ Regeneration boundaries — regenerate at each of the following, not only at fin
 - Every append to `mutations[]`.
 - Every append to `drift_events[]`.
 - Every append to an item's `mergeable_conflicts_resolved`.
+- Every write of an `observed_resolution`.
 - Run completion in `closed` mode, or run close in `open` mode.
 
 Defining the `mutations[]` and `drift_events[]` appends as regeneration boundaries here means F6 and

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

@@ -172,9 +172,32 @@ explicitly not an integration branch: no item branch ever merges into it, it nev
 item branch, and it holds only `docs/features/parallel/<slug>/**`, a subtree no item's blast radius
 may include. Each item opens its own pull request against `main`.
 
-**Read access.** Readers — validators and the future `parallel-orchestrator` — reach both artifact
-classes by ref: `git fetch origin <branch>` followed by `git show <ref>:<path>`, without checking
-the ref out, per the technique documented in `.claude/skills/epic-run/SKILL.md`.
+**Plan-home checkout.** After the last preparation child has terminated (the re-plan delegations
+for a V1 or V2 failure count as preparation children) and before `## Manifest Authoring`, the
+planner prepares the plan-home branch in its own session checkout: it runs `git fetch origin main`
+and then `git checkout -b parallel/<slug>-plan origin/main`. When the branch already exists, as on
+a resumed run, it runs `git checkout parallel/<slug>-plan` instead of recreating it. If the
+checkout is refused, stop planning and report the refusal; do not stash, force, or reset. The run
+folder is written in place, committed through the pathspec-bearing forms of
+`### Integration Commit Form (issue #539)`, and pushed with
+`git push -u origin parallel/<slug>-plan`. The checkout stays on `parallel/<slug>-plan` for the
+remainder of the run.
+
+**Read access.** Readers — validators, the planner itself, and the future `parallel-orchestrator` —
+reach both artifact classes by ref: `git fetch origin <branch>` followed by `git show <ref>:<path>`,
+without checking the ref out, per the technique documented in `.claude/skills/epic-run/SKILL.md`.
+The planner reads each item's approved plan text and `spec.md` text for `### Planner procedure`, and
+performs the git-integrity check, with `git fetch origin <branch>` followed by
+`git show origin/<branch>:<path>` or `git cat-file -e`; it never checks an item branch out.
+
+**No planner worktrees.** The planner runs no `git worktree add` for any step of planning: it
+authors `parallel/<slug>-plan` in its own session checkout and reads item text by ref. The only
+worktrees created during planning are the preparation children's `isolation: "worktree"` worktrees,
+and the Claude Code runtime creates and removes them: it removes one immediately when the child
+leaves no changes, and otherwise through its periodic sweep once the commits are pushed and the
+tree is clean. A worktree the planner creates itself is outside every record the removal gates read
+and outside the runtime sweep, so it stays registered after the run closes and only the
+repository-wide cleanup apply mode can remove it.
 
 Three residual risks are recorded rather than eliminated:
 
@@ -258,9 +281,11 @@ any work: the policy rules, the tier map, and the process artifacts. A citation
 paths is evidence that the author obeyed the reading order, not evidence that the change will write
 the file, so `derive_blast_radius` drops it from the harvest and `validate_blast_radius` drops it
 from its plan-side extraction, which keeps V1 and V2 self-consistent. The extractor likewise rejects
-three token shapes that were never write claims: a wildcard-free token naming a directory rather
-than a file, a `docs/features/` glob whose wildcard spans every feature folder, and a contract token
-carrying no ASCII letter. These exclusions are part of the landed contract, so the prohibition now
+five token shapes that were never write claims: a wildcard-free token naming a directory rather
+than a file, a `docs/features/` glob whose wildcard occupies or truncates the feature-folder
+segment, a contract token carrying no ASCII letter, a token containing a placeholder or
+interpolation marker, and a contract token that is a default spreadsheet sheet name. These
+exclusions are part of the landed contract, so the prohibition now
 reads: do not narrow a radius beyond the configured exclusions in order to suppress a conflict edge.
 
 **Appending an excluded path is the planner's obligation, not an exception.** An exclusion describes
@@ -331,6 +356,41 @@ The kickoff artifact's `## Item Summary` `complexity` cell for the item equals i
 derivation. It is distinct from the deliberately absent worthiness verdict: assessing a band never
 admits, rejects, or reorders an item.
 
+## Issue Combination
+
+Combination (issue #1013) runs once, at planning time, after every item is prepared, its radius is
+declared, and its band is assigned, and before cohort seeding. The rules are stated in
+`### Integration-cost scheduling (issue #722)` of `.claude/rules/parallel-orchestration.md`; this
+section states the planner's steps.
+
+1. **Find combinations.** Call Get-BlastRadiusCombination from the facade `BlastRadius.psm1` with
+   `-Item` (each item's key, declared radius, and band), `-Config` (the parsed truth table), and
+   `-Relation ${function:Test-BlastRadiusConflict}`. Combination proceeds without operator
+   approval. It returns nothing when `conflict_tolerance` is absent or tolerance_percent is 0.
+2. **P6 skip.** If applying every combination would leave fewer than two items (ready-gate
+   invariant P6), apply none, and report each qualifying pair as not combined with the reason
+   "applying the combinations would leave fewer than two items".
+3. **Re-plan on the primary branch.** For each combination, issue one follow-up preparation-mode
+   delegation on the primary item's pushed branch, the same re-plan posture as a V1 or V2 failure.
+   The delegation carries the unchanged preparation kickoff line, followed by the line
+   `Combined issues: #A #B` naming each other member by issue number and by branch name only.
+4. **Child work.** The child imports each other member's committed feature folder by path from that
+   member's pushed branch ref (a path checkout, not a branch merge, so there is still no fan-in
+   merge), authors one atomic plan in the primary feature folder covering every member's spec,
+   re-runs preflight, commits, and pushes.
+5. **Fresh assessment.** Re-derive the combined item's declared radius from the combined plan, read
+   by ref as `**Read access.**` describes, and run a fresh `## Complexity Assessment` for it.
+6. **Record.** Remove the non-primary members from `items[]`, record `combined_issue_nums` (the other
+   members' issue numbers) on the primary item, and add the combination (members, primary, pairs
+   with cost and benefit, `estimated_savings`) to the checkpoint's `combinations` list.
+7. **Capped scheduling.** Only then run the scheduling entry point over the post-combination item
+   set; its aggregate cap applies to every remaining item.
+
+Each combination re-plan delegation is a preparation child, so the `**Plan-home checkout.**` of
+`## Artifact Home` follows its termination. The planner reads the combined plan by ref and never
+checks an item branch out. The non-primary members' preparation branches stay in place and are
+reported, the same residual as risk 2 in `## Artifact Home`.
+
 ## Cohort Seeding
 
 Reach cohort computation through the **destination-runtime bash entry point** under
@@ -673,6 +733,9 @@ The final report to the operator must include:
   gate the report, does not change the cohort table, and no finding is escalated to Blocking.
 - Both kickoff artifact paths: `artifacts/orchestration/parallel-kickoff-<slug>.md` and
   `docs/features/parallel/<slug>/parallel-kickoff.md`.
+- The combination listing (issue #1013): each combination with its members, primary, qualifying
+  pairs with cost and benefit, the `combination_threshold_percent` applied, and
+  `estimated_savings`; and each qualifying pair that was not combined, with the reason.
 
 End with the statement that execution has NOT started and begins only when the operator runs
 `/parallel-run <slug>` or replays the kickoff prompt from the main session.

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

@@ -25,6 +25,15 @@ this operation may disturb. Read that section before applying anything here.
   tracks its `parallel_slug`.
 - `$ARGUMENTS` names exactly one item key — an integer `items[].issue_num`. Item keys are integers
   throughout this surface; there is no string key.
+- The run-existence check is evaluated first. When no checkpoint tracks the run's `parallel_slug`,
+  stop without changing state and emit the rejection signal defined in
+  `## Mutation Rejection Signal (issue #1012)` of `.claude/rules/parallel-orchestration.md`: when
+  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.
+- An argument that is not exactly one integer key is rejected only after the run-existence check,
+  while the run's checkpoint exists; that rejection emits no rejection signal and validates against
+  that checkpoint.
 
 ## Re-Derive Durable State Before Applying Anything
 
@@ -55,6 +64,12 @@ Implement this table exactly, one branch per row:
 An item already `withdrawn` or `blocked` is not a live removal target and is rejected as an unknown
 item.
 
+On a rejected row, put the line `parallel_slug: <slug>` before the signal and end the final output
+with one literal signal line as its last line, with no formatting and no trailing text, per
+`## Mutation Rejection Signal (issue #1012)`: `PARALLEL_MUTATION_REJECTED: items_in_flight` for an
+`in_flight` item without `--disposition`, and `PARALLEL_MUTATION_REJECTED: unknown_item` for an
+unknown, `withdrawn`, or `blocked` item. The `merged` rejection emits no rejection signal.
+
 ## No Default Disposition
 
 Removing an item that is `in_flight` without an explicit `--disposition` is REJECTED. No default is

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

@@ -27,6 +27,12 @@ $ARGUMENTS
    - STOP without delegating anything when that path does not exist. Report that the run has no
      committed kickoff artifact: the user must run `/parallel-plan` first (or, for a run whose
      manifest was authored manually, invoke `/parallel-orchestrate <manifest-path>` directly).
+   - On that STOP, emit the rejection signal defined in `## Mutation Rejection Signal (issue #1012)`
+     of `.claude/rules/parallel-orchestration.md`: put the line `parallel_slug: <parallel-slug>`
+     before the signal, and end the final output with the literal line
+     `PARALLEL_MUTATION_REJECTED: kickoff_artifact_missing` as its last line, with no formatting and
+     no trailing text. No run checkpoint exists for this run, so the stop hook releases the stop on
+     that line.
    - Do not synthesize a kickoff prompt, do not fall back to the planner's working copy under
      `artifacts/orchestration/`, and do not launch a partial run in place of the STOP.
 3. Execute the kickoff artifact's `## Invocation Prompt` section as the run objective, applying the

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

@@ -79,9 +79,10 @@ writes and the `gh pr create` / `gh pr edit --body-file` handoff.
 - Auto-close bullets must use exactly `- Closes #NNN` format. Three sources are valid:
   1. the PR-context "Issues to autoclose" list;
   2. the PR-context "Author-asserted autoclose issues" list (rendered from the PR Intent);
-  3. an issue named as author-asserted in the delegation prompt, on the line
-     `Author-asserted autoclose issues: #NNN`. This source is valid even when the PR context
-     lists no verified autoclose issues.
+  3. each issue named on the line `Author-asserted autoclose issues: #NNN [#NNN ...]` in the
+     delegation prompt; a combined parallel item (issue #1013) names every member issue on that
+     one line, and each named issue gets its own `- Closes #NNN` bullet. This source is valid even
+     when the PR context lists no verified autoclose issues.
 - Emit the fallback `- None` bullet only when no source has an entry.
 - GitHub validation applies to the two PR-context lists: if it is unavailable or unverified for
   an entry on those lists, do not emit `Closes` for that entry. An issue named as author-asserted
@@ -122,4 +123,20 @@ an edit in one of two ways:
 - Run `gh pr edit <N> --body-file artifacts/pr_body_<N>.md` from the item worktree. The gate
   derives the branch from that worktree's checkout.
 - When running outside the item worktree, append the shell comment `# branch: <branch>` to the
-  command, and pass the absolute canonical body path beneath the item worktree.
+  command, and pass the absolute canonical body path beneath the item worktree.
+
+## Coordinator-Session Topology (issue #1011)
+
+When the process directory is not the item worktree (for example, when the orchestrator delegates
+from a coordinator session rooted in another checkout), a relative `artifacts/` path resolves to the
+wrong checkout. In that topology, use this procedure instead of the relative forms above:
+
+1. Run `git worktree list --porcelain` as a single command. Select the `worktree` entry whose `branch refs/heads/<branch>` line names the `--head` branch, and use that entry's absolute root, written with forward slashes, as `<item worktree>`. If zero or more than one entry matches, stop and report the result; do not choose a root.
+2. Confirm that the PR context summary already exists at `<item worktree>/artifacts/pr_context.summary.txt`. The orchestrator produces it; pr-author does not call `collect_pr_context`.
+3. Write the body to `<item worktree>/artifacts/pr_body_<N>.md` by absolute path.
+4. Run `sha256sum <item worktree>/artifacts/pr_body_<N>.md` as a single command and take the lowercase hexadecimal digest.
+5. Write the receipt to `<item worktree>/artifacts/pr_body_<N>.receipt.json` by absolute path. Keep `pr_body_path` and `context_summary_path` repo-relative (`artifacts/pr_body_<N>.md` and `artifacts/pr_context.summary.txt`), so no absolute path is recorded in the receipt. The receipt `created_at` must be strictly newer than the last-write time of the summary.
+6. Run `gh pr create --head <branch> --body-file <item worktree>/artifacts/pr_body_<N>.md`. The gate resolves the item worktree from `--head` and verifies the body and receipt beneath it; in this topology it denies a relative `--body-file` with `PR_BODY_PATH_NONCANONICAL`.
+
+In this topology pr-author is delegated without worktree isolation, because an isolated agent
+worktree refuses command text that names another worktree.