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.Tenant), never a client header, and that org selects the tenant's DB file AND scopes every row.

ACTIVATION is the standard enable-list gate (config.stagedSubsystems): captable mounts ONLY when the operator adds "captable" to CLOUD_ENABLE, so the mount-all default is unchanged and the standalone captable service keeps authority until the phase-2 cutover.