---
status: reconciled-partial
coverage_depth: deep-for-shipped-core
last_reconciled: 2026-07-17
specs:
  - apps/oshun/web/e2e/arete-create-habit.spec.ts
  - apps/oshun/web/e2e/arete-full-journey.spec.ts
  - apps/oshun/web/e2e/arete-habits-bff.spec.ts
source: WALKTHROUGH/journeys/arete-create-habit.md
---

# Journey result: Arete create habit

- **Walked**: 2026-05-29 by Claude (Opus 4.8) against commit `3678298cd3`, with
  a deeper form/API probe in the same result pass.
- **Reconciled**: 2026-07-17 against both current habit-entry lanes, the live
  BFF habit/check-in store, cross-device readback, Arete Home, streak, identity,
  error, and focused Playwright sources.
- **Verdict**: **partial** — the original proposal-form scope passed, and the
  current shipped core now has deep create→read→check-in→streak evidence across
  browser contexts. The broader journey remains partial because reminder/scope
  confirmation, lagged coaching observation, durable Home continuation, and
  route-level loading/error boundaries are not yet proved.
- **Historical runner**:
  `/tmp/claude-oshun-lt-2-walkthrough/walk.mjs arete-create-habit` plus the
  historical `_batch4-deep` probe. Those temporary scripts are provenance, not
  the portable rerun contract.

## Result at a glance

| Lane                       | Current result                                                                                       | Disposition                  |
| -------------------------- | ---------------------------------------------------------------------------------------------------- | ---------------------------- |
| Habit-loop wizard          | Cue → routine → reward creates through the real BFF, persists the returned id, and renders the row   | Proven                       |
| Proposal form              | `/arete/habits/new` submits the canonical payload and returns `202 awaiting-coach-approval`          | Proven                       |
| First check-in             | Owner records `done`, receives a one-day streak, and can amend the same day to rest                  | Proven                       |
| Cross-device readback      | A second browser context with no local Arete store rehydrates the BFF habit/check-in state           | Proven                       |
| Home and streak projection | `/arete`, Home Arete, and `/arete/streak` reflect the new check-in within their documented authority | Proven, partly local on Home |
| Seeded sample toggle       | Visual state flips without a BFF request or persisted habit                                          | Fixture-only boundary        |
| Coaching/reminder closure  | Reminder cadence, scope confirmation, Sunday observation, durable coach decision                     | Open                         |

## Evidence map

```mermaid
flowchart LR
    A[Habit dashboard] --> B{Entry lane}
    B -->|habit-loop wizard| C[Cue routine reward]
    C --> D[POST habit]
    B -->|proposal form| E[Label cadence source why]
    E --> D
    D --> F[202 awaiting coach approval + habit id]
    F --> G[GET habit readback]
    G --> H[First check-in]
    H --> I[Persisted done + one-day streak]
    I --> J[Second-device BFF readback]
    I --> K[Arete and streak projections]
    L[Seeded sample toggle] -. local fixture only .-> A
    M[Reminder and coaching closure] -. not proved .-> F
```

## Proven observations

### Historical proposal walk

- `/arete/habits` and `/arete/habits/new` replaced the 404s recorded before the
  2026-05-29 repair.
- The proposal form exposed the required label, daily/weekly cadence,
  domain-source, and “why it matters” fields.
- `POST /v1/arete/habits` returned `202` with `state=awaiting-coach-approval`
  and a two-day review window. The current portable suites now drive this
  through the browser instead of inferring success from separate form and API
  probes.

### Current wizard and proposal lanes

- `/domains/arete/habits` opens `HabitLoopWizard` from “New Habit”; the direct
  `?wizard=loop` URL opens the same flow, and Back returns to the dashboard.
- Cue, routine, and reward fields produce the real BFF payload. The browser
  persists the returned habit id, emits `arete_habit_created` with that id and
  loop metadata, and renders the created row.
- The polished proposal lane enters from “Propose a habit,” validates
  recoverable errors without losing form state, sends the same server contract,
  reads the habit back through authenticated GET, and shows it in the list.
- A selected sample identity statement is stored locally and its line is sent as
  `whyItMatters`. The result proves this explicit payload projection; it does
  not claim a new server-side identity relation.

### Check-in, streak, and continuity

- The first real check-in posts `done` to `/v1/arete/habits/:habitId/check-in`,
  updates the created row, and reads back “Done today,” a one-day streak, and
  weekly progress.
- The BFF rejects anonymous create/check-in, too-short labels, invalid check-in
  status, and another member's habit with a non-enumerating `404`.
- A same-day `skip` amendment records a grace/rest day and returns `todayKept`
  to false instead of punishing or duplicating the day.
- A second browser context reuses only the authenticated member session—no
  `oshun.arete` local store—and rehydrates the checked-in habit from
  `/v1/arete/room`.
- `/arete/streak` reads the live overall rollup for both a fresh member and the
  first-check-in state, while the six-week heatmap and humane no-punish framing
  remain accessible.

## Boundaries and gaps

- **Accepted is not coach-approved.** Habit creation returns
  `awaiting-coach-approval`. The record can be read and checked in by the
  focused harness, but this result does not prove a durable coach review service
  or notification closed the proposal.
- **Two UI lanes share one write contract.** The wizard and proposal form are
  different customer experiences, not two independent habit stores.
- **Home continuity is mixed.** Same-browser Home Arete projection intentionally
  includes the pending local check-in. The second-device proof belongs to the
  BFF-backed Arete surfaces and must not be generalized to every Home tile.
- **Seeded toggles are fixtures.** Clicking a seeded sample habit changes
  `aria-pressed` locally, sends no check-in request, and creates no persisted
  habit. The test guards that limitation explicitly.
- **Reminder and scope choices remain open.** Cadence input exists, but a full
  reminder-delivery schedule, notification permission, and scope-confirmation
  round trip are not walked.
- **No lagged coaching observation.** The Sunday/weekly coach interpretation and
  “not this week” lifecycle are only partially represented by the broader Arete
  journey fixtures.
- **Route resilience is incomplete.** The source-reconciled journey still
  records missing focused `loading.tsx` and `error.tsx` behavior around the
  primary Arete route.

## Re-run evidence

```bash
PW_BROWSER_CHANNEL=chrome pnpm exec playwright test \
  -c apps/oshun/web/playwright.config.ts \
  apps/oshun/web/e2e/arete-create-habit.spec.ts \
  apps/oshun/web/e2e/arete-full-journey.spec.ts \
  apps/oshun/web/e2e/arete-habits-bff.spec.ts \
  --workers=1
```

The BFF suite owns persistence and authorization assertions; the browser suite
owns visual state, navigation, telemetry, continuity, and responsive behavior.
Neither should be used alone to claim the combined result.

## Source trail

- [Primary habit system](../../apps/oshun/web/src/components/domains/arete/AreteHabitSystem.tsx)
- [Habit dashboard composition](../../apps/oshun/web/src/components/domains/arete/AreteHabits.tsx)
- [Polished proposal form](../../apps/oshun/web/src/app/arete/habits/new/AreteProposeHabitForm.tsx)
- [Primary habits route](../../apps/oshun/web/src/app/domains/arete/habits/page.tsx)
- [Polished habits route](../../apps/oshun/web/src/app/arete/habits/page.tsx)
- [BFF habit and check-in routes](../../apps/oshun/bff/src/routes/domain-stubs.ts)
- [Postgres habit/check-in adapter](../../apps/oshun/bff/src/routes/domain-stubs-postgres.ts)
- [Cross-view browser spec](../../apps/oshun/web/e2e/arete-create-habit.spec.ts)
- [Real-HTTP BFF spec](../../apps/oshun/web/e2e/arete-habits-bff.spec.ts)

## Cross-references

- [Source-reconciled journey](../journeys/arete-create-habit.md)
- [Arete streak-recovery result](./arete-streak-recovery.md)
- [Arete weekly-review result](./weekly-review-arete.md)
- [Journey coverage matrix](../journeys/coverage.md)

## Open questions

- What event changes an accepted habit from `awaiting-coach-approval` to
  approved, and which customer surface owns that durable readback?
- Should the wizard and proposal lane converge visibly, or is their different
  framing intentional product segmentation?
- Which Home continuity fields must be server-backed before the same result can
  be promised across devices?
- What is the authoritative reminder scheduler and notification-permission
  contract for daily versus weekly cadence?
- Which route-level loading, retry, and recovery states should be added to make
  the primary Arete flow resilient under BFF latency or failure?