What is this?

One store, both sides — Jesh’s shared-database CQRS. The Approval Bus (command service — owns the queue)Approval Bus (command service — owns the queue)Service•v0.1.0The command side: owns the proposal queue. propose_* only queue; a cleared human approves in the card; only then does th...Publishesproposal-created, proposal-approved +3Subscribespropose-vendor-bill, propose-bill-date-correction +6Ownervisionary-engineeringMapRepoView docs owns writes (state transitions are row-atomic: transition(id, to, patch) claims pending→decided exactly once) and serves the read side (List Pending ApprovalsList Pending ApprovalsQuery•v0.1.0The approval inbox: every proposed mutation still awaiting a human decision.Ownervisionary-engineeringMapView docs) from the same rows. Deliberately not event-sourced and not split into read/write stores — “it’s not gonna be this complicated.”

Swappable behind the ApprovalStore interface: PROPOSAL_STORE=postgres (durable, the real topology — DO Managed Postgres) or memory (tests/demo; the live beta runs memory because nothing writes yet).

Schema

src/approvals/postgres/schema.ts (Drizzle) — proposals table: id, kind, summary, payload (jsonb), requestedBy, status, createdAt, decidedBy/At/Note, result (jsonb), error, widgetToken. Migrations via drizzle-kit. (An ERD here is directly derivable from the Drizzle schema — an Atlas/code-generation candidate.)