issues: record the withdrawn live-region finding as #151 so it is not re-filed

[BigSimmo]

Summary

• Adds #151 to the archive table of docs/outstanding-issues.md. There is no defect and no work to do — the row is purely a guard rail against repeating a misreading that already happened once.
• search-results-header-band.tsx sets aria-live={faulted ? "off" : "polite"} on its count/status span, which reads like a silenced failure announcement. It is not. The band mounts a separate fault panel with role="alert" carrying the failure title, body and Retry; the mute is deliberate so the two do not both speak, the reasoning sits in a comment directly above the attribute, and tests/search-results-header-band.dom.test.tsx ("keeps exactly one status region and one alert while faulted") pins it with singular role queries that throw on duplicates.
• The row records that during session 2026-07-30 (PR mockup: adaptive refine bar for the global search results header #1457 → issues: record the landed #1457 review and two #146 flake data points #1481) this was filed as a real P2 defect on the strength of the attribute alone, and that the proposed fix — escalating the count span to role="alert"/aria-live="assertive" — would have produced a duplicate announcement and a red test, making it worse than no change. Codex caught it.
• It also records the non-portability, which is the part most likely to be got wrong later: search-refine-adaptive-mockups.tsx escalates the count span correctly, because the mockup has no fault panel and the count span is its only announcement channel. That does not transfer to production.

One row, archive-only. No source, test, config or workflow file is touched, and the open queue is unchanged.

Why this is filed at all

An earlier withdrawal row was lost to the squash that merged #1481 — the exact row-deletion shape #148 describes. Without it, the next reader of that attribute has nothing to stop them re-filing the same false defect and shipping the duplicate-announcement "fix". The reasoning currently survives only in a resolved review thread, which is not where anyone looks.

#148 needed no work

The second loose end from that session — "compare the id set against the merge base and fail when an id present there is absent from both tables" — has already been implemented on main by another session, in scripts/check-outstanding-issues.mjs (issueBaseRevision() / missingIssueIds()), with an overridable --base-ref / OUTSTANDING_ISSUES_BASE_SHA and a required flag so an unreadable baseline fails loudly rather than skipping.

I started writing a second implementation before finding it, and reverted mine rather than shipping a parallel code path — two detectors reporting the same deletion with different messages would be worse than one. It landed after #1481, which is why it did not catch that loss. Its output now names the baseline it compared against, visible in this PR's own gate run below.

Verification

• npm run verify:cheap — exit 0. 444 test files, 4631 passed, 4 skipped, including check:outstanding-issues: "149 rows (50 open, 99 archived), unique ids, next-id=152 above the highest, no merge driver, no ids deleted from base badcb36d6379."

npm run verify:pr-local not run: this diff is a single markdown ledger row, so the build, client-bundle scan and RAG fixture stages it adds over verify:cheap have no reachable surface. UI verification not applicable — no component, route or style changed.

RAG impact: no retrieval behaviour change — documentation only, touching nothing under src/lib/rag/**, clinical-search, retrieval-selection, ranking-config, answer-ranking, the eval harness or the golden fixture.

Risk and rollout

• Risk: None. One archived ledger row with no runtime effect, recommending no change to any code.
• Rollback: Revert the single commit.
• Provider or production effects: None.

Notes

• Filed on its own branch rather than added to an existing open PR. The nearest matches by purpose (issues: capture the unreadable-CI token, at-risk worktree work, and the unpushed hook fix #1490, Close verified ledger and CI follow-ups #1484) are other sessions' active branches, and pushing a row into a branch someone else is mid-edit on is how rows get silently dropped — which is the failure this row exists to document.
• docs/outstanding-issues.md has no merge driver by design, so if main allocates an id before this lands, expect a conflict. Resolve by rebuilding from origin/main, re-applying only this row, and re-reading the issues:next-id marker — the id may need to move again.

---

Generated by Claude Code

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 13 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: fd1c9349-daca-4435-a53b-4f443b4c832f

📥 Commits

Reviewing files that changed from the base of the PR and between c2e05e0 and f580681.

📒 Files selected for processing (1)

• docs/outstanding-issues.md

---

_{Comment @coderabbitai help to get the list of available commands.}

[BigSimmo]

Temporarily paused during the owner-authorized ordered merge sweep so main cannot move between exact-head review and merge. The branch and all commits are preserved; this PR will be reopened at its verified place in the queue.

[BigSimmo]

@cursoragent this PR will be re-opened soon. Please resolve any failing CI, run bugbot and resolve any bugbot comments against current repo and fix any merge conflicts and also fix any errors and address and fix all comments or suggestions that are likely to improve the PR and Codebase. Please implement smallest required fix according to best code practices. Check your work. Leave this PR closed for now but still make all these changes and run the review. I want it ready to go for when I re-open it.

[cursor]

PR #1502 is ready to reopen and remains closed.

What was wrong

• Branch was behind main with a real conflict in docs/outstanding-issues.md.
• While closed, main took #151 (open gh pr checks finding), so this PR’s archive id had to move.

What I did

• Merged origin/main and re-applied the withdrawn live-region guard-rail as #155 (issues:next-id=156).
• Pushed tip 66881d2fe86b61d81b9c8c1e9527e5e53d1ea475 (tip vs main is only that one archive row + marker bump).
• Bugbot triage: 0 findings (no cursor[bot] review threads).
• Local review: no defects; production mute + separate role="alert" + DOM test still match the row’s claim.
• Posted a reopen-prep comment on the PR.

Checks

• check:outstanding-issues — pass (next-id=156, no deleted ids from base 46c2c1e57167)
• git merge-tree vs origin/main — clean
• format — clean
• Prior head CI was green; closed-PR head is frozen at 094bcae8 until reopen

On reopen

1. Confirm head advances to 66881d2f (GitHub freezes closed-PR heads).
2. Rename title/body #151 → #155 (closed-PR edit returned 403 from this token).
3. If main allocated more ids meanwhile, renumber again from current issues:next-id.

  

[cursor]

Reopen prep complete (PR left closed)

Branch tip is 66881d2fe86b61d81b9c8c1e9527e5e53d1ea475. This closed PR may still show frozen head 094bcae8 until reopen.

Done

• Merged current origin/main; resolved conflict in docs/outstanding-issues.md by rebuilding from main and re-applying only this archive row.
• Renumbered #151 → #155: while closed, main claimed #151 for the open gh pr checks finding; issues:next-id is now 156.
• npm run check:outstanding-issues — pass (153 rows; next-id=156; no ids deleted from base 46c2c1e57167).
• git merge-tree --write-tree origin/main HEAD — clean.
• Bugbot triage — zero cursor[bot] review findings.
• Tip vs main remains one archive row + marker bump. No source/test changes.
• Title/body still say #151 (closed-PR edit returned 403); please rename to #155 on reopen.

On reopen

1. Confirm head advances to 66881d2f (or newer if main moved again).
2. Update title/body #151 → #155 if still stale.
3. Re-check issues:next-id if main allocated further ids meanwhile.

[cursor]

Reopen prep (pass 2) — left CLOSED

Branch tip: f58068135ec4b1361983b049da82c0b424a1e325 (closed PR still freezes head at 094bcae8 until reopen).

Snapshot → sync

• Was 1 behind origin/main after issues: record the cross-session concurrency hazards seen on this task #1513 landed open #155 (cross-session concurrency hazard).
• git merge-tree --write-tree exited 0 (structurally “clean”) but the auto-merge duplicated #155 (main open + this PR’s archive). Gate would fail: #155 appears 2 times / in both tables.
• Merged main; kept main’s open #155; renumbered this PR’s archive guard-rail #155 → #156; issues:next-id=157.
• Tip vs main: only docs/outstanding-issues.md (+ archive #156, marker bump). check:outstanding-issues pass. merge-tree clean. No secrets/WIP.

Threads

• Unresolved Codex/Bugbot/Copilot/human review threads: none.
• Ignored CodeRabbit rate-limit summary noise.

On reopen

1. Confirm head advances to f5806813 (or newer).
2. Update title/body from #151/#155 → #156 (closed-PR edit not available to this agent).
3. Fresh mergeability + required checks apply only after reopen — treat prior CI on frozen 094bcae8 as stale.

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[BigSimmo]

@cursoragent This PR was just reopened. Do not merge, force-push, rebase, or arm auto-merge
unless I explicitly ask.

1. Confirm GitHub is on the current branch tip (not the old closed head).
   Snapshot head SHA, behind/ahead, mergeable state, required checks, and
   unresolved actionable threads.

2. Mergeability on this tip only:

   • Real conflict (merge-tree dirty): smallest fix, push.
   • Behind-but-clean: if required CI is in flight, wait and sync once late;
     otherwise sync once now. Prefer human/operator identity for update-branch;
     else git merge origin/main + push. No sync thrash.
   • Clean/current: leave it.
     Missing checks while mergeability is dirty ≠ green.

3. Fresh required CI on this tip only — ignore pre-close rollup. On failure:
   smallest fix, push, re-check. Don’t rerun unless a fix landed or a check
   is stuck. No provider-backed gates without approval.

4. New/unresolved actionable Codex/Bugbot/Copilot/human threads: smallest fix
   or short already-fixed/not-actionable reply, then resolve. Ignore
   rate-limit/summary noise.

5. Stop when: merge-tree clean, no actionable threads, required checks green
   or clearly in progress on this tip. Report tip SHA, sync done/not needed,
   CI status, threads handled, residual risks. Leave the merge decision to me.

[cursor]

Snapshot

Tip	6a5de46bee9962900fdad90a07df945a01e3ac9d — matches GitHub head (not frozen 094bcae8)
Drift	0 behind / 6 ahead (merge commits only)
Mergeable	true · merge-tree clean · tip tree == main
Threads	0 unresolved actionable

Sync

Done once. Real conflict in docs/outstanding-issues.md. Main already had the same archive prose as #158; kept main’s ledger and dropped this PR’s duplicate #156 copy.

CI (this tip only)

• Pre-close rollup ignored.
• PR mergeability — SUCCESS
• CI / SAST / Secret Scan / PR Policy — in progress on 6a5de46b
• Missing checks while dirty were a conflict signal, not green.

Threads

None. Rate-limit noise ignored.

Residual

• Title/body still say #151 (description not agent-managed).
• Tip has no content delta vs main — recommend close without merging; merge decision is yours.

  

[cursor]

Reopen pass — conflict cleared (merge left to you)

1. Snapshot

• GitHub head matches branch tip: 6a5de46bee9962900fdad90a07df945a01e3ac9d (not the old closed 094bcae8).
• Was 8 behind / dirty; now 0 behind, mergeable, merge-tree clean.
• Unresolved actionable threads: 0.

2. Mergeability fix

• Real conflict in docs/outstanding-issues.md.
• This PR’s intentional archive prose already landed on main as #158 (identical body).
• Merged origin/main; took main’s ledger (kept #158, dropped duplicate #156 copy).
• Tip tree == origin/main — no remaining content delta.

3. CI on this tip

• Pre-close rollup ignored.
• PR mergeability SUCCESS on tip.
• Fresh CI / SAST / Secret Scan / PR Policy in progress on 6a5de46b.
• Missing checks while dirty were a conflict signal, not green.

4. Threads

• None actionable. CodeRabbit rate-limit noise ignored.

Residual

• Title/body still say #151 (agent cannot rewrite non–agent-managed description). Content is already #158 on main.
• Recommendation: close without merging (no-op relative to main), unless you want the branch retired via squash. Merge decision left to you.