@danmoisan/drm-copilot-mcp 1.1.11 → 1.1.14

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

@@ -170,6 +170,13 @@ frontmatter default — `opus` for these workers — which suppresses a `fable`
 MUST NOT hard-code `model=opus` in a way that overrides the resolved routing model, mirroring
 step 5 of `## Model Selection` in `.claude/skills/orchestrate/SKILL.md`.
 
+Every such spawn of `Agent(pr-author)` also carries the canonical issue number line and a
+`branch: <name>` label naming the branch checked out in the worktree the pull request is opened
+from, per `## Issue Number Consistency` in `.claude/skills/orchestrate/SKILL.md`.
+`enforce-model-routing-receipt.ps1` identifies the item from those two lines and denies a gated
+delegation it cannot identify, so a spawn that omits both is refused rather than validated against
+whichever checkpoint occupies the calling session's root.
+
 `route` is never an input to model selection; `route` remains file-count driven and governs only
 agents, skills, and MCP tools. A skill whose frontmatter `context` field holds the value `fork`
 inherits the parent model and ignores a model override, so model selection applies to agent
@@ -281,7 +288,9 @@ checkpoint JSON remains the durable, machine-authoritative source.
 `epic_feature_folder`, `epic_manifest_path` (which points at
 `docs/features/epics/<epic-slug>/epic.md`), `epic_status_doc_path`, `integration_branch`,
 `completed_steps`, `next_step`, `last_updated`, `current_wave`, `waves[]`, `features[]`,
-`epic_merge_pr`, and the three receipt arrays (`delegation_receipts[]`, `skill_receipts[]`,
+`epic_merge_pr`, `epic_issue_num` (the epic-level issue `epic-planner` promoted),
+`model_routing_receipts[]` (the routing receipt for each delegation `epic-orchestrator` itself
+spawns), and the three receipt arrays (`delegation_receipts[]`, `skill_receipts[]`,
 `mcp_call_receipts[]`). The
 `merge_status` enum is: `not_started`, `worktree_created`, `pr_open`, `ci_green`,
 `merge_conflict`, `blocked_conflict_loop_limit`, `merged`, `worktree_removed`. The optional
@@ -298,6 +307,10 @@ Validate the checkpoint through the
 that same call at the completion gate. The validation is implemented in
 `scripts/dev_tools/validate_epic_orchestrator_state.py`.
 
+**Checkpoint hygiene (issue #673).** The coordinating session never holds a per-feature checkpoint at its own root. Before the first child delegation of a run it moves any `artifacts/orchestration/orchestrator-state.json` at its root to `artifacts/orchestration/handoff/orchestrator-state.issue-<issue-num>.<yyyy-MM-ddTHH-mm>.json`, and writes none there for the rest of the run, because each item's checkpoint lives in that item's worktree. A gated call the coordinator issues on an item's behalf is resolved by the item's issue number and branch, never by the coordinator root.
+
+**Integration-PR checkpoint shape (issue #663).** The integration-to-`main` pull request and its `Agent(pr-author)` delegation are gated against `artifacts/orchestration/epic-orchestrator-state.json`, and no per-feature checkpoint is written for them. Before `epic-orchestrator` opens that pull request, the epic checkpoint carries `route_id: "epic"`, `integration_branch`, `epic_issue_num`, and a `features[]` array in which every entry's `merge_status` is `merged` or `worktree_removed`. Before the `Agent(pr-author)` delegation, `epic-orchestrator` records the `pr-author` routing receipt in that file's `model_routing_receipts[]`. The pr-author gate, the epic base-branch check, the model-routing gate, and the preimplementation gate treat a call as epic scope when its branch signal (or, for a staging command or file edit, the worktree HEAD) equals `integration_branch`; the pull request base must then be `main`.
+
 ## Completion Requirements
 
 `epic-orchestrator` must not report completion until:

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

@@ -66,6 +66,10 @@ At manifest-authoring time child issues do not exist yet, so `issue_num` values
 placeholders and back-filled from each child's promotion receipt as preparation completes. The
 manifest is committed in final, resolved form before the kickoff artifact is written.
 
+## Epic-Level Issue Promotion
+
+Issue #663. Before the first preparation-mode child delegation, `epic-planner` promotes one epic-level GitHub issue for the epic itself. It authors a potential entry under `docs/features/potential/` describing the epic and promotes it through `mcp__drm-copilot__potential_to_issue` with `promotion_type: epic`; `gh issue create` is not used. It records the resulting number as `epic_issue_num` in the epic planning checkpoint (`artifacts/orchestration/epic-planner-state.json`) and in the kickoff prompt artifact, and `epic-orchestrator` copies it into the epic checkpoint `artifacts/orchestration/epic-orchestrator-state.json` at its first checkpoint write. The integration-to-`main` pull request uses `epic_issue_num` as its canonical issue number.
+
 ## Complexity Assessment
 
 Assess each child feature's complexity band (`C1`-`C4`) using the `model_policy` scale and
@@ -200,6 +204,17 @@ content-widening options, and any operand that resolves outside the five exempt
 exempt operand with one production operand denies the whole invocation. Name each exempt path
 explicitly; the exemption is allow-side only and every parse ambiguity denies.
 
+#### Attribution trailers (issue #713)
+
+With no ready feature checkpoint, the exemption admits two attribution-trailer forms on a pathspec-bearing `git commit`, each followed by the double-dash separator and the exempt path operands:
+
+- The trailer option: `git commit -m 'docs: plan' --trailer 'Co-Authored-By: Name <email>' --trailer 'Claude-Session: <url>' -- <exempt paths>`. The separate-value form and the `--trailer=<value>` form are both admitted, any number of times, on `git commit` only; `git add --trailer` and a trailer option with no value are denied. Git writes every trailer value into one trailer block.
+- The one-paragraph multi-message form: the subject in the first `-m` and every trailer in one single-quoted second `-m` value, separated by a literal newline. Each `-m` value becomes its own paragraph and git parses only the last paragraph as the trailer block, so trailers split across separate `-m` values do not form one trailer block.
+
+Quoting rules: `$` and backtick are literal and admitted inside single quotes, and denied outside quotes and inside double quotes, where the shell expands them. `<` and `>` are admitted inside single or double quotes and denied outside quotes. An unquoted `#` is denied anywhere, because it starts a shell comment that the exemption does not model; a `#` inside quotes is admitted. A typographic quote character (U+2018 to U+201E) anywhere in the command line is denied, because a PowerShell host reads it as a quote.
+
+Not admitted: heredoc-fed messages, including `git commit -m "$(cat <<'EOF' ... EOF)"` and `git commit -F - <<'EOF'`, and message files supplied through `-F <file>` or `--file=<file>`. Use one of the two forms above instead.
+
 ## Checkpoint Handling
 
 Persist `artifacts/orchestration/epic-planner-state.json` after every completed step with the

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

@@ -33,6 +33,7 @@ On every invocation, the main session must:
 1. Read `artifacts/orchestration/orchestrator-state.json` to check for existing state.
 2. If a valid checkpoint exists with a matching objective, resume from the recorded `next_step`.
 3. If no checkpoint exists or the objective is new, begin the orchestration lifecycle from the start.
+4. **Checkpoint hygiene (issue #673).** When the checkpoint at `artifacts/orchestration/orchestrator-state.json` records an `issue-num` other than the item this invocation is about, move it to `artifacts/orchestration/handoff/orchestrator-state.issue-<issue-num>.<yyyy-MM-ddTHH-mm>.json` before writing a new checkpoint, rather than overwriting it or leaving it in place. Apply the same move when this session hands an item whose checkpoint it holds to another session or worktree. A checkpoint left at a session root is read by gates that resolve against that root, so a foreign one there is state a gate can answer from.
 
 ## Prepared-State Portable Handoff Intake
 
@@ -255,10 +256,12 @@ A bounded loop consisting of five steps. The loop variable `remediation_pass` st
 
 The canonical issue number is derived once from the active feature folder name: extract the trailing integer from the folder base name (e.g., `2026-04-26-push-down-claude-customizations-162` yields `162`). Record as `issue_num` in the checkpoint.
 
-Every delegation prompt to `atomic-planner`, `atomic-executor`, and `feature-review` must include the line:
+Every delegation prompt to a receipt-gated subagent type — `atomic-planner`, `atomic-executor`, `feature-review`, `task-researcher`, `prd-feature`, and `pr-author` — must include the line:
 
 > `Canonical issue number for this feature is <issue_num>. All artifact content, file paths, and cross-references must use this number.`
 
+Each such prompt also carries a `branch: <name>` label naming the branch checked out in the item's worktree, written as the first `branch:` occurrence in the prompt. Before promotion assigns an issue number, the branch label alone is required. Two gates, `enforce-model-routing-receipt.ps1` and `enforce-prd-feature-before-planner.ps1`, identify the item from these two lines: they deny a gated delegation they cannot identify rather than checking it against whichever checkpoint occupies the calling session's root, and they never use a feature-folder path to choose the worktree, because a merged feature folder exists in every checkout branched from main.
+
 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.
 
 ## Step S9 — CI Green Gate

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

@@ -58,25 +58,38 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    advances `proposed` -> `admitted` -> `prepared` during this step, recorded as item-state updates in
    `items[]` with the checkpoint's lifecycle timestamps.
 
-3. **Compute conflict edges over ALL items, including in-flight ones.** Invoke the contention
-   relation `Test-BlastRadiusConflict` from the destination-runtime PowerShell port
+3. **Compute conflict edges over ALL items, including in-flight ones.** Invoke the scheduling
+   entry point Get-BlastRadiusConflictEdge from the destination-runtime PowerShell port
    `.claude/lib/blast-radius/BlastRadius.psm1`, which is published by push-down and needs no Python
    interpreter (the default PowerShell 5.1 execution policy blocks `Import-Module` of a `.psm1`
    file, so `pwsh` is mandatory: run as `$repoRoot = git rev-parse --show-toplevel; Import-Module
    (Join-Path $repoRoot '.claude/lib/blast-radius/BlastRadius.psm1') -Force -ErrorAction Stop`).
-   Its two radius arguments are the two items' radius hashtables, not strings, and the third
-   argument is the required parsed `config/blast-radius.json` mapping, which push-down publishes
-   into the destination workspace. That mapping's optional `mergeable_paths` list is read by
-   `Test-BlastRadiusConflict`, which contributes no `path_overlap` edge for a path matching it
-   while the path stays in the declared radius. `conflicts(a, b, config)` in
+   Call it once, as `Get-BlastRadiusConflictEdge -Item <items> -Config <config> -Relation ${function:Test-BlastRadiusConflict}`, where each item
+   record carries `key` (the `items[].issue_num` value), `radius` (the item's radius hashtable, not
+   a string), and the optional complexity `band`, and `-Config` is the required parsed
+   `config/blast-radius.json` mapping, which push-down publishes into the destination workspace.
+   The -Relation argument is required and carries the facade's detection relation; an omitted
+   relation fails fast. The entry point applies the contention relation `Test-BlastRadiusConflict` to every unordered
+   pair and then the integration-cost edge rule of `.claude/rules/parallel-orchestration.md`
+   (hard classes, integer cost, pairwise benefit, and the configured `conflict_tolerance`); the
+   relation still reads the mapping's optional `mergeable_paths` list and contributes no
+   `path_overlap` edge for a path matching it while the path stays in the declared radius.
+   `schedule_conflict_edges(items, config)` and `conflicts(a, b, config)` in
    `scripts/dev_tools/compute_blast_radius.py` (defined in
-   `scripts/dev_tools/_blast_radius_conflicts.py`) remains the repository authority and the parity
-   reference. Read the verdict from `$result['conflict']`; do not test the returned hashtable
-   itself, since it is always truthy under PowerShell boolean coercion, so a bare `if ($result)`
-   check treats every pair as conflicting. Map each conflicting pair onto an `(int, int)` conflict
-   edge of `items[].issue_num` values, normalized so `a < b`. Do not reimplement the relation and do not
-   compute edges over the unstarted subset only: an in-flight conflict is precisely what the
-   admission decision turns on.
+   `scripts/dev_tools/_blast_radius_scheduling.py` and `scripts/dev_tools/_blast_radius_conflicts.py`)
+   remain the repository authority and the parity reference. The call returns a hashtable with
+   `edges` (records `a`, `b`, `reason`, `hard`, `cost`, `benefit`, already normalized so `a < b`)
+   and `tolerated_overlaps` (records `a`, `b`, `reasons`, `cost`, `benefit`). Take each returned
+   edge as an `(int, int)` conflict edge of `items[].issue_num` values, and record the returned
+   tolerated overlaps in the checkpoint's tolerated_overlaps list. When `Test-BlastRadiusConflict`
+   is called directly for a single pair, read the verdict from `$result['conflict']`; do not test
+   the returned hashtable itself, since it is always truthy under PowerShell boolean coercion, so a
+   bare `if ($result)` check treats every pair as conflicting. Do not reimplement the relation or
+   the edge rule, do not apply the relation to each pair by hand, and do not compute edges over the
+   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.
 
 4. **Decide admission.** Call
    `decide_admission(candidate, conflict_edges, in_flight, current_cohort_members=current_cohort_members)`
@@ -150,9 +163,11 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
 
 - One admission per invocation, one `mutations[]` entry per successful admission. A failed
   preparation appends no entry and leaves `items[]` without the candidate.
-- No field and no enum member is added to `mutations[]`, `conflict_edges[]`, `items[]`, or any
-  state or merge-status enum. The nine parallel enums are owned by
-  `.claude/rules/parallel-orchestration.md` and are consumed, never extended.
+- No field and no enum member is added to `mutations[]`, `items[]`, or any state or merge-status
+  enum. A `conflict_edges[]` entry may carry only the three tolerated extra fields `hard`, `cost`,
+  and `benefit` (tolerated-not-validated, returned by the scheduling entry point), and no reason
+  member is added: the four `conflict_edges[].reason` members are unchanged. The nine parallel
+  enums are owned by `.claude/rules/parallel-orchestration.md` and are consumed, never extended.
 - This operation never moves, restates, or re-derives an in-flight item's cohort or state.
 - This operation performs no destructive side effect: it closes no pull request and removes no
   worktree. Those belong to `/parallel-remove` with `--disposition abandon`.

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

@@ -234,6 +234,8 @@ There is no final integration pull request and no fan-in path: the epic surface'
 integration-branch lifecycle has no counterpart on this surface, and its absence is structural
 rather than an omission.
 
+**Checkpoint hygiene (issue #673).** The coordinating session never holds a per-feature checkpoint at its own root. Before the first item delegation of a run it moves any `artifacts/orchestration/orchestrator-state.json` at its root to `artifacts/orchestration/handoff/orchestrator-state.issue-<issue-num>.<yyyy-MM-ddTHH-mm>.json`, and writes none there for the rest of the run, because each item's checkpoint lives in that item's worktree. A gated call the coordinator issues on an item's behalf is resolved by the item's issue number and branch, never by the coordinator root.
+
 ## Parallel-Mode Kickoff Parameter
 
 When `parallel-orchestrator` delegates an item to `Agent(orchestrator)`, the delegation prompt
@@ -326,12 +328,43 @@ Procedure, per item:
 
 **Merge-gate authorization.** `.claude/hooks/enforce-epic-merge-gate.ps1` is a project-wide
 `PreToolUse` Bash-matcher hook that denies any `gh pr merge --merge` unless a checkpoint satisfies
-one of its allow conditions; its block reason is `EPIC_MERGE_GATE_BLOCKED`. The gate now authorizes
-a parallel 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`.
+one of its allow conditions; its block reason is `EPIC_MERGE_GATE_BLOCKED`. The gate has
+four 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
+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:
+
+1. Write the record into a top-level `standalone_merge_authorizations` array in the
+   parallel-orchestrator checkpoint (`artifacts/orchestration/parallel-orchestrator-state.json`);
+   the gate also reads the key from the per-feature and epic checkpoints.
+2. Write one entry per authorized pull request, with these fields: `pr_number` (JSON integer),
+   `pr_url` (ending in `/pull/<pr_number>`), `issue_num` (JSON integer), `branch_name`,
+   `authorized_by`, `authorized_at` (ISO 8601 date-time), `session_id`, `basis` (at least 20
+   characters), and optionally `run_slug`.
+3. Set `session_id` to the session id of the coordinating session that will run the merge
+   command. The gate compares it with the live hook envelope and denies on any difference, so a
+   record written by another session or a previous run authorizes nothing.
+4. Name the pull request explicitly in the merge command (`gh pr merge <PR> --merge`); a bare
+   command never satisfies the standalone condition.
+
+A blanket flag is actively rejected: a `standalone_merge_authorizations` value that names no
+specific pull request (for example `true`) denies with
+`STANDALONE_MERGE_AUTHORIZATION_NOT_PR_SPECIFIC`. Other denials carry
+`STANDALONE_MERGE_AUTHORIZATION_ABSENT`, `STANDALONE_MERGE_AUTHORIZATION_PR_MISMATCH`, or
+`STANDALONE_MERGE_AUTHORIZATION_MALFORMED` (naming the failing field) after the
+`EPIC_MERGE_GATE_BLOCKED` token. The record is a policy-level, auditable declaration, not a
+security control; see the Standalone-Merge-Authorization section of
+`.claude/rules/orchestrator-state.md` for the full field rules and the disclosure.
 
 Branch protection on `main` affects only the pacing of step 3, not its ownership: if `main`
 requires branches to be up to date, an automated `gh pr update-branch` plus re-green cycle is

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

@@ -312,16 +312,25 @@ The library returns the partition; the planner supplies the record fields.
 ### Seeding procedure
 
 1. Invoke `compute-cohorts.sh` exactly once per plan run, over the full conflict graph, after every
-   item is `prepared` and radius-validated. Derive the conflict edge set by applying
-   `Test-BlastRadiusConflict` to every unordered pair of `declared` radii, then pass the pairs as
+   item is `prepared` and radius-validated. Derive the conflict edge set with one call to the
+   scheduling entry point over every item's `declared` radius and complexity band: Get-BlastRadiusConflictEdge
+   (`Get-BlastRadiusConflictEdge -Item <records carrying key, radius, band> -Config <parsed truth table> -Relation ${function:Test-BlastRadiusConflict}`)
+   in PowerShell, or `schedule_conflict_edges(items, config)` (re-exported from
+   `compute_blast_radius.py`, taking `SchedulingItem` records) in Python. Do not apply the
+   detection relation to each pair by hand: the entry point applies it to every unordered pair and
+   then applies the integration-cost edge rule of `.claude/rules/parallel-orchestration.md`
+   (hard classes, integer cost, pairwise benefit, and the configured `conflict_tolerance`). It
+   returns `edges` and `tolerated_overlaps`. The -Relation argument is required; pass the facade's
+   Test-BlastRadiusConflict function object as shown. Pass the returned `edges` pairs as
    `--edges "<a>:<b> ..."` and the item keys as `--keys "<k1> <k2> ..."`.
-   Read the verdict from the conflict key of the returned hashtable.
-   `Test-BlastRadiusConflict` contributes no `path_overlap` edge for a path matching the truth
-   table's optional `mergeable_paths` list, and the path stays in the declared radius.
-   The hashtable itself is always truthy, so a bare boolean test on the result treats every pair as
-   conflicting and serializes the whole run. This is the sibling hazard to the `@(...)` warning
-   above for `Test-BlastRadius`: that function writes an `IList`-shaped pipeline result whose
-   emptiness is falsy, while this one returns a hashtable whose emptiness is not expressible at all.
+   The detection relation inside the entry point contributes no `path_overlap` edge for a path
+   matching the truth table's optional `mergeable_paths` list, and the path stays in the declared
+   radius. When `Test-BlastRadiusConflict` is called directly (for example, while investigating a
+   single pair), read the verdict from the conflict key of the returned hashtable: the hashtable
+   itself is always truthy, so a bare boolean test on the result treats every pair as conflicting.
+   This is the sibling hazard to the `@(...)` warning above for `Test-BlastRadius`: that function
+   writes an `IList`-shaped pipeline result whose emptiness is falsy, while this one returns a
+   hashtable whose emptiness is not expressible at all.
 2. Immediately after the conflict-edge set is derived and before anything consumes it, run the
    lane-assertion diagnostic:
    `bash .claude/lib/bash/report-lane-assertion.sh --manifest docs/features/parallel/<slug>/parallel.md --edges "<a>:<b> ..."`
@@ -341,7 +350,16 @@ The library returns the partition; the planner supplies the record fields.
    Recording the diagnostic's result in the planner checkpoint is a tolerated extra field, not a
    validated one; no validator changes for it.
 3. Record `cohorts[]` at `generation: 0`, each cohort's `item_keys[]` sorted ascending.
-4. Record `conflict_edges[]` as `{a, b, reason}` entries for auditability.
+4. Record `conflict_edges[]` as `{a, b, reason}` entries for auditability; each entry may also carry
+   the tolerated extra fields `hard`, `cost`, and `benefit` returned by the entry point. Record the
+   returned tolerated overlaps in a `tolerated_overlaps` list on the planner checkpoint, one
+   `{a, b, reasons, cost, benefit}` entry per detected, non-hard pair within tolerance. No reason
+   member is added and no validator reads these fields.
+   **Soft-overlap merge rule.** A tolerated pair is not an edge: its two items run in the same or
+   adjacent cohorts without a barrier. The later-merging item of a tolerated pair merges
+   `origin/main` under the existing per-item merge-conflict handling and re-passes CI before it
+   merges. This is the operator-directed configured policy of issue #722; it never licenses
+   hand-narrowing a radius.
 5. Record `recolor_generation: 0` and `current_cohort: 0`.
 6. Record `max_concurrency` — default 4, bounded 1 through 32 by the F3 schema — without enforcing
    it. Enforcement is F5's, through
@@ -570,6 +588,17 @@ content-widening options, and any operand that resolves outside the five exempt
 exempt operand with one production operand denies the whole invocation. Name each exempt path
 explicitly; the exemption is allow-side only and every parse ambiguity denies.
 
+#### Attribution trailers (issue #713)
+
+With no ready feature checkpoint, the exemption admits two attribution-trailer forms on a pathspec-bearing `git commit`, each followed by the double-dash separator and the exempt path operands:
+
+- The trailer option: `git commit -m 'docs: plan' --trailer 'Co-Authored-By: Name <email>' --trailer 'Claude-Session: <url>' -- <exempt paths>`. The separate-value form and the `--trailer=<value>` form are both admitted, any number of times, on `git commit` only; `git add --trailer` and a trailer option with no value are denied. Git writes every trailer value into one trailer block.
+- The one-paragraph multi-message form: the subject in the first `-m` and every trailer in one single-quoted second `-m` value, separated by a literal newline. Each `-m` value becomes its own paragraph and git parses only the last paragraph as the trailer block, so trailers split across separate `-m` values do not form one trailer block.
+
+Quoting rules: `$` and backtick are literal and admitted inside single quotes, and denied outside quotes and inside double quotes, where the shell expands them. `<` and `>` are admitted inside single or double quotes and denied outside quotes. An unquoted `#` is denied anywhere, because it starts a shell comment that the exemption does not model; a `#` inside quotes is admitted. A typographic quote character (U+2018 to U+201E) anywhere in the command line is denied, because a PowerShell host reads it as a quote.
+
+Not admitted: heredoc-fed messages, including `git commit -m "$(cat <<'EOF' ... EOF)"` and `git commit -F - <<'EOF'`, and message files supplied through `-F <file>` or `--file=<file>`. Use one of the two forms above instead.
+
 ## Completion Report
 
 The final report to the operator must include:

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

@@ -76,3 +76,18 @@ writes and the `gh pr create` / `gh pr edit --body-file` handoff.
 - Do not treat PR numbers as issues.
 - Auto-close bullets must use exactly `- Closes #NNN` format, sourced only from "Issues to autoclose" or "Author-asserted autoclose issues."
 - If GitHub validation is unavailable/unverified, do not emit `Closes`; use the fallback `None` bullet.
+
+## Required `--head` on `gh pr create` (issue #687)
+
+Every `gh pr create` command this agent issues MUST carry an explicit
+`--head <branch>` naming the branch the pull request is opened from.
+
+This is what makes the call's target derivable. `enforce-pr-author-skill.ps1` resolves the
+worktree the call pertains to from the command text, and validates the orchestrator checkpoint
+belonging to that worktree. Without `--head`, `gh pr create` infers its head branch from the
+current checkout and the command carries no signal at all, so the gate denies with
+`TARGET_WORKTREE_NOT_DERIVABLE` rather than validating against whichever checkpoint occupies the
+session root, which in a parallel or epic topology belongs to a different item.
+
+Pass `--head` even when the branch is the current one: the gate resolves it to the session root
+and behaves exactly as before, and the command stays correct if it is ever replayed elsewhere.

package/resources/claude-customizations/.claude/skills/quota-throttling/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: quota-throttling
+description: 'Quota throttling and account-switching policy for multi-agent orchestration. Use when pacing agent work against five-hour and seven-day usage limits, deciding whether and when to switch accounts, setting concurrency caps, forecasting a rate-limit wall, handling total weekly exhaustion, or designing a usage monitor. Covers account viability, failover-dependent pacing targets, the measured cost model, commit-before-the-wall, and the coordinator/agent division of labour.'
+---
+
+# Quota Throttling and Account-Switching Policy
+
+Policy for keeping long-running, multi-agent orchestration inside account usage limits without
+losing work. Derived from about five days of continuous multi-agent orchestration (TaskMaster runs
+`bugs-2026-09-11` and `bugs-2026-09-17`).
+
+Every figure marked **MEASURED** was observed; figures marked **ESTIMATE** are extrapolations.
+Cost figures are machine- and repository-specific. Re-measure before relying on them elsewhere.
+
+## When to Use This Skill
+
+Use this skill when:
+
+- a coordinating session runs orchestrators, epic runs, or parallel runs that spawn subagents;
+- deciding whether to start, stagger, hold, or stop agent work because of usage limits;
+- choosing whether and when to switch between accounts;
+- a rate-limit wall is forecast, or every account is exhausted;
+- designing a monitor that watches usage or CI state.
+
+## Reading Quota
+
+The coordinator reads usage from the account switcher, for example `cswap list --json`. The
+fields each rule below depends on:
+
+| Field | Meaning |
+|---|---|
+| `accounts[].active` | Whether the account currently supplies credentials. |
+| `accounts[].usageStatus` | Must be `ok`; any other value makes the account non-viable. |
+| `usage.fiveHour.pct` | Five-hour window utilization, an integer percentage. |
+| `usage.fiveHour.resetsAt` | Authoritative ISO-8601 UTC reset time. `null` means the window has not started. |
+| `usage.sevenDay.pct` | Seven-day utilization, an integer percentage. |
+| `usage.sevenDay.resetsAt` | Authoritative ISO-8601 UTC weekly reset time. |
+| `usage.sevenDay.willLastToReset` | The switcher's own projection of whether the weekly budget lasts. |
+| `usage.*.clock`, `usage.*.countdown` | Human-readable display values. `clock` is LOCAL time; do not use it for arithmetic. |
+
+Some switchers switch automatically on the five-hour threshold alone and do not consult the
+seven-day window. Such a switcher can hand over to an account whose five-hour window has reset
+but whose weekly budget is spent. Apply section 1 yourself rather than relying on the switcher.
+
+## 1. Account Viability
+
+An account is a viable target only if BOTH hold:
+
+- seven-day usage < 95%
+- five-hour usage < 90%
+
+The weekly gate dominates. An account at >= 95% weekly is NOT a viable target regardless of its
+five-hour state, and must be excluded from all pacing math.
+
+The binding budget is `min(five-hour headroom to 90%, weekly headroom to 95%)`. Compute both every
+time. Late in a week the weekly headroom is usually the smaller number, and the five-hour window
+is then irrelevant.
+
+## 2. Pacing Target Depends on Whether a Failover Exists
+
+**Two or more viable accounts: front-load.** Target about 90% of the five-hour window in about
+2 hours (about 45% per hour). Reaching 90% triggers a switch, so the unused remainder of the
+window costs nothing.
+
+**Exactly one viable account: spread.** Target about 90% across the WHOLE five-hour window (about
+18% per hour). Front-loading here is wrong: reaching 90% at the 2-hour mark produces a stall of
+about 3 hours with no account to switch to.
+
+These are different policies, not different settings of one policy. Applying the two-account
+target to a one-account situation is the most expensive mistake observed (see section 12,
+item 1).
+
+## 3. Cost Model (MEASURED, Serialized Single Items)
+
+| Activity | Five-hour points | Weekly points | Wall clock |
+|---|---|---|---|
+| Coordination only (API calls, git, checkpoint writes, no agents) | ~3 total | negligible | — |
+| One item, full cycle (child + executor + toolchain + coverage run) | ~17 | ~3 | ~43 min |
+| One plan revision, or a low-cost item | ~4-5 | — | — |
+| Three items entering Phase 0 simultaneously | 96-108 per hour | — | a full five-hour window in 62 min |
+
+Builds and test runs consume wall-clock time but zero quota. A long quiet period at 0% per hour
+with agents alive usually means they are inside a build, not stalled.
+
+Ratio (ESTIMATE, two data points): one full five-hour window is about 14 weekly points.
+
+## 4. Concurrency Control
+
+A concurrency cap governs an orchestrator's DIRECT children. Each child spawns its own
+grandchildren (executors, planners, researchers), and those are the dominant consumers. Always
+express a cap as a budget on TOTAL AGENTS IN THE SUBTREE, and require that it be propagated
+verbatim to every level.
+
+A cap change only restricts NEW starts. It does nothing to work already running. Cutting a cap
+from 6 to 2 mid-flight changed the burn rate by zero, because the cost was in agents already
+alive.
+
+For in-flight burn there are exactly two controls:
+
+- **Commit-and-hold** — finish the current task, commit, start nothing new.
+- **Stopping agents outright** — destructive; use only as a last resort.
+
+**Stagger starts.** The dominant cost driver is not item count; it is simultaneous Phase 0
+cycles. Bring items in one at a time and let each settle before starting the next.
+
+## 5. Measurement Discipline
+
+- The usage percentage is an INTEGER. At 5-minute sampling the computed rate quantizes to
+  multiples of about 12% per hour. Do not react to a single sample; measure over spans of at
+  least 15 minutes.
+- The FIRST sample after an account switch is inflated by batched accounting. Take a second
+  reading before acting on it, but do not dismiss it either; it has been partly real more than
+  once.
+- Reset times: the human-readable `clock` field is LOCAL time. The ISO `resetsAt` field is
+  authoritative. Convert before doing arithmetic; a four-hour error from this changed a plan.
+- Five-hour window elapsed time = 300 − (minutes until reset). The window starts on first use,
+  not on a fixed clock boundary.
+- VERIFY a reset directly before resuming. Never infer it from the clock. A reset timestamp can
+  pass while the counter still reads the old value for a minute or two.
+
+## 6. Approaching a Wall
+
+Commit BEFORE the wall, not at it. A rate-limit error terminates an agent immediately; the agent
+does not wait out the gap and resume. The duration of the outage does not change this risk: even
+a 60-second gap terminates in-flight work.
+
+Sequence when a wall is forecast:
+
+1. Order all in-flight children to COMMIT NOW, in whatever state, without finishing the current
+   task. A committed partial result is recoverable; an uncommitted complete one is not.
+2. Let them keep working until the wall actually arrives.
+3. Set the commit checkpoint with real margin, and recompute it as the rate moves. A checkpoint
+   that lands ON the forecast wall protects nothing.
+
+Git operations are LOCAL and consume no model quota; they succeed on a fully exhausted account.
+If errors start before committing finishes, keep retrying the COMMIT specifically and nothing
+else.
+
+## 7. Total Weekly Exhaustion
+
+When no account is viable:
+
+1. **Serialize** — stop all parallel activity; zero new starts.
+2. **Commit ALL working documents across ALL worktrees** — every item worktree, the plan-home
+   worktree, and every in-flight child, not only the current item.
+3. **Report and hold.**
+
+This differs from a routine pause: the outage may last days, so nothing may be left uncommitted
+on the assumption of a quick return.
+
+## 8. Switching
+
+- Switch at 90% of the five-hour window IF a viable target exists.
+- If no viable target exists, do NOT switch; hold until the earliest reset. Switching onto an
+  exhausted account produces immediate failures.
+- Verify the switch landed (active account, both windows) before releasing work.
+- A mid-flight credential change is transparent to running agents. Instruct them explicitly not
+  to treat the change, or a brief error around it, as a failure signal.
+
+## 9. Usage Credits and Overage
+
+Never spend credits on work. The ONLY sanctioned use is completing a non-destructive
+serialization and commit so that work is not lost. If any path offers to continue past a limit
+by consuming credits, stop and ask the user.
+
+## 10. Reserve Policy
+
+Holding an account's last few points as an emergency commit reserve is correct ONLY while
+something is uncommitted. Verify first: if every branch is pushed and every worktree is clean,
+the reserve protects nothing and should be spent on useful work instead. Check before assuming.
+
+## 11. Monitor Design
+
+Report on thresholds, not on every sample. An idle monitor that fires every ten minutes costs a
+turn each time and hides the signal among routine readings.
+
+**A check for the ABSENCE of a bad state is satisfied by the absence of ALL state.** A CI waiter
+polling for "no pending checks" reported SETTLED during the window between one run being
+superseded and the next registering, when no checks existed at all. Require a POSITIVE assertion
+instead: a conjunction that an empty set cannot satisfy (for example, "at least one required check
+exists AND none is pending").
+
+Alert on:
+
+- threshold crossings;
+- a sustained rate above target;
+- a non-`ok` status;
+- account-viability changes;
+- window rollovers.
+
+Stay silent otherwise.
+
+## 12. Observed Failure Modes
+
+1. Applying the two-account front-load target with only one viable account.
+   Cost: about 95 minutes of idle time.
+2. Cutting a concurrency cap to control burn from work already running.
+   Cost: none directly, but the effective control went unused while the window drained.
+3. Launching multiple items into simultaneous Phase 0.
+   Cost: a full five-hour window in 62 minutes.
+4. Assuming a fallback account was fresh without checking.
+   Cost: about 1 hour, and seven items' preparation output stranded uncommitted when agents were
+   terminated.
+5. Setting a commit checkpoint that landed on the forecast wall instead of before it.
+6. Reacting to single 5-minute samples inside the quantization band, producing cap oscillation
+   that achieved nothing.
+
+## 13. Division of Labour
+
+An orchestrating agent generally CANNOT see quota. Do not ask it to estimate usage. The workable
+split is:
+
+- the **agent** reports its COST PROFILE: how many agents are alive, what kind of work they are
+  doing, and what it is about to start;
+- the **coordinator** supplies the MEASUREMENT and the decision.
+
+Have the agent announce before starting each item, and reply with a live reading.
+
+Corollary: if the coordinator is slow to respond, the agent should proceed on its own rather than
+stall. A four-hour idle period occurred because an agent correctly held for a ruling that was
+never sent. Absorbing a small pacing error is preferable to repeating that.

package/resources/claude-customizations/config/blast-radius.json

@@ -20,7 +20,8 @@
     ".claude/skills/policy-compliance-order/SKILL.md",
     ".claude/agent-memory/**",
     ".agents/skills/**",
-    "scripts/vscode/**"
+    "scripts/vscode/**",
+    ".github/copilot-instructions.md"
   ],
   "mergeable_paths": [
     "**/*.csproj",
@@ -29,6 +30,18 @@
     "**/*.vbproj",
     "**/*.props"
   ],
+  "conflict_tolerance": {
+    "tolerance_percent": 100,
+    "weights": { "same_file": 8, "possible_overlap": 2, "append_only": 1, "module": 2 },
+    "band_durations": { "C1": 1, "C2": 2, "C3": 4, "C4": 8 },
+    "default_band": "C1",
+    "append_only_paths": [
+      "**/CHANGELOG.md",
+      "extensions/drm-copilot/resources/claude-customizations/pack-manifests/core.json"
+    ]
+  },
+  "write_intent_extraction": true,
+  "path_roots": [],
   "modules": {
     "config": ["config/**"]
   },

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

@@ -27,12 +27,14 @@
     ".claude/hooks/enforce-discovery-artifact-gate.ps1",
     ".claude/hooks/enforce-epic-invocation-origin.ps1",
     ".claude/hooks/enforce-epic-merge-gate.ps1",
+    ".claude/hooks/enforce-epic-merge-gate-authorization.ps1",
     ".claude/hooks/enforce-epic-wave-barrier.ps1",
     ".claude/hooks/enforce-epic-worktree-removal-gate.ps1",
     ".claude/hooks/enforce-evidence-locations.ps1",
     ".claude/hooks/enforce-feature-folder-order.ps1",
     ".claude/hooks/enforce-model-routing-receipt.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate.ps1",
+    ".claude/hooks/enforce-orchestration-preimplementation-gate-epic-scope.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-helpers.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-modes.ps1",
     ".claude/hooks/enforce-parallel-abandon-gate.ps1",
@@ -44,6 +46,7 @@
     ".claude/hooks/enforce-pr-author-skill.epic-base-branch.ps1",
     ".claude/hooks/enforce-pr-author-skill.ps1",
     ".claude/hooks/enforce-pr-author-skill-helpers.ps1",
+    ".claude/hooks/enforce-prd-feature-before-planner-helpers.ps1",
     ".claude/hooks/enforce-prd-feature-before-planner.ps1",
     ".claude/hooks/enforce-promotion-mcp-only.ps1",
     ".claude/hooks/hook-command-invocation.ps1",
@@ -103,6 +106,7 @@
     ".claude/skills/pr-author/SKILL.md",
     ".claude/skills/pr-base-branch-merge-base/SKILL.md",
     ".claude/skills/pr-context-artifacts/SKILL.md",
+    ".claude/skills/quota-throttling/SKILL.md",
     ".claude/skills/remediation-handoff-atomic-planner/SKILL.md",
     ".claude/skills/research-issue/SKILL.md",
     ".claude/skills/review-epic/SKILL.md",
@@ -138,6 +142,8 @@
     ".claude/lib/blast-radius/BlastRadiusTokenShape.psm1",
     ".claude/lib/cleanup-manifest/CleanupWorktreeManifest.psm1",
     ".claude/lib/blast-radius/BlastRadiusConflict.psm1",
+    ".claude/lib/blast-radius/BlastRadiusScheduling.psm1",
+    ".claude/lib/blast-radius/BlastRadiusWriteIntent.psm1",
     ".claude/lib/project-file-merge/ProjectFileMergeGrammar.psm1",
     ".claude/lib/project-file-merge/ProjectFileMerge.psm1",
     ".claude/lib/project-file-merge/Resolve-MergeableConflict.ps1",
@@ -163,6 +169,11 @@
     ".claude/lib/mermaid/MermaidLineScanner.psm1",
     ".claude/lib/mermaid/MermaidMarkdownFences.psm1",
     ".claude/lib/mermaid/MermaidValidation.psm1",
+    ".claude/lib/worktree-resolution/WorktreeResolution.psm1",
+    ".claude/lib/worktree-resolution/WorktreeTargetResolution.psm1",
+    ".claude/lib/worktree-resolution/WorktreeItemResolution.psm1",
+    ".claude/lib/worktree-resolution/EpicScopeResolution.psm1",
+    ".claude/lib/worktree-resolution/EpicScopeReadiness.psm1",
     ".claude/skills/mermaid-diagram/references/flowchart.md",
     ".claude/skills/mermaid-diagram/references/sequence.md",
     ".claude/skills/mermaid-diagram/references/class.md",