Problem

The repo's queue-contract convention (doc/rfc/messagequeue-contract.md) is proto3 payloads serialized as protojson, with a contract package owning both the messages and their topic_keys bindings — api/runway/messagequeue/ is the reference example and stovepipe/core/messagequeue/ follows it. The submitqueue domain has not been ported: there is no submitqueue/core/messagequeue/ package, and 11 of its 12 topics still carry hand-rolled JSON via ToBytes/FromBytes methods on entity types.

Current state per topic:

Consequences of the split: no additive-evolution guarantees (protojson's unknown-field discard, UPPER_SNAKE enums, int64-as-string are only enforced on merge), no topic_keys binding or contract test for internal topics, and queue-payload serialization concerns living on domain entities (which are supposed to be pure data).

Work

1. Create submitqueue/core/messagequeue/ mirroring the reference layout: proto/ sources, committed protopb/, and the generic protojson glue (Marshal / Unmarshal[T] / TopicKeys) — same as stovepipe/core/messagequeue/.
2. Define proto messages for each payload shape (request-ID carrier, batch-ID carrier, build-ID carrier, queue-ID carrier, cancel request, request log) and bind each topic key to its message via the topic_keys option from api/base/messagequeue.
3. Add the contract test: protojson round-trip per message + every topic key bound to exactly one message.
4. Migrate producers and consumers topic by topic (gateway Land/Cancel publishes, all orchestrator stage controllers, core/request.PublishLog, and the DLQ controllers/republish tooling — anything touching msg.Payload).
5. Once no queue payload uses them, remove ToBytes/FromBytes from the submitqueue entity types (RequestID, BatchID, BuildID, QueueID, CancelRequest, RequestLog, and the full-entity variants) so entities go back to being pure data.
6. Bazel visibility stays domain-scoped per the internal-contract rule.

Caveats

• Wire-format flip: protojson output (snake_case fields, int64-as-string) differs from the current encoding/json entity output, so in-flight messages from before a cutover won't parse after it. Port topic-by-topic with drained queues (fine at the current pre-prod stage), or give consumers a transitional dual-format read if needed.
• The log topic crosses gateway ↔ orchestrator but both are submitqueue-domain services, so the internal contract location (submitqueue/core/messagequeue/) is correct — it must not go under api/.
• The message-ID convention is a separate concern tracked in messagequeue: entity-ID message IDs + publish dedup silently drop wake-up events; use intent-scoped message IDs #352 (intent-scoped message IDs); porting payloads to proto neither depends on nor resolves it, but call sites will be touched by both — coordinate to avoid churn.

Related

• messagequeue: entity-ID message IDs + publish dedup silently drop wake-up events; use intent-scoped message IDs #352 — intent-scoped message IDs (same call sites)
• stovepipe: keep queue contracts proto-only — retire entity JSON serializers, contracts for upcoming stages #357 — stovepipe counterpart (retire leftover JSON serializers, contracts for upcoming stages)