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

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.

### 5. Follow the deep link

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`](../../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`](../../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

- [`customer/03-tara/tara.md`](../customer/03-tara/tara.md) — Tara domain
  workspace entry and player.
- [`customer/07-nisaba/nisaba.md`](../customer/07-nisaba/nisaba.md) — Nisaba
  shell/daily reading destination.
- [`customer/07-nisaba/nisaba-daily.md`](../customer/07-nisaba/nisaba-daily.md)
  — the morning/sleep target.
- [`shell/04-auth-session.md`](../shell/04-auth-session.md) — authenticated
  customer-shell boundary.

## Cross-references

- [`tara-daily-ritual.md`](./tara-daily-ritual.md) — separates this local
  immersive player from the BFF-backed compact Tara player.
- [`veritas-to-nisaba-deeper.md`](./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?