V1 Web PWA · Walk result

Journey result: Arete streak recovery

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

On this page
  • Walked: 2026-05-29 by Claude (Opus 4.8) against commit 3678298cd3.
  • Reconciled: 2026-07-17 against the current streak/recovery routes, humane recovery engine, Tara completion seam, journal write, coaching decision, and focused Playwright suite. This is not a fresh execution of the old walker.
  • Verdict: partial — the historical heading and tone check has grown into real threshold, engagement, journal, and plan read-back evidence. The recovery route is still reachable independently of engine eligibility, and crisis, notification, coaching-summary, social-isolation, and decline branches remain incomplete.
  • Historical runner: /tmp/claude-oshun-lt-2-walkthrough/walk.mjs arete-streak-recovery. The temporary path remains provenance only; the repository suite below is the portable rerun surface.

Result at a glance#

Evidence lane Current result Authority limit
Streak surface One heading, 42 labelled heatmap cells, no-shame promise, and navigation-only Adjust/Begin controls Controls do not mutate engagement
Recovery threshold Two missed windows stay grace_window/intact; three enter freeze_window/protected Route rendering is not eligibility-gated
Tara return Start receipt, partial/done completion, member-scoped recovery habit, and /v1/arete/room streak read-back Requires completing the destination
Written return Labelled/gated note, durable journal POST, partial recovery habit, and room read-back Decline semantics are not covered
Coach re-scope Approve/defer/undo persists; approved proposal appears in plan and next intention Weekly coaching aggregation remains open
Policy suppression No-shame copy is exercised on principal screens Crisis, quiet hours, social, and push not joined

Evidence map#

The recovery engine decides eligibility, but it does not gate the route. State changes occur only after the user completes a Tara return, saves a written return, or records a coaching decision.

flowchart LR A[Member habits and check-ins] --> B{Humane recovery engine} B -->|two missed windows| C[Grace window; streak intact] B -->|three missed windows| D[Freeze window; streak protected] D -. does not route-gate .-> E[Static recovery surface] E --> F[Tara return link] F --> G[Start and completion receipts] G --> H[Recovery habit check-in] E --> I[Written one-sentence return] I --> H H --> J[Arete room streak read-back] K[Coach proposal] --> L{Approve or defer} L --> M[Plan and intention read-back]

Proven observations#

Historical walk#

  • /arete/streak rendered one proper heading and retained the humane “practice, gently kept” framing. The then-current streak response was supplied through mock adapters.
  • That 2026-05-29 surface result repaired the earlier missing-heading and 404 defects. It did not prove threshold calculation or durable recovery effects.

Current threshold and surface evidence#

  • /v1/arete/streak folds member habits and check-ins through the humane recovery policy. Isolated records prove the exact two-window grace state and three-window protected state with humane action copy.
  • /arete/streak renders the dated/state-labelled 42-cell heatmap. Adjust links to /arete/plan?intent=adjust; Begin links to the Tara sit. The browser suite proves both navigations leave the Arete room record unchanged.
  • /arete/recovery renders “What Lilith noticed,” “An offer · not a debt,” three return sizes, a labelled one-sentence field, and the no-shame floor. It is a reachable page even when the member is not in the recovery stage.

Current engagement and coaching evidence#

  • Starting the six-minute return from origin=arete-recovery writes a Tara start receipt and reads it back from the sitting-session endpoint.
  • Finishing below or above the completion threshold records a member-scoped Tara recovery return Arete habit as partial or done. /v1/arete/room and the rendered Arete surface show the updated engagement streak.
  • Saving a sufficiently long recovery note writes through /v1/arete/recovery/journal, creates/reuses Written recovery return, records a partial check-in, and reads it back through the same room projection.
  • Approve, Not this week, and undo use /v1/arete/coach/decision. A deferral survives reload without escalating copy; an approved re-scope appears on the plan invitation and next intention row.

Boundaries and gaps#

  • Reachable is not trigger-gated. The engine's two-versus-three-window decision is real, but /arete/recovery does not mount conditionally from that decision. Tests prove engine state and page behavior as separate seams.
  • Navigation is not engagement. Streak-surface Adjust and Begin controls only navigate. Recovery engagement changes after the destination writes a journal or Tara completion record.
  • Crisis precedence is not joined here. The policy says a crisis frame suppresses recovery prompting; no focused test proves the recovery route, assistant, or notification path yields to that frame.
  • No-shame scope is bounded. Principal Arete and recovery views reject the named shaming phrases. The weekly summary, Activity, Messages, leaderboards, and shareable surfaces are not exhaustively scanned for drift leakage.
  • Outbound cadence remains unproved. Quiet hours, declined accountability, midnight/day-three push suppression, and notification delivery are not part of this result.
  • Decline and empty-data semantics remain open. A declined return should not count or break a streak; empty offers and singular/plural quiet-day copy lack focused evidence.

Re-run evidence#

The portable focused suite is:

bash
PW_BROWSER_CHANNEL=chrome pnpm exec playwright test \
  -c apps/oshun/web/playwright.config.ts \
  apps/oshun/web/e2e/arete-streak-recovery.spec.ts \
  --workers=1

It requires the web/BFF real-development-infrastructure harness. A green source audit alone is not a fresh runtime result.

Source trail#

Cross-references#

Open questions#

  • Which route or shell selector should consume the recovery engine and decide when the member actually sees the soft-return surface?
  • How is crisis-frame precedence enforced before recovery prompts, assistant suggestions, or outbound notifications appear?
  • Where are quiet hours and an explicit accountability opt-out joined to the day-three signal?
  • Which durable weekly-summary field receives the recovery pattern, and how is non-disclosure to social and leaderboards continuously verified?