# Feature Plan: Transport Capability Matrix ## Goal Define transport feature capabilities centrally so router/policy/UI can make deterministic decisions. ## Why This Fits GIA - GIA currently spans Signal/WhatsApp/Instagram/XMPP with uneven feature support. - Prevents silent failures (for example reaction exists internally but cannot be sent outward). ## How It Follows Plan 1 - Plan 1 established canonical event flow as the shared source language for transport actions. - Plan 2 uses that event flow to gate what may be attempted per transport before adapter calls. - Interlink: - Canonical events define **what happened** (`reaction_added`, `message_edited`, etc.). - Capability matrix defines **what is allowed** on each service at execution time. - Together they prevent drift: - no silent no-op on unsupported features, - no adapter-specific policy branching, - deterministic user-visible failure reasons. ## Required Inputs From Plan 1 - Canonical event types and normalized action shapes are stable. - Event write path exists for ingress/outbound actions. - Traceability exists for diagnostics (`trace_id`, source transport metadata). ## Scope - Add capability registry per transport. - Features: reactions, edits, deletes, threaded replies, typing, media classes, read receipts, participant events. - Runtime helper APIs used by router and compose UI. ## Implementation 1. Add `core/transports/capabilities.py` with static matrix + version field. 2. Expose query helpers: `supports(service, feature)` and `unsupported_reason(...)`. 3. Integrate checks into `core/clients/transport.py` send/reaction/edit paths. 4. Compose UI: disable unsupported actions with clear hints. 5. Add tests per service for expected behavior. ## Acceptance Criteria - Unsupported action never calls transport adapter. - User receives explicit, actionable error. - Service capabilities are test-covered and easy to update. - Capability decisions are traceable against canonical event/action context. ## Out of Scope - Dynamic remote capability negotiation.