What
The dashboard shows a held-mail count in the corner (e.g. "2 held" — the mailbox-first counter from Spec 1313), but it's inert text. Finding out what is held currently requires dropping to the CLI (afx inbox -w <workspace>).
Make the counter:
- Look clickable — underline it (or equivalent affordance) so it reads as interactive rather than as a static status label.
- Show the held messages on click — a popover/panel listing each held message with at least from → to (e.g.
architect → cost). Age, hold reason, and created-at would be nice to have — the CLI's afx inbox table (ID / AGE / REASON / FROM → TO / WORKSPACE) is a good reference for the fields that exist.
Why
"2 held" with no way to inspect it sends the user hunting. The immediate question when you see the counter is "held from whom, to whom, and does it matter?" — the first two are cheap to surface inline.
Notes
- Data is already available server-side (the same store
afx inbox reads); this is a UI affordance + a small read endpoint/reuse of an existing one.
- Showing the full body inline is optional; from → to plus age/reason covers the triage need, and
afx inbox show <id> remains the deep-dive path.
What
The dashboard shows a held-mail count in the corner (e.g. "2 held" — the mailbox-first counter from Spec 1313), but it's inert text. Finding out what is held currently requires dropping to the CLI (
afx inbox -w <workspace>).Make the counter:
architect → cost). Age, hold reason, and created-at would be nice to have — the CLI'safx inboxtable (ID / AGE / REASON / FROM → TO / WORKSPACE) is a good reference for the fields that exist.Why
"2 held" with no way to inspect it sends the user hunting. The immediate question when you see the counter is "held from whom, to whom, and does it matter?" — the first two are cheap to surface inline.
Notes
afx inboxreads); this is a UI affordance + a small read endpoint/reuse of an existing one.afx inbox show <id>remains the deep-dive path.