PRD-022: Reliable Cross-Context Messaging Platform

1
2
3
4
5
Given a command that modifies domain state
When the command handler commits
Then the state change and outbox event are in the same transaction
And if the transaction fails, neither is persisted
And INV-022 (atomic state+event) holds

1
2
3
4
5
Given an incoming event message
When the consumer attempts to process
Then it first inserts into inbox_messages with message_id PK
And if conflict (duplicate), processing is skipped
And INV-021 (exactly-once processing) holds

1
2
3
4
5
6
Given a message being processed
When the handler returns 5xx or times out
Then the consumer does NOT ACK the message
And JetStream redelivers after ack_wait expires
And the message appears again for processing
And INV-020 (at-least-once delivery) holds

1
2
3
4
5
6
Given a message with invalid payload or schema mismatch
When the handler returns 422 Unprocessable
Then the consumer publishes to DLQ subject
And marks original message as failed in inbox
And ACKs the original message (prevents infinite retry)
And POL-022 (poison handling) holds

1
2
3
4
5
Given an outbox event to publish
When the publisher sends to JetStream
Then the Nats-Msg-Id header is set to outbox.id (UUID)
And JetStream deduplicates within its window
And republishes after crash don't create duplicates

1
2
3
4
5
Given SEA™ and VibesPro™ contexts
When configuring JetStream
Then SEA_EVENTS stream captures sea.event.>
And VIBESPRO_EVENTS stream captures vibespro.event.>
And each context owns retention/limits for its stream

1
2
3
4
5
Given a Rust consumer worker
When fetching messages from JetStream
Then it uses pull-based fetch with batch size
And explicitly ACKs after successful processing
And can control concurrency via max_ack_pending

1
2
3
4
5
6
Given an event type vibe_created
When publishing
Then subject is vibespro.event.vibe_created.v1
And .v1 payload schema is immutable
And breaking changes require .v2
And consumers can handle multiple versions

1
2
3
4
5
Given an event consumed from JetStream
When the worker dispatches to a handler
Then the HTTP request body includes message_id, subject, event_type, event_version,
And occurred_at, correlation_id, causation_id, aggregate_type, aggregate_id, payload
And the handler responds with 200/409/422/5xx per SDS-047

1
2
3
4
5
Given a message has been moved to DLQ
When the replay worker runs
Then it re-publishes after exponential delays with jitter
And updates replay_attempts in dlq_metadata
And stops replay after a configured max attempt cap

1
2
3
4
Given updated manifest events
When the registry generator runs
Then a static handler registry is produced with stable ordering
And the worker uses the generated registry without hot-reload