vscode: idle-state action queue — surface small grooming / curation tasks when the triage queue is empty

[amrmelsayed]

Exploratory issue — purpose and shape are still open. This issue's job is to frame the problem and the design questions so the plan-approval gate can pin the answers. Action-oriented by design; passive content surfaces are out of scope (see What this isn't).

Depends on #800 (focus mode) shipping first — see Why #800 is a prerequisite below.

Problem — the interstitial state

Codev's workflow has a natural rhythm: spawn builders, wait, triage gates as they fire, repeat. The waiting part — when no builder is at a gate, no PR needs review, no message awaits a reply — is a real interstitial state that today is dead time. The engineer either context-switches out (loses momentum, returns slow), refreshes the sidebar (no signal arrives), or starts something off-Codev (compounding the context cost when a gate eventually does fire).

#800's focus mode handles the busy side of the queue (5+ builders blocked, serve them one at a time). This issue handles the inverse state — queue empty, what do you do.

The instinct to fill that gap with curated reading (rotating lessons, recent reviews, arch snippets) is real but passive surfaces tend to get ignored. The proposal here is action-oriented: small concrete tasks the engineer can complete in 30s–5min that move the project forward incrementally. The wait time becomes maintenance time — the project gets a little tidier with each interstitial.

Why action-oriented

Two qualitative reasons over passive content:

1. Acting builds a habit; reading doesn't. Engineers in flow state will skim a surfaced "tip" and dismiss it; engineers asked to do one specific thing — relabel an issue, close a stale duplicate, leave a one-line comment on a teammate's PR — actually do it. The action becomes part of the wait-time muscle memory rather than an interrupted reading session.
2. The artifacts Codev already produces (reviews, lessons-learned, arch.md) gain real downstream value when triggered by an action. A review file that never resurfaces after the PR merges is curation theater. A review file that triggers "this PR's follow-up #948 was never filed — file it now?" is curation that compounds.

Candidate action categories

Not exhaustive, not prescriptive — what's the kind of thing the queue could surface. Plan-gate picks 2–3 to ship in v1.

Category	Example surfaced action	Time cost	Who benefits
Backlog grooming	"#XXX is missing an area/* label — pick one" or "#YYY hasn't moved in 60 days — close, archive, or relabel?"	15–30s	The project (tidy backlog)
Protocol classification	"#XXX has no protocol decision recorded — judge: AIR / BUGFIX / PIR / SPIR?"	30–60s	Future spawn decisions
Sibling PR review	"PR #NNN from architect-<other> has been open 6h with no review activity — leave one comment"	2–5min	Teammates (cross-architect awareness)
Lessons curation	"Recent reviews #A, #B, #C each cited the same gotcha — promote to a durable lesson?"	2–5min	The project (lessons-learned quality)
Follow-up filing	"Review #X mentioned a follow-up that was never filed — file it now?"	1–3min	The project (no dropped threads)
Issue deduplication	"#A and #B look like the same thing — close one?"	1–2min	The project (signal-to-noise)

The queue surfaces one item at a time with a clear primary action button, same shape as the focus-mode prompt — Approve / Skip / Exit becomes Do / Skip / Exit.

Open design questions (plan-approval)

1. What goes in the queue? Which categories above ship in v1; which are followups. Quality threshold: better to surface 5 high-confidence items per session than 50 noisy ones the engineer learns to dismiss.
2. How is queue order chosen? Time-sensitivity (stale labels first? PRs waiting longest?), engineer affinity (your area first?), or random rotation? Each has a different feel.
3. What's the UI shape? Sidebar section that appears only when the focus-mode queue is empty; a title-bar action; a Cmd+K I ("idle") command; an opt-in walkthrough-style overlay. The interstitial nature suggests something quiet — a row that appears only when relevant, not a permanent fixture.
4. What detection logic surfaces each category? Backlog grooming is easy (label-presence check). Sibling PR review needs cross-architect awareness. Lessons-curation needs cross-review pattern detection. Each category has a cost-to-detect; v1 ships the cheap ones.
5. Per-session memory. Once skipped, does an item resurface next session? Next day? Never until its state changes (e.g., a relabeled issue stops being a grooming candidate naturally)? Natural state changes is probably the answer — no per-user state to manage, items leave the queue when the underlying condition stops being true.
6. Composition with #800. When #800's focus mode is active, this queue is silent. When focus mode is empty (the queue is exhausted), this is the next surface the user encounters. Possibly the focus-mode exit screen offers "Continue with grooming queue?" as the natural handoff.
7. Cross-machine awareness. Some categories (e.g. sibling PR review) need cross-architect or cross-team data Codev doesn't yet surface in one place. v1 stays within what's already on the wire from the overview cache; richer cross-team data is a followup.

Why #800 is a prerequisite

This issue is the empty-queue side of the same workflow #800 builds the busy-queue side of. Two concrete dependencies make #800 a hard precursor, not just a related/composing item:

1. Trigger surface. The natural entry point for the idle action queue is "focus mode's queue just drained" — the exit screen from vscode: focus mode — sequentially triage blocked builders, one at a time, with auto-advance #800 hands off to this surface with a "Continue with grooming?" affordance. Without focus mode shipped, the idle queue has no organic trigger; it would need a standalone command + sidebar entry that competes for attention with the normal triage flow, defeating the "fills the interstitial" framing.
2. UX vocabulary. vscode: focus mode — sequentially triage blocked builders, one at a time, with auto-advance #800 establishes the per-action actionPick pattern (Approve / Skip / Exit) for serving one builder at a time. This issue reuses that pattern verbatim (Do / Skip / Exit for each surfaced grooming task) — the engineer's muscle memory transfers directly. Shipping the idle queue first would mean inventing a one-off UX language that vscode: focus mode — sequentially triage blocked builders, one at a time, with auto-advance #800 then has to reconcile.

Plan-gate for this issue should not start until #800 is at least at the plan-approval stage; implementation should not start until #800 has landed.

What this isn't

• Not a passive reading surface. No rotating "tip of the day" cards, no surfaced lesson snippets without an action attached. Reading-only would belong in a different issue, deliberately rejected here per the action-oriented framing.
• Not gamified. No streaks, no points, no daily-goals, no graded performance. The queue is a microtask offering, not a productivity-app pattern.
• Not prescriptive. The engineer is never required to act — the queue is offered, not enforced. Skip / Exit always available.
• Not a notification source. Items appear when the engineer chooses to look (opens the surface), not via toasts / badges / push.
• Not auto-acting. Every surfaced action requires explicit user confirmation. No "Codev relabeled 3 issues while you weren't looking" surprises.

Acceptance (deliberately loose pending plan-gate)

• An idle-state queue exists, surfaced through some UI shape decided at plan-approval.
• Queue populates from at least 2 categories from the table above (specific picks decided at plan-approval).
• Each item presents a primary action that completes in ≤5 min, with Skip + Exit available.
• Items leave the queue when the underlying condition becomes false (label added, stale issue closed, PR reviewed) — no manual dismissal state required.
• Composes cleanly with #800 focus mode: silent while focus mode is active, available when focus mode's queue is empty.
• Honest empty state: when no actionable items exist, the surface says so plainly rather than padding with low-quality items.

Related

• #800 — focus mode for the busy side of the triage queue. Hard prerequisite for this issue (see Why vscode: focus mode — sequentially triage blocked builders, one at a time, with auto-advance #800 is a prerequisite).
• #797 — actionPick keyboard-first QuickPick helper. Reuse for each surfaced action's Do / Skip / Exit prompt.
• #790 — terminal-focus → tree-reveal plumbing. Same principle ("quiet, contextual, no focus-stealing") informs the UI shape here.

Why this is a project / not BUGFIX or AIR

The shape is a new product surface, not a fix or a small feature. The "action-oriented" framing is firm, but the specifics (which categories ship, queue order, UI shape, composition with #800) are real design surface that benefits from plan-approval. A PIR plan-gate is the right place to lock those calls in before code lands.