V1 Web PWA · Journey

Journey: Tara sit completion to Nisaba contemplative reading hand-off

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

automated · 2 specs verdict: partial· 2026-05-29
9sections6 minread1table
Markdown source
On this page
Journey at a glance
ActorsTara practitionerNisaba readerReturning browser userSource-trail reviewer
Systems exercisedtara.mdnisaba-daily.mdnisaba.md04-auth-session.md
Automation2 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. Launch an immersive Tara session"] s2["2. Classify the session and build the compani…"] s3["3. Complete the Tara player"] s4["4. Inspect the completion companion"] s5["5. Follow the deep link"] s6["6. Distinguish landing from citation payoff"] s7["7. Return to the completed session"] s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 click s1 href "#1-launch-an-immersive-tara-session" click s2 href "#2-classify-the-session-and-build-the-companion" click s3 href "#3-complete-the-tara-player" click s4 href "#4-inspect-the-completion-companion" click s5 href "#5-follow-the-deep-link" click s6 href "#6-distinguish-landing-from-citation-payoff" click s7 href "#7-return-to-the-completed-session" s7 --> v(["verdict: partial"]) click v href "../results/tara-to-nisaba-handoff.html" style v stroke:#d6a531,color:#d6a531

The /domains/tara player ships a real, responsive Tara-to-Nisaba hand-off: every launched session receives one deterministic companion, completion shows its action, the action deep-links into /domains/nisaba, and Browser Back restores the completed Tara player. This is a client-composed content bridge, not a personalized recommendation. The current source does not consult Iris, Lilith crisis state, lineage, entitlement, cadence, or the BFF recommendation service.

Personas#

  • Tara practitioner — completes an immersive /domains/tara session and wants one calm next step.
  • Nisaba reader — follows the hand-off into a daily, reflective, grounded, lineage, or evening passage.
  • Returning browser user — expects Browser Back to restore the completion surface rather than restart the timer.
  • Source-trail reviewer — distinguishes a Nisaba shell landing from an exact grounded-passage citation trail.

Pre-conditions#

  • The signed-in customer enters /domains/tara with a path that launches a session, such as /meditate/featured; this journey does not use the separate compact /tara → /tara/sit/<id> player.
  • TaraSurface can build a PlayingSession. It creates the companion before playback by calling buildTaraNisabaPassageCompanion.
  • The Nisaba domain is authorized in the customer shell. The bridge itself has no local entitlement or source-availability check.
  • A generated companion always exists: the resolver covers all six ritual moments and the classifier defaults unmatched content to morning_opening.

Steps#

1. Launch an immersive Tara session#

Open /domains/tara?origin=<surface>&stack=<domains>&path=<session-path>. TaraSurface derives a session id/title/description/tags and constructs its Arete, Nisaba, Metis, Nyx, and assistant follow-ups. No request is made to /v1/cross-domain/recommendations for this completion card.

2. Classify the session and build the companion#

inferTaraRitualMomentFromSession scans the session id, title, description, transcript, and tags in fixed regex order. The domain library then resolves one descriptor for that moment:

Tara moment Nisaba result
morning_opening contemplative reading · /daily-passage
midday_reset virtue study · /library/passage/nisaba-passage-1?view=grounded
transition_pause study reflection · /library/passage/nisaba-passage-1
reflection_close source lineage · /library/passage/nisaba-passage-1?view=source-lineage
sleep_descent contemplative reading · /daily-passage
news_decompression claim grounding · /library/passage/nisaba-passage-1?view=grounded

resolveCrossDomainTarget is an injectable catalogue seam, but the web caller does not provide a resolver. The seed path—including the shared nisaba-passage-1 placeholder for four mappings—therefore remains the target.

3. Complete the Tara player#

Playback reaches the full timer duration, or a scrub reaches totalSec. SessionPlayer changes to complete, writes recent Tara theme continuity to localStorage, and adds taraSessionState=complete to the current Tara history entry. Unlike the compact Tara player, this component does not use an 80% completion threshold or post a completion record to the BFF.

4. Inspect the completion companion#

NisabaPassageCompanionCard appears on both completion and reflection screens. It exposes the ritual/study moments in data attributes, renders the bridge label, title, summary, and full-width action, and names the source session. The action is a real button wired to router.push(companion.shellPath); there is no null/empty-companion branch in the shipped builder.

The shell URL preserves origin, prepends tara to the de-duplicated domain stack, and carries the target as the encoded path plus a stable tara-nisaba-passage-companion-<moment> ref. For the covered featured session, the exact destination is the Nisaba daily-passage path with stack=tara,veritas.

6. Distinguish landing from citation payoff#

The continuous player test proves that the action lands in the authenticated Nisaba customer shell without a welcome/login bounce. It does not prove that the daily-passage target opens a grounded reading or a citation trail.

The citation-destination test separately opens /library/passage/nisaba-passage-attention with an exact sentence locator. That direct route proves the reading highlight and NisabaCitationTrailPanel primary-source locator, but it does not start from the companion URL. These are two valid seams, not one fully joined browser path.

7. Return to the completed session#

Browser Back returns to the history entry that was rewritten with taraSessionState=complete. TaraSurface reconstructs the same session and deterministic companion, and SessionPlayer starts on the completion screen. No server session envelope or companion-open receipt is required for this restoration.

Post-conditions#

  • The current Tara URL records completion state in browser history and recent theme continuity in browser storage.
  • The customer sees one deterministic Nisaba companion and can open its shell path with origin, stack, target, and ref intact.
  • Browser Back restores the completion UI and companion card.
  • No companion impression/open telemetry, preference write, cadence decay, crisis suppression, lineage filter, or server-side recommendation record is created by this path.
  • Exact citation-trail behavior is proven on a separate Nisaba passage URL, not on the continuous daily-passage hand-off.

Failure modes#

  • Classifier overmatch — fixed regex priority can select news before sleep/reflection terms; unmatched sessions silently become morning openings.
  • Seed-target concentration — four moments reuse nisaba-passage-1 because the web path supplies no catalogue resolver.
  • No safety/personalization gate — active crisis state, declined memory, lineage preference, or repeated exposure does not suppress or re-rank the card.
  • Destination unavailable — the card is constructed without checking that its target passage exists; failure is deferred to Nisaba navigation.
  • Citation proof discontinuity — the exact-locator E2E bypasses the actual companion target, so a regression between /daily-passage and a grounded passage could escape the combined evidence.
  • History-only restoration — a copied/reloaded URL can recreate the completion UI without proving that the sit actually ran or persisted.
  • No card fallback branch — the documented “no relationship” state cannot occur with the current total resolver.

E2E coverage#

  • apps/oshun/web/e2e/tara-session-player.spec.ts drives play → completion, asserts the morning_opening card, follows the real encoded daily-passage URL, and proves Browser Back restores the completion screen and companion.
  • apps/oshun/web/e2e/tara-to-nisaba-handoff-destination.spec.ts directly opens a different exact-locator Nisaba passage and proves the highlighted sentence plus canonical-source trail step.
  • Coverage depth: partial. The UI/navigation/back-stack seam is deep and the citation component is deep, but no single test connects the emitted companion path to the cited reading payoff. Catalogue resolution, crisis, lineage, cadence, offline, and telemetry behavior are not covered because they are not wired here.

Per-view files touched#

Cross-references#

  • tara-daily-ritual.md — separates this local immersive player from the BFF-backed compact Tara player.
  • veritas-to-nisaba-deeper.md — another Nisaba source-depth bridge.
  • Sources: apps/oshun/web/src/components/domains/TaraSurface.tsx, apps/oshun/web/src/components/domains/tara/SessionPlayer.tsx, apps/oshun/web/src/components/domains/tara/taraSessionCompanions.ts, and libs/oshun/domain-tara/src/nisaba-relationship.ts.

Open questions#

  • Should the completion card consume the BFF cross-domain recommendation and attribution contract instead of rebuilding a static relationship client-side?
  • Which catalogue resolver replaces the shared seed passage and verifies target availability before the card renders?
  • Where should crisis, lineage, entitlement, memory-consent, and cadence gates run, and how should their decisions be inspectable?
  • Should companion shown/open events be real analytics calls rather than DOM metadata?
  • Which emitted target is canonical for the grounded citation payoff, and can one E2E walk it continuously from Tara completion?