@danmoisan/drm-copilot-mcp 1.1.22 → 1.1.24

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.
+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
 
@@ -312,6 +313,7 @@ S9 procedure:
 4. Poll with a bounded interval and a documented total timeout while `conclusion == "pending"`. When the timeout is exhausted, record the timeout as a finding with `Remediability: awaiting_ci` in `remediation-inputs.<timestamp>.md` and follow the wait branch in Post-Review Outcome Evaluation (`blocked_reason: "awaiting_ci"`, `next_step: "S9_ci_green"`); `step9_status` stays `pending`. A poll timeout does not enter the remediation loop.
 5. Write the `ci_gate` object and `last_verified_ci_sha` to the checkpoint, and set `step9_status` to `passed` only when `ci_gate.conclusion == "success"` AND `ci_gate.head_sha` equals the current PR head SHA.
 6. If the checkpoint's `epic_mode` is `true`, execute `gh pr merge --merge <PR>` merging the feature branch into `epic_context.integration_branch` (already the PR's base branch per the epic-mode `--base` override applied at S8). On success, record `epic_merge: { merge_commit_sha, target_branch, merged_at }` in the checkpoint. On failure due to merge conflict (non-mergeable PR), do not retry blindly: convert the conflict into a synthetic Blocking finding per "Merge-Conflict Remediation" below and re-enter the standard R1–R5 remediation loop; do not proceed to DONE. Merge confirmation (issue #952): a zero exit from `gh pr merge` does not prove a merge when the base branch uses a merge queue, so `epic_merge.merge_commit_sha` is recorded only after the merge is confirmed by polling and ancestry check. Read the pull-request state every 30 seconds, for at most 90 minutes, with the `gh api graphql` query and `.claude/lib/ci-gate/Invoke-MergeConfirmationParser.ps1` exactly as step 3 of `## Per-Item Merge to Main (Merge-on-Green)` in `.claude/skills/parallel-orchestrate/SKILL.md` defines them; on `merged`, run `git fetch origin <integration_branch>` and confirm that `git merge-base --is-ancestor <merge-commit-oid> origin/<integration_branch>` exits 0 before recording `epic_merge`. When the 90 minutes are exhausted, record a finding naming `awaiting_merge_queue` with `Remediability: awaiting_ci` in `remediation-inputs.<timestamp>.md` and follow the wait branch (`blocked_reason: "awaiting_ci"`, `next_step: "S9_ci_green"`). A `not_queued` outcome whose `mergeable` value is `CONFLICTING` follows "Merge-Conflict Remediation"; any other `not_queued` outcome enters `## Remediation Loop — CI-Failure Handling`; a `closed` outcome halts the run with a failure. `gh pr merge` is never re-issued in a loop after `not_queued`.
+7. Standalone merge-on-green (issue #997). This step applies only when the checkpoint's `epic_mode` is absent or `false`, no `Parallel mode: true` marker was supplied in the kickoff, the route requires S9 (the `preparation` route never merges), and the PR base branch is `main`. After step 5 records `step9_status: "passed"` and after every CI-dependent acceptance criterion is checked off and S9 has re-run against the final head, execute `gh pr merge --merge <PR> --match-head-commit <ci_gate.head_sha>`. The merge gate (`.claude/hooks/enforce-epic-merge-gate.ps1`) allows this command through its green-CI branch only when the checkpoint records `pr_gate.pr_number` equal to `<PR>` and the live PR head equals `ci_gate.head_sha`. A zero exit does not prove a merge: confirm it with the step 3 procedure of `## Per-Item Merge to Main (Merge-on-Green)` in `.claude/skills/parallel-orchestrate/SKILL.md` (the `gh api graphql` query and `.claude/lib/ci-gate/Invoke-MergeConfirmationParser.ps1` every 30 seconds for at most 90 minutes; on `merged`, `git fetch origin main` and `git merge-base --is-ancestor <merge-commit-oid> origin/main` exiting 0). Record `pr_merge: { merge_commit_sha, target_branch, merged_at }` in the checkpoint only after that confirmation. Exhausted polling, `not_queued`, and `closed` outcomes are handled as in step 6, and `gh pr merge` is never re-issued in a loop after `not_queued`. A parallel item never merges itself: the parallel parent performs every item merge, and the child records `parallel_mode: true` so the gate declines. The merge gate's parallel exclusion is best-effort, because the `Parallel mode: true` marker is not visible to a Bash hook, so this step relies on the kickoff marker as well as on the gate.
 
 CI-dependent acceptance criteria: when the item has acceptance criteria whose verification requires the result of CI on the PR head, the item's own orchestrator run owns their check-off, and a parent or coordinating session never commits them from its own root. After step 5 records `ci_gate.conclusion == "success"`, check off each CI-dependent criterion in the item's own worktree, commit, push to the PR branch, and re-run S9 from step 1 against the new head SHA, so that `ci_gate.head_sha` equals the final PR head before DONE. In epic mode this completes before step 6 merges. A failed re-run enters `## Remediation Loop — CI-Failure Handling` below; the shared `remediation_loop.completed_attempts` count and its halt after three completed attempts are unchanged.
 
@@ -333,6 +335,12 @@ The orchestrator checkpoint (`artifacts/orchestration/orchestrator-state.json`)
   - `merge_commit_sha` — the merge commit SHA produced by merging the feature branch into `epic_context.integration_branch`.
   - `target_branch` — the integration branch the feature branch was merged into.
   - `merged_at` — ISO-8601 timestamp of when S9 step 6 recorded the merge.
+- a top-level `pr_merge` object (populated only by a standalone S9 step 7 merge, issue #997) containing:
+  - `merge_commit_sha` — the merge commit SHA confirmed on `main`.
+  - `target_branch` — the base branch the pull request merged into (`main`).
+  - `merged_at` — ISO-8601 timestamp of when S9 step 7 recorded the confirmed merge.
+
+  Like `epic_merge`, `pr_merge` is not read by any validator; it is an unvalidated record.
 
 Illustrative shape:
 
@@ -376,9 +384,9 @@ The orchestrator must not create a PR, push a branch for PR purposes, or report
 4. The checkpoint `next_step` is `S8_create_pr` (precondition to entering S9).
 5. PR body produced via the pr-author handoff: `artifacts/pr_body_<N>.md` exists with a matching `artifacts/pr_body_<N>.receipt.json`, created with `--body-file`.
 6. `ci_gate.conclusion == "success"` AND `ci_gate.head_sha == current head SHA of the PR branch`. DONE is not written while either sub-condition is false.
-7. `epic_mode` is `false`, OR (`epic_mode` is `true` AND the integration-branch merge (`gh pr merge --merge`) has completed and `epic_merge.merge_commit_sha` is recorded in the checkpoint). `epic_merge.merge_commit_sha` is recorded only after the merge is confirmed by polling and ancestry check (S9 step 6).
+7. `epic_mode` is `false`, OR (`epic_mode` is `true` AND the integration-branch merge (`gh pr merge --merge`) has completed and `epic_merge.merge_commit_sha` is recorded in the checkpoint). `epic_merge.merge_commit_sha` is recorded only after the merge is confirmed by polling and ancestry check (S9 step 6). In a standalone run whose route requires S9 (issue #997), DONE additionally requires `pr_merge.merge_commit_sha`, recorded only after the S9 step 7 merge is confirmed; the `preparation` route never merges.
 
-This gate is non-negotiable. Each condition is independently verified before PR creation proceeds. Conditions 1-4 are unchanged from the prior contract; conditions 5-7 (receipt handoff, CI-green gate, and epic-mode merge-on-green gate) are additive.
+This gate is non-negotiable. Each condition is independently verified before PR creation proceeds. Conditions 1-4 are unchanged from the prior contract; conditions 5-7 (receipt handoff, CI-green gate, and epic-mode merge-on-green gate, with the standalone merge of S9 step 7 for a standalone run) are additive.
 
 ## Step 6 Delegation — Prohibited Prompt Language
 
@@ -459,6 +467,6 @@ Example:
 
 The validator counts an MCP receipt as successful only when `tool` is a non-empty string, `ok` is exactly `true`, and `evidence` is a non-empty string. Every `required_mcp_tools` entry must have such a receipt unless a valid `issue_adoption` record waives it.
 
-When the GitHub issue already exists before orchestration starts (transferred, filed by hand, or created by epic decomposition) and has been verified read-only (`gh issue view`, a `gh api` GET, or a GitHub MCP issue read), do not call `potential_to_issue`. Record a top-level `issue_adoption` object in the checkpoint instead of a `potential_to_issue` receipt. It may waive only `potential_to_issue` and the checkpoint's promotion-entry tool (`new_potential_entry`, or `new_potential_bug_entry` for a bug-type checkpoint); `potential_to_issue` must always be listed. For a promotion-entry waiver, `potential_record` (a markdown path under `docs/features/potential/`) is required when `origin` is `epic_decomposition`, optional when `origin` is `transferred` or `filed_before_orchestration`, and validated whenever it is present. Every other required tool still needs a successful receipt. Any adoption error waives nothing. The field rules, the closed waivable set, and the error placement are defined in `.claude/rules/orchestrator-state.md` under `## Invariants (issue_adoption object)`.
+When the GitHub issue already exists before orchestration starts (transferred, filed by hand, or created by epic decomposition) and has been verified read-only (`gh issue view`, a `gh api` GET, or a GitHub MCP issue read), do not call `potential_to_issue`. Record a top-level `issue_adoption` object in the checkpoint instead of a `potential_to_issue` receipt. It may waive only `potential_to_issue`, the checkpoint's promotion-entry tool (`new_potential_entry`, or `new_potential_bug_entry` for a bug-type checkpoint), and `new_active_feature_folder` with a valid `feature_folder_record` when the feature folder was already created and committed before this run (for example by a preparation child or an earlier session); `potential_to_issue` must always be listed. For a promotion-entry waiver, `potential_record` (a markdown path under `docs/features/potential/`) is required when `origin` is `epic_decomposition`, optional when `origin` is `transferred` or `filed_before_orchestration`, and validated whenever it is present. Every other required tool still needs a successful receipt. Any adoption error waives nothing. The field rules, the closed waivable set, and the error placement are defined in `.claude/rules/orchestrator-state.md` under `## Invariants (issue_adoption object)`.
 
 These three receipt arrays, populated with the retained required names of the selected route, are what allow the routing-contract validation under `require_complete: true` to pass.

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

@@ -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
 
@@ -70,7 +81,10 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    the issue was transferred), waiving potential_to_issue and the promotion-entry tool for the
    checkpoint's promotion-type. When a lifecycle record for the item exists under
    docs/features/potential/promoted/, cite it as potential_record.` The line is omitted for a
-   potential-entry item, whose child promotes it.
+   potential-entry item, whose child promotes it. The preparation child creates and commits the
+   item's feature folder, so the item's later execution child records `feature_folder_record` for
+   that committed folder instead of calling `new_active_feature_folder` again, per
+   `/parallel-orchestrate` kickoff element 4.
 
 3. **Compute conflict edges over ALL items, including in-flight ones.** Invoke the scheduling
    entry point Get-BlastRadiusConflictEdge from the destination-runtime PowerShell port
@@ -103,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:
 
@@ -209,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

@@ -248,10 +248,19 @@ carries exactly these five elements.
    The token `Parallel mode: true` must appear exactly: it is the marker F7's Layer 1 barrier hook
    matches on. The clause `PR base branch MUST be main` is the child's explicit base-branch
    instruction, recorded as prompt text rather than left to a base-branch ancestry heuristic.
+   The prompt also instructs the child to record top-level `parallel_mode: true` and
+   `parallel_slug: <slug>` in its first per-feature checkpoint write (issue #997). Both keys are
+   unvalidated; the merge gate's green-CI branch declines a checkpoint that carries either, so a
+   parallel child that records them cannot merge its own pull request through that branch; the exclusion is best-effort when the keys are omitted.
 2. The item's active feature folder path, written literally as `docs/features/active/<basename>`.
    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
@@ -263,7 +272,12 @@ carries exactly these five elements.
    with origin `filed_before_orchestration` unless the issue was transferred, waiving
    `potential_to_issue` and the promotion-entry tool for the checkpoint's promotion-type. When a
    lifecycle record for the item exists under `docs/features/potential/promoted/`, the child cites
-   it as `potential_record`.
+   it as `potential_record`. The preparation child already created and committed the item's feature
+   folder, so the prompt also instructs the execution child not to call
+   `new_active_feature_folder`, to confirm the folder read-only
+   (`git cat-file -t HEAD:<feature-folder>` prints `tree`), to add `new_active_feature_folder` to
+   `waived_tools`, and to record `issue_adoption.feature_folder_record` with `path` equal to the
+   checkpoint `feature-folder`, `verified_via` `git_cat_file_head`, `verified_at`, and `evidence`.
 5. The model-budget marker line `model_budget.fable_policy: <disabled|available|preferred>.`
 
 Spawn parameters, passed on the `Agent` call and never written into the prompt text:
@@ -358,9 +372,11 @@ delegations, not to fork-routed skill invocations.
 ## Per-Item Merge to Main (Merge-on-Green)
 
 The parent — `parallel-orchestrator` — performs each item's merge to `main`. The child contract is
-unchanged: `.claude/skills/orchestrate/SKILL.md` is **not modified by this feature**. There is no
-`parallel_mode` clause in its step 9, no `parallel_merge` object in the child checkpoint, and no
-additional condition on the child's PR Creation Gate.
+unchanged: `.claude/skills/orchestrate/SKILL.md` is **not modified by this feature**.
+Issue #997 amends `.claude/skills/orchestrate/SKILL.md` for standalone runs only: a standalone run with a green S9 gate merges its own pull request, and a parallel child never merges its own pull request.
+Its step 9 mentions `parallel_mode` only to exclude a parallel child from that standalone merge.
+There is no `parallel_merge` object in the child checkpoint and no parallel-specific condition on
+the child's PR Creation Gate.
 
 Issue #744 later amended two parts of that child contract for CI-dependent acceptance criteria,
 whose verification requires the result of CI on the item's pull-request head: PR Creation Gate
@@ -416,20 +432,32 @@ Procedure, per item:
 `gh pr merge` spelling except a pure `--disable-auto`, and every `gh api` merge or enqueue
 mutation; issue #952) unless a checkpoint satisfies
 one of its allow conditions; its block reason is `EPIC_MERGE_GATE_BLOCKED`. The gate has
-four allow conditions
+five allow conditions
 which it evaluates in this order: a per-feature checkpoint with `epic_mode == true` and
 `step9_status == "passed"`; an epic checkpoint whose `epic_merge_pr.ci_gate.conclusion` is
-`success` with a matching `pr_number`; the parallel condition described next; and a standalone
-merge authorization record, described after it. The parallel condition authorizes a per-item merge
+`success` with a matching `pr_number`; the parallel condition described next; the green-CI
+standalone condition (issue #997), evaluated after the parallel condition and before the
+authorization record; and a standalone merge authorization record, described after it. The parallel condition authorizes a per-item merge
 when the parallel-orchestrator checkpoint has `route_id == "parallel"`, the target item's
 `merge_status == "ci_green"`, and, when a PR number is named, it matches the item's `pr_number`.
 Step 3 above is therefore permitted for a legitimate parallel merge; a missing, unreadable, or
 invalid parallel checkpoint, a target item whose `merge_status` is not `ci_green`, or a PR number
 that matches no item still fails closed with `EPIC_MERGE_GATE_BLOCKED`.
 
-The standalone condition (issue #670) is the only route for merging a pull request that is not a
-parallel item, such as a standalone fix that unblocks the run. It is evaluated last and never
-overrides the other three. Writer procedure for the coordinating session:
+The green-CI condition (issue #997) lets a standalone run merge its own pull request after S9
+step 7 of `.claude/skills/orchestrate/SKILL.md`: the command names the PR number, no epic or
+parallel checkpoint records that number or the item worktree, the per-feature checkpoint carries
+no `parallel_mode` or `parallel_slug` marker and records `step9_status == "passed"`,
+`ci_gate.conclusion == "success"`, and a matching `pr_gate.pr_number`, and the live PR head
+equals `ci_gate.head_sha` (and `--match-head-commit`, when passed). Its parallel exclusion is
+best-effort: the `Parallel mode: true` marker is in the delegation prompt, not in a Bash payload,
+so a parallel child whose PR number and worktree are not yet recorded by this checkpoint, and
+which omits the `parallel_mode` key, is not excluded by the hook. A parallel child still never
+merges its own pull request; that rule is enforced by the kickoff contract above.
+
+The standalone authorization condition (issue #670) is the route for merging a pull request that
+is not a parallel item and has no green S9 gate, such as a standalone fix that unblocks the run.
+It is evaluated last and never overrides the other four. Writer procedure for the coordinating session:
 
 1. Write the record into a top-level `standalone_merge_authorizations` array in the
    parallel-orchestrator checkpoint (`artifacts/orchestration/parallel-orchestrator-state.json`);
@@ -460,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
@@ -528,11 +566,25 @@ 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
-`gh pr view --json state,mergedAt,headRefOid`, the parent — running from the main repository
-checkout, never from inside a child worktree — issues `git worktree remove <worktree_path>`. On
+`gh pr view --json state,mergedAt,headRefOid`, the parent removes the item's worktree through
+substep 1 of `### Run Closing` below, which takes the absolute path from
+`git worktree list --porcelain` rather than from the relative `items[].worktree_path`. On
 success it records `merge_status: worktree_removed` and `worktree_removed_at`, then regenerates
 `docs/features/parallel/<slug>/parallel-status.md`.
 
@@ -550,7 +602,56 @@ non-authorizing `merge_status` still denies on both branches. The coordination m
 `PreToolUse` denials are conjunctive: a new allow-hook alone could not have overridden the epic
 gate's independent deny, which is why the epic gate itself had to gain the parallel branch.
 The parallel-orchestrator-surface feature (F7) shipped no hook file and made no
-`.claude/settings.json` change of its own.
+`.claude/settings.json` change of its own. Both gates compare a recorded `worktree_path` to the
+removal target through `Test-WorktreeRunRecordedPathMatchesTarget`, so a relative record is joined
+to the main checkout root and to the root that holds the checkpoint (issue #995).
+
+### Run Closing
+
+Run Closing runs once per run, after every non-withdrawn item has `merge_status` of `merged` or
+`worktree_removed` and before completion is reported (issue #995). It re-derives state from
+`git worktree list --porcelain`, `git`, and `gh` rather than from the checkpoint, so it is safe to
+repeat: a substep whose outcome already holds is skipped. The five substeps run in order.
+
+1. **Item worktrees.** For each item whose `merge_status` is `merged`, take the absolute worktree
+   path from `git worktree list --porcelain`, never from the relative `items[].worktree_path`. When
+   that registration is locked, run `git worktree unlock <path>` only when the lock reason names
+   the item's own agent; leave any other lock in place. Run `git worktree remove <path>` with no
+   force flag. On success, set `merge_status: worktree_removed` and `worktree_removed_at`. On
+   refusal, leave `merge_status: merged`, append a `completed_steps` entry naming the path and the
+   refusal reason as a deferral, and continue with the next item.
+2. **Final status.** Regenerate `docs/features/parallel/<slug>/parallel-status.md` so it shows the
+   closing state.
+3. **Run documents.** Stage the run folder and the promoted lifecycle files created for this run by
+   literal path only, in commands of the form
+   `git add -- docs/features/parallel/<slug>/parallel-status.md docs/features/potential/promoted/<promoted-file>.md`
+   and
+   `git commit -m "docs(parallel): close run <slug>" -- docs/features/parallel/<slug>/parallel-status.md docs/features/potential/promoted/<promoted-file>.md`,
+   in which every pathspec begins with `docs/features/`. The `artifacts/` tree is gitignored, so Run
+   Closing never stages it. Never use
+   `git add -A` or `git add .`, and never stage a `docs/features/active/<item>/` folder: each item
+   folder lands through that item's own pull request. Before pushing, require that
+   `git diff --name-only origin/main...HEAD` lists only `docs/` paths; when it lists any other
+   path, stop and report without forcing, rebasing, or splitting the branch. The coordinator holds
+   no `artifacts/orchestration/orchestrator-state.json`, so the existing documentation-only
+   exemptions apply to these commands. Push the branch, delegate the pull request to
+   `Agent(pr-author)` with a `branch:` label in place of an issue number, merge it with
+   `gh pr merge <PR> --merge` naming the pull request number, and confirm the merge with the step 3
+   procedure of `## Per-Item Merge to Main (Merge-on-Green)`.
+4. **Scratch worktrees.** After the merge of the run-document pull request is confirmed, run the
+   `cleanup-merged-worktrees` report with
+   `bash .claude/skills/cleanup-merged-worktrees/scripts/cleanup-worktrees.sh`. Run the same script
+   with `--apply` only when every row the report marks delete-eligible is a worktree this run
+   created: an item worktree, or a planner scratch worktree named in the run's manifest, kickoff,
+   or checkpoint. Otherwise apply nothing and report each remaining scratch worktree as a deferral,
+   because apply mode is repository-wide and can classify a concurrent session's clean,
+   zero-commit worktree as merged. Add no hook allow for scratch worktrees.
+5. **Report.** Report every deferral. The named deferral cases are LV1, an item worktree whose
+   removal was refused after unlock because the item's harness process still holds it; LV2, a
+   run-document pull request still open because the merge queue has not merged it or `origin/main`
+   was absent when the merge gate evaluated it; and LV3, a run-document pull request that needs
+   manual authoring because the `Agent(pr-author)` delegation without an issue number failed its
+   model-routing receipt check. Each scratch worktree left in place is also a deferral.
 
 ## Documentation Maintenance Boundaries
 
@@ -584,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.
@@ -593,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
@@ -660,6 +767,8 @@ hold:
    source files by that item's own run, per the `acceptance-criteria-tracking` skill.
    A CI-dependent criterion is checked off and pushed by that item's own run before its DONE, so
    the head the parent merges already contains the check-off; the parent never commits it.
+5. `### Run Closing` (under `## Worktree Cleanup`) has run, and its run-document pull request is
+   merged or reported as a deferral.
 
 In `open` mode there is no automatic completion. The run is a standing queue and terminates only via
 `/parallel-close`, which is owned by F6 and is neither specified nor shipped by this feature. Do not
@@ -667,7 +776,8 @@ synthesize a completion condition for an `open`-mode run.
 
 No completion condition involves a run-level pull request. There is no final integration pull
 request on this surface, so completion keys on the per-item terminal states above and on nothing
-else.
+else. The Run Closing run-document pull request is a bookkeeping pull request that lands the run's
+generated documents; it is not a run-level integration pull request and merges no item work.
 
 ## Mutation Protocol (F6)
 

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

@@ -140,7 +140,9 @@ the model-budget marker line, and is omitted for a potential-entry item, whose c
 The line carries no mode marker, no digits, and no active feature-folder path, so hook target
 resolution and mode classification are unchanged. The preparation checkpoint does not carry over
 to execution, so the execution child records its own adoption (see
-`.claude/skills/parallel-orchestrate/SKILL.md`, kickoff element 4).
+`.claude/skills/parallel-orchestrate/SKILL.md`, kickoff element 4). Because the preparation child
+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.
 
 **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
@@ -170,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:
 
@@ -256,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
@@ -329,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
@@ -671,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