dave/storkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity

story-kit: accept 96_story_reset_agent_lozenge_to_idle_state_when_returning_to_roster

Browse Source
This commit is contained in:
Dave
2026-02-23 20:52:06 +00:00
parent 7f18542c09
commit bed46fea1b
13 changed files with 627 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
.story_kit/work/2_current/96_story_reset_agent_lozenge_to_idle_state_when_returning_to_roster.md
View File

@@ -1,19 +0,0 @@
---
name: "Reset agent lozenge to idle state when returning to roster"
---
# Story 96: Reset agent lozenge to idle state when returning to roster
## User Story
As a user, I want agent lozenges to return to their idle appearance (grey with green dot) when they move back to the Agents roster, so that the UI accurately reflects which agents are currently active.
## Acceptance Criteria
- [ ] Agent lozenges in the Agents roster always display in idle state (grey background with green dot)
- [ ] After an agent completes work and returns from current/qa/merge to the roster, its lozenge resets to idle appearance
- [ ] Lozenges still show amber/green states while assigned to work items in current/qa/merge
## Out of Scope
- TBD

28
.story_kit/work/2_current/97_bug_agent_pool_allows_multiple_instances_of_the_same_agent_to_run_concurrently.md
View File

@@ -1,28 +0,0 @@
---
name: "Agent pool allows multiple instances of the same agent to run concurrently"
---
# Bug 97: Agent pool allows multiple instances of the same agent to run concurrently
## Description
The agent pool does not enforce single-instance concurrency per agent name. When the pipeline auto-advances (e.g. coder finishes and QA starts automatically), it spawns a new agent instance even if that agent is already running on another story. With only one QA agent defined in project.toml, two QA processes were observed running simultaneously on different stories, driving load average past 33 on an M1 Mac. Each QA run spawns cargo clippy, cargo test, and vitest — two concurrent runs is brutal on resources.
## How to Reproduce
1. Have one QA agent defined in project.toml\n2. Start a coder on story A — when it completes, pipeline auto-starts QA on story A\n3. While QA is running on story A, start a coder on story B — when it completes, pipeline auto-starts QA on story B\n4. Observe two QA agents running simultaneously despite only one being defined
## Actual Result
Two QA agent processes run concurrently, competing for CPU and causing extreme load.
## Expected Result
The agent pool should enforce single-instance concurrency per agent name. If QA is already running, the next QA job should queue until the current one finishes.
## Acceptance Criteria
- [ ] Agent pool checks if an agent name is already running before spawning a new instance
- [ ] If the agent is busy, the new job is queued and starts when the agent becomes available
- [ ] Pipeline auto-advancement respects the concurrency limit
- [ ] cargo clippy and cargo test pass