Timeline Visualization

The design site already has several pieces of historical material, but they are split across separate surfaces and structures:

• content/archive contains date-driven design artifacts
• /archive provides a grid-based visual explorer
• /history contains curated project narratives
• cycle records and git history contain additional chronology that is not yet part of a unified browsing experience

We want a timeline surface that makes chronology itself explorable. That means a user should be able to scan what happened when, click into an event, reveal more context inline when that is enough, or move into a dedicated detail page without losing temporal context.

This work needs its own cycle because it spans information architecture, data normalization, API shape, and interaction design. It should not be mixed informally into the archive or history pages without first defining the canonical event model and route structure.

Define and execute the first implementation plan for a reusable timeline system in the existing Nuxt/Vue/Tailwind app.

The first useful version should:

• introduce a normalized timeline event model
• aggregate at least archive artifacts and manual milestones into one event stream
• provide a horizontal overview timeline
• support both inline reveal and dedicated detail pages
• preserve provenance back to source-native pages such as /archive/...

• cycles/c39.timeline-visualization/ — cycle record and planning artifacts
• normalized event schema and source adapter design
• timeline API design
• overview/detail route plan
• phased implementation plan aligned with the current app structure

Out of scope for this cycle unless explicitly pulled in later:

• full git history ingestion
• commit-level narrative curation across multiple repos
• final production polish for dense-data clustering or advanced compare modes

• CYCLE.md
• execution-plan.md

Potential later deliverables as implementation begins:

• timeline data types and adapters
• /api/timeline endpoints
• /timeline and /timeline/[id] pages
• timeline components and composables

Execution plan is now partially implemented. The timeline has a working first pass for archive and manual events, with source-native archive pages rendered inline beneath the overview instead of a separate timeline detail route for now.

1. What is the canonical normalized event shape that can support archive, history, git, and manual sources?
2. Which source types belong in the first release, and which should wait?
3. When should a click reveal inline detail versus navigate to a dedicated page?
4. How should timeline detail pages preserve chronology and context while showing rich content?
5. How do we keep source provenance explicit so the timeline becomes a unifying surface rather than a replacement for source-native pages?

First implementation pass is now in the repo and keeps the cycle active.

Implemented in this snapshot:

• normalized TimelineEvent model with ids, slugs, date precision, provenance, and filter metadata
• server-side aggregation for archive + manual sources
• GET /api/timeline and GET /api/timeline/[id]
• /timeline overview route with filters, zoom bands, timeline/sequential layout modes, and query-based selection
• inline timeline detail for manual items and inline source-page loading for archive items beneath the timeline
• manual timeline content collection and initial kickoff milestone
• shared archive detail component reused by both /archive/[...slug] and the inline timeline surface

Deferred from the original plan:

• dedicated /timeline/[id] page
• history source ingestion
• git source ingestion
• richer zoom-density logic beyond the current first pass