- Walked: 2026-05-29 by Claude (Opus 4.8) against commit
bf12b0f7d8plus the repair made during that walk. - Reconciled: 2026-07-17 against the current proxy, disclosure page, entitlement route, and focused Playwright suites. This is a source and automation reconciliation, not a claim that the 2026-05-29 walker was rerun.
- Verdict: partial — the historical route walk passed and the shipped boundary now has deep browser, real-HTTP BFF, mobile, telemetry, safety, and offline-replay coverage. It is still partial at journey level because the web proxy and BFF entitlement resolver are independently proven rather than one joined call chain, and proxy-side structured access-log evidence remains open.
- Historical runner:
/tmp/claude-oshun-lt-2-walkthrough/walk.mjs aaa-upgrade-entitlement-bounce. The temporary path is retained as provenance only; the repository Playwright specs below are the portable rerun surface.
Result at a glance#
| Evidence lane | Current result | Disposition |
|---|---|---|
| Studio Isis web boundary | AAA creator and operator-admin sessions receive a 307 disclosure redirect; contemplative, missing, and malformed sessions receive a non-leaking 404 | Proven |
| Disclosure page | Safe source echo, fixed internal destinations, CTA telemetry, keyboard focus, 44 px targets, mobile standalone layout | Proven |
| BFF entitlement status | Authenticated tier resolution, AAA-only surface inventory, upgrade status, anonymous 401 | Proven separately |
| Offline continuity | A warmed /aaa-upgrade document replays from the real Chromium service worker |
Proven in Chromium |
| Cross-layer authority | Proxy tags are not resolved by calling GET /v1/entitlements/aaa |
Not one joined flow |
| Proxy decision observability | Structured redirect / hard-block access logs | Open |
Evidence map#
The key distinction is product transfer versus entitlement status. The web boundary sends an already-AAA-tagged visitor to a disclosure because the raw surface lives in Yemaya; the BFF status route separately reports that the same tier is entitled and does not require an entitlement upgrade.
flowchart LR
A[Studio Isis AAA-only route] --> B{Web proxy tier}
B -->|AAA creator or operator admin| C[307 disclosure]
B -->|contemplative or invalid| D[404 app shell]
C --> E[Safe source normalization]
E --> F[Continue in Yemaya]
E --> G[Back to generation gallery]
H[BFF entitlement route] --> I{Authenticated tier}
I -->|AAA tier| J[Entitled; no upgrade required]
I -->|contemplative| K[Upgrade available]
C -. independently tested .- H
Proven observations#
Historical walk#
/aaa-upgraderendered the intended “This surface lives in Yemaya AAA Studio” transfer notice./billingandGET /v1/entitlements/aaano longer returned the 404s recorded before the repair.- The dead
/welcome/yemayadestination was replaced. The current primary destination is/studio/yemaya/studio-weband the secondary destination is/studio/generation-gallery.
Current automated evidence#
- The web spec drives the actual AAA-only Studio Isis URL without following the
first response and pins
307,X-Studio-Boundary: aaa-cta, request-source propagation, and the disclosure document. - The hard-block cases preserve the attempted URL, return
404, ship the root document language/title shell, and do not reveal either/aaa-upgradeor a legacy welcome route. fromaccepts one local/studio/isis/…path of at most 160 characters. External, repeated, tabbed, or newline-bearing values are dropped; no hostile value becomes text, a link, or a propagated query.aaa_upgrade_viewed,aaa_upgrade_open_yemaya_clicked, andaaa_upgrade_back_to_gallery_clickedare asserted with their safe source and fixed destination.- The disclosure remains overflow-free in a 390 × 844 standalone launch, and both actions meet the minimum touch-target contract.
- The BFF spec uses real HTTP to prove
aaa-creatorresolves as entitled, the default contemplative tier reports an available upgrade URL, and an unauthenticated request returns401.
Boundaries and gaps#
- Not a checkout. The disclosure is a product-boundary transfer, not a billing purchase or entitlement mutation. “Upgrade” is legacy journey vocabulary; the page itself promises access to a separately hosted product.
- No proxy-to-BFF join. The proxy resolves session tags locally. The BFF route uses authenticated scopes and the canonical Isis entitlement engine. Their agreement is regression-tested in two suites, not by a runtime call from one layer to the other.
- No structured proxy log assertion. Browser analytics cover the page and CTA events, but the redirect and hard-block decisions do not yet have a focused structured access-log contract.
- Offline scope is read-only replay. The service-worker case proves a warmed document is served offline; it does not make either destination navigable without a network.
- System Chrome is not the offline claim. The service-worker test is explicitly Chromium-only. Other engines still receive the ordinary responsive disclosure coverage.
Re-run evidence#
The portable focused suites are:
bash
PW_BROWSER_CHANNEL=chrome pnpm exec playwright test \
-c apps/oshun/web/playwright.config.ts \
apps/oshun/web/e2e/aaa-upgrade-entitlement-bounce.spec.ts \
apps/oshun/web/e2e/entitlements-aaa-bff.spec.ts \
--workers=1
They require the web/BFF real-development-infrastructure harness described by the application Playwright configuration. A green source audit alone must not be reported as a fresh browser walk.
Source trail#
- Web proxy boundary
- AAA disclosure page
- Disclosure actions and telemetry
- BFF entitlement routes
- Canonical generation entitlement service
- Boundary browser spec
- BFF entitlement spec
Cross-references#
- Source-reconciled journey
- Journey coverage matrix
- Sign-up and crypto billing result
- Lilith Studio → Tara publication result
Open questions#
- Should the journey and route be renamed around “AAA product transfer” so an already-entitled creator is not told they are upgrading?
- Should the proxy consume a shared entitlement decision adapter, or is regression-tested agreement with the BFF the intended architecture?
- Which structured event records the proxy decision, tier, safe source, request id, and hard-block/redirect disposition without leaking the protected route?
- Should offline destination taps receive an explicit network-required notice before navigation?