[Frontend][Review] Degraded-queue follow-ups: decision rail sticky is inert, recovery sentence retired by explicit loads

[Chris0Jeky]

Follow-up to PR #2630 (#2214 degraded-queue disclosure), from the read-only verification pass on its round-2 fixes. Neither item blocks that merge; both are tracked here for the smallest follow-up PR.

1. The decision rail's sticky positioning is scoped to a container that never scrolls, so the "rail below the pinned warning" handshake is inert and its comments assert a browser fact that appears false. ReviewDecisionRail renders inside ReviewMain.vue's .paper-review-main, which is overflow: auto with auto height (ReviewMain.vue ~397-401). overflow: auto makes that element the rail's nearest scrollport even though it never overflows (the surrounding .paper-review-deep__main-col is the element that scrolls), so .paper-review-decision { position: sticky; top: var(--paper-review-sticky-offset, 0) } stays at its flow position. Consequences: the round-1 review premise that the rail covered the pinned warning, and the round-2 remedy (a ResizeObserver in PaperReviewView.vue ~1206-1237 writing --paper-review-sticky-offset on the main column, consumed by ReviewDecisionRail.vue ~305-311), target a rail that does not pin; the comments at PaperReviewView.vue ~1195-1200 and ~3027-3032 and ReviewDecisionRail.vue ~305-311 describe a two-sticky band that does not exist; the spec at PaperReviewView.spec.ts ~3392-3394 frames the property as true but unreachable. The pinned warning itself is a direct child of the scrolling column and does stick. This is a CSS reading, not a browser observation; confirm first in a real browser (DevTools shows the sticky badge and its scroll container), then either make the rail's sticky real (its intended scroller is the main column; check why .paper-review-main carries overflow: auto before changing it) or remove the offset machinery and rewrite the comments to say the rail is in flow.

2. The recovery sentence is retired on any successful load, so an explicit load within a poll interval of a recovery can blank the live region before it is announced. useReviewProposals.ts ~651-667 retires queueRefreshRecovered on the next recordQueueRefreshSuccess where queueRefreshStale is already false; explicit loads take the same path (loadProposalsWithOutcome ~588), and they are common right after a recovery: post-decision reloads in useReviewActions.ts (~563, ~591), the batch composables, the board-filter watcher, dismissSettledElsewhereNotice, the pre-decision refresh barrier. Scenario: the poll recovers and sets the text; the reviewer's already-clicked Approve completes ~150 ms later and its reload empties the region; a polite live region whose text is reverted within a few hundred milliseconds may never be spoken. Fix: retire only on a background poll success (not on explicit loads), or track a recovered-at tick and retire on the next poll after it; add the poll-recovery-then-explicit-load spec.

3. Coverage note. The ResizeObserver seam (PaperReviewView.vue ~1206-1237 and the unmount disconnect) has no spec beyond the presence of the custom property; if item 1 keeps it, cover the watch, the observe call and the disconnect.

Refs #2214, PR #2630, PR #2388.

[Chris0Jeky]

[Claude lane claim v2]
lane: alpha-product-trust (session taskdeck-alpha-85, Taskdeck-Alpha checkout)
issue: #2638
base: origin/main at claim time (a789dab or later; PaperReviewView.vue and the review composable are free, the lane's #2694 and #2697 merged)
residual acceptance: items 1 and 3, one PR on the Paper review layout; item 2 (the recovery sentence retired by an explicit load) is a separate composable slice claimed after. Item 1: the decision rail's sticky positioning is inert because ReviewMain.vue's .paper-review-main is overflow: auto (unchanged since PAPER-06, 82f4898, 2026-04-25) and so becomes the rail's nearest scrollport although it never overflows, while the element that scrolls is PaperReviewView.vue's .paper-review-deep__main-col (overflow: auto); the #2630 handshake (a ResizeObserver writing --paper-review-sticky-offset on the main column, consumed by ReviewDecisionRail.vue's top) therefore targets a rail that does not pin, and the comments in both files plus the spec at PaperReviewView.spec.ts ~3392 describe a two-sticky band that does not exist. Fix direction: make the property true rather than delete the intent: remove the scrollport from .paper-review-main (drop its overflow: auto, keeping padding and min-height, or replace it with overflow: visible, after checking what that rule protected in April: narrow-width wrapping, long code blocks, the diff pane's own scroll) so the main column is the rail's scrollport and the rail pins below the sticky warning; prove it in a real browser with a Playwright leg (the rail's bounding top equals the warning's bounding bottom after scrolling the main column, at desktop width; at 375 px the responsive spec stays green), keep the ResizeObserver seam and, per item 3, cover it in the mounted spec (the watch, the observe call, the disconnect on unmount), and rewrite the comments and the spec framing to state what is now true. If the browser check shows the rule cannot be removed without a regression the lane cannot fix in the same files, fall back to the honest alternative: delete the inert handshake and the false comments, and record the layout constraint on the issue. Item 2 stays open on this issue for the next slice.
owned paths/modules: frontend/taskdeck-web/src/views/paper/review/ReviewMain.vue (the overflow rule only); src/views/paper/PaperReviewView.vue (the sticky-offset seam, its comments, the main-column style); src/views/paper/review/ReviewDecisionRail.vue (the sticky rule and its comment); src/tests/views/paper/review/PaperReviewView.spec.ts; tests/e2e/review-proposals.spec.ts or a new tests/e2e/review-sticky.spec.ts for the browser leg; tests/e2e/paper-responsive.spec.ts read only. NOT owned: useReviewProposals.ts (item 2), the receipt recorders, the poll disclosures, the diff pane, the review locales
shared-path leases: none; no open PR touches these files (checked gh pr list files at claim time); the #1940 loading-identity and settled-state residuals also need PaperReviewView.vue and are sequenced after this PR
parallel-safe work: #1871's PR #2700 (inbox composer) is disjoint
open PRs/branches/review threads checked: both claim forms on #2638 (none; the issue was filed by the lane from PR #2630's verification on 2026-09-05); PRs #2630, #2694, #2697 merged
human or decision gates: none
status: active (worktree codex-2638-sticky-rail at a789dab)

[Chris0Jeky]

[Claude lane release v2]
lane: alpha-product-trust (session taskdeck-alpha-85)
issue: #2638 items 1 and 3
PR: none; parked before implementation on a measured design hole (worktree codex-2638-sticky-rail removed with no commits)
measurement (Chromium 1280x720, the real stack, a seeded proposal on /workspace/review, the real degraded warning raised by answering the proposals GET with 503 for three polls): nothing between the decision rail and the document scrolls. The document is the scrollport (documentElement clientHeight 720, scrollHeight 3166); .paper-review-deep__main-col, .paper-review-main and the shell's .td-content each have scrollHeight equal to clientHeight because .td-shell is min-height 100vh and grows with content. Resting: rail top 528, warning top 76, the column carrying --paper-review-sticky-offset: 37px (the ResizeObserver seam works). After window.scrollTo(0, 788): rail top -260, warning top -712. Both move 1:1 with the page and leave the viewport. So item 1 is confirmed and extended: the #2214/#2630 "pinned" warning does not pin either; its position: sticky is captured by the main column's overflow: auto, which never scrolls. Controlled variants on the same page: making .paper-review-main overflow visible (the issue's fix) has zero effect; only when .paper-review-main, .paper-review-deep__main-col AND the shell's .td-content all stop being scroll containers does the rail pin (rail top 0 under the warning). .td-content's overflow-y: auto lives in AppShell.vue on every route in both themes, outside this slice.
why parked: the acceptance's fallback ("delete the inert rail handshake, keep the warning sticky") would leave an equally false claim standing, since the warning is not sticky in effect either; the choice between the real options is a layout decision wider than this issue.
options, measured not implemented: (1) shell fix: make .td-content the bounded scroller (.td-shell height 100vh with a min-height: 0 chain) and drop the two review-side overflow: auto rules; largest blast radius (every route, both themes, the responsive and E2E suites), fixes every sticky in the app; (2) bound the review grid inside PaperReviewView.vue with a definite height so its columns scroll internally (about 616 px at a 720 px viewport: topbar 48 plus 56 of content padding), magic numbers and three independent scrollers instead of one page scroll; (3) honest-comments-only: delete the offset machinery and the warning's pinned rule and record the constraint, retiring the #2214/#2630 sticky behaviour as shipped-in-name-only.
recommendation: option 1 as its own slice with a browser-proven Playwright leg across the routes the responsive suite covers, decided by the maintainer because it changes the scroll model of the whole shell; until then the thirteenth block's #2630 sticky sentences are corrected in the next STATUS block as rules with no effect, and the offset seam stays (harmless, spec-covered by item 3 when the slice lands).
artifacts kept outside the repo (scratchpad worker-2638): review-sticky.spec.ts (the two-leg browser spec asserting the fixed property, red today, with the 503-route recipe raising the real degraded warning in about 55 s), tmp-2638-probe.spec.ts, probe1-3.txt.
still open on #2638: items 1 and 3 behind the layout decision; item 2 (the recovery sentence retired by an explicit load) unaffected and claimable separately.
CLAUDE_SYNC_PACKET: lane=alpha-product-trust; issue=#2638; pr=none; merge=none; decision=layout scroll model (proposed D-15 in OUTSTANDING_TASKS.md, filed with the next block PR); status=Blocked

[Chris0Jeky]

[Claude lane claim v2]
lane: alpha-product-trust (session taskdeck-alpha-85, Taskdeck-Alpha checkout)
issue: #2638 item 2
base: origin/main at claim time (a789dab or later; items 1 and 3 are parked on the D-15 layout decision and are not touched)
residual acceptance: item 2 of the issue: the #2630 recovery sentence (queueRefreshRecovered, "This review queue is up to date again. Showing current proposals.") is retired on the next recordQueueRefreshSuccess where the queue is no longer stale, and explicit loads take the same path (loadProposalsWithOutcome), which are common right after a recovery (post-decision reloads in useReviewActions, the batch composables, the board-filter watcher, dismissSettledElsewhereNotice, the pre-decision refresh barrier), so a polite live region whose text is reverted within a few hundred milliseconds may never be spoken. Fix: retire the recovery sentence only on a later background poll success (track the poll tick or the read kind that raised it and retire on the next background success after it), never on an explicit load; the #2694 list-scoped retraction of a refusal keeps raising it once through recoveryAlreadyRaised; the degraded onset still retires it (the #2694 verification pinned that). Also the copy-only follow-up recorded on #2214 from PR #2694 if it fits in the same composable and catalog change: a distinct sentence for the refusal retraction (review.queue.refused.recovered or similar) that says the refresh is being accepted again and nothing about the queue's contents, so the list-success/pin-fail tick no longer overclaims "Showing current proposals" for up to two intervals; keys in en, it and es; both skins already render the sentence through one hoisted live region each, so the view change is at most the key. Specs, red-first, in useReviewProposals.spec.ts: poll recovery then an explicit load within the interval leaves the sentence standing; the next background success retires it; the degraded onset retires it; the refusal retraction raises the refusal-specific sentence and the composite success does not swap it for the queue sentence; catalog parity for the new key.
owned paths/modules: frontend/taskdeck-web/src/composables/useReviewProposals.ts; src/locales/{en,it,es}/review.ts (review.queue.* only); src/tests/composables/useReviewProposals.spec.ts; src/views/paper/PaperReviewView.vue and src/views/LegacyReviewView.vue only if the hoisted region must read a second key (say so). NOT owned: the sticky layout (items 1 and 3, D-15), the receipt recorders, the diff pane, the Inbox files
shared-path leases: none; no open PR touches the composable, the review views or the review locales (checked gh pr list files at claim time); #1940's two residuals also need PaperReviewView.vue and are sequenced after this PR if it touches the view
parallel-safe work: #1871's PR #2700 (inbox composer) is disjoint
open PRs/branches/review threads checked: both claim forms on #2638 (the lane's items-1-and-3 claim of ~18:05Z parked at ~18:20Z with its disposition; nothing else); PRs #2630, #2694 merged
human or decision gates: none for item 2; items 1 and 3 wait on D-15
status: active (worktree codex-2638-recovery-retire at a789dab)