event.clinic · suite overview
Each figure below is parsed from that product’s own build ledger by the same code that renders its own status page, so the two cannot disagree. Nothing here is typed in by hand.
The events platform the other products read from — and the only one
publishing a no-login surface, /directory/v1.
Three products read event.clinic’s database directly, one consumes its public directory,
and the layout and seat-map engine lives in its repository and is shared rather than copied.
One caution worth stating plainly: much of that coupling is currently accidental —
ALTER DEFAULT PRIVILEGES grants every new app table to Mise unless
someone remembers to REVOKE. A declared hub should mean a published contract,
not more implicit sharing.
Artist management
27 complete · 1 in progress · 5 not started · 33 total
Own auth, own database. The sell side of the live deal. Ecosystem bridge is S31 — pending, and it says to re-measure siblings first.
Open the ShowLedger24 status page →Catering management
19 complete · 4 in progress · 3 not started · 26 total
Reads event.clinic directly as mise_rw — identified by the database role it connects as, impersonating no tenant.
AV production & rental
14 complete · 1 blocked · 17 not started · 32 total
Lives in the av schema of event.clinic’s database, read-only on app. Couplings are T22 and T30, both not started.
Temporary workforce
16 complete · 1 in progress · 23 not started · 40 total
Not yet coupled. Mise’s X4 exists to receive its crew (agency kind, agency_worker_ref) and is blocked on Q-007.
Recorded in Mise’s own ledger as slices X1–X6 — the one place the couplings are currently written down. Two of the six have no transport: the logic is built and tested, but nothing carries the payload between products.
| Slice | Coupling | Status | The ledger’s note |
|---|---|---|---|
| X1 | Mise → event.clinic | live | Reader, snapshot model, sync check and exception lifecycle all built and tested. The engaged event returns rows; an unengaged one returns none. |
| X2 | Mise → Estate | partial | GET /api/venues/:id joins venue, spaces, Estate’s diary and Mise’s kitchen. Reads Estate defensively and returns estateReadable: false rather than an empty array. |
| X3 | Mise → Procurevent | partial | Bid requests, requirements, responses and the submission gate all built. No transport — Q-005. |
| X5 | Mise → VELA | partial | The inbound receiver stores verbatim then processes. It refuses to guess which sitting a requirement belongs to. No transport — Q-007. |
| X4 | Mise → Verbunk | not started | The agency crew kind and agency_worker_ref exist to receive it. Q-007. |
| X6 | Mise → Rigfold | not started | Same database, so the cheapest of the six. |
These four are not absent from the dashboard because they are unbuilt — VELA is live in production and event.clinic is the hub. They are absent because none of them has a ledger with one row per unit of work and a status on it, and a page generated from anything less would be hand-maintenance wearing a generator’s clothes.
Venue & property portal
Has: docs/03-delivery/status-2026-08-02.md — a layer table (schema, reference data, fixture, API, portal) with how each was verified.
Missing: That table records layers, not slices, and carries no status column. A generated page needs one row per unit of work with a status.
Wedding planning · live at velawel.com
Has: PROGRESS.md with a ticket table and 211 passing tests.
Missing: The table lists only what is done. Generating from it would report 100% complete, which would be false rather than merely thin.
Event procurement
Has: 16 numbered handoff documents and a decision log.
Missing: The module table in the master brief is a specification (“required in MVP”), not a build record. Nothing states what is built.