Harden security

artifacts/plans/02-transport-capability-matrix.md

@@ -7,6 +7,22 @@ Define transport feature capabilities centrally so router/policy/UI can make det
 - 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.
@@ -23,6 +39,7 @@ Define transport feature capabilities centrally so router/policy/UI can make det
 - 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.