Retrospective: PR #632 (template library rail label rebalance) repair-free merge review

[tvna]

PR overview

PR #632 (issue #631, refs #501) split the 4 template-library left-rail labels that had grown to >= 50 items (server-common 216, network-common 123, ai 114, middleware 88) into 14 smaller sub-50 labels via Library.tsx-only Set-membership filter predicates, with zero changes to templates.ts/types.ts/the taxonomy drift gate. Owner-requested (via chat, brainstorming dialogue) visibility improvement. Merged 2026-08-01T06:16:47Z by @tvna, 14 commits, +948/-15 across 4 files (web/src/components/Library.tsx, web/src/components/Library.test.tsx, docs/superpowers/specs/2026-08-01-template-library-rail-rebalance-design.md, docs/superpowers/plans/2026-08-01-template-library-rail-rebalance.md). Opened 05:57:59Z, merged 06:16:47Z (~19 minutes).

Repairs during implementation (before PR open)

Per this repo's established retrospective scope (repairs counted from PR-open to merge), these are noted but not counted below -- all fixed and re-reviewed before the branch's final push and PR open:

1. Task 4 (ai split) code-quality review found an Important finding: no test covered whole-RAIL-array id-uniqueness or group-heading contiguity across all 34 entries -- the existing tests only checked within-category slices, so a duplicate id or non-contiguous group split touching all/ops/facility would have shipped silently. Fixed by adding two structural tests (d815bfc), re-reviewed and confirmed via empirical mutation testing (temporarily duplicating an id / breaking group contiguity, confirming both new tests fail as expected, then reverting).
2. Task 3 code-quality review caught a Minor doc-accuracy error (the design doc's longest-label character count claimed 9 chars when two labels actually tie at 10) -- fixed (202afdc).
3. The final whole-diff holistic review (after all 4 tasks landed, before PR open) caught two more Minor findings, both fixed before push: (a) a pervasive arithmetic slip repeated across the design doc, plan doc, and issue Rebalance template library rail labels: split 4 oversized labels under 50 items #631 -- "13 new labels"/"22->34 rail entries" should have been "14 new labels"/"24->34" (3+5+3+3=14, not 13; the post-Consolidate Docker/Podman/K8s templates into server コンテナ #628 baseline was 24 entries, not 22 -- the 22 figure was accurate only for a stale pre-sync snapshot taken before this session fast-forwarded onto the latest develop); (b) a content-classification nuance -- network's sole 監視 (monitoring) subCategory member (snmp-device-monitoring) is generic SNMP device-health polling, not security monitoring, and was a weaker fit for network-common-security than its IDS・IPS/トラフィック分析/パケット解析 siblings; reclassified to the network-common-other residual bucket (edd16e2).

Repairs between PR open and merge

None. CI ran fully green on the first push (all ~34 check runs success/skipped/neutral, no failures), zero review comments or review threads appeared, and mergeable_state stayed clean throughout. The two comments that did appear (Vercel deployment-ready, Dependency Review clean) were both automated/informational, requiring no action. The PR was merged by the owner directly, ~19 minutes after opening.

Process finding: send_later requires approval not pre-granted in this session

While checking in on the open PR per the standing PR-activity-subscription instructions ("if the send_later tool is available, schedule a self check-in roughly an hour out"), the call failed: MCP error -32003: MCP tool call requires approval. This silently degrades the intended fallback -- webhooks are explicitly documented as not reliably delivering CI-success, new-push, or merge-conflict transitions, and the hourly self-check-in exists specifically to cover that gap. In this instance the PR merged quickly enough (~19 min) that the gap had no practical consequence, but a longer-lived PR in a session without this approval pre-granted would silently lose the fallback coverage with no signal that it happened, beyond an agent noticing the tool-call error in the moment (which this session did, and reported to the user rather than silently swallowing it).

• Classification: external/human decision that cannot be automated, at the tool-permission layer -- granting send_later approval is a per-session/per-account decision outside this repo's own gates. Not something a .pre-commit/CI change or a CLAUDE.md instruction can force through.
• Contributing agent-side factor (unclear agent instruction): nothing currently tells a future session that this approval may be absent, so each session re-discovers the block fresh mid-PR-watch rather than checking availability upfront and setting expectations with the user before relying on it. Cheap mitigation: when subscribing to a PR, attempt (or explicitly note the intent to attempt) a scheduling call early and surface the result to the user immediately, rather than only after a check-in is already due -- this session did report it, but only once already partway into the monitoring window.

Classification summary

• Repair Bump actions/setup-node from 1 to 4 #1 (missing whole-array structural test, pre-open): caught before PR open, gate shipped in the same commit that introduced the risk (d815bfc) -- a clean example of this repo's "ship the drift gate in the same change" principle in action.
• Repairs Bump actions/checkout from 1 to 4 #2-3 (doc/content accuracy, pre-open): caught before PR open by the holistic final review; not new systemic gaps, ordinary review-loop function.
• No repairs between PR open and merge -- clean, fast merge.
• New process finding (send_later approval gate): external/human-decision classification; recommend documenting the "may require pre-approval, verify early" caveat somewhere future PR-watching sessions will see it (e.g. this repo's own runbooks, or upstream in the harness's own guidance) rather than leaving it to be rediscovered per-session.

Refs #631, #501.