This repository has no description
flarebot docs golden-path.md
4.3 kB

v0.1 golden-path release gate #

pnpm test:golden-path runs one connected installation and customer session through the twelve release-defining steps. It requires Node/pnpm dependencies, Playwright Chromium and Docker with the pinned public Sandbox image available.

Build the customer before the publisher because the customer build clears dist:

pnpm build:release
pnpm build:control-plane
pnpm exec playwright install chromium
docker info
pnpm test:golden-path

CI runs this gate sequentially after the production builds and existing native checks. During uncommitted development, use build:control-plane:fixture if the customer release is dirty; production catalog packaging rejects dirty artifacts.

  1. Install from the actual publisher UI after OAuth and account selection. The native InstallationWorkflow uploads a checksummed fixture release. Its accepted module and asset bytes, installation configuration and session secret launch the customer Worker. Production signed health checks actual packaged assets, authorization denials, PersonalAgent and a disposable Docker Sandbox before registry Ready. Open Flarebot performs the actual owner PKCE bridge and issues its Secure HttpOnly cookie.
  2. Save a nondefault Workers AI model through Settings and verify it after reload.
  3. Ask the agent to remember a fact through the native remember action.
  4. Create a different conversation and answer using its actual saved-memory context. The original conversation's user message must be absent.
  5. Search and read a public page with native web tools; persist and display the returned evidence and citations.
  6. Render another page through native Chromium. The answer must use evidence inserted by JavaScript after navigation.
  7. Run a small Node.js calculation through the production shell tool in the real Sandbox container, checking stdout and completed workspace cleanup.
  8. Ask the agent to create a one-off future UTC task through createSchedule.
  9. Close every browser context and customer WebSocket before the due time.
  10. Keep the Worker alive while its native alarm, Agents scheduler and Think submission execute. A passive completion hook reports to the local runner. There must be zero customer sockets and no customer requests between disconnection and this completed event. A claimed/running task is insufficient.
  11. Stop and restart the customer on the same native identity and SQLite directory, then reconnect with the cookie issued by the real owner bridge.
  12. Verify both conversations, source/tool activity history and the exact completed task run. One native scheduled submission, one scheduled user prompt and one assistant result must remain in the intended conversation. Repeated delivery of a completion notification does not count as another execution.

The fixed external boundaries are Cloudflare OAuth/token/account responses, Cloudflare deployment REST, inference and public destination pages. The inference fixture chooses tools from natural-language requests and derives answers from real tool results or the actual memory context; it never seeds memory or tasks. No ready-row seeding, manually minted cookie, health override, manual alarm dispatch or owner task reconciliation establishes a claimed step.

The launcher validates the complete accepted Worker binding/runtime/export/assets and Containers relation before adapting filesystem paths and local resource allocation. It also validates the accepted Containers application configuration against the native pinned image and resource contract. Account-level namespace and application IDs belong to the fixed REST boundary; local workerd owns its real namespace allocation. Test entries and loopback ports are absent from production bundles. Temporary archives, private accepted upload data and native state are removed together with owned services during teardown.

This is reproducible local release evidence. It does not certify live Cloudflare OAuth scopes, account entitlements, account uploads, propagation timing or hosted Container rollout behavior. The separate upgrade gate still proves two immutable releases preserving native state; this golden path covers a fresh installation.