Journey result: Crisis-aware tone policy — V1 Web PWA

Walked: 2026-05-29 by Claude against commit bf12b0f7d8; that pass verified the then-current customer surfaces and public resource endpoint.
Reconciled: 2026-07-18 against the current safety journey, browser suites, BFF routes, durable crisis-frame worker, and member recovery surface. This was a source reconciliation, not a fresh runtime walk.
Verdict: partial — deep automation proves one active-input preflight on Arete, the real classifier and public resource API, an operator-activated durable five-surface frame, and the member-owned /profile/safety view. It does not connect arbitrary customer input to durable activation across every named surface, and the visible recovery choices do not close or extend the server markers.
Primary specs: arete-offering-actions.spec.ts, crisis-safety-policy-bff.spec.ts, and profile-safety-crisis-recovery.spec.ts.

Result at a glance#

Evidence lane	Current result	Authority limit
Active-input interception	`/arete/offering` preflights typed text, blocks the write, and replaces actions with a safety panel	One customer surface; no universal input-hook claim
Classification and resources	Real 13-rule BFF classifier, allow/block branches, validation/scope guards, and public resources	Test cases are policy checks, not a clinical-safety sign-off
Durable frame activation	Authorized operator activation projects markers to assistant, Iris, Lilith video, Psyche, and Tara	Operator-initiated; not bridged from customer input
Member safety record	`/profile/safety` reads live member markers, shows the timeline, resource link, and visible audit	Signed-in view; no anonymous customer safety page
Recovery presentation	Browser model covers stillness, accept/decline re-entry, 24h dismissal, 7d opt-out, and offline replay	Decisions are local; durable markers remain active
Lifecycle and cross-surface UX	Not closed	No server deactivation/extension or every-surface in-place swap

Evidence map#

The shipped evidence contains two strong paths with a missing bridge between them. Treating those paths as one end-to-end cascade would overstate the runtime.

flowchart LR A[Typed Arete intention] --> B[Live safety assessment] B -->|allow| C[Normal offering action] B -->|block| D[In-place safety interruption] D --> E[Public resources and profile handoff] B -. durable activation bridge absent .-> F[Five-surface crisis frame] G[Authorized operator activation] --> H[Redis-backed worker] H --> F F --> I[Member crisis-frame API] I --> J[Profile safety timeline] J --> K[Local stillness and re-entry model] K -. no close or extend API .-> F

Proven observations#

Active input and fail-closed behavior#

On /arete/offering, the browser sends the entered intention and region to the live Lilith safety-assessment route before any keep/send write. A blocking disposition replaces the action region with plain safety UI, exposes the support-resource and /profile/safety handoff, redacts the submitted text, and proves that the offering write did not occur.
A safety-preflight outage also fails closed before the keep/send mutation. That guard is important evidence for the one integrated surface; it does not imply the same ordering on assistant, Tara, Metis, Veritas, or other inputs.
The BFF suite covers allow and block dispositions plus missing-payload, missing-bearer, wrong-scope, and resource-suggestion validation branches.

Durable frame and member ownership#

An authorized operator activation publishes the crisis-frame event through the Redis-backed worker. The worker persists one marker for each current target—assistant, Iris, Lilith video, Psyche, and Tara—and the affected member reads those markers back. An unrelated member receives an honest empty set.
Customer-scoped activation is rejected, malformed operator activation fails, and the member endpoint requires authentication and no-store semantics.
The public resource endpoint remains available without a bearer. That proves resource data can be obtained without sign-in at the API layer, not that an anonymous browser safety surface exists.

Recovery view#

/profile/safety renders the live cross-surface timeline, expandable frame detail, visible “what happened” record, and actionable support-resource link. Opening the tested resource emits the linked safety-resource telemetry event.
The browser model covers a stillness window, accept and decline re-entry, a 24-hour check-in dismissal, a 7-day opt-out, a no-frame empty state, anonymous redirect, mobile layout, and loaded-state offline replay.
The test deliberately distinguishes browser recovery state from server marker state. Lifting local presentation restrictions does not deactivate the durable crisis frame.

Boundaries and gaps#

One preflight is not universal interception. Only the Arete offering path proves user input is checked before its domain write. The other named customer inputs need the same browser-to-BFF ordering evidence.
Classification is not durable activation. A blocking customer assessment does not currently create the five durable markers; today that verified path starts with an authorized operator call.
Projected markers are not complete in-place suppression. The store and consulting handlers are real, but the focused suites do not show every Tara, assistant, Iris, Psyche, media, reminder, notification, and generation surface switching together.
Local recovery is not server lifecycle. Re-entry, dismissal, and opt-out state is frame-namespaced browser storage. There is no verified close, deactivate, extend, expiry, or cross-device recovery write.
Public API access is not anonymous web access. /profile/safety is authenticated. A cold anonymous browser experience and offline-first resource availability are not established.
Automated scenarios are not a clinical validation. They verify software policy branches, access control, persistence, UI honesty, and failure modes; they do not establish the adequacy of signal taxonomy, wording, localization, or human-support policy.
False-positive and repeat-frame flows remain open. The customer dismissal affordance and re-frame extension behavior are not browser-driven.

Re-run evidence#

The current focused suite can be run serially with:

bash

PW_BROWSER_CHANNEL=chrome pnpm exec playwright test \
  -c apps/oshun/web/playwright.config.ts \
  apps/oshun/web/e2e/arete-offering-actions.spec.ts \
  apps/oshun/web/e2e/crisis-safety-policy-bff.spec.ts \
  apps/oshun/web/e2e/profile-safety-crisis-recovery.spec.ts \
  --workers=1

It requires the real-development-infrastructure web/BFF composition, including the safety worker and its stores. A green run proves the two current paths and their explicit seam; it must not be reported as universal crisis interception or a complete recovery lifecycle.

Source trail#

Cross-references#

Open questions#

Which shared boundary will guarantee that every Lilith-wired input runs the safety preflight before persona, generation, persistence, or delivery work?
How will a blocking customer assessment atomically create the same durable frame currently proven through operator activation?
What server contract owns close, extend, expiry, re-entry choice, follow-up preference, and cross-device recovery while preserving the member-visible audit?
Where will the anonymous, localized, cold-offline safety-resource experience live without making /profile/safety public?
What product and policy review matrix governs false-positive dismissal, repeat-frame protection, locale/tenant resource selection, and human-support handoff copy?