App flows
What a person sees and how they move through it, with one file per feature, written with every decision that changes the interface.
What a person sees and how they move through it — one file per feature, written with every ADR that changes the UI (ADR-0008).
Living snapshots. Edit in place so each file describes the system as it is right now. No revision tables, no "previously X, now Y" — delete what is no longer true (ADR-0002).
Conventions
- File name:
<feature-slug>.mdx, matching the feature's PRD slug. - The flow as a Mermaid
flowchartwith its Archify view; oneblock-betawireframe per screen, phone width first, with its Archify view drawn from it (anarchitecturediagram inside a phone-screen region). Each is a<Diagram>(ADR-0022). - Every screen lists its states: empty, loading, not found, refused, error, degraded, success. Degraded is what the person sees when an external service (search, for one) is unavailable: a clear notice, never a hang or a raw error.
- Sample values are invented: an example package name, never a private project's.
- Each page type names its Markdown entry point (
/<slug>.md), so readers and tools can take the content without the site.
Template: ../_templates/app-flow.mdx
Documents
Architecture — puncoz-packages-docs
How the site works as built: a Next.js and Fumadocs app rendering content as pages, Markdown, images and search records, with its routes and components.
App flow — the ADR constellation
How an ADR folder's station in the sidebar shows its decisions as a constellation of moons, and each state of it.