[Frontend][Inbox] A dropped scope-replacement response latches isScopeReplacement with no retry affordance (from PR #2584 review)

[Chris0Jeky]

Non-blocking residual from the fresh-context review of PR #2584 (closes #2501, Paper Inbox scope-replacement truth), tracked here rather than fix-cycled. References are at that PR's round-1 head c3258be.

LOW, latched replacement state with no retry affordance. After #2584, useInboxOrchestrator clears isScopeReplacement only when captureStore.fetchItems reports that it applied the response (~379-381). When the response is dropped (superseded request id) nothing clears the flag and nothing re-triggers a load. If the superseding request then succeeds (listError null, loadingList false), PaperTriageTable falls through every branch: the count span is hidden (!scopeReplacement), the Loading block needs loadingList, the empty state needs !hasItems, and the list renders hidden, so the user sees an empty table body under the count-free eyebrow with no Retry until they re-navigate or capture something.

Reachability today: the only production fetchItems caller other than the orchestrator is captureStore.batchTriage's unscoped post-POST refresh, reachable only through batchAction, which only LegacyInboxView destructures, and Legacy never renders isScopeReplacement; so it needs a Paper-theme toggle mid-batch to be seen. It becomes directly reachable the moment Paper gains a batch action or any second fetchItems call site.

Fix direction: when a scope-replacement load resolves as not applied, either re-issue the load for the current scope or clear the flag once a later applied load for the same scope lands; add a deferred-promise spec for the dropped-then-succeeded ordering.

Refs #2501, #2022, #2570, PR #2584.

[Chris0Jeky]

[Claude lane claim v2]
lane: alpha-product-trust (session taskdeck-alpha-85, Taskdeck-Alpha checkout)
issue: #2591
base: origin/main at claim time (e050846 or later)
residual acceptance: the LOW from PR #2584's review, one PR: after a scope-replacement load whose response is dropped (superseded request id, so captureStore.fetchItems reports it did not apply), nothing clears isScopeReplacement and nothing re-triggers a load, so if the superseding request then succeeds the Paper triage table falls through every branch (count span hidden, no Loading block, no empty state, list hidden) and the user sees an empty table body under a count-free eyebrow with no Retry until they re-navigate or capture. Fix in useInboxOrchestrator: when the replacement load resolves as not applied, clear the flag as soon as a later applied load for the same scope lands (the superseding request is that load) and, if no later load is pending for the current scope, re-issue the load once for the current scope; never leave the flag latched with no load in flight. Red-first deferred-promise spec for the dropped-then-succeeded ordering (two loads, the first resolving not-applied after the second was issued, the second applying: the flag clears and the table state is coherent), plus the no-pending-load case (a dropped replacement with nothing in flight re-issues once, and a second drop does not loop). Reachability today needs a Paper-theme toggle mid-batch (only Legacy's batchTriage calls fetchItems outside the orchestrator); the fix is the guard for the day Paper gains a batch action.
owned paths/modules: frontend/taskdeck-web/src/composables/useInboxOrchestrator.ts; src/tests/composables/useInboxOrchestrator.spec.ts (or the orchestrator's spec file by its real name); src/components/paper/inbox/PaperTriageTable.vue only if a read-only prop must change (say so). NOT owned: src/store/captureStore.ts (the applied/not-applied contract from #2584 stays), LegacyInboxView.vue, the capture API, the Inbox draft seam (#2698)
shared-path leases: none; no open PR touches the orchestrator, the triage table or the capture store (checked gh pr list files at claim time)
parallel-safe work: #2599's PR #2712 (Review queue) is disjoint
open PRs/branches/review threads checked: both claim forms on #2591 (none; filed from PR #2584's review on 2026-09-04); PRs #2584, #2580, #2698 merged
human or decision gates: none
status: active (worktree codex-2591-scope-latch, being created)

[Chris0Jeky]

[Claude lane park v2]
lane: alpha-product-trust (session taskdeck-alpha-85, ending 2026-09-05 ~21:50Z)
issue: #2591
PR: #2713 open, ready for review, head e3adaab (fresh-context review owed, see the PR checkpoint; CI in progress)
remaining: one fresh-context review, CI green, three-minute age, then a merge commit; the InboxView.spec.ts stale fetchItems mock is a follow-up candidate named in the PR
claim: released to the ready PR; the worktree is removed and the branch is on origin

[Chris0Jeky]

Residuals recorded from PR #2713's review (tracked here, not blocking that merge): (1) the inbox-load perf measure is clobbered by the repair's own start(), so it reports only the repair leg and under-reports the two-request case; (2) openItemFromHash() runs twice for one repaired load (a second peekDetail GET on the board-scoped path); (3) the repair can still fire after a concurrent load already cleared the latch, and after unmount (one bounded read); (4) the "changed scope" spec is decided by the request-id guard alone, so the scope-key guard and a plain-load drop under a latch for another scope are untested, and no spec renders PaperTriageTable for the repair or second-drop terminal states; (5) the second-drop clear is safe only while the orchestrator is Paper's sole fetchItems caller: a Paper batch surface must clear only on an applied read (the round-2 comment on the PR records this).

[Chris0Jeky]

Coordinator note (2026-09-05): PR #2713's fresh-context review recorded two LOWs for this issue beyond the dropped-response latch it fixes. (1) The failure path can still reach the hidden-rows, no-count, no-Retry state: a batch poll success clears listError (captureStore.ts around line 894) without touching isScopeReplacement, so a replacement load that threw while a poll was running loses its Retry on the next successful tick. Pre-existing on main. (2) The repair is issued only after await openItemFromHash(), so the broken state stays visible for a detail round-trip, a transient hash failure fires a duplicate peekDetail GET, and a rejection there would skip the repair; issuing the repair before the hash step or wrapping it would close both.

[Chris0Jeky]

Coordinator note (2026-09-05): PR #2713 merged as 9b864ea (head 032fa4f). A dropped Paper Inbox scope-replacement response now issues one repair read for the current scope instead of latching isScopeReplacement; a second drop clears the flag and lets the table state what it has. Two fresh-context reviews (the alpha lane's, SHIP with a MEDIUM comment-truth item, and the coordinator's after the lane's session ended, FIX-FIRST on a stale fetchItems mock in InboxView.spec.ts); both fixed in-PR (the comment now states that the second-drop clear is safe only while the orchestrator is the sole Paper-side fetchItems caller; the mock resolves true). Remaining here: the failure-path shape and the repair-after-hash-await ordering recorded above, plus the reviewers' LOWs (the inbox-load perf measure reports only the repair leg; openItemFromHash runs twice for one repaired load; the changed-scope spec is decided by the request-id guard alone).