captable

Overview ¶

Package captable folds hanzoai/captable into the unified hanzoai/cloud binary as an in-process subsystem (HIP-0106) — the PILOT of epic #96 (fold the Captable,Inc app into cloud, drop Next.js/Prisma/Postgres). Cloud serves the cap-table surface (/v1/captable/*) ITSELF, per tenant, on Base/SQLite.

WRAP, DON'T REWRITE — the read-WRITE variant. Where clients/plan + clients/ pricing host a read-only @hanzo catalog in goja, captable hosts the tRPC business LOGIC (ported to a self-contained goja bundle in github.com/hanzoai/ captable) and gives it PERSISTENCE over per-tenant Base/SQLite. The bundle carries logic; the Go host carries storage. The seam between them is the REUSABLE clients/gojabase binding (the RW-Base goja host), which esign (#100) and dataroom (#101) reuse unchanged — this leaf is just:

captable bundle (github.com/hanzoai/captable.Bundle)  +  the per-tenant Schema
                         │
                  clients/gojabase.New(...)   ← injects __db/__newId/__now,
                         │                       one SQLite file per tenant,
                  /v1/captable/* zip routes     one transaction per request

No Prisma, no Postgres, no Next.js in this path. Every route resolves the org from the VALIDATED cloud principal (principal.Org), never a client header, and that org selects the tenant's DB file AND scopes every row.

ACTIVATION: captable is NOT staged — it mounts under the mount-all default (empty CLOUD_ENABLE), so the one binary serves /v1/captable/* from first boot. There is no standalone Captable,Inc pod to defer to (the Next.js/Prisma/Postgres app is retired by this fold — no such deployment runs in the fleet), so cloud's fresh per-tenant Base/SQLite is authoritative from the first write, with no data to migrate.