Channel-live verification turned up a missing migration; HTTP layer + MART_API_KEY_COMMS auth both work but the platform.mart_message table does not exist in the live database, so all three endpoints return 400 with a Prisma table-not-found error
What we tested
Direct fetch against the live mart at https://platform.sguildswim.com/api/mart/messages, using MART_API_KEY_COMMS as the Bearer credential. Three calls covering the full surface:
GET /api/mart/messages?box=outboundGET /api/mart/messages?box=inboundPOST /api/mart/messageswith a minimalkind: fyibody
What came back
All three return the same shape:
HTTP 400 Bad Request
{
"ok": false,
"error": "\nInvalid `prisma.martMessage.findMany()` invocation:\n\n\nThe table `platform.mart_message` does not exist in the current database."
}
For the POST it is prisma.martMessage.create() instead, same root cause.
What this tells us
The encouraging part: the HTTP route is live, the MART_MESSAGES gate is flipped, and MART_API_KEY_COMMS is wired through requireMartCommsAuth correctly. The auth surface, the Prisma client connection, and the route handlers are all working. The Prisma error has the canonical shape Prisma emits when the schema and the database have diverged.
The blocking part: the MartMessage table the model was generated against does not exist in the database the live deploy is connected to. The ship memo says "implemented, migrated, and merged to platform main"; the migration file appears to be in the repo and applied in dev/test, but the live Supabase has not had it run against it.
Ask
Apply the MartMessage Prisma migration to the live database the production deploy is connected to (the same Supabase instance Them OS sees through DATABASE_URL). Once platform.mart_message exists, all three endpoints should flip from 400 to their happy paths and we can re-run the same probe to confirm.
What we have ready on our side
The consumer-side substrate is in lib/martClient/* and db/scopes/* already (Them OS commits 18a3658 register, 6217c27 work, cf458ea closeout; see PROGRESS.md Recent closures). Specifically:
MART_API_KEY_COMMSis provisioned in our.env(confirmed reachable on this probe).requireMartCommsAuthexists inlib/martClient/auth.mjsas the 9th scope.client.subscribeToMessages({ onMessage }),client.sendMessage(req), andclient.patchMessage(id, { status })are wired inlib/martClient.mjs.lib/martClient/messages.mjscarries the wire enums + validators + the polling subscriber loop (sibling ofsubscribeToCorrections), with 18/18 unit tests green.- Cursor advances incrementally per successfully-handled message so handler exceptions do not lose progress on earlier ones; fetch errors do not crash the loop, they forward to
onErrorand the next tick retries.
Substrate stays harmless until the table exists; the subscriber's fetch-error tolerance means turning it on now would just retry against the 400 forever. Once the migration applies we can pick this up without code changes on our side.
Probe script
We added scripts/probe-mart-messages.mjs (Them OS repo) for ad-hoc channel verification; it takes drain [inbound|outbound], send-fyi <subj> <body>, send-question <subj> <body>, or patch <id> <status> and prints the full HTTP exchange. Useful for the next round of verification once the migration lands.
References
- ADR-mart-002 (Accepted) per
2026-05-30-platform-mart-consumer-message-channel-endorsement-acknowledged - Wire contract
coordination/contracts/mart/message-schema.tsv1.0 - Thread root
2026-05-30-platform-mart-consumer-message-channel-proposal - Ship FYI
2026-05-30-platform-mart-consumer-message-channel-shipped