[nikolasd]

Every digest the milestone bridge injects went through pi.sendMessage as a bare string. A bare string is oh-my-pi's shorthand for a CustomMessagePayload that omits customType, which the runtime normalizes to DEFAULT_CUSTOM_MESSAGE_TYPE ("custom-message") — the same generic type every other extension's un-typed message falls back to, rendered under a header naming no extension at all. A crew notice was indistinguishable from any other extension's.

What changed

• The bridge now sends { customType: "crew", content } on any omp build that proves it supports custom renderers (see below). Digest wording itself is unchanged.
• attachMilestoneBridge registers a renderer for that type via pi.registerMessageRenderer — a small box with crew's own icon and label as its header, the digest text as its body. Label text ("Crew") is the maintainer's agreed default, pending final confirmation on the exact wording; the icon is a placeholder pick for the same reason.

One capability check gates both the wire shape and the module

Two review findings shared one root: the code was carefully defensive about the method (registerMessageRenderer accessed through a cast, degrading to "no custom renderer" when absent) but not defensive about the two things that method's presence was meant to stand in for.

Finding 1 — the wire shape. The { customType, content } object was sent unconditionally. The package's peer range is >=17.0.7 <19, and nobody has established that a build as old as 17.0.7 accepts anything but a bare string — if it doesn't, the digest isn't "less legible" as the code claimed, it's garbled or dropped. Fixed: supportsCustomMessageRenderer(pi) is computed once at attach and read at both the registration call site and the send call site. A build without the method gets a bare-string digest, unconditionally.

Finding 2 — the module. Box/Text were a static top-level import of @oh-my-pi/pi-tui, a module the build marks --external. A static import of an external specifier is evaluated at load time, unconditionally — so a build that doesn't expose that module to extensions would fail the whole extension's load, every tool and the monitor included, not just this renderer's header. Fixed: the import moved to a dynamic await import(...) inside registerCrewMessageRenderer, itself only ever called after the same capability check. A resolution failure there (or the host's own registerMessageRenderer rejecting the renderer, covered by the same try/catch) degrades exactly like the method being absent.

Together these make the real promise provable by reading the code: on any build without custom-renderer support, the digest still arrives as plain text, unconditionally, and nothing else about the extension is at risk.

@oh-my-pi/pi-tui is a direct peer/dev dependency and a second --external in the build — registerMessageRenderer's own return type (Component) is pi-tui's, so any extension implementing this method already needs pi-tui's types regardless of how the import is structured.

Live-render gap, stated plainly

Live rendering in a real interactive omp session was not exercised by the author — this sandbox's nested PTY produces zero output for any interactive omp launch (omp --version responds instantly, so it isn't the binary). What's verified instead: the actual registerMessageRenderer call path through real @oh-my-pi/pi-tui Box/Text components (not mocks), with the rendered output asserted against the real string and confirmed to discriminate (swapped the icon, watched the assertion fail on the real render). The live proof is deferred to the protocol spike's E2E now that the terminal-path attempt is cancelled in favor of the protocol-first pivot.

Tests

Registration itself; the digest's wire shape (object when supported, bare string when not — each verified to discriminate); the renderer's real output on a plain-string digest and on a rich-content payload it must still degrade gracefully on; the combined try/catch covering both the dynamic import and the register.call that follows it; a build with no registerMessageRenderer attaching without throwing.

Gates

bun run typecheck, bun run format:check, the extension build (confirmed via the built bundle: zero static from "@oh-my-pi/pi-tui" imports remain), bun test, and cargo test --workspace all green on the committed tip, merged with origin/main at 02d90c0.