Memory
OS PRODUCT LAYER — two design areas (Mike, Sep 3, 2026, ~6:50am BST): 1. TERMINOLOGY REBRAND. Cloudflare OS currently speaks developer ('gadget', the agent literally says 'I will make you a gadget') — the whole OS feels like a dev playground, but DocuClear users are SMB owners handling business. Task: a NAMING AUDIT across workshop-frontend UI strings, the agent's SYSTEM PROMPTS (the self-description lives there, not just in UI labels), and blueprint metadata. Produce a terminology map — gadget → 'app'/'tool', blueprint → 'template', gatekeeper → never user-facing — implemented as ONE wrapper-owned override/patch layer so upstream upgrades stay clean (check first whether upstream exposes i18n/strings config or AdminSettings branding hooks; if not, a single codemod patch applied on pin bump). Agent persona shifts from dev-playground to business assistant. This is the GlassAgent/DocuClear brand separation (old-sphere d13666c4) made concrete at the string level. 2. THE FILE BRIDGE. In the OS the gadget IS the document — every spreadsheet is its own live app instantiated from a blueprint. Mike's call: this is the RIGHT model (the document becomes live, computable, agent-addressable), but SMBs live in a file-based world (.xlsx arrives by email, leaves by email) and will for years. So an OfficeCLI-enabled backend bridges both: IMPORT — file arrives (email attachment via the agentic inbox, or upload) → OfficeCLI/xBerg parse → materialise a gadget from the blueprint and populate its state; the original file is preserved in R2 DOCUMENTS (originals rule) with provenance ('born from file X at T'). EXPORT — gadget state → OfficeCLI generates .xlsx/.docx/.pptx → a versioned commit in Artifacts (file projections of the live object — the context-git role from the MVP boundary) → download or email out. Round-trip fidelity (formulas, formatting, pivots) is the hard problem and is OfficeCLI's whole purpose: the old-sphere decision record 7574bce6 (OfficeCLI as rendering+mutation engine, dump BatchItem commands as the mutation contract) maps directly — gadget mutations ⇄ BatchItem commands. Define the SUPPORTED SUBSET for round-trip explicitly, and build a round-trip test corpus from real customer files (evidence standard). Mike's assessment: doable, needs design.
[Update Sep 3, 2026]: Update (Sep 3, 2026, ~6:55am BST): XBERG FIDELITY QUESTION — Mike's hypothesis: if xberg handles docx/pptx/xlsx at high fidelity, the file-bridge import problem is largely solved and OfficeCLI is needed mainly for saving compatible outputs (pivot tables later). VERIFIED from Kreuzberg/xBerg docs: full Office coverage — docx/docm/dotx/doc/odt, pptx/ppsx/ppt (native Rust + OLE/CFB legacy), xlsx/xlsm/xlsb/xls/ods via calamine — with the gold-nugget claim: 'multi-sheet support, FORMULA PRESERVATION' for Excel; PPTX gets slide extraction + image OCR + table detection; DOCX preserves formatting + metadata. Benchmarks: 91% F1 PDF markdown extraction (parity with Docling, ~3x faster); one anecdotal Reddit complaint about extraction typos — reason to test, not to trust. REFINEMENT (Perplexity): two different fidelity bars are being conflated — CONTENT fidelity (text/tables for memory/search — xberg already proven in the live pipeline) vs STRUCTURAL fidelity for the LIVE-GADGET import (cell types, merged regions, formula SEMANTICS — a gadget that must recompute needs formulas mapped into the gadget's formula model, not just preserved as strings). Charts almost certainly out of scope. PLAN — the fidelity eval (evidence standard, zero new infra — the live ingestion service IS the test rig): corpus of 20-50 real customer-type files (invoices, policies, price lists, multi-sheet workbooks with formulas/merges) → POST /extract → score per format: text exactness, table structure, sheet coverage, formula-string survival. Outcome enum: PASS-CONTENT (memory plane done) / PASS-STRUCTURE (live import via xberg) / GAP-LIST — and the gap list IS OfficeCLI's scope definition. OfficeCLI regardless owns the export plane (compatible outputs).
[Update Sep 3, 2026]: Update (Sep 3, 2026, ~7:01am BST): EXTRACTION ARCHITECTURE CALL (Mike): the PaddleOCR/Tesseract combo in the xberg container is not enough — the product needs a proper VISION model (Qwen-VL class) for intelligent document understanding, sourced via Runware (pay-per-call, no GPU infra, OpenAI-compatible API; grant credits can cover experimentation). PLUS the agentic wrestler idea: give an agent (the OpenClaw instance or our own opencode container agent) the file + xberg + office-cli + Python/JS and let it intelligently wrestle stubborn documents into usable shape — 'this is what agents are for'.
PERPLEXITY SYNTHESIS — the TIERED EXTRACTION ARCHITECTURE: Tier 1 = xberg native extraction (bulk, fast, deterministic, already live). Tier 2 = VL-model pass via Runware, behind the gatekeeper (cost-capped, logged, redaction-first per da50557b — redact BEFORE any external VL call on sensitive docs), triggered by low-confidence / complex-layout / scanned inputs. Tier 3 = the agent wrestler for documents that resist — and the killer detail: the wrestler's output is CODIFIED into a reusable recipe (script/config per nasty format), so the next similar document clears at tier 1/2 — agents convert exceptions into pipeline; the system self-improves; the eval corpus (from the previous update) becomes the fitness function. PROVENANCE: every document records its extraction_path (tier, model, cost) in the evidence store. Tier 3 is also the CALLSIGN LAYER's first production workload — 'wrestle document X' as a work item assigned to a callsign. OPEN CHECKS: VL model selection from the Runware catalogue (Qwen2.5-VL-class vs purpose-built document parsers), per-page cost/latency benchmarks to set tier thresholds, and where the wrestler runs (OpenClaw free UK instance vs own CF container agent — the agentic-workspace container pattern from July applies).
[Update Sep 3, 2026]: [Decision, Sep 3, 2026, ~10:47am BST — Mike]: INGESTION BECOMES A GADGET — the extraction surface moves into the workspace as a gadget that uses the xberg/crawlberg containers. Three-layer shape: SURFACE = ingestion gadget (upload/drop, job status, extraction review, tier visibility showing extraction_path — tier/model/cost provenance user-facing, wrestler handoff as a work item from the gadget when a document resists); APERTURE = gatekeeper-ingestion (policy/plan-tier/cost caps, approvals, audit; the gadget calls through it — gadgets have no outbound internet and never touch containers directly); MACHINERY = the shared ingestion service + containers (unchanged). Ingestion keeps TWO consumers over the same contract: the automated pipeline (sphere → ingestion: email attachments, bulk) and the interactive surface (gadget → gatekeeper-ingestion → ingestion). Lineage: the old sphere's Curator ingestion_status was the proto-version of this surface. Dogfood: Mike's own workspace uses the ingestion gadget daily. Ships with per-customer OS instances via blueprints automatically.
[Update Sep 3, 2026]: [Refinement, Sep 3, 2026, ~10:50am BST — Mike]: the ingestion SERVICE shrinks to capability — 'we just need the containers.' The tier-routing intelligence (escalation decisions, extraction review, wrestler orchestration, recipe codification) lives in the WORKSPACE: the OS agent + ingestion gadget. What remains platform-side: the xberg/crawlberg containers as dumb execution capacity, thin job bookkeeping (/jobs), and the trust-critical enforcement INSIDE gatekeeper-ingestion (auth, plan-tier/cost caps, Analytics Engine metering). BOUNDARY RULE (Perplexity): the agent proposes, the gatekeeper disposes — intelligence moves to the workspace; enforcement never does (the workspace is the customer's environment; billing/policy enforcement stays platform-side). AUTOMATED-PATH CONSEQUENCE: the email-attachment/bulk pipeline runs tier-1 deterministically server-side; anything that resists becomes a CALLSIGN WORK ITEM (the wrestler workload) rather than autonomous server-side escalation. FUTURE UNIFICATION (noted, not decided): the wrestler's execution substrate may be cloudflare/computer's container backend (e612ca12) rather than the ingestion service's containers — general compute for wrestling, dedicated containers for metered tier-1 bulk.
[Update Sep 3, 2026]: [Decomposition, Sep 3, 2026, ~10:53am BST — Mike]: ingestion splits further into CAPABILITY workspaces/gadgets — a crawl workspace/gadget (crawlberg: long-running, multi-page, URL frontiers) and an extraction workspace/gadget (xberg: single-document, sync-ish) — mapping 1:1 onto the existing containers. KEY MECHANISM (Mike): workspaces call each other via RPC (capnweb — the same RPC idiom as gadget→gadget-server, 5d0286c4). Workspaces become addressable capabilities: the main workspace orchestrates, specialised workspaces execute. GOVERNANCE RULE (Perplexity): same-trust-domain workspace↔workspace RPC is internal; CROSS-DOMAIN calls (a customer workspace → a platform capability workspace) pass through the gatekeeper aperture — contract + policy + audit at the boundary, per the every-contract-a-gatekeeper principle (6ed41ea6). The mesh in one line: callsigns route the work, RPC executes it, contracts define it, gatekeepers govern it, evidence records it. GRANULARITY GUIDANCE: a workspace earns its split when it has a distinct context, toolset, and evidence trail — crawl and extract qualify today; split further only when proven. The ac303570 plan draws from this entry at pickup time.
Tags: docuclear, cloudflare-os, ux, terminology, office-cli, file-bridge, product-layer, volatility:state, project:docuclear, kind:episodic — Source: mcp — 2026-09-03 05:50:51 UTC