---
status: reconciled-partial
coverage_depth: deep
last_reconciled: 2026-07-18
specs:
  - 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
source: WALKTHROUGH/journeys/crisis-aware-tone-policy.md
---

# Journey result: Crisis-aware tone policy

- **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.

```mermaid
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

- [Source-reconciled journey](../journeys/crisis-aware-tone-policy.md)
- [Arete active-input browser suite](../../apps/oshun/web/e2e/arete-offering-actions.spec.ts)
- [Safety-substrate BFF suite](../../apps/oshun/web/e2e/crisis-safety-policy-bff.spec.ts)
- [Profile recovery browser suite](../../apps/oshun/web/e2e/profile-safety-crisis-recovery.spec.ts)
- [Crisis-frame runtime](../../apps/oshun/bff/src/safety/crisis-frame-runtime.ts)
- [Member crisis-frame route](../../apps/oshun/bff/src/safety/my-crisis-frames-route.ts)
- [Crisis-recovery policy library](../../libs/oshun/persona-policy-lilith/src/crisis-recovery/index.ts)

## Cross-references

- [Profile safety view](../customer/09-account/profile-safety.md)
- [Arete offering journey](../journeys/arete-living-offering-create.md)
- [Arete recovery view](../customer/04-arete/arete-recovery.md)
- [Tara customer view](../customer/03-tara/tara.md)
- [PWA behavior](../shell/03-pwa-behavior.md)
- [Journey coverage matrix](../journeys/coverage.md)

## 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?