story-kit: accept 181_story_live_pipeline_updates_in_matrix

This commit is contained in:
Dave
2026-02-25 16:06:22 +00:00
parent 401138b608
commit cc30bfd82c
2 changed files with 0 additions and 0 deletions

View File

@@ -0,0 +1,42 @@
---
name: Live Pipeline Updates in Matrix
---
# Live Pipeline Updates in Matrix
## User Story
As a developer in a Matrix room, I want to see live pipeline activity — agents starting, stories moving stages, failures — posted automatically so that I can monitor progress without asking.
## Background
Story Kit already broadcasts pipeline events internally via `watcher_tx` (work item changes) and `reconciliation_tx` (reconciliation progress). The web UI subscribes to these via WebSocket. This story subscribes the Matrix bot to the same channels and posts formatted updates to the room.
This is the "social coding" feed — you're in a group chat and see things like:
- "coder-opus started on 42_story_dark_mode"
- "42 moved to QA"
- "QA passed on 42, moved to merge"
- "mergemaster merged 42 to master"
- "coder-1 failed on 38 — test suite errors"
## Acceptance Criteria
- [ ] Bot subscribes to `watcher_tx` broadcast channel for pipeline work item events
- [ ] Bot subscribes to agent state change events
- [ ] Story stage transitions (e.g., current → QA → merge → done) are posted to the room
- [ ] Agent assignments (started, completed, failed) are posted to the room
- [ ] Messages are concise and human-readable (not raw JSON dumps)
- [ ] Notification rate is reasonable — batch or debounce rapid successive events to avoid flooding the room
- [ ] Bot only posts updates when Matrix is configured and connected
## Out of Scope
- Filtering which events to post (all events go to the room for now)
- Per-room event subscriptions
- Configurable verbosity levels
- Reconciliation progress events (keep it to pipeline + agent events)
## Technical Notes
- Subscribe to `watcher_tx.subscribe()` in the matrix module's tokio task
- Format `WatcherEvent::WorkItem` and `WatcherEvent::AgentStateChanged` into human-readable strings
- Consider a short debounce (e.g., 2 seconds) to batch rapid events into a single message
- Depends on the Matrix bot story (currently 174, will be renumbered after merge)

View File

@@ -0,0 +1,36 @@
---
name: Matrix Bot Conversation Context and Multi-Room
---
# Matrix Bot Conversation Context and Multi-Room
## User Story
As a developer, I want the Matrix bot to remember recent conversation history and work across multiple rooms so that conversations feel natural and different projects or teams can have their own rooms.
## Background
The Matrix bot story (currently 174, will be renumbered) delivers a basic Matrix bot that responds to individual messages with no memory. This story adds:
- Per-room conversation context so the bot remembers what you were just talking about
- Multi-room support so a single Story Kit instance can serve multiple rooms (e.g., a project room and a 1:1 DM)
## Acceptance Criteria
- [ ] Bot maintains a rolling conversation history per room (last N messages, configurable)
- [ ] Conversation context is included when calling the LLM so it can reference earlier messages
- [ ] Bot handles multiple rooms independently (configured in `bot.toml` as a list of room IDs)
- [ ] Each room has its own independent conversation history
- [ ] History is in-memory only — restarting the server resets context (persistence is a future concern)
- [ ] Bot correctly attributes messages to different Matrix users in the conversation history
## Out of Scope
- Persistent conversation history across restarts
- Per-room configuration (different LLM models, different tool access)
- Thread-based conversations (Matrix threads)
- User-specific context or preferences
## Technical Notes
- Store conversation history as a `HashMap<RoomId, Vec<Message>>` with a configurable max length
- Trim oldest messages when the history exceeds the limit
- Include Matrix display names in the message context so the LLM knows who said what
- Depends on the Matrix bot story (currently 174, will be renumbered after merge)