Checkpoint 1 · My Cards / Study Cards Redesign

Study Cards — from five buttons to a filter that thinks with you

Today's Study Cards screen shows every card at once and gives each one five ghost buttons — you hunt for the one action you want. This is a design proposal: replace the button pile with a progressive dropdown (archetype → card type → lifecycle) built on the FSRS engine states you find easiest to reason about, and let the available actions change with what's on screen. Nothing here is built — no code, no schema, no session loader has been touched.

Design only — nothing built FSRS states as the primary lens 3-level dropdown cascade 5 per-card buttons → Info + a context set 1 build item flagged (paused auto-return) 5 decisions for you
Checkpoints Latest →
Start here

Why this page — and the words it uses

What happened. The Study Cards screen today shows 3 stat-tile filters (Total / Due / Learned), 3 tabs (Cards / Coming Up / Paste), and — once you tap a card open — 5 ghost-icon buttons (Info, Star-priority, Pause, Mark-learned, Retire). You said it's "too complicated with the different buttons." Separately, you said the scheduler's own four states (new / learning / review / relearning) are "a lot easier" for you to reason about than the friendly stage names (Intro, Active, Learned…) we currently show.

What this proposes. Re-ground the screen's lifecycle vocabulary on the FSRS states, then replace the flat button/tab/tile pile with a progressive dropdown that narrows step by step — archetype, then card type, then lifecycle — and have the available actions adapt to whatever's currently on screen. It also captures two behavior changes you described: paused cards should return on their own once the due queue runs dry, and a retired word's derived forms may still deserve to stay learnable even after the word itself is retired.

What this does NOT do. Touch code, touch the database, or promise the auto-return behavior works today — section 5 flags exactly what's missing and why it can't be turned on safely yet.

The words this page uses

Archetype (CA) — what a card teaches: Vocabulary (a word meaning), Script-alphabet (a letter), Phrase (a multi-word unit), Passage (a formatted block, proposed). This is the top dropdown level.

Card tier (CT) — where the card's row sits in a word's family tree: CT1 lemma (the headword container, hidden), CT2 sense (one meaning — the main studyable card), CT3 form (a spelling/inflection under a sense). This is the middle dropdown level.

FSRS state — the scheduler's own state for a card: new (never studied), learning (early repetitions), review (settled into normal spaced rotation), relearning (slipped and being recovered). This is the base of the bottom dropdown level.

Overlay — a manual flag layered on top of the FSRS state: paused (learn later), retired (never again), learned (you've mastered it), priority (show me more). These fill out the rest of the bottom dropdown level.

ADR-083 — the new archetype registry decision (table t080_card_archetypes) that will define, per archetype, which card types exist and which lifecycle options apply. It's the data source behind the top dropdown level. t310_profile_card_progress — the table holding each learner's FSRS state + overlay per card; the source for the bottom dropdown level.

1 · The lifecycle lens

FSRS states first, friendly names as a translation — not a replacement

Your call: reason about cards by their scheduler state, not the derived stage name. The stage names don't go away — they become a label on top of the FSRS state, the same way they already work today.

FSRS statePlain meaningFriendly name todayOverlay that can sit on top
newNever studied yetIntro / Heldpriority (jump the queue)
learningEarly repetitions, still fragileActivepriority, paused
reviewSettled into normal spaced rotationActivepriority, paused, learned
relearningSlipped a review, being recoveredActivepaused
— overlay, not an FSRS state —Pausedlearn later, comes back on its own (build item — §5)
— overlay, not an FSRS state —Retiredpermanent "never show me again"

This is the same fact renamed, not two systems: every card the app shows already carries one FSRS state plus zero or one overlay. Today's screen names the combination (Intro, Active, Learned, Paused, Retired); this redesign just makes the FSRS state the primary sort/filter key instead of the derived name.

Already shipped, same principle On 2026-07-03 (commit 67c5b82d) the per-row lifecycle badge changed to show only surprising states — Active and Held/new cards carry no badge at all; Intro, Learned, Paused, and Retired still show one. That's "filter is context, badge is surprise" already live at the row level. This redesign is the same principle applied to the whole screen: once you've picked a lifecycle in the dropdown, you don't need every card re-announcing what you already filtered for.
2 · The redesign

A dropdown that narrows, instead of buttons that pile up

Three levels, each one narrowing what's visible. Mobile-first, 390px frame shown below — illustrative, not a pixel-accurate mock.

Study Cards — filter
1 Archetype Vocabulary ▾
2 Card type Sense ▾
3 Lifecycle Retired ▾
42 cards match
nasi
rice · noun
retired
Un-retire Info

Each pick narrows the list under it — pick Vocabulary, then Sense, then Retired, and you land on exactly the retired word-meaning cards, with Un-retire as the natural primary action instead of a ghost button buried in a 5-icon row. Pick Paused instead of Retired and the primary action becomes Resume now. Leave Lifecycle on its default ("everything active") and you get today's normal management set: Info, Star, Pause, Mark learned, Retire.

Where each dropdown level actually comes from

LevelOptions shownReal data source
1 · ArchetypeVocabulary, Script-alphabet, Phrase, Passaget080_card_archetypes (ADR-083 registry) — key / display_name, plus enabled flag (see decision D3)
2 · Card typeDepends on archetype — Vocabulary: lemma / Sense / FormEach archetype's tier_scheme in the registry, backed by t070_study_card_catalog.card_tier (1/2/3) — see decision D2
3 · LifecycleNew, Learning, Review, Relearning, Paused, Retired, Learned, PriorityNot in the registry. Comes straight from the card's own row: FSRS state + user_status overlay on t310_profile_card_progress

The registry (ADR-083) only gates what exists per archetype — e.g. Script-alphabet has no "Form" tier, so level 2 wouldn't offer it. Lifecycle is a property of each learner's progress, never the registry's business.

3 · What happens to the buttons

Five ghost icons → Info, plus a context set that adapts

The decluttering you asked for: keep per-card Info always available (it's a drill-in, not a status lever), and let the remaining status actions become a smaller set that changes with whatever the dropdown is currently showing — and can act on the whole filtered set, not just one card at a time.

Today

5 ghost buttons on every selected card

Info, Star-priority, Pause, Mark-learned, Retire — all 5 shown together, every time, regardless of what state the card is already in.

  • All 5 route through one wrapper endpoint (POST /api/review, type user-action)
  • Same set whether the card is brand new or already retired
  • No way to act on more than one card at once
Proposed

Info + a context set that follows the filter

Info stays put per-card. The status levers collapse into a smaller set that matches the refined view — and because the dropdown already narrowed the list, the same action set can apply to everything on screen.

  • Viewing Retired → primary action: Un-retire
  • Viewing Paused → primary action: Resume now
  • Viewing New / Learning / Review (normal) → the familiar set: Star, Pause, Mark learned, Retire
  • Same underlying POST /api/review wrapper — this is a UI reshuffle, not a new API
4 · Build item — flagged, not built

Paused auto-return — the behavior you described isn't wired yet

Your ask: once the due queue is exhausted, paused cards should come back on their own — paused means "learn after other things," not rejection. Today only a manual unpause exists. This section locates the work; it doesn't do it.

The landmine: retire and pause currently write the same value

Today, both Retire and Pause write user_status='paused' (web/src/app/api/review/route.ts ~717 / ~723). The data has no way to tell "learn later" apart from "never again." Auto-return can't be built safely on top of this — a naive version would resurface cards a learner deliberately retired. Splitting retire and pause into distinct states is a prerequisite, not a nice-to-have (decision D1 below).

This section stops at design — it locates the behavior in the session-loader / lifecycle layer, which is ENR territory per ADR-050. An ENR briefing follows once you've ruled on D1 and D4; the design only marks where the work lives, ENR builds it.

5 · Open nuance

Retiring a word doesn't have to retire its forms

Your framing: retiring a sense (e.g. nasi = "rice," clearly known after two days) is a permanent "never show me again" — the outlet that keeps the app from over-showing words a learner already has locked in. But you flagged a nuance: a retired sense's derived forms may still be independently worth learning — "there are forms associated with it, so it kind of makes sense" they stay studiable.

This is genuinely open — does retiring a sense cascade-retire its forms, or leave them studiable on their own? Captured as decision D5 below, leaning toward leaving forms studiable per your comment.

Decisions

What's explicit vs. inferred going into this checkpoint

1
FSRS states (new / learning / review / relearning) are the primary lifecycle lens, not the derived stage names
You said the FSRS states are "a lot easier" for you to reason about. The friendly names stay as a translation layer, not a replacement.
Decided by Frank
2
Paused means "learn after other things," not rejection — and should auto-return once the due queue empties
Stated directly. The mechanism to build it is captured in §4; it doesn't exist today.
Decided by Frank
3
Retired is a permanent outlet — "never show me again" — to prevent over-showing known words
Named explicitly as the pain from a previous app you want WordSense to avoid.
Decided by Frank
4
Replace the button-heavy My Cards UI with multi-level dropdown filters, actions changing with the refined view
Stated directly: "too complicated with the different buttons" → progressive dropdown cascade.
Decided by Frank
5
This checkpoint supersedes the W3 thread on the cmux close-out board
W3 offered three narrow filter-set options (F-keep / F-split / F-paused); this fuller design replaces that question rather than answering it as posed.
Inferred from what you said
6
A retired sense should probably not automatically cascade-retire its forms
You raised the nuance but didn't rule on it — captured as open decision D5 below rather than assumed.
Inferred from what you said
6 · Decision items

Your call — answer any subset, one click each

Each item states what it changes first, then the options. The "recommended" tag on an option is our own domain-best judgment on the design merits — not a guess at what you'd pick.

D1
Prerequisite: split retire vs pause into distinct data states before building auto-return?
What it changes: whether "learn later" and "never again" can ever be told apart in the data — required both for safe auto-return and for the permanent/temporary distinction you described.
Recommended because it's a hard blocker for D4 — auto-return can't be built safely on a shared state without risking retired cards resurfacing.
D2
Does the middle dropdown ("Card type") mean the tier, or the part of speech?
What it changes: what "Card type" means to a learner browsing the list — a structural position in the word's family tree, or a grammatical category.
Recommended: Tier, because it matches the CA×CT taxonomy backbone and each archetype's tier_scheme already defines it; POS could layer in later as an optional facet rather than replacing the tier meaning.
D3
Does the top dropdown show only enabled archetypes (2), or every archetype with corpus rows (4)?
What it changes: whether Phrase and Passage appear in the dropdown at all. The registry currently has Vocabulary + Script enabled; Phrase and Passage are disabled but the corpus already has 2 phrase cards and 10 passage cards.
Recommended: show all four, greyed out if disabled — cards already exist, so hiding them entirely would make real content invisible.
D4
When paused cards auto-return, how many come back and how often is "due empty" checked?
What it changes: how aggressively paused cards flood back into a learner's queue once due cards run out. Depends on D1 being resolved first.
Recommended: drip a few, per-session — mirrors the existing candidate-drip feel rather than dumping the whole paused set back at once.
D5
Does retiring a sense cascade-retire its derived forms, or leave them independently studiable?
What it changes: whether "never show me nasi again" also silently kills any spelling-variant cards under it.
Recommended: leave forms studiable, matching your own comment that the forms "kind of make sense" to keep around even after the base sense is retired.
Worth your eye

A few things worth noticing before you answer

🗂️
The archetype dropdown isn't a UI-only list — it reads straight off ADR-083's registry table (t080_card_archetypes). Enabling Phrase or Passage there is what would flip them from greyed-out to selectable, independent of anything in this redesign.
🩹
The 2026-07-03 badge-suppression shipment (commit 67c5b82d) already proves "filter is context, badge is surprise" works at the row level — this redesign is that same idea pushed up to the whole screen's filter chrome.
🚧
The auto-unpause transition already has a name and a predicate in the lifecycle code (T75, lifecycle.ts:157-159) — it was designed once and never wired to either session loader. Building it is connecting an existing seam, not inventing new lifecycle theory.
⚠️
D4 (auto-return mechanics) can't actually ship until D1 (split retire vs pause) lands — answering D4 without D1 would describe a behavior the data can't yet support safely.