🏗️ Architecture: How should the S211 rich message type system be structured?

Date: 2026-03-13
Time: 01:44:56 UTC
Session: gspace1-211.2
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should the S211 rich message type system be structured?

Task: S211 Tasks 1-3: RichMessage type system, ChannelAdapter interface, AdapterRegistry service

🎯 Decision Made

Chosen:

Discriminated union of 8 message types (text, quick_reply, list_picker, card, carousel, cta, media, location) with BaseRichMessage containing type discriminant + fallbackText. Factory helpers enforce WhatsApp constraints (button limits, char limits) at creation time.

Options Considered:

• No alternatives documented

💭 Reasoning

Discriminated unions give exhaustive switch/case checking at compile time. fallbackText ensures every message degrades gracefully on channels that can't render rich types. Factory helpers bake in WhatsApp constraints (3 buttons max, 20 char buttonText, 10 cards max) so downstream code doesn't need to validate. Channel-agnostic design means adapters handle the translation, not the message creators.

📁 Files Involved

• APIs/backend-vitto-api/src/app/engine/rich-messages/rich-message.types.ts
• APIs/backend-vitto-api/src/app/engine/adapters/channel-adapter.interface.ts
• APIs/backend-vitto-api/src/app/engine/adapters/adapter-registry.service.ts

🔗 Related

• Decision ID: dev_1773366296672_g3gsele
• Session: 211
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation