story-kit: accept 291_story_show_test_results_in_work_item_detail_panel
This commit is contained in:
Dave
@@ -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,25 +0,0 @@
|
||||
---
|
||||
name: "Matrix bot help command lists available bot commands"
|
||||
---
|
||||
|
||||
# Story 285: Matrix bot help command lists available bot commands
|
||||
|
||||
## User Story
|
||||
|
||||
As a user in a Matrix room, I want to type "{bot_name} help" and get a list of all available bot commands with brief descriptions, so that I can discover what the bot can do without having to ask or remember.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Chat command "{bot_name} help" displays a list of all available bot-level commands (bot name comes from display_name in bot.toml)
|
||||
- [ ] Each command is shown with a short description of what it does
|
||||
- [ ] Help output is formatted for readability in Matrix
|
||||
- [ ] Help command is handled at the bot level — does not require a full Claude invocation
|
||||
- [ ] Help list automatically includes new commands as they are added (driven by a registry or similar, not a hardcoded string)
|
||||
|
||||
## Notes
|
||||
|
||||
- **2026-03-18**: Moved back to current from done. Previous attempt committed code directly to master (commit a32cfbd) instead of the worktree, and the help command is not functional in the running server. Needs a clean implementation this time.
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
name: "Server self-rebuild and restart via MCP tool"
|
||||
---
|
||||
|
||||
# Story 286: Server self-rebuild and restart via MCP tool
|
||||
|
||||
## User Story
|
||||
|
||||
As a project owner away from my terminal, I want to tell the bot to restart the server so that it picks up new code changes, without needing physical access to the machine.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] MCP tool `rebuild_and_restart` triggers a cargo build of the server
|
||||
- [ ] If the build fails, server stays up and returns the build error
|
||||
- [ ] If the build succeeds, server re-execs itself with the new binary using std::os::unix::process::CommandExt::exec()
|
||||
- [ ] Server logs the restart so it's traceable
|
||||
- [ ] Matrix bot reconnects automatically after the server comes back up
|
||||
- [ ] Running agents are gracefully stopped before re-exec
|
||||
|
||||
## 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,29 +0,0 @@
|
||||
---
|
||||
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
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
name: "rebuild_and_restart MCP tool does not rebuild"
|
||||
agent: coder-opus
|
||||
---
|
||||
|
||||
# Bug 289: rebuild_and_restart MCP tool does not rebuild
|
||||
|
||||
## Description
|
||||
|
||||
The rebuild_and_restart MCP tool re-execs the server binary but does not run cargo build first. It restarts with the old binary, so code changes are not picked up.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Make a code change to the server
|
||||
2. Call rebuild_and_restart via MCP
|
||||
3. Observe the server restarts but the code change is not reflected
|
||||
|
||||
## Actual Result
|
||||
|
||||
Server re-execs with the old binary. Code changes are not compiled.
|
||||
|
||||
## Expected Result
|
||||
|
||||
Server runs cargo build --release (or cargo build) before re-execing, so the new binary includes the latest code changes.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Bug is fixed and verified
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
name: "Remove agent thinking traces from agents sidebar"
|
||||
---
|
||||
|
||||
# Story 290: Remove agent thinking traces from agents sidebar
|
||||
|
||||
## User Story
|
||||
|
||||
As a user viewing an expanded work item in the web UI, I want to see the live agent output stream (thinking traces, tool calls, progress) for the agent working on that story, so that I can monitor progress in context rather than in the agents sidebar.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Agent thinking traces are removed from the agents sidebar panel — they should only appear in the work item detail panel (which already has SSE streaming wired up in `WorkItemDetailPanel.tsx`)
|
||||
|
||||
## Notes
|
||||
|
||||
The detail panel (`WorkItemDetailPanel.tsx`) already has agent log streaming implemented — SSE subscription, real-time output, status badges, etc. The only remaining work is removing the thinking traces from the agents sidebar (`AgentPanel.tsx` or similar) so they don't appear in both places.
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- Replacing the agents sidebar entirely — it still shows agent names, status, and assignments
|
||||
- Historical agent output (only live stream while agent is running)
|
||||
@@ -1,21 +0,0 @@
|
||||
---
|
||||
name: "Show test results in work item detail panel"
|
||||
---
|
||||
|
||||
# Story 291: Show test results in work item detail panel
|
||||
|
||||
## User Story
|
||||
|
||||
As a project owner viewing a work item in the web UI, I want to see the most recent test run results in the expanded detail panel, so that I can quickly see pass/fail status without digging through agent logs.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Expanded work item detail panel shows the most recent test results for that story
|
||||
- [ ] Test results display pass/fail counts for unit and integration tests
|
||||
- [ ] Failed tests are listed by name so you can see what broke
|
||||
- [ ] Test results are read from the story file's ## Test Results section (already written by record_tests MCP tool)
|
||||
- [ ] Panel shows a clear empty state when no test results exist yet
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
Reference in New Issue
Block a user