v0.2 MCPs and Skills release gate #

pnpm test:golden-path runs one connected installation and customer session through the existing twelve v0.1 checkpoints, then the connected MCP and Skill flow below. 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.

After checkpoint 12 proves the installation, the same owner session continues:

• Add an MCP server and enter its bearer credential through Extensions. The native Agents SDK connects, authenticates and discovers three tools and a resource.
• Enable then disable one tool. The inference fixture checks the actual advertised tool set and rejects any appearance of that disabled capability. Invoke the enabled read tool and read the discovered resource through native capabilities.
• Invoke an Ask tool, confirm that the external server has received no call while approval is pending, approve once, and require exactly one invocation. Inspect the persisted source and approval details in conversation activity.
• Review an uploaded Skill's provenance, instructions, reference, script and declared requirements before installing it disabled. Inspect the real default permissions, then enable it.
• Prove an unrelated turn has no private Skill instruction or reference content. A relevant turn activates the Skill through the native registry, reads its reference, and requests its script. Approve execution through the owner UI and inspect the real WorkerLoader result and recorded activity.
• Disable the Skill and use a fresh conversation to verify native activation rejects it and its script action is absent from the model's tools.
• Restart the customer with the same native storage and owner session. Require persisted MCP tool/policy settings and authenticated reconnection, plus the installed Skill's disabled state and permission choices.
• Download diagnostics through the owner UI. Require extension evidence while excluding credential, instruction, resource, script input/output and conversation canaries.

This remains one connected test: no checkpoint seeds application state or creates an alternate owner session to stand in for an earlier step. The fixture's small MCP server implements the external wire protocol and counts real invocations; production native client, discovery, policy, approval and activity paths run unchanged. Skill installation uses the real owner HTTP flow and R2 storage; activation and script execution use the native Agents SDK and WorkerLoader. The fixed inference boundary derives replies from actual returned results and checks the advertised tool catalog and lazy instruction context.

The fixed external boundaries are Cloudflare OAuth/token/account responses, Cloudflare deployment REST, inference, the MCP server 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.