# ADR-0058: OSHUN Daypart Cross-Domain Journey Model

**Status**: Accepted  
**Date**: 2026-03-24  
**Authors**: OSHUN Product, OSHUN Design, OSHUN Web Engineering  
**Reviewers**: Tara, Arete, Veritas, Nyx, Nisaba leads  
**Supersedes**: N/A  
**Superseded by**: N/A

## Context and Problem Statement

The PRD already defines a daily flow model for morning, midday, and evening, but
the repo did not publish that answer as a canonical contract.

Instead, the implementation was fragmented:

- assistant and wearable systems had strong `morning` and `evening` vocabulary
- cross-domain ritual mocks only modeled morning/evening and omitted midday
- Nisaba's role in the daily loop was described in the PRD but not encoded in
  one shared shell-level model
- home surfaces had no single, authoritative representation of how a user's day
  should move from centering into recovery into closure

That left OSHUN with a product narrative but not a shared journey contract.
Teams could reference the PRD prose, but route helpers, home surfaces, QA, and
future routine work still had to invent their own interpretation.

The PRD already states the intended daily flow:

- **Morning**: Tara centering, Arete deliberate action, one grounded Veritas
  brief when relevant, one Nisaba passage or concept thread
- **Midday**: assistant-led reorientation, Arete plan recovery, Veritas
  significance framing, Nisaba source lookup
- **Evening**: Nyx perspective, Tara downshift, Nisaba annotation or comparative
  reading, one shared closure space

## Decision Drivers

- **Daily continuity**: the shell should carry one day-long arc rather than
  isolated domain sessions.
- **Midday recovery**: the model must explicitly handle drift and interruption,
  not only idealized start/end rituals.
- **PRD alignment**: the existing daily flow language should become normative,
  not advisory.
- **Nisaba parity**: study and source grounding must appear in the daily loop as
  first-class roles.
- **Implementation leverage**: web home and future mobile/assistant work need
  typed, reusable definitions.

## Considered Options

### Option 1: Keep daypart behavior implicit in routines, assistant prompts, and copy

**Description**: leave morning/evening behavior spread across assistant,
wearable, and ritual components without one shared contract.

**Pros**:

- Lowest immediate implementation cost.

**Cons**:

- Leaves midday under-modeled.
- Lets surfaces drift into inconsistent interpretations.
- Keeps Nisaba's daily role easy to omit.

### Option 2: Model only routines, not journeys

**Description**: treat dayparts purely as routine schedules (`morning`,
`evening`, `custom`) and avoid a broader cross-domain journey model.

**Pros**:

- Fits existing routine typing.
- Easier to connect to current routine UI.

**Cons**:

- Midday is not primarily a routine; it is a recovery journey.
- Misses assistant-led reorientation and shared closure semantics.
- Flattens the PRD's broader continuity model into scheduling.

### Option 3: Publish an explicit three-part daypart journey model and render it on home (Chosen)

**Description**: define `Morning anchoring`, `Midday reorientation`, and
`Evening integration` as canonical shell journeys, publish them in shared
navigation contracts, map them into web actions, and expose them on the home
surface as a real navigational rail.

**Pros**:

- Makes the PRD daily flow model executable.
- Gives midday a first-class recovery role.
- Encodes Nisaba and shared closure into the daily shell loop.
- Produces one contract reusable by docs, web, assistant, QA, and later mobile
  work.

**Cons**:

- Adds a new shared model that later routine work must respect.
- Requires clear separation between journey semantics and lower-level routine
  scheduling semantics.

## Decision Outcome

**Chosen option**: Option 3.

### Normative Daypart Rule

OSHUN's customer shell owns one daily continuity loop composed of three
canonical journeys:

- `Morning anchoring`
- `Midday reorientation`
- `Evening integration`

These are not optional marketing labels. They are the normative structure for
how the shell should guide daily cross-domain movement.

### Morning Rule

Morning must begin from `Home` and follow this priority:

1. Tara centering ritual
2. Arete deliberate action or check-in
3. Veritas grounded brief when context matters
4. Nisaba passage or concept thread when study should travel with the day

Morning is complete when the user has a felt center, one deliberate next action,
and one grounded input for the day.

### Midday Rule

Midday must be modeled as recovery, not restart.

Its normative order is:

1. Assistant grounding exchange
2. Arete plan recovery
3. Veritas significance framing when live context matters
4. Nisaba source or quote lookup when the question needs grounding

Midday is complete when the user regains direction with one clarified next move
instead of carrying vague drift or ambient anxiety.

### Evening Rule

Evening must close the day into perspective and durable memory.

Its normative order is:

1. Nyx nightly orientation
2. Tara downshift
3. Nisaba annotation or comparative reading when reflection deepens through text
4. One shared closure space (journal, notebook, or library resume point)

Evening is complete when the day ends in reflection, wonder, or preserved
continuity rather than unstructured residue.

### Handoff Rule

The required daypart handoffs are:

1. `Morning -> Midday`: preserve intention, plan, trusted context, and any study
   thread worth revisiting.
2. `Midday -> Evening`: turn open loops into reflection, saved context, or
   deliberate closure.
3. `Evening -> Morning`: use closure notes, annotations, and saved continuity as
   next-day re-entry points rather than forcing a blank restart.

### Surface Rule

- `Home` is the canonical entry surface for morning and evening journeys.
- `Assistant` is the canonical entry surface for midday reorientation.
- `Library` and notebook/journal destinations are the durable closure surface
  when a day cannot be finished in one sitting.

### Contract Publication

The shared daypart model lives in
`libs/oshun/navigation/src/daypart-journeys.ts`.

The web route/action mapping for that model lives in
`apps/oshun/web/src/navigation/daypart-journeys.ts`.

The current web home rendering of that model lives in
`apps/oshun/web/src/components/home/DaypartJourneyRail.tsx`.

## Scope Boundaries

- This ADR defines the shell-level journey model, not the full routine engine.
- It does **not** require every current routine type to gain a new `midday`
  schedule enum immediately.
- It does **not** replace later journey work such as research-to-practice,
  story-to-source, sky-to-text, or assistant-led continuity models.

## Architecture Implications

- shared navigation code should expose typed daypart journeys and handoffs
- web home should make the daypart model visible and actionable
- Nisaba should remain explicit in morning, midday, and evening continuity work
- future assistant, mobile, and QA work can reuse one canonical daypart
  definition instead of inventing local copies

## Acceptance Criteria

`V1-UX-006` is complete only when all criteria below are true:

1. A canonical ADR defines the morning/midday/evening journey model.
2. Shared navigation code publishes the same journey and handoff model.
3. The web home surface reflects the canonical daypart journeys as actionable
   continuity guidance.
4. Midday recovery and Nisaba study roles are explicit in the shipped model.
5. Tests verify the shared model, web action mapping, and home rendering.

## Related Decisions

- `docs/adr/ADR-0059-oshun-customer-information-architecture-and-tara-centered-spine.md`
- `docs/adr/ADR-0061-oshun-web-shell-relationship-model.md`
- `docs/adr/ADR-0062-oshun-mobile-shell-relationship-model.md`

## References

- `docs/releases/v1/specs/web-app-admin-v1-prd.md`
- `libs/oshun/navigation/src/daypart-journeys.ts`
- `apps/oshun/web/src/navigation/daypart-journeys.ts`
- `apps/oshun/web/src/components/home/DaypartJourneyRail.tsx`