Memory
DESIGN PROPOSAL — unified vibesdk deployment + slimmed sphere (Mike, Sep 3, 2026, ~11:48am BST; transcribed from voice, lightly cleaned; status DRAFT — under design review with Perplexity, NOT yet decided). PROPOSAL: (1) Slim the sphere repo (currently a modified clone of the upstream MIT repo = second-brain-cloudflare) down to only the pieces the product needs — remove the UI, remove the MCP server. (2) Move the slimmed sphere into an Artifacts git repo inside vibesdk. (3) EVERYTHING that gets deployed gets deployed by vibesdk — 'this is what vibesdk was built to do' — it is already Workers-for-Platforms-ready (dispatch namespaces etc.). (4) Billing + other infra/customer-lifecycle concerns live in the main DocuClear 'owner app', which interfaces with vibesdk. (5) vibesdk owns the product pieces that are deployed, deploys them, and is where code tweaks/changes happen; customer config items flow through vibesdk at deployment time. (6) Control mechanism = CONTRACT ENFORCEMENT over all of the above ('that's the right way to g—' [transcription cut off — read as 'go'/'govern it']). CLAIMED ADVANTAGE (Mike): 'huge advantage' — one deployment machinery for all product artifacts, customer config at deploy time, contracts as the control plane. KNOWN COLLISIONS for the review: the sphere line (5d0286c4, 'the deploy IS the customer lifecycle', provisioning workflows own sphere deploy); vibesdk binding-taxonomy gap (vibesdk-exploration-v1 section B: no service bindings, no secrets_store_secrets, keep_bindings unused); amend-2 wizard MCP worker inventory still open; personal-sphere MCP connectors are live tooling (do-not-decommission ruling). Review outcome to be appended.
[Update Sep 3, 2026]: [Refinement, Sep 3, 2026, ~11:56am BST — Mike, via dictation]: (1) The vibesdk in this proposal is INTERNAL ONLY — customers never get it; it is the factory that deploys the client's DocuClear system and owns the code lifecycle. (2) GREENFIELD: existing sphere repo/deployments and the current vibesdk + cloudflare-os deployments ('my current infra sitting out there') stay exactly where they are — no migration, no legacy constraints; new repos as separate entities; 'don't consider legacy'. Legacy disposition deferred ('figure out later'). (3) The contract ships INSIDE the deployed product — each client deployment is contract-configured. (4) Two questions delegated to Perplexity for recommendation: (a) repos in GitHub+Artifacts vs Artifacts-only; (b) reuse the existing vibesdk deployment vs deploy our own custom build with the contract model built in. (5) Note: prior strategy (330253d7) had vibesdk = customer-facing websites lane — this proposal is a separate internal role; existing instance may stay in the customer-website lane.
Tags: docuclear, design-proposal, deployment, vibesdk, sphere, architecture, design-review, project:docuclear, kind:episodic, volatility:state — Source: mcp — 2026-09-03 10:50:07 UTC