[Frontend][UX] Review view is overwhelming, gives weak decision feedback, and the All/Mine filter is confusing

[Chris0Jeky]

Source: maintainer dogfooding session 2026-08-22 (voice-captured walkthrough of a fresh/demo account). The build under test was not pinned — re-verify each symptom against current main before implementing; some items may already be partially addressed by the closed live-repro wave (#1764–#1769) and #1818.

Observed

1. The Review view fills the whole page with everything about the captured proposals at once — overwhelming for a new user. The maintainer asks for progressive disclosure: present the queue "in waves"/prompts, guiding verification step by step rather than one dense wall of information.
2. The "All / Mine" filter at the top of the queue is confusing — unclear what it partitions on a single-user/demo account.
3. After deciding on an item, it just vanishes from view with minimal feedback — the user does not understand what happened or where the item went.

Acceptance criteria

• Decision produces clear feedback: what was decided, where the item went, and an undo/where-to-find-it pointer.
• Progressive-disclosure design pass on the review surface (could be a focused one-proposal-at-a-time mode).
• All/Mine filter hidden on single-user accounts or explained inline.
• Relates: REVIVAL-11: Risk-tiered review prioritization + explicit batch-confirm + model-derived confidence #1307 (risk-tiered review prioritization).

[Chris0Jeky]

VERIFIED — 2026-08-22 (v0.7.2 at 127.0.0.1:5000)

Reviewed a real proposal end to end. The density complaint is well-founded: a single proposal fills the viewport with, simultaneously —

• queue rail (All / Mine / Stale filter, risk-order explainer, "File away 1 settled", Recently Applied, This Week)
• proposal title + restated body
• decision row (Reject / Request edit / Defer / Approve) + keyboard hints
• confidence dial .96 with a four-row breakdown (Pattern match / Reach / Operation safety / Recency) and "Above your apply threshold (set 0.70 · Settings)"
• Author + "Why now" + Tune heuristics + Similar past decisions
• § I The change — Before/After panes + PER-FIELD CHANGES
• § II Provenance — Summary / Operation 1, with model confidences
• DECIDE WITH KEYS legend (6 bindings)

Every element is individually justified; the aggregate is a wall. This is the "in waves" request.

All / Mine filter — confirmed confusing

Rendered on a single-user Solo Workspace, where "Mine" and "All" are necessarily identical. Clicking "Mine" on the empty queue shows "Nothing in this filter." — a distinction with no difference for this user.

Decision feedback — better than reported, one real gap

After deciding, the queue does update honestly: QUEUE · 0 AWAITING · 0 STALE, a genuinely nice empty state ("Nothing waiting. Good." / "When the assistant has something to propose it will appear here for review."), and the item moves to Recently Applied with a relative timestamp. Toast confirms "Proposal applied to board".

The gap is that the decided item vanishes from the main column instantly while the confirmation lives in a peripheral rail and a transient toast — so the eye, which was on the centre, sees only disappearance. That matches "it removed it and cleared the view, but I didn't get enough feedback."

Acceptance criteria (revised)

• Progressive disclosure: collapse Provenance / confidence breakdown / similar-decisions behind expanders by default; keep title, the change, and the decision row primary. Consider a focused one-proposal-at-a-time mode.
• On decision, render the outcome where the user was looking — an inline confirmation in the main column before the item clears, not only rail + toast.
• Hide All/Mine when the workspace has one member; or label what it partitions.
• Tests: spec asserting default-collapsed sections stay collapsed on first render (the failure mode is a future change quietly defaulting one open again), and a spec asserting post-decision confirmation is rendered in the primary column.