Memory
DECISION (Sep 2, 2026, ~5:36pm BST): Cloudflare OS vs vibesdk roles RESOLVED. Cloudflare OS = the customer/agent WORK ENVIRONMENT. Its built-in gadget builder is comprehensive ('outstanding in capability') and gadgets are shareable via Blueprints — no external builder needed for internal surfaces. Gadgets have NO outbound internet by design and operate only through the gatekeeper layer (Cap'n Web RPC to their gadget server, then gatekeeper bindings), which makes them pure internal-trust-domain surfaces: they physically cannot exfiltrate or be reached from the public internet. vibesdk = RESERVED for a separate SMB product feature: customer-facing websites, forms, and public apps for SMB clients. Internet-facing by nature, deployed per-app as isolated Workers into a dispatch namespace (vibesdk does this natively). This replaces vibesdk's earlier tentative role as sphere coder / evidence-centre builder (entry 794c9197) — that internal role likely folds into the OS's own agent. Design rule recorded: public apps (vibesdk) must never hold sphere credentials. Any data flow from a public form/site into a customer's sphere goes through a platform-mediated path (ingestion-service style auth or a queue), never embedded tokens. Open follow-ups for the SMB line: separate dispatch namespace for public apps (different trust/limit profile from 'spheres'), custom hostnames for client sites, per-app plan limits + metering.
[Update Sep 2, 2026]: Update (Sep 2, 2026, ~10:17pm BST): VIBESDK ROLE EXTENDED — Mike notes vibesdk can build apps using Durable Objects and even CF Agents (Agents SDK), making it the logical FUTURE LAYER for building new features and handling updates. Agreed framing (Perplexity): the trust-domain rule generalises — vibesdk is the factory for PUBLIC and PLATFORM-FACING generation; the OS's own gadget builder remains the factory for WORKSPACE-INTERNAL surfaces (gadgets stay internet-less, gatekeeper-governed). Two distinct loops: (1) PRODUCT loop — SMB client sites/forms/agents: vibesdk's native generate→preview→deploy loop, incl. updates by regeneration; (2) PLATFORM loop — vibesdk as the most powerful AUTHOR in the fleet (the 'sphere coder' role from 794c9197), but its output enters through the same contract-first, evidence-verified pipeline as any agent's code: PRs, requirement→diff mapping, the evidence centre; never direct deploy to platform workers. Note: vibesdk generating Agents-SDK code means generated apps speak the platform's own idiom (CustomerAgent/IngestionAgent/CuratorAgent patterns). OPS CONSEQUENCE: generated apps with DOs/agents consume account resources per app — the SMB product needs per-app metering + the 'no secrets in generated apps' lint rule (evidence-centre territory) from day one.
[Update Sep 2, 2026]: Update (Sep 2, 2026, ~10:34pm BST): DEPLOYMENT-INFRA THREAD CLOSED — agreed landing spot: ONE deployment idiom (containerised build+deploy, harvested from vibesdk's deployment-sandbox pattern), TWO planes. Platform plane deploys first-party bundles (sphere, OS instances, platform workers) via the provisioning workflows; vibesdk product plane deploys generated/bespoke client apps into the sites namespace. vibesdk does NOT own sphere deployment — the deploy IS the customer lifecycle (16-binding manifest injection, secrets_store_secrets, DO migrations, health-poll, keep_bindings), and stacking a second early-access upstream under the core data plane was explicitly rejected.
FUTURE DIRECTION (Mike): make vibesdk CONTRACT-BASED in a future release — generation constrained by explicit versioned contracts so generated apps are machine-verifiable against a spec rather than freeform. Lineage noted by Perplexity: this is the second application of the FlowStream component-knowledge-base insight (9b24524d — exact structural contracts beat embeddings for code generation; the commonMistakes field exists to stop code-node spam), and it plugs vibesdk into the platform's emerging contract family (INGESTION_CONTRACT, SPHERE_GATEKEEPER_CONTRACT) — every boundary a versioned contract. Candidate per-app contract artifacts: capability contract (allowed bindings, egress, secrets: none — turns the no-secrets lint into a build-time clause), interface contract (routes/APIs), data contract (schemas for writes — ties to the platform-mediated intake pattern so public forms never hold sphere credentials). Update safety becomes contract-bump-driven regeneration with requirement→diff mapping (794c9197) — client work gains a compliance-grade audit trail. SEQUENCING NOTE: ship vibesdk v1 as-is in the product loop first; design contract-based v2 from OBSERVED generation failures (collect the artifacts), not anticipated ones.
[Update Sep 2, 2026]: Update (Sep 2, 2026, ~10:56pm BST): DECISION — DocuClear's own marketing site + customer signup page will be VIBESDK-BUILT. DocuClear becomes the SMB product line's zero-customer (dogfooding: generation quality, update loop, per-app metering, no-secrets lint, custom-hostname flow all get exercised before a paying client touches them). Signup-page design rules: it is a PUBLIC app, so it calls exactly ONE platform intake endpoint; Paddle.js client-side checkout with the PUBLIC client token is acceptable (public by design), while the Paddle secret stays server-side in the admin webhook (subscription.activated → provisioning, already built — 32c6fe9a). This makes the signup page the first live exercise of the capability-contract idea: {egress: api.docuclear.ai only, secrets: none}. Sequencing: the signup site unblocks recorded next-step #1 (onboard the first real customer). Bonus: 'our own site is built by our product' is itself a marketing asset.
Tags: docuclear, decision, cloudflare-os, vibesdk, gadgets, smb-product, architecture, volatility:state, project:docuclear, kind:episodic, status:canonical — Source: mcp — 2026-09-02 16:37:29 UTC