story-kit: create 316_refactor_abstract_bot_transport_layer_for_multi_platform_support

.story_kit/work/1_backlog/316_refactor_abstract_bot_transport_layer_for_multi_platform_support.md

@@ -0,0 +1,36 @@
+---
+name: "Abstract bot transport layer for multi-platform support"
+---
+
+# Refactor 316: Abstract bot transport layer for multi-platform support
+
+## Current State
+
+- TBD
+
+## Desired State
+
+Extract the Matrix-specific bot code behind a transport trait so the command registry, pipeline status, and all bot commands work across multiple chat platforms. The command registry in commands.rs is already transport-agnostic (takes a string, returns a string). The Matrix-specific parts (message sending, message editing for htop, typing indicators, room IDs, ambient mode) need to be behind an abstraction.
+
+After this refactor:
+- A ChatTransport trait defines send_message, edit_message, send_typing, etc.
+- MatrixTransport implements the trait using the existing matrix-sdk code
+- A stubbed WhatsAppTransport implements the trait with no-ops or TODOs
+- The command dispatch and bot logic work against the trait, not Matrix directly
+- htop's message editing works through the trait (WhatsApp stub can just send new messages instead of editing)
+- All existing Matrix functionality continues to work unchanged
+
+## Acceptance Criteria
+
+- [ ] Define a ChatTransport trait with methods for: send_message, edit_message, send_typing_indicator, get_room_id
+- [ ] MatrixTransport implements the trait using existing matrix-sdk code from bot.rs
+- [ ] WhatsAppTransport stub implements the trait with TODO/no-op implementations
+- [ ] Command dispatch (try_handle_command) works against the trait, not Matrix types directly
+- [ ] htop message editing works through the trait
+- [ ] All existing Matrix bot functionality preserved — no regressions
+- [ ] Transport is selected via config (e.g. bot.toml transport = 'matrix')
+- [ ] Tests pass with both Matrix and stub WhatsApp transports
+
+## Out of Scope
+
+- TBD