V1 Web PWA · Walk result

Journey result: Arete create habit

A dated evidence record for V1 Web PWA: observed behavior, current source reconciliation, automation evidence, and explicit proof limits.

verdict: partial· 2026-05-29
8sections5 minread1table
Markdown source
On this page
  • 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#

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#

Cross-references#

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?