docs: consolidate stranded documentation and agent-memory before merged-worktree cleanup

.claude/agent-memory/epic-orchestrator/MEMORY.md

@@ -8,4 +8,6 @@
 - [Epic checkpoint schema gotchas](project_epic_checkpoint_schema_gotchas.md) — max_parallel_features (1-8) REQUIRED; waves[] uses feature_folders key; wave-barrier notices are unconditional on unmerged deps (expected mid-flight, MCP returns ok:false but merging a dep clears its specific line); additive extra keys tolerated; Python CLI validator absent in TaskMaster (use MCP)
 - [Merged child worktree defer removal — two causes](feedback_merged_child_worktree_still_locked_defer_removal.md) — non-force git worktree remove fails exit 128 for framework-lock (shared session pid) OR uncommitted files; never force mid-wave. Locks release PIECEMEAL — retry every deferral each resume (a merged child's lock can clear while siblings stay locked); a child may own a named-feature worktree + a secondary agent worktree
 - [Cross-child annotation fan-in debt](project_cross_child_annotation_fanin_debt.md) — parallel per-file opt-in annotation children fan in NEW diagnostics on the integrated tree that no scope-locked child can fix; a green per-child gate ≠ green integrated-tree gate; reserve a capstone full-tree gate + carry residuals as blocking capstone_inputs
+- [Child PRs on an integration base get ZERO CI](project_child_pr_ci_gap_integration_base.md) — TaskMaster ci.yml triggers pull_request only on [main, development]; merge-on-green silently becomes merge-on-nothing. Verify the trigger list yourself; gate the integrated tree with `gh workflow run ci.yml --ref <integration>`; never edit the workflow mid-epic
+- [Prepared-epic stale child branches collide](feedback_prepared_epic_stale_child_branches.md) — after /epic-plan the child bug/* branches survive as local refs (strict ancestors of the integration tip); delete them pre-wave-0 or execution children get suffixed branches; also tell each child to checkout -B from origin/integration
 - [Constraint-propagation waivers cascade serially](feedback_constraint_propagation_waiver_cascades_serially.md) — a ratified generic-base constraint implicates cross-child consumers ONE FILE AT A TIME (waiver grew 1→2→3→4, then CLOSED via assembly-wide enumeration: each generic base has a Wrapper+Converter consumer → symmetric closed set); re-escalate per new consumer never widen blind, but DO demand the enumeration to bound it; expect plan-literal targets ([P9 "four bases" wording; solution-wide-zero) to be DEVIATIONS to document not fail — solution-wide zero is the capstone's gate, the child's is its isolated cluster

.claude/agent-memory/epic-orchestrator/feedback_prepared_epic_stale_child_branches.md

@@ -0,0 +1,25 @@
+---
+name: prepared-epic-stale-child-branches
+description: After /epic-plan, the prepared child branches survive as stale local refs that collide when execution children recreate them; delete them pre-wave-0 after proving ancestry into the integration branch
+metadata:
+  type: feedback
+---
+
+Before launching wave 0 of an `epic-planner`-prepared epic, check for leftover local child
+branches (`bug/*`, `feature/*`) from preparation and delete them once ancestry is proven.
+
+**Why:** `epic-planner` prepares each child on its own branch, then fans the preparation commits
+into `epic/<slug>-integration`. The child branches are left behind as local refs. When an
+execution child later runs `git checkout -b <same-name>`, the name is taken, and the framework
+falls back to a suffixed branch (the `-r2` pattern visible in older QuickFiler worktrees), which
+desynchronizes the branch recorded in the epic checkpoint from the branch the child actually
+pushes and PRs from. Related: [[feedback_hung_child_recovery_blocked_by_removal_gate]].
+
+**How to apply:** Prove each stale branch is a strict ancestor of the integration branch first —
+`git rev-list --left-right --count epic/<slug>-integration...<branch>` must show `0` on the right
+side. Then `git branch -D` it; nothing is lost because the work is already reachable from a pushed
+ref. Leave the *remote* copies alone: they are ancestors of the integration tip, so a child's first
+push is a fast-forward. Also tell each child to `git checkout -B <branch>
+origin/epic/<slug>-integration` explicitly — the framework creates the isolated worktree from the
+session HEAD, not from the integration branch, so the prepared feature folder and its committed
+`plan-path` are otherwise absent from the child's tree.

.claude/agent-memory/epic-orchestrator/project_child_pr_ci_gap_integration_base.md

@@ -0,0 +1,28 @@
+---
+name: child-pr-ci-gap-integration-base
+description: TaskMaster's ci.yml triggers pull_request only on [main, development], so epic child PRs based on the integration branch get zero CI checks; use workflow_dispatch on the integration branch as the integrated-tree gate
+metadata:
+  type: project
+---
+
+In TaskMaster, `.github/workflows/ci.yml` declares `pull_request: branches: [main, development]`.
+An epic child PR whose base is `epic/<slug>-integration` matches no workflow trigger, so
+`gh pr view --json statusCheckRollup` returns empty and `mergeStateStatus` is `CLEAN`. The child's
+S9 merge-on-green step has nothing to parse.
+
+**Why:** This silently converts merge-on-green into merge-on-nothing for every child in an epic.
+A child that reports "CI green" against an integration base has not been gated by CI at all — it
+has at best run local CI-equivalent commands. The failure would otherwise surface only at the final
+integration-to-`main` PR, after every child has already merged, which is the most expensive place
+to discover it. Compare [[project_cross_child_annotation_fanin_debt]]: a green per-child gate is
+not a green integrated-tree gate, and here the per-child gate does not even exist.
+
+**How to apply:** Verify the trigger list yourself early in any epic run rather than trusting a
+child's CI claim — read `.github/workflows/ci.yml` from the integration ref. Then: (1) tell each
+child in its kickoff prompt that no CI will run and that local CI-equivalent verification is
+mandatory and must be recorded as feature evidence; (2) `ci.yml` also declares
+`workflow_dispatch`, so run `gh workflow run ci.yml --ref epic/<slug>-integration` at each wave
+boundary to gate the *integrated* tree; (3) rely on the final `main`-based integration PR for the
+authoritative full-CI gate. Do not "fix" this by adding the integration branch to the workflow's
+trigger list mid-epic — a `.github/workflows/**` diff is itself Blocking under the
+`modified-workflow-needs-green-run` policy rule and is outside every child's scope.

.claude/agent-memory/epic-planner/MEMORY.md

@@ -6,3 +6,9 @@
 - [Concurrent prep children need worktree isolation](feedback_concurrent_prep_children_worktree_isolation.md) — each concurrent prep child gets isolation:worktree + child-scoped orchestrator-state.<slug>.json or siblings overwrite the canonical checkpoint
 - [Force-remove prep-child worktree](feedback_prep_child_worktree_force_remove.md) — worktree remove may block on uncommitted orchestrator-agent-memory scratch; force-remove is safe once HEAD == merged tip and only .claude/agent-memory/orchestrator/** is dirty
 - [epic-planner-state require_ready_for_execution mode](reference_epic_planner_state_ready_for_execution_mode.md) — hardened contract wants execution-time launch/topology/model-routing receipts epic-planner doesn't produce; validate with DEFAULT call, don't fabricate; run against integration worktree root
+- [Pre-existing issues: skip potential_to_issue](feedback_preexisting_issues_skip_potential_to_issue.md) — epics scoped from an open backlog must tell each prep child to call only new_active_feature_folder, or every child files a duplicate issue
+- [Governance-doc edits need execution authorization](feedback_governance_doc_edits_need_execution_authorization.md) — issues that are defects IN CLAUDE.md/.claude/rules collide with the policy-compliance hard constraint; plan it, scope the suspension per child, make /epic-run the authorization act
+- [Recover a dead prep child: commit, then relaunch](feedback_recover_dead_prep_child_by_committing_then_relaunching.md) — infra-killed children leave the whole feature folder uncommitted and epic-planner has no SendMessage; commit to bug/<slug>, push, force-remove the worktree, relaunch as a resume
+- [Prepared-plan CRLF hazard at execution](reference_prepared_plan_crlf_hazard_at_execution.md) — plans commit LF but core.autocrlf=true makes them CRLF in a fresh worktree; the MCP plan validator has rejected that — tell epic-orchestrator to re-normalize
+- [epic-kickoff validator table rules](reference_epic_kickoff_validator_table_rules.md) — the table must immediately follow "## Feature Summary" (first line after it is parsed as the header), issue_num must be a bare integer, and trailing prose becomes a phantom row
+- [Lane A gate-fidelity epic](project_lane_a_gate_fidelity_epic.md) — build-ci-coverage-gate-fidelity is Flight 0 of the blocked parallel run; #513 is un-fixable here (lives in drm-copilot); nullable debt is a follow-on epic

.claude/agent-memory/epic-planner/feedback_governance_doc_edits_need_execution_authorization.md

@@ -0,0 +1,35 @@
+---
+name: governance-doc-edits-need-execution-authorization
+description: An epic whose issues require editing CLAUDE.md or .claude/rules/** collides with the policy-compliance-order hard constraint; plan it, scope it, and make the user's kickoff the authorization point
+metadata:
+  type: feedback
+---
+
+Some bug issues are defects *in* the governance documents themselves (wrong toolchain commands,
+contradictory coverage thresholds). Fixing them requires editing `CLAUDE.md` and
+`.claude/rules/**`, which the `policy-compliance-order` skill hard constraint prohibits: "Do NOT
+modify policy documents under `.claude/rules/` or `.github/instructions/`."
+
+Do not treat this as a planning blocker and do not silently ignore it. Resolve it structurally:
+
+1. **Planning is unaffected.** Preparation produces specs and atomic plans that *propose* the
+   edits; no governance file is modified. Say this explicitly in the checkpoint.
+2. **Record a `governance_edit_authorization` block** in `epic-planner-state.json` naming the
+   exact files, the issues that require them, and `status: required_at_execution`.
+3. **Put an "Execution Authorization Required" section in `epic.md`** and repeat it in the kickoff
+   artifact, so running `/epic-run <slug>` is the visible authorization act.
+4. **Scope the suspension per child, in the delegation prompt.** State that the constraint is
+   suspended for that feature only, only at the sites its issues enumerate, and add the hard
+   limit: no policy requirement may be relaxed, weakened, or deleted in order to make a gate pass.
+5. **Partition the shared file between siblings.** Two children editing `CLAUDE.md` in different
+   sections merge cleanly only if each is told which region it owns and which regions belong to a
+   sibling. In the Lane A epic, feature 512 owned the C# toolchain command block and feature 494
+   owned § UT2 coverage; each prompt named the other's region as off-limits. That let both stay
+   in different waves without a fake `depends_on` edge.
+
+**Why:** An agent cannot grant itself or a subagent permission to edit configuration or policy.
+The user's own `/epic-run` command is the only thing that can, so the plan's job is to make that
+authorization explicit, bounded, and reviewable rather than to smuggle it into a delegation prompt.
+
+Related: [[check-inflight-branches-before-decomposition]],
+[[preexisting-issues-skip-potential-to-issue]].

.claude/agent-memory/epic-planner/feedback_preexisting_issues_skip_potential_to_issue.md

@@ -0,0 +1,36 @@
+---
+name: preexisting-issues-skip-potential-to-issue
+description: When an epic decomposes an existing bug backlog, prep children must skip potential_to_issue and call only new_active_feature_folder, or every child files a duplicate issue
+metadata:
+  type: feedback
+---
+
+An epic scoped from an existing issue backlog (rather than from fresh potential entries) must tell
+every preparation child, in the delegation prompt, NOT to run the first two promotion steps:
+
+> Issue #N is already open and its potential entry is already promoted at
+> `docs/features/potential/promoted/<file>`. Do NOT call `new_potential_bug_entry` or
+> `potential_to_issue` — `potential_to_issue` always creates a NEW issue and would duplicate #N.
+> Call only `new_active_feature_folder` with `issue_number = N`. Record the promotion receipts
+> truthfully: note that the potential-entry and issue receipts refer to pre-existing artifacts
+> rather than newly created ones. Do not fabricate receipts.
+
+**Why:** `mcp__drm-copilot__potential_to_issue` has no idempotent path; it always creates a new
+issue. A default-behaviour child following `feature-promotion-lifecycle` literally would file a
+duplicate of every backlog issue the epic is supposed to close. The `preparation` route still
+wants promotion receipts, so the child must record the pre-existing artifacts truthfully instead
+of inventing them.
+
+Two related traps seen in the Lane A run (2026-08-10):
+- The promoted potential file under `docs/features/potential/promoted/` is often far richer than
+  the GitHub issue body, which frequently reads "(not provided in potential file)" in every
+  section. Point children at the promoted file, not just `gh issue view`.
+- A backlog issue marked `- Work Mode: minor-audit` whose body has no populated
+  `## Acceptance Criteria` fails the minor-audit eligibility check. Per
+  `feature-promotion-lifecycle`, fail closed to the full path (`full-bug`) and say so in the
+  prompt, rather than letting the child discover the integrity failure mid-run.
+
+**How to apply:** Check `gh issue view <N> --json state` for every candidate during the
+epic-worthiness gate. Any already-open issue gets this paragraph in its delegation prompt.
+Related: [[concurrent-prep-children-worktree-isolation]],
+[[check-inflight-branches-before-decomposition]].

.claude/agent-memory/epic-planner/feedback_recover_dead_prep_child_by_committing_then_relaunching.md

@@ -0,0 +1,49 @@
+---
+name: recover-dead-prep-child-by-committing-then-relaunching
+description: A preparation child killed by an API/spend-limit error leaves its whole feature folder uncommitted; commit it to the child branch yourself, then relaunch from that commit — SendMessage is not available to epic-planner
+metadata:
+  type: feedback
+---
+
+When a preparation-mode child dies on an infrastructure error (API failure, org monthly spend
+limit) rather than a task failure, its worktree survives but **its entire feature folder is
+typically uncommitted** — the preparation-mode kickoff line only tells it to commit *after*
+`PREFLIGHT: ALL CLEAR`, so a child killed before that point has committed nothing.
+
+`SendMessage` is **not** in the `epic-planner` tool set (only `Agent`, `Read`, `Grep`, `Glob`,
+`Write`, `Edit`, `Bash`, and the MCP validator), so resuming a child in place is not possible even
+when the caller asks for it. Relaunching naively is destructive, because a fresh `Agent` call gets
+a **new** worktree and the old worktree's uncommitted work is never seen.
+
+Recovery procedure:
+
+1. `git -C <wt> status --porcelain` and `git -C <wt> log --oneline origin/<integration>..HEAD` for
+   every surviving worktree. Uncommitted feature folder plus zero commits is the common shape.
+2. Commit each worktree's work onto its own `bug/<slug>` branch yourself, with explicit pathspecs
+   (`docs/features/active/<folder>` plus `.claude/agent-memory`), stating in the message that
+   epic-planner preserved it after an infrastructure termination and that preflight was not
+   reached.
+3. `git push -u origin bug/<slug>` for each — durable backup, and it lets a fresh worktree check
+   the branch out.
+4. Force-remove the now-clean worktrees. Required, not optional: git refuses to check a branch out
+   in two worktrees, so the old worktree must go before the relaunched child can use the branch.
+   Some agent worktrees are locked and need `git worktree remove -f -f`.
+5. Relaunch with a prompt whose first section is "THIS IS A RESUME, NOT A FRESH RUN": check out the
+   preserved branch, merge the current integration tip, enumerate the artifacts that already exist,
+   and state the specific remaining step.
+
+Two things the relaunched child must be told explicitly:
+
+- **Rebuild the child-scoped checkpoint.** `artifacts/` is gitignored, so the checkpoint does not
+  travel with the branch and is absent in the new worktree.
+- **Trust on-disk artifacts over the dead run's `next_step`.** Child checkpoints lag badly; one
+  child's checkpoint said `next_step: S2_research` while its folder already held research, three
+  feature documents, an atomic plan, and nine evidence artifacts.
+
+Also re-verify each child's real state rather than the last reported line: a caller's summary of
+"where it left off" is a report from the dead agent's context, not ground truth, and findings held
+only in that context (for example a preflight's specific blocking-defect list) are gone and must
+be regenerated by re-running the gate.
+
+Related: [[concurrent-prep-children-worktree-isolation]], [[prep-child-worktree-force-remove]],
+[[prepared-plan-crlf-hazard-at-execution]].

.claude/agent-memory/epic-planner/project_lane_a_gate_fidelity_epic.md

@@ -0,0 +1,35 @@
+---
+name: lane-a-gate-fidelity-epic
+description: The build-ci-coverage-gate-fidelity epic is Lane A / Flight 0 of the blocked parallel-bug run; it must land before the other 59 open bugs can be certified
+metadata:
+  type: project
+---
+
+Epic `build-ci-coverage-gate-fidelity` (planned 2026-08-10, integration branch
+`epic/build-ci-coverage-gate-fidelity-integration`) delivers Lane A of
+`docs/research/2026-08-10-parallel-bug-flighting-and-surface-blockers.md` as a conventional epic.
+
+**Why:** The `/parallel-plan` surface is hard-blocked (missing `compute_cohorts`, missing
+`config/blast-radius.json` — see the user-level memory `parallel-surface-not-ported-taskmaster`).
+§9 of that research document names `/epic-plan` on Lane A as the fallback available today. Lane A
+is Flight 0: it must run first and alone, because the repository's coverage gates measure an
+inflated denominator and the nullable gate cannot fail, so running any of the other 59 open bugs
+first would certify them against gates that cannot fail.
+
+**How to apply:**
+- Nine issues, five features, three waves. Wave 0: 441 (+478), 512 (+492, +509, +522), 394.
+  Wave 1: 457. Wave 2: 494.
+- **Issue 513 is excluded and cannot be fixed in TaskMaster.** `collect_pr_context`'s
+  classification step lives at `extensions/drm-copilot/src/lib/pr-context/collector-output.ts` in
+  the `drm-copilot` repository. File it upstream; do not re-investigate whether TaskMaster can
+  close it.
+- Nullable *debt* burn-down (~195-220 `CS86xx` in `UtilitiesCS.csproj`) is deliberately a
+  follow-on epic. Issue 492 separates "make the gate report truthfully" from "fix what it
+  reports"; only the first is in this epic.
+- Non-DAG coordination risk: feature 441 changes every coverage figure in the repository, which
+  invalidates the committed baselines that the 21 unmerged branches of the QuickFiler per-file
+  coverage epic (#136) gate on. No file conflict, but decide merge order before landing either
+  epic on `main`.
+
+Related: [[governance-doc-edits-need-execution-authorization]],
+[[preexisting-issues-skip-potential-to-issue]].