46 lines
2.0 KiB
Markdown
46 lines
2.0 KiB
Markdown
# 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.
|