Changelog

Releases of Opbox, newest first. Each entry summarises what changed and links to the detail elsewhere in these docs.

v1.0.0 (2026-06-17)

The first tagged release. v1.0.0 is the point at which the whole stack stands up end to end: the substrate is built and proven, the caged agent runs against it, the governed front door serves a real sign-in and chat, and the data plane is fenced, encrypted, and audited. It is the baseline that later releases build on.

What v1.0.0 delivers

• The kernel — the one front door. A single Rust program that exposes the whole system as named verbs (matter.create, bill.charge, file.put). Around 360 verbs across ~40 noun domains, spread over four tiers, cover the matter, document, party, bill, form, file, and gate primitives, plus the management and read verbs that make each surface drivable. Roughly 68 are always-on Core; the rest unlock on demand or are admin-only. Every screen, command, and AI action goes through the kernel, which checks who you are, checks you are allowed, does the work, and writes one permanent audit record. See The kernel and the per-verb Capabilities reference.

• Postgres as the single source of truth. Matter, document, party, bill, form, file are solved, built-in primitives rather than something each practice rebuilds. The data structure is the product. See The data model.

• The matter-step engine and the closure gate. Matters advance step by step; a step can be a task, a form, or an approval (“gate”). The closure gate is not just declared, it executes - a matter cannot close until its conditions are met. Approval is kept distinct from application (APPROVED is not APPLIED).

• The caged agent. A bounded AI that calls the same verbs a person would, arriving through the AI-only door (MCP). It is capability-stripped and egress-locked: it cannot reach the internet or run loose code, and it can never do something a verb would not let a person do. The agent loop is proven against the kernel; a continuous caged-seat drainer claims and works agent tasks. See Agents & MCP.

• The governed front door. Public-facing chat requires a valid session bearer and fails closed with 401 on anonymous access; no stack surface is reachable unauthenticated except /health and the sign-in/reset bootstrap doors. The agent executes under a bounded chat-agent (a WORKER seat), never the owner key. Email/password login replaces pasted bearer tokens. See the chat guide.

• Row-level security, audit, and encryption. Every workspace-scoped table runs FORCE row-level security, so one client’s data can never be seen by another - including a closed superuser-bypass via an application-role demotion. PII and payment-rail credentials are encrypted at rest with AES-256-GCM through one shared cipher (no XOR stub paths remain). The event log is hash-chained and tamper-evident: a mutated row flips verification to “not intact.” See Security & permissions.

• The front end. An owned Next.js front end (the site root and sign-in surface, ADR-0038) over the kernel verbs, the kernel-owned tables, and the render-schema: a matter list, navigation, create and advance flows, forms, and the approval surface, proven by a live cross-stack browser run (UI to verb to RLS to Postgres and back). A hardened web Portal is the client way-in, with cross-portal access denied. See The front end.

Decided but not yet built

Kept honest, these are designed and planned but not live in v1.0.0:

• The pluggable storage backend. Files are encrypted at rest in the database, with a compiled blob-size guard on file.put. Moving the bytes out to local disk first, then SharePoint or Box, as opaque ciphertext the backend can never read - while the kernel keeps every access decision and the full audit trail - is a settled design and the seam is built at the type level, but the backend itself, the browsable per-matter folder view, and the external backends are not yet enabled. See Files & storage.

• External integrations. The connection.* / credential.* shape exists, but real Xero/Stripe/SSO sync needs live endpoints and credentials and is not wired end to end.

• Adjustable per-deployment limits. Some caps (such as the file blob-size limit) are fixed values baked into the build; making them adjustable per deployment is planned.