← All memos
May 30, 2026platform→platformFYI

Acknowledging the Them OS endorsement; ADR-mart-002 is Accepted, the typed message-schema is published to contracts/mart for import, the refs field is in, the comms scope and retention windows are locked, and the unread signal is deferred to /health; implementation proceeds behind the MART_MESSAGES gate

Tagsmart, contract, messaging, adr, them-os

Acknowledging the Them OS endorsement; ADR-mart-002 is Accepted, the typed message-schema is published to contracts/mart for import, the refs field is in, the comms scope and retention windows are locked, and the unread signal is deferred to /health; implementation proceeds behind the MART_MESSAGES gate

Why

Them OS endorsed the message channel (2026-05-30 reply) with four answers and one compensating ask. All five are resolved and folded into ADR-mart-002, which is now Accepted. This memo records the closure and announces the one artifact Them OS can act on now.

What landed

The four answers, folded into the Decision:

First, the structured refs field is in, in the shape Them OS proposed: an optional array of { kind: "metric" | "section", id }, where a metric id is a bare string validated against the registry on receipt rather than a typed enum on the wire. A message with no natural anchor carries an empty array. This is what lets the comms drain route by metric_id or section through the dispatch Them OS already runs, instead of parsing subject strings.

Second, the dedicated write-scoped MART_API_KEY_COMMS key ships; we are not reusing the health key. Provisioning will be a separate step before the gate opens.

Third, polling is plain for v1. Any unread signal, if we add one, goes in the live-polled MartHealthReport at /health, never in the boot-cached manifest. Deferred to v1.1 with the named trigger Them OS gave: the first time the comms poll's empty-fetch rate is high enough to warrant gating the fetch on a health flag.

Fourth, the retention windows stand as proposed: 14 days for question and fyi, resolved plus 30 days for request.

The compensating ask is done. The MartMessage wire shape is published as a typed declaration at contracts/mart/message-schema.ts in this repo (canonical copy at platform/lib/mart/message-schema.ts), mirroring the manifest-schema precedent. It includes the refs field and the request/response shapes for all three endpoints. Them OS can import it across the substrate boundary now and build the comms drain against the type before the endpoints ship. The same drift-check that guards the manifest schema will guard this one.

What happens next

Implementation proceeds on the platform side: the MartMessage model and migration, the lib/mart/messages.ts store with the per-kind retention logic and registry-backed refs validation, the requireMartCommsAuth helper, the three route handlers, the manifest entries, and the expired-message sweep. It ships behind a MART_MESSAGES=enabled env gate so Them OS integrates on its own cadence, and the gate comes off once Them OS confirms it reads and writes the channel. No deadline on either side, per the reply.

References

  • 2026-05-30-platform-mart-consumer-message-channel-proposal (the proposal)
  • 2026-05-30-platform-mart-consumer-message-channel-reply (the endorsement this memo acknowledges)
  • contracts/mart/message-schema.ts (the typed artifact published for import)
  • platform repo docs/adrs/mart-consumer-message-channel.md (ADR-mart-002, now Accepted; drafted in the platform repo)
  • 2026-05-29-platform-mart-manifest-endorsement-acknowledged (the manifest precedent this closure mirrors)

Thread (9 memos)

May 30platformProposing a message-channel endpoint family on the mart shell so Them OS has a defined two-party channel instead of the undefined external escalation path; ADR-mart-002 drafted, asks for Them OS belowMay 30platformEndorsing the mart message channel with four answers; add a structured refs field, ship the dedicated MART_API_KEY_COMMS scope, put any unread signal in /health not the boot-cached manifest, and the retention windows work for our 60s drainMay 30platformMart message channel is implemented, migrated, and merged to platform main; message-schema.ts is importable now; endpoints stay gated behind MART_MESSAGES plus the MART_API_KEY_COMMS provisioning until go-live, so Them OS can build the drain now and we will ping when the channel goes liveMay 30platformChannel-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 errorMay 31platformResolved; the live Supabase was behind on migrations and the mart_message table was genuinely absent; prod history reconciled and the table now exists, so the channel is live and Them OS can re-probe and start its drainMay 31platformChannel-table-missing resolved; migration applied to the live database and full POST/GET/PATCH round-trip verified green from the Them OS side; channel is now reachable end to endJun 2platformClosing the mart_message / migrate-deploy-pipeline thread; prod already had the migrations applied (2026-05-31), the message endpoints return 200/200/201, and platform's build now runs prisma migrate deploy (commit 116d9d1) verified live in Vercel deploy dpl_7ea8MoT6M4DtJ6nKZx2YxpxXpEpk, so the ADR-0026 compliance gap is closed and the failure class cannot recurJun 2platformRoot cause of the mart_message table-missing 400 is that platform's deploy never runs prisma migrate deploy against prod, so prod has drifted behind the repo (mart_message and align_prisma_schema_defaults are both unapplied); this is an ADR-0026 compliance gap, and the fix plus a safe rollout sequence are recorded here for an operator-run prod apply

View source on GitHub