Search

Search components, tokens, patterns, architecture

Architecture · arrives in Phase 2

State Maps

Every possible state of every screen and component: no data, partial data, loading, error, syncing, permission denied, stale data, conflicting cycle information, wearable disconnected, incomplete onboarding, network and authentication failures — each with triggers, UI response and recovery path.

Scheduled for documentation Phase 2

This section's structure is reserved and its source material already exists in the shipped application. It will be populated when Phase 2 of the documentation package is delivered — see the roadmap.

What this section will contain

  • Per-surface state tables: state → trigger → UI response → recovery path
  • State diagrams (Mermaid) for the app shell, sync lifecycle, and DailyFocusCard
  • The cycle-mode state machine: regular → irregular (≥35d) → late_peri (≥60d) → no_data
  • The threshold ladder as a global data-maturity state
  • Conflict handling: duplicate dates, legacy tag values, deprecated field aliases

Grounded in (already shipped)

  • ·getCycleMode() thresholds in lib/cycle.ts
  • ·Sync states (idle/ok/syncing/error) in useAppData
  • ·Empty/learning gates per card (<3, <5, <14 entries, <2 period starts)