[chpy04]

Closes #2.

The complaint was that you cannot tell which dot the card belongs to. Two
halves fix it, and the plan was explicit that the second is the one that
actually does the work.

What changed

A leader line joins the dot to the card. It drops from the selected
dot, runs across, and meets the card's top edge, in that entry's own kind
colour at half opacity. It is a three-segment elbow rather than the single
vertical the plan describes, because the card is max-w-3xl centred in a
max-w-7xl shell: at 1440px a dot at either end of the axis is ~220px
outside the card's horizontal span, so a purely vertical drop would end in
empty space beside the card rather than on it. The elbow's lower half is
anchored at 50%, which is the card's centre whatever the viewport, since
the two buttons flank it symmetrically. No measurement, no resize observer.

The dot treatment widens the gap rather than adding decoration.
Selected goes 14px → 16px with ring-ink/30; ring-ink/15 was invisible
on the black canvas, which is what the screenshot on the issue shows.
Unselected go 10px → 8px and dim from opacity-60 to opacity-50. Only
existing @theme tokens with opacity modifiers — no new token was needed.

Previous/next buttons flank the card and step one entry at a time in
date order, disabled at either end rather than wrapping. move() grows a
focusDot flag so the buttons change the selection without pulling focus
onto the destination dot; the tablist's own arrow keys, Home and End keep
today's roving-tabindex behaviour, and the buttons sit outside the tablist
as ordinary buttons.

Departures from the plan

• The leader is an elbow, not a vertical line — reason above. Same
  decision, same moving part, geometry that survives a dot at 3% or 97%.
• The buttons are flex siblings of the card, not absolutely positioned
  in its dead space. The plan's reasoning for putting them beside the
  card ("dead space that is already empty at 1440px") stops holding at
  tablet width, where the shell is ~704px and the card fills it — overlays
  would land on top of the card there. As siblings the card narrows
  instead. Verified by screenshot at 800px.
• docs/STATE.md is untouched. Its timeline bullet is about the axis
  arithmetic in lib/timeline.ts, which is still true word for word.
• D-024 added for the arrows' placement, since the plan flagged it as
  the most reversible call in the change.

Worth knowing

The track opens on the most recent entry, which is the right-hand end of
the axis — so the next arrow is disabled on first paint. That is the
clamping in decision 4 working, not a bug, and it is the honest signal:
there is nothing newer. The e2e spec asserts it.

lib/timeline.ts and its 22 tests are untouched. No query, endpoint,
migration or contract change; the mobile TimelineList is untouched.

Verified

npm run verify, whole gate, on a worktree off origin/main:

• format:check, lint, typecheck — clean
• test — 120 passed, 0 failed, 0 skipped (unchanged from main; the
  skip count is 0, so the query and session suites really ran)
• build — clean
• reseed + smoke — 10/10 checks passed
• test:e2e — 16 passed, up from 15: the new spec is
  the timeline arrows step the selection one entry at a time

Also checked by screenshot at 1440px on the first, a middle and the last
entry, and at 800px, confirming the leader lands on the card at both ends
of the axis and the buttons never overlap it.

One environment note, not a code change: there is no .env in the main
checkout, so the worktree's symlink dangled and the DB suites would have
self-skipped to a green 104/120. DATABASE_URL was supplied explicitly for
the gate run.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
portfolio-app	Ready	Preview	Sep 20, 2026 11:29pm UTC