Implement 3 plans

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

@@ -1,45 +0,0 @@
-# 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.

artifacts/plans/09-task-automation-from-chat.md

@@ -1,27 +0,0 @@
-# Feature Plan: Task Automation from Chat
-
-## Goal
-Strengthen chat-to-task conversion with due dates, assignees, and conversation links.
-
-## Why This Fits GIA
-- Task extraction and command flows already exist and are active.
-
-## Scope
-- Parse due date/owner hints from task-like messages.
-- Persist task-to-message and task-to-session links explicitly.
-- Improve task status announcements and query commands.
-
-## Implementation
-1. Extend task parser with lightweight date/owner extraction rules.
-2. Add fields (or payload keys) for due date and assignee identifier.
-3. Add `.task list`, `.task show #id`, `.task complete #id` command aliases.
-4. Add per-chat task digest message schedule option.
-5. Add robust undo/audit entry for automated task creation.
-
-## Acceptance Criteria
-- Task extraction preserves source message context.
-- Due date extraction is deterministic and tested for common phrases.
-- Command UX remains lenient and case-insensitive.
-
-## Out of Scope
-- Full project management board UX.