V1 Web PWA · Journey

Journey: Tara daily ritual

A source-reconciled journey record for V1 Web PWA — shipped behavior, state boundaries, failure modes, and the automation evidence available today.

automated · 4 specs verdict: partial· 2026-05-29
9sections6 minread
Markdown source
On this page
Journey at a glance
ActorsDaily customerCompact-room customerReturning practitionerInterrupted/offline practitioner
Systems exercisedhome.mdtara.mdarete-streak.md03-pwa-behavior.md
Automation4 E2E spec(s) · verdict: partial· 2026-05-29

Journey flow#

Generated from the authored steps below — click a node to jump to that section.

flowchart TD s1["1. Choose the Home domain-workspace path"] s2["2. Choose the compact BFF-backed room path"] s3["3. Start and control /tara/sit/ id"] s4["4. Complete through the BFF-backed player"] s5["5. Capture reflection and continue"] s6["6. Re-enter and compare observable state"] s1 --> s2 --> s3 --> s4 --> s5 --> s6 click s1 href "#1-choose-the-home-domain-workspace-path" click s2 href "#2-choose-the-compact-bff-backed-room-path" click s3 href "#3-start-and-control-tarasitid" click s4 href "#4-complete-through-the-bff-backed-player" click s5 href "#5-capture-reflection-and-continue" click s6 href "#6-re-enter-and-compare-observable-state" s6 --> v(["verdict: partial"]) click v href "../results/tara-daily-ritual.html" style v stroke:#d6a531,color:#d6a531

Tara currently has two polished but separate customer paths. Home opens the domain workspace at /domains/tara?..., whose immersive player and continuity are client-side. /tara opens a compact BFF-backed room and /tara/sit/<id>, whose start/completion writes require Postgres. Automation is deep for both paths, but no test proves one continuous Home → persisted completion → refreshed streak journey.

Personas#

  • Daily customer — starts from the time-aware Home Tara rail and wants a short centering/reset/downshift.
  • Compact-room customer — opens /tara, chooses today's or a course sit, and uses the timer/transcript player.
  • Returning practitioner — expects recent theme continuity or completed sitting state to survive at the correct storage boundary.
  • Interrupted/offline practitioner — needs honest audio, completion, and reflection recovery behavior.

Pre-conditions#

  • The customer is signed in. Anonymous /tara is redirected to /welcome?redirect=%2Ftara.
  • Home can render its daypart fallback without BFF Tara history. Recent /domains/tara theme continuity, when present, comes from oshun.tara.theme-continuity.v1 in localStorage.
  • /tara server-loads GET /v1/tara/room. An unreachable BFF produces an honest unavailable room rather than invented progress.
  • BFF start/completion persistence requires Postgres. Without it those endpoints return 503.

Steps#

1. Choose the Home domain-workspace path#

HomeTaraRitualContinuationSection selects morning, midday, or evening copy and links to /domains/tara with a /meditate/breathwork, /featured, or resume path. It shows a fallback curated ritual until local theme continuity exists; it does not read /v1/tara/ritual or the BFF completion ledger.

The /domains/tara SessionPlayer provides audio/timer fallback, play/pause, scrub, transcript, speed/quality/ambient controls, completion/reflection screens, exports, and Nisaba/Metis/Arete/Nyx/assistant handoffs. On completion it writes recent theme continuity to localStorage. It does not post a Tara completion to the BFF.

2. Choose the compact BFF-backed room path#

Direct /tara calls getTara() → /v1/tara/room and renders today's sit, course sittings, teachers, and breath ritual. When Postgres is available, completed sitting ids mark rows done; the room data has no streak field and does not show the /v1/tara/ritual streak count. Begin links to /tara/sit/<id>.

3. Start and control /tara/sit/<id>#

TaraSitPlayer loads deterministic ambient WAV through the authenticated BFF, or discloses that ambient audio is unavailable. It exposes timer, scrub, play/pause, voice speed, ambient mix, transcript/captions, reduced motion, 90-second drift pause, keyboard controls, and an 80% early-finish threshold.

The first started transition posts POST /v1/tara/sittings/:id/start. Non-OK/network failure is placed in a browser-local tara:start:<id> record; there is no shipped drain for that record.

4. Complete through the BFF-backed player#

Natural end or “End sitting” moves the UI to completed/partially-completed and posts POST /v1/tara/sittings/:id/complete once per mounted player. The BFF stores a completion row, dual-writes the canonical completion event, and returns the user's date-based Tara streak when Postgres is available.

The completion insert is not server-idempotent by sitting/day; the client ref only prevents a duplicate post in one mount. Duplicate rows on the same day do not increase the current streak because streak calculation uses distinct UTC dates, but they remain duplicate completion records.

5. Capture reflection and continue#

In /tara/sit, the completion POST captures the reflection value present at the moment state changes—normally empty because the reflection field appears after completion. The later “Save reflection” button only waits 300 ms and shows “Saved”; it does not call a BFF endpoint. Offline it writes tara:reflection:<id> to localStorage (or honestly reports in-tab-only state), and no drain is shipped.

The /domains/tara reflection path supports local drafting/export and returns to the Tara dashboard; it likewise does not join the Postgres completion row.

6. Re-enter and compare observable state#

Returning to /domains/tara/Home can reflect the local theme-continuity record. Returning to /tara can reflect BFF completed sitting ids when the completion request succeeded and the room revalidates. The separate /v1/tara/ritual and /v1/tara/today routes can compute a real Tara streak, but this journey's shipped /tara room does not display it and no automatic Arete increment occurs for an ordinary Tara completion. Arete recovery origin is a special explicit branch only.

Post-conditions#

  • The Home/domain-workspace path offers a responsive immersive ritual and persists recent theme continuity locally.
  • The compact-room path can persist start/completion records and derive a Tara streak when Postgres and the authenticated request succeed.
  • Completed sitting state can reappear in /tara; it is not the same state as Home's local theme continuation.
  • Reflection UI is not a durable server write in either path.
  • Named data-telemetry-event attributes exist on several controls, but a full hub viewed → completed → Arete streak → Home continuation analytics/event chain is not proven.

Failure modes#

  • Parallel frontdoors — Home's primary action does not enter /tara, so combining their tests does not prove one continuous lifecycle.
  • No Postgres — start/completion endpoints return 503. Start notices and queues the failure; completion only catches fetch rejection and does not check response.ok, so an HTTP 503 can still leave the UI claiming completion without a queued retry.
  • Duplicate completion — remount/replay can insert another row for the same sitting/day; streak stays date-distinct but the ledger is not idempotent.
  • Reflection false durability — online Save shows “Saved” after a timer with no request; offline queues have no drain.
  • Ambient fetch failure — the compact player stays usable in timer mode and exposes the unavailable state.
  • Unknown sitting id — /tara/sit/<id> renders the app 404 and Browser Back remains the recovery.
  • Offline completion — only thrown fetches create tara:completion:<id>; there is no service-worker/background-sync admission or replay worker.
  • Streak equality assumption — Tara's date-based sit streak and Arete habit streaks are distinct metrics and should not be asserted equal.

E2E coverage#

Per-view files touched#

Cross-references#

  • first-tara-sit.md — deeper compact-player control audit.
  • tara-to-nisaba-handoff.md — domain-player companion continuation.
  • arete-streak-recovery.md — the special origin=arete-recovery write branch.
  • Sources: HomeTaraRitualContinuationSection.tsx, TaraSitPlayer.tsx, components/domains/tara/SessionPlayer.tsx, and the Tara block in apps/oshun/bff/src/routes/domain-stubs.ts.

Open questions#

  • Which Tara frontdoor is canonical, and how should Home enter the same persistence contract the compact room reads?
  • Should completion accept a stable session/idempotency key and reject duplicate sitting/day records?
  • Which endpoint stores post-completion reflection and drains offline drafts?
  • How should the UI surface a failed completion POST instead of claiming a durable success?
  • Should /tara render the real Tara streak returned by the ritual/today routes, and how should that remain distinct from Arete habit streaks?