V1 Web PWA · Walk result

Journey result: Agentic pipeline customer invocation

A dated evidence record for V1 Web PWA: observed behavior, current source reconciliation, automation evidence, and explicit proof limits.

verdict: partial· 2026-05-29
8sections4 minread1table
Markdown source
On this page
  • Walked: 2026-05-29 by Claude (Opus 4.8) against commit bf12b0f7d8 plus the profile hydration repair made during that walk.
  • Reconciled: 2026-07-17 against the current customer Run Now component, AgentRun lifecycle routes, guarded execution route, canonical @oshun/agentic-studio engine, and focused browser/route suites.
  • Verdict: partial — the current product has a real customer request→approval→confirm/discard surface and a real server-authoritative guarded tool-plan executor. The customer result intentionally stops at queued after confirmation; provider-backed variant generation, cross-agent DAG completion, grounded composition, and a customer-visible final artifact are not proved by this walk.
  • Historical runner: /tmp/claude-oshun-lt-2-walkthrough/walk.mjs agentic-pipeline-customer-invocation. It is retained only as historical provenance.

Result at a glance#

Surface or boundary Proven result Authority limit
Customer /arete/review Run Now Request creates an approval-gated run; invoker confirms to queued or discards to cancelled Does not display a fabricated completed draft
AgentRun lifecycle BFF Submit/list/get/approve/discard with owner isolation and approval-role checks Lifecycle state is not downstream execution output
Guarded execution BFF Validates a server-owned plan, fails closed without tools, executes a registered read-only tool, honors the kill switch Focused execution contract, not every pipeline variant
Canonical engine Approval status, completion notification contract, budgets, kill switches, and dispatch primitives Provider/runtime bindings determine whether real generation can finish
Historical profile fix Stable server snapshots removed the recorded hydration mismatch A profile rendering repair, not agentic completion evidence

Evidence map#

flowchart LR A[Customer Run Now] --> B[POST AgentRun] B --> C[awaiting approval] C -->|confirm by invoker| D[queued] C -->|discard| E[cancelled] D --> F[Downstream composer or executor] F -. provider-bound completion not proved .-> G[Customer-visible artifact] H[POST runs execute] --> I{Server tool catalog} I -->|unregistered| J[503 fail closed] I -->|registered| K[Governance admission] K -->|kill switch| L[terminated before tool] K -->|admitted| M[Read-only tool result]

Proven observations#

Customer approval lifecycle#

  • AreteReviewDraftRun is mounted on the natural weekly-review surface and calls the live /v1/agentic/runs lifecycle rather than a browser-only fixture.
  • Requesting arete.weekly_review_draft creates an awaiting_approval run with the user.confirm.before.publish gate.
  • The invoker can confirm the pending run to queued or discard it to cancelled. The UI labels those states honestly and never promotes queued to “complete.”
  • Another user cannot enumerate or approve the invoker's run. The real-HTTP suite pins the non-enumerating owner boundary and the approval-role refusal.

Guarded execution boundary#

  • POST /v1/agentic/runs/execute rejects anonymous and malformed requests.
  • The plan and tool registration are server-authoritative. A planned tool that is not present in the configured catalog returns 503 agent_tools_not_configured instead of pretending to run.
  • A registered read-only Studio tool executes under the governance guard and returns its AgentRun status plus executedCount.
  • An active global kill switch terminates the run before the first tool call. The test asserts that no remaining tool executes.
  • Budget admission and deeper dispatch behavior are exercised by the BFF/domain unit suites; the customer Playwright result does not silently inherit those tests as an end-to-end output claim.

Historical walk and repair#

  • The 2026-05-29 runner proved /messages and /profile rendered and that the then-new /v1/agents and /v1/orchestrator endpoints responded.
  • It found a React hydration mismatch on /profile. The repair gave all profile useSyncExternalStore hooks a stable seed getServerSnapshot and deferred render-time date values until mount.
  • That repair remains useful product history, but route rendering and profile hydration are no longer treated as proof that an agentic job completed.

Boundaries and gaps#

  • Queued is not completed. Confirmation releases a run to the downstream composer. The result contains no provider-produced weekly-review draft and no completed AgentRun notification.
  • Two execution surfaces are distinct. The customer lifecycle routes manage approval-gated envelopes. runs/execute directly exercises the guarded server plan. Current tests prove both but do not claim the customer button invokes that direct endpoint.
  • One registered tool is not seven variants. The execution spec proves a read-only catalog tool and governance termination. It does not walk every Metis, Nisaba, Arete, Studio, and operator variant.
  • Provider credentials stay fail-closed. Provider-bound generation and grounded composition are not replaced with fixture output when bindings are absent.
  • No end-to-end provenance chain. A customer-triggered run is not followed through sub-agent DAG dispatch, Sophia grounding, Isis provenance hashing, publication review, and final delivery in one recorded test.
  • The old hydration bug is closed separately. Its fix should stay guarded by profile component/browser tests, not by this agentic result alone.

Re-run evidence#

bash
PW_BROWSER_CHANNEL=chrome pnpm exec playwright test \
  -c apps/oshun/web/playwright.config.ts \
  apps/oshun/web/e2e/agentic-pipeline-invocation.spec.ts \
  apps/oshun/web/e2e/agentic-pipeline-runnow-arete.spec.ts \
  apps/oshun/web/e2e/arete-weekly-review.spec.ts \
  --workers=1

The route suites require the real local BFF harness. Provider-backed completion must remain skipped/fail-closed when its credentials or runtime are unavailable; changing the expected state from queued to a fixture “success” would weaken this result.

Source trail#

Cross-references#

Open questions#

  • Which executor consumes a confirmed customer queued run in each deployment, and where is its completion callback made authoritative?
  • What customer surface should show provider failure, budget refusal, kill-switch termination, and retry without collapsing those states into one error?
  • Which single trace joins the customer request, approval, tool admissions, grounding evidence, provenance chain, review decision, and final artifact?
  • Which of the remaining pipeline variants have a shipped customer/operator trigger rather than only a registered lifecycle variant?