story-kit: done 288_bug_ambient_mode_state_lost_on_server_restart
This commit is contained in:
@@ -1,25 +0,0 @@
|
|||||||
---
|
|
||||||
name: "Human QA gate with rejection flow"
|
|
||||||
---
|
|
||||||
|
|
||||||
# Story 247: Human QA gate with rejection flow
|
|
||||||
|
|
||||||
## User Story
|
|
||||||
|
|
||||||
As the project owner, I want stories to require my manual approval after machine QA before they can be merged, so that features that compile and pass tests but do not actually work correctly are caught before reaching master.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- [ ] Story files support a manual_qa front matter field (defaults to true)
|
|
||||||
- [ ] After machine QA passes in 3_qa, stories with manual_qa: true wait for human approval before moving to 4_merge
|
|
||||||
- [ ] The UI shows a clear way to launch the app from the worktree for manual testing (single button click), with automatic port conflict handling via .story_kit_port
|
|
||||||
- [ ] Frontend and backend are pre-compiled during machine QA so the app is ready to run instantly for manual testing
|
|
||||||
- [ ] Only one QA app instance runs at a time — do not automatically spin up multiple instances
|
|
||||||
- [ ] Human can approve a story from 3_qa to move it to 4_merge
|
|
||||||
- [ ] Human can reject a story from 3_qa back to 2_current with notes about what is broken
|
|
||||||
- [ ] Rejection notes are written into the story file so the coder can see what needs fixing
|
|
||||||
- [ ] Stories with manual_qa: false skip the human gate and proceed directly from machine QA to 4_merge
|
|
||||||
|
|
||||||
## Out of Scope
|
|
||||||
|
|
||||||
- TBD
|
|
||||||
@@ -1,22 +0,0 @@
|
|||||||
---
|
|
||||||
name: "Rename upcoming pipeline stage to backlog"
|
|
||||||
---
|
|
||||||
|
|
||||||
# Story 287: Rename upcoming pipeline stage to backlog
|
|
||||||
|
|
||||||
## User Story
|
|
||||||
|
|
||||||
As a project owner, I want the "upcoming" pipeline stage renamed to "backlog" throughout the codebase, UI, and directory structure, so that the terminology better reflects that these items are not necessarily coming up next.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- [ ] Directory renamed from 1_upcoming to 1_backlog
|
|
||||||
- [ ] All server code references updated (watcher, lifecycle, MCP tools, workflow, etc.)
|
|
||||||
- [ ] Frontend UI labels updated
|
|
||||||
- [ ] MCP tool descriptions and outputs use "backlog" instead of "upcoming"
|
|
||||||
- [ ] Existing story/bug files moved to the new directory
|
|
||||||
- [ ] Git commit messages use "backlog" for new items going forward
|
|
||||||
|
|
||||||
## Out of Scope
|
|
||||||
|
|
||||||
- TBD
|
|
||||||
@@ -1,24 +0,0 @@
|
|||||||
---
|
|
||||||
name: "Matrix bot sends typing indicator while waiting for Claude response"
|
|
||||||
---
|
|
||||||
|
|
||||||
# Story 273: Matrix bot sends typing indicator while waiting for Claude response
|
|
||||||
|
|
||||||
## User Story
|
|
||||||
|
|
||||||
As a user chatting with the Matrix bot, I want to see a typing indicator in Element while the bot is processing my message, so that I know it received my request and is working on a response.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- [ ] Bot sets m.typing on the room as soon as it starts the Claude API call
|
|
||||||
- [ ] Typing indicator is cleared when the first response chunk is sent to the room
|
|
||||||
- [ ] Typing indicator is cleared on error so it doesn't get stuck
|
|
||||||
- [ ] No visible delay between sending a message and seeing the typing indicator
|
|
||||||
|
|
||||||
## Notes
|
|
||||||
|
|
||||||
- **2026-03-18**: Moved back to current from done. Previous attempt went through the full pipeline but merged with an empty diff — no typing indicator code was actually implemented. Needs a real implementation this time.
|
|
||||||
|
|
||||||
## Out of Scope
|
|
||||||
|
|
||||||
- TBD
|
|
||||||
@@ -1,22 +0,0 @@
|
|||||||
---
|
|
||||||
name: "Matrix bot status command shows pipeline and agent availability"
|
|
||||||
---
|
|
||||||
|
|
||||||
# Story 284: Matrix bot status command shows pipeline and agent availability
|
|
||||||
|
|
||||||
## User Story
|
|
||||||
|
|
||||||
As a user in a Matrix room, I want to type "{bot_name} status" and get a formatted summary of the full pipeline (upcoming through done) with agent assignments, plus which agents are currently free, so that I can check project status without leaving chat.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- [ ] Chat command "{bot_name} status" triggers a pipeline status display (bot name comes from display_name in bot.toml)
|
|
||||||
- [ ] Output shows all stages: upcoming, current, qa, merge, done — with story names and IDs
|
|
||||||
- [ ] Each active story shows its assigned agent name and model
|
|
||||||
- [ ] Output includes a section showing which agents are free (not currently assigned to any story)
|
|
||||||
- [ ] Response is formatted for readability in Matrix (monospace or markdown as appropriate)
|
|
||||||
- [ ] Command is handled at the bot level — does not require a full Claude invocation
|
|
||||||
|
|
||||||
## Out of Scope
|
|
||||||
|
|
||||||
- TBD
|
|
||||||
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
name: "Ambient mode state lost on server restart"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bug 288: Ambient mode state lost on server restart
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
Story 282 implemented ambient mode toggle but only in-memory. The acceptance criterion requiring persistence in bot.toml was not implemented. Every server restart (including rebuild_and_restart) clears ambient mode for all rooms.
|
||||||
|
|
||||||
|
## How to Reproduce
|
||||||
|
|
||||||
|
1. Type "timmy ambient on" — get confirmation
|
||||||
|
2. Restart server (or rebuild_and_restart)
|
||||||
|
3. Send unaddressed message — bot ignores it, ambient mode is gone
|
||||||
|
|
||||||
|
## Actual Result
|
||||||
|
|
||||||
|
Ambient mode state is lost on server restart.
|
||||||
|
|
||||||
|
## Expected Result
|
||||||
|
|
||||||
|
Ambient mode per-room state is persisted in bot.toml and restored on startup.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] Ambient mode per-room state is saved to bot.toml when toggled
|
||||||
|
- [ ] Ambient mode state is restored from bot.toml on server startup
|
||||||
|
- [ ] bot.toml.example includes the ambient_rooms setting with a comment
|
||||||
Reference in New Issue
Block a user