Journey result: Journey E2E quality audit — Wave 5

Walked: 2026-06-05 as a seven-auditor re-review of the then-current 52-journey suite, followed by a one-worker run against the available web and BFF development stack.
Reconciled: 2026-07-18 against the current 64-journey registry, the Wave 6 successor, and the surviving Tara, scene, Nisaba, PWA, and messages specs. This was a source reconciliation, not a fresh full-suite runtime walk.
Verdict: partial — Wave 5's durable contribution is methodological and concrete: live execution disproved auditor premises, vacuous guards were made falsifiable, and four useful failure-mode tests landed. Several observations described one 2026-06-05 environment and have since been superseded by deeper coverage or product fixes.
Lineage: Wave 4 supplied the prior repair ledger; Wave 6 later became the live work list and corrected more route and test claims.

Result at a glance#

Wave 5 lane	Dated evidence	Current source disposition	Authority limit
Auditor premise checks	A messages count and a Nisaba passage/title assumption failed in the live dev environment and were reverted	Preserved as an audit lesson, not a current product invariant; the current suites model the real messages path and explicit Nisaba unavailable/full-passage states	One environment can falsify a claim but cannot define every environment
Tara early exit	Exiting below 80% reached a shame-free `partially-completed` state	Still present in `first-tara-sit-deepening.spec.ts`, with the completion status asserted	Browser source proof was reconciled; this page did not rerun it
Tara offline reflection	Offline submission queued a `tara:reflection:*` item and exposed local-save copy	Still present, including the honest no-drain boundary after reconnect	Local queue persistence is not server synchronization
Scene failure modes	Missing-password copy and the per-owner mass-share `429 mass_share_pattern` branch were added	Both remain explicit in `scene-password-and-grants.spec.ts`	Deterministic route/store time, not a production abuse-traffic study
Vacuous format guards	Optional `count()` branches let missing BibTeX/Markdown controls pass	Closed: current notebook tests require those controls, their pressed state, changed preview, and exported content	Named formats, not every export consumer
Consent terminology	“Rejected consent suppresses update” was false; only unresolved consent held the prompt	Current PWA spec and headers consistently drive the unresolved gate and then resolve consent	Application prompt logic, not browser/OS install policy
Deferred defects	Heatmap labels and an unsubscribe race were left open	Later fixed: heatmap cells now have descriptive labels; unsubscribe arms `waitForRequest` before retrying the hydrated submit	Current source presence, not a new accessibility or flake-rate run

Evidence map#

Wave 5's strongest visual is the correction loop: an auditor claim had to survive both source review and observable runtime behavior before it could enter the coverage record.

flowchart LR A[Source-backed audit claim] --> B[One-worker live check] B --> C{Observed as claimed?} C -- no --> D[Revert overreach<br/>record environment truth] C -- yes --> E[Make assertion falsifiable] D --> F[Wave 6 and later repairs] E --> F F --> G[Current 64-journey registry] G -. fresh execution required .-> H[Current runtime verdict]

Proven observations#

The repairs that still carry evidence#

The Tara suite retries the early-exit click across a known hydration seam, then requires the partially-completed state. Its offline reflection case checks the local queue key, queued presentation, persistence through reload, and the absence of a fabricated reconnect drain.
The scene suite drives the missing-password redirect copy and isolates a per-owner share window before requiring the backend's 429 reason. That is a more falsifiable contract than asserting a mocked error body.
The Nisaba notebook suite no longer treats citation-format buttons as optional. BibTeX and Markdown controls must render and change the preview; notebook exports also pin media types and representative exported content.
The PWA update suite says what the product implements: a waiting update is suppressed while consent is unresolved. Resolving consent is distinct from accepting optional cookies and does not retroactively turn rejection into a suppressing state.
The messages unsubscribe path now arms a request waiter before the click, retries across the hydration boundary, and asserts payload plus idle success state. That later hardening closes the flake Wave 5 explicitly left behind.

Historical observations that are no longer current truth#

“0 unread of 0” described the real, unseeded BFF reached during the Wave 5 run; it was never a contractual total. The current messages coverage includes live dispatch, receipt, read, archive, unsubscribe, suppression, and restore behavior with BFF read-back.
The one-language Nisaba unavailable desk described that run's unauthenticated SSR outcome. The current scholarly-read suite deliberately owns both the unavailable projection and a full passage model with Pali, English, and Both modes. Neither fixture certifies production SSR credential propagation.
The Arete heatmap accessibility gap was real then and is closed in the current source: the heatmap has a group label and each cell receives a date/status label.
Wave 5 still called Sophia grounding and several specimen surfaces blocked or shallow. Wave 6 found registered routes and added real-HTTP coverage; current coverage.md, not the Wave 5 “verified-and-left” list, owns those grades.
Its citation-drift prose stopped at a visible skip. A later harness-ledger pass replaced that intermediate state with clean, broken, unavailable, and empty provenance assertions.

Boundaries and gaps#

A live correction is not a permanent environment contract. “0 of 0” and one-language fallback copy were observations useful for rejecting false assertions, not values every deployment should preserve.
A retry across hydration is not first-click proof. The helpers make the eventual interaction deterministic; separate performance/readiness evidence is needed if first-input responsiveness is the product promise.
A local reflection queue is not a sync engine. Reload survival proves client durability. The test intentionally records that reconnect does not drain the Tara item today.
An explicit unavailable fixture is not production outage evidence. It proves honest degradation; it does not prove the full server-component auth path or provider availability.
A rate-limit test is not abuse-system authority. Deterministic owner/time controls prove the rule, not distributed enforcement, alerting, or evasion resistance.
Source reconciliation is not current execution. None of the application E2E specs named here was rerun as part of this documentation-page audit.
The 52-journey scope is historical. The current registry contains 64 journeys and later evidence must not be back-projected into Wave 5's result.

Re-run evidence#

The surviving Wave 5 seams can be checked serially:

bash

PW_BROWSER_CHANNEL=chrome pnpm exec playwright test \
  -c apps/oshun/web/playwright.config.ts \
  apps/oshun/web/e2e/first-tara-sit-deepening.spec.ts \
  apps/oshun/web/e2e/scene-password-and-grants.spec.ts \
  apps/oshun/web/e2e/nisaba-notebook-capture-cite.spec.ts \
  apps/oshun/web/e2e/pwa-install-update-offline.spec.ts \
  apps/oshun/web/e2e/messages-center.spec.ts \
  --workers=1

Use the suite's expected web/BFF harness and retain its revisions and artifacts. A green result supports only these named seams; it does not recreate the exact Wave 5 environment or certify the current 64-journey suite.

Source trail#

Cross-references#

Open questions#

Which harness metadata should every audit artifact retain so environment facts cannot be mistaken for product invariants?
Can hydration readiness expose an explicit signal so interaction specs do not need retry loops to distinguish early clicks from product failures?
When will the Tara reflection queue gain a durable replay contract, conflict policy, and user-visible receipt?
Which test owns production-shaped Nisaba SSR authentication in addition to explicit unavailable and fixture-backed full-passage states?
How should resolved historical gaps be annotated so later readers can see both the original defect and the commit/spec that closed it?