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

story-kit: queue 253_bug_watcher_and_auto_assign_do_not_reinitialize_when_project_root_changes for merge

Browse Source
This commit is contained in:
Dave
2026-03-16 23:23:45 +00:00
parent 7c3a756a5c
commit 2e25e2a46b
10 changed files with 124 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.story_kit/work/3_qa/245_bug_chat_history_persistence_lost_on_page_refresh_story_145_regression.md
View File

@@ -2,6 +2,10 @@
name: "Chat history persistence lost on page refresh (story 145 regression)"
---
## Rejection Notes
**2026-03-16:** Previous coder produced zero code changes — feature branch had no diff against master. The coder must actually use `git bisect` to find the breaking commit and produce a surgical fix. Do not submit with no code changes.
# Bug 245: Chat history persistence lost on page refresh (story 145 regression)
## Description

21
.story_kit/work/3_qa/249_story_agent_assignment_via_story_front_matter.md
View File

@@ -1,21 +0,0 @@
---
name: "Agent assignment via story front matter"
---
# Story 249: Agent assignment via story front matter
## User Story
As a project owner, I want to specify which agent should work on a story via a front matter field (e.g. agent: coder-opus) so that complex stories get assigned to the right coder automatically.
## Acceptance Criteria
- [ ] Story files support an optional agent front matter field (e.g. agent: coder-opus)
- [ ] When the pipeline auto-assigns a coder to a story, it uses the agent specified in front matter if present
- [ ] If the specified agent is busy, the story waits rather than falling back to a different coder
- [ ] If no agent is specified in front matter, the existing default assignment behaviour is used
- [ ] The supervisor agent respects the front matter assignment when starting coders
## Out of Scope
- TBD

34
.story_kit/work/3_qa/250_bug_merge_pipeline_cherry_pick_fails_with_bad_revision_on_merge_queue_branch.md Normal file
View File

@@ -0,0 +1,34 @@
---
name: "Merge pipeline cherry-pick fails with bad revision on merge-queue branch"
---
## Rejection Notes
**2026-03-16:** Previous coder (coder-opus) produced zero code changes. The feature branch had no diff against master. Actually fix the bug this time.
# Bug 250: Merge pipeline cherry-pick fails with bad revision on merge-queue branch
## Description
The mergemaster merge pipeline consistently fails at the cherry-pick step with: fatal: bad revision merge-queue/{story_id}. The merge-queue branch is created and the squash commit succeeds, but the branch reference is not accessible during the subsequent cherry-pick onto master. This affects every story that reaches the merge stage — no stories can be automatically merged. The issue is in the git reference handling within the merge pipeline, not a code conflict.
## How to Reproduce
1. Have a completed story in 4_merge/ with a feature branch containing commits ahead of master
2. Trigger merge_agent_work via MCP or let the mergemaster agent run
3. Observe the cherry-pick failure
## Actual Result
Cherry-pick fails with fatal: bad revision merge-queue/{story_id}. The merge-queue branch was created and squash commit succeeded, but the branch reference is not found during cherry-pick. Master is untouched.
## Expected Result
The merge pipeline should successfully squash-merge the feature branch into master, run quality gates, move the story to done, and clean up the worktree and branch.
## Acceptance Criteria
- [ ] Use git bisect or git log to find when the merge pipeline broke
- [ ] Fix the root cause — do not layer on a workaround
- [ ] Merge pipeline successfully merges a story from 4_merge to master end-to-end
- [ ] Quality gates run and pass before the merge commits to master

32
.story_kit/work/3_qa/251_bug_archive_sweep_not_moving_stories_from_done_to_archived.md Normal file
View File

@@ -0,0 +1,32 @@
---
name: "Archive sweep not moving stories from done to archived"
---
# Bug 251: Archive sweep not moving stories from done to archived
## Description
Stories that have been in `5_done/` for well over the configured retention period (default 4 hours) are not being automatically swept to `6_archived/`. Items from March 14 are still sitting in `5_done/` as of March 16 — over 2 days past the threshold. The last items that successfully reached `6_archived/` date from Feb 23-24.
Additionally, story file moves (e.g. from one pipeline stage to another) are sometimes not being auto-committed, which used to work.
## How to Reproduce
1. Start the Story Kit server
2. Move a story to `5_done/`
3. Wait longer than `done_retention_secs` (default 14400 seconds / 4 hours)
4. Observe that the story is never moved to `6_archived/`
## Actual Result
Stories remain in `5_done/` indefinitely. No sweep log messages appear in the server output.
## Expected Result
Stories older than `done_retention_secs` are automatically moved to `6_archived/` and the move is auto-committed.
## Investigation Notes
The sweep logic lives in `server/src/io/watcher.rs` around line 208 (`sweep_done_to_archived()`). The watcher runs on a dedicated OS thread (line 310) with a timer-based sweep interval (line 441, default 60s).
**Do NOT layer new code on top of this.** Use `git bisect` or `git log` to find when the sweep stopped working. The code looks structurally correct — the watcher thread may be dying silently with no restart mechanism, or something changed in how/when the sweep is triggered. Find the root cause and fix it there.