[Engineering] Convert the open PR backlog into dependency-aware merge trains and product verticals

[seonghobae]

Parent: #958
Baseline PR: #968
Machine-readable seed: docs/product-readiness/open-pr-queue.json
Human baseline: docs/product-technical-gap-baseline.md

Buyer and maintainer problem

The 2026-08-20 snapshot contains 83 open pull requests above protected develop@acdbea6344fe1231c39535b575f4de35e4c607c9. The queue contains valuable work, but it is not yet a reviewable product sequence:

• many feature heads depend on a canonical dependency/toolchain/coverage base;
• adjacent rehearsal PRs each add one cue or action without one active-player authority;
• current-head checks and approval cannot be transferred after restacking or predecessor changes;
• dependency, workflow, security, design, scientific, and buyer-facing work are interleaved;
• duplicate or superseded writers can remain open because closure would otherwise lose their unique test/requirement.

A high PR count is not product velocity. It increases review drift, stale evidence, conflicting ancestry, duplicate state, and the chance of merging locally correct slices that do not form a usable product.

Product outcome

Maintain one generated dependency/succession manifest and process the queue as bounded merge trains. Every live PR must appear exactly once and have one explicit disposition:

canonical_active
stacked_after
refresh_required
superseded_by
duplicate_of
invalid_or_out_of_scope
blocked_by_external_owner

The queue is reduced by merging coherent product verticals and closing superseded/duplicate work with evidence—not by bypassing checks or indiscriminately merging every head.

Initial live routing

The following classification was verified against the 83 live PRs returned during the investigation. It is an initial product-boundary routing, not a merge-readiness decision. Exact head SHA, checks, reviews, unresolved threads, diff overlap, and dependency edges must be refreshed before action.

T0 — dependency, toolchain, workflow, and quality base (30)

#754 #780 #783 #861 #867 #881 #894 #895 #896 #907 #918 #919 #920 #921 #922 #923 #924 #925 #926 #927 #928 #929 #930 #931 #932 #933 #936 #942 #944 #948

Canonical starting points currently include #783 for the JavaScript dependency-security baseline and #861 for Python branch-coverage evidence. CodeQL phase updates (#924, #930, #932, #933) must not land independently if doing so creates a mixed lifecycle.

T1 — local input, filesystem authority, resource admission, and cancellation (6)

#750 #811 #824 #858 #865 #866

#866 is the current canonical local-audio resource-policy slice. PDF, CLI, filesystem, timeout, and cancellation work must converge on shared limits and authority rather than separate constants.

T2 — scientific accuracy, MIR evaluation, and numerical parity (8)

#732 #746 #827 #828 #834 #873 #891 #892

These advance or support #770. #828 is a bounded known-stem/live-input slice, not by itself the complete multi-fixture product acceptance program.

T3 — rehearsal actions and active-player vertical (23)

#776 #845 #850 #874 #884 #900 #901 #903 #904 #905 #910 #912 #913 #914 #916 #934 #937 #939 #943 #946 #947 #955 #957

These must converge behind #961's single transport/action state machine. One cue per PR is acceptable only as an explicit stack; it must not create 23 permanent competing stores or callback contracts.

T4 — handoff and interoperability (2)

#737 #740

These own outbound/inbound handoff slices. They do not replace #962's durable project source of truth.

T5 — activation, UI system, Storybook, and accessibility (8)

#731 #744 #833 #849 #859 #897 #898 #899

#897 is the current executable Storybook/token slice. The train must reconcile code tokens, Figma file BP30foevuRtufwRpTknZUw, localization, first-run behavior, and shipped UI under #964/#965.

T6 — diagnostics, redaction, export security, and supportability (6)

#826 #941 #949 #950 #951 #956

Preserve each security regression while converging on #963's typed error/redaction/support-bundle contract.

T7 — commercial release

No current implementation PR in the 83-PR snapshot owns the complete #960 signed/notarized updater and rollback contract.

Required implementation

Generated queue manifest

Replace the initial read-only seed in #968 with an API-generated manifest containing, for every live PR:

• PR number, title, exact head SHA, base SHA, draft state, and last update time;
• owning train and canonical issue;
• predecessor/dependency PRs and overlapping writer set;
• current disposition and successor/predecessor reference;
• required checks and their exact-head status;
• review decision, last reviewed SHA, unresolved actionable thread count;
• decision timestamp, rationale, and responsible maintainer/agent.

The human table in docs/product-technical-gap-baseline.md must be generated from the same source or checked for exact parity.

Canonicalization rules

• One product/file boundary has one active canonical writer unless a stack order is declared.
• A leaf PR may not carry unrelated lockfile, toolchain, workflow, or dependency-baseline drift.
• After a squash merge or ancestry change, restack the successor and require fresh exact-head checks/review.
• Close a duplicate/superseded PR only after its unique tests, requirements, and findings are transferred.
• Post a succession comment linking the surviving issue/PR and retained evidence.
• Draft PRs state their missing exit criteria and are never represented as merge-ready.
• queued, pending, skipped-required, failed inherited-base, predecessor-head, protected-base, self/author, or administrative-bypass evidence is not passing.

Execution loop

refresh live queue
→ validate canonical predecessor
→ inspect current review threads and exact diff overlap
→ repair root cause
→ remove unrelated drift
→ run current-head checks
→ obtain qualifying independent approval
→ merge or enable auto-merge
→ restack the next PR
→ close superseded duplicates with succession evidence
→ refresh manifest and baseline

Waiting for GitHub-hosted checks or external review on one train is not a blocker to productive work on an independent train. It is not permission to introduce a second writer for the same boundary.

Acceptance criteria

• Every live PR appears exactly once in the generated manifest.
• The manifest rejects missing/duplicate PRs, cycles, unknown predecessors, stale head SHAs, and impossible dispositions.
• fix(security): establish canonical npm, PDF.js, Nanoid, and Undici baseline #783 is integrated or replaced by one explicit canonical successor; feature PRs do not carry conflicting dependency baselines.
• Every overlapping writer set has an ordered stack or one surviving canonical PR.
• Duplicate/superseded PRs close only after unique requirements/tests are transferred and succession evidence is posted.
• Each train yields a buyer-visible vertical or a necessary release-quality boundary, not an arbitrary list of diffs.
• Every merged exact head has terminal-success required checks, qualifying independent approval, zero unresolved actionable threads, and ordinary branch-protection acceptance.
• No repository workflow duplicates central maintenance policy without a documented repository-specific requirement.
• Open PR count and median age are reported as operational signals, not incentives for unsafe merge or closure.
• The BandScope 1.0 release has no unexplained open PR affecting its supported product surface.

Non-goals

• Do not force-push over concurrent agent work.
• Do not merge solely to reduce the count.
• Do not close a PR before preserving its unique requirement/test/evidence.
• Do not create another PR for every checkbox here; use coherent stacked slices.
• Do not bypass independent review, branch protection, or current-head checks.