Surface follow-ups from peer review in PR body Follow-ups block (do not lose at merge)

Context

[2026-05-05 RESHAPE — operator challenge: PR-body text refs are post-merge-invisible.]

Original framing of this ticket assumed PR-body Follow-ups block as the durable surface. @tobiu sharply caught the anti-pattern: "once a PR gets closed, will anyone ever look at PR body hints for new tickets?" PR bodies become invisible after merge; follow-up tickets surfaced only in PR-body text get buried.

The actual gap is post-merge discoverability via native graph relationships. A PR-body Follow-ups block can still serve as a pre-merge operator-visibility surface (helps the merger see follow-ups before merge), but the durable substrate is filed tickets + native parent_child / blocked_by relationships via update_issue_relationship.

Empirical anchor: I filed 10 follow-up tickets earlier in the same session (2026-05-05); audit revealed 9 of 10 had NO parent_child link. Only the retroactive #10774 had a parent. Post-merge those 9 tickets would have orphaned in the backlog without graph-discoverability, even though I'd named them in PR-body text. @tobiu's challenge produced the audit.

The Problem (revised)

pr-review-guide §9 Strategic-Fit Step-Back enumerates verdicts including Approve+Follow-Up, but pull-request-workflow doesn't have a corresponding Pre-Flight that requires authors to:

1. File the follow-ups as actual tickets (not just text references)
2. Link them via update_issue_relationship to a discoverable parent (epic OR close-target OR sibling-ticket-anchor)
3. (optionally surface in PR body for pre-merge operator-visibility)

Without #1 + #2, follow-ups orphan post-merge. The PR-body block (#3) is a surface but not the durable substrate.

The Fix (revised)

Add to pull-request-workflow.md a new Pre-Flight section: "Post-Review Follow-up Surfacing". Triggers when a reviewer's verdict is Approve+Follow-Up (or any verdict with explicit follow-up items in the [KB_GAP] / [TOOLING_GAP] / [RETROSPECTIVE] tags). The author MUST:

1. File each follow-up as an actual ticket via create_issue with full Fat Ticket Body Structure
2. Link each filed ticket to a discoverable parent via update_issue_relationship — typically the close-target's parent epic, or a sibling-anchor-ticket from the review's substrate
3. (Optionally) add a ## Follow-ups block to the PR body LISTING the filed tickets — this serves as PRE-MERGE operator-visibility but is NOT the durable substrate. Block at TOP for at-a-glance merge-time visibility.

The order matters: file-and-link FIRST (durable substrate), surface-in-PR-body OPTIONALLY (pre-merge surface). The PR body block alone, without filed-and-linked tickets, is the anti-pattern this Pre-Flight prevents.

Contract Ledger

Existing Enforcement Sufficiency Audit

Conclusion: existing enforcement is insufficient. The minimal positive-ROI substrate change is to add a narrow author-side pre-flight plus reviewer-side cross-reference, not a new global rule or CI gate.

Acceptance Criteria

• (AC1) pull-request-workflow.md adds "Post-Review Follow-up Surfacing" Pre-Flight section
• (AC2) Pre-Flight requires PR author to file each follow-up as actual ticket + link via update_issue_relationship BEFORE merge (mechanical-or-discipline check)
• (AC3) PR body Follow-ups block (if added) lists ticket numbers + lines, serving as PRE-MERGE operator-visibility — NOT the durable substrate
• (AC4) pr-review-guide §9 cross-references the new Pre-Flight — reviewer who lands Approve+Follow-Up knows the author has a file-and-link obligation
• (AC5) Anti-pattern table entry: "PR body lists follow-ups in text but no actual tickets are filed or linked via graph relationships — orphans post-merge"
• (AC6) Memory-anchor cross-reference: feedback_post_merge_discoverability_via_graph.md (filing alongside this ticket)

Out of Scope

• Mechanical hook that grep-blocks gh pr merge if follow-ups aren't filed-and-linked — file as scope-extension if discipline alone insufficient
• Auto-creating follow-up tickets from review-comment text — heavier scope; author still owns ticket-creation discipline
• Native GitHub feature requests (e.g. Action-required check for unfiled follow-ups) — out of repo scope

Avoided Traps

• Conflating PR-body text refs with durable substrate: PR bodies are post-merge-invisible. Native graph relationships (parent_child / blocked_by) are the durable surface. The original framing of this ticket conflated the two; reshape addresses it.
• Auto-filing tickets without intake-discipline: the author still runs full ticket-create §1a Content Sweep + Five-Stage Challenge Chain on each follow-up, not auto-spawning from review-comment text.
• Forgetting to link as parent_child: even with tickets filed, missing update_issue_relationship is the same orphan-pattern. Both file AND link required.

Related

• Empirical anchor: session 2026-05-05 — audit revealed 9 of 10 follow-up tickets I filed today had no parent_child link until @tobiu surfaced the discoverability gap
• Sibling substrate: #10164 (cross-PR collision Pre-Flight), #10755 (Resolves keyword Pre-Flight), #10775 (evaluation metrics Pre-Flight)
• Parent epic: #10757 (cycle-2 cognitive-load — substrate-improvement family)
• Reference: pr-review-guide §9 Strategic-Fit Step-Back

Origin Session ID: 23b9cbcd-4938-4a46-b21a-0d48dd12e7e7

Retrieval Hint: query_raw_memories(query="approve+follow-up native graph relationships post-merge discoverability parent_child filed tickets vs PR body text")