story-kit: queue 253_bug_watcher_and_auto_assign_do_not_reinitialize_when_project_root_changes for merge
This commit is contained in:
@@ -0,0 +1,22 @@
|
||||
---
|
||||
name: "Add refactor work item type"
|
||||
---
|
||||
|
||||
# Story 254: Add refactor work item type
|
||||
|
||||
## User Story
|
||||
|
||||
As a project owner, I want a refactor work item type so that I can track and assign code restructuring tasks separately from features and bugs.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] create_refactor MCP tool creates a refactor file in work/1_upcoming/ with deterministic filename (e.g. 254_refactor_split_agents_rs.md)
|
||||
- [ ] Refactor files use the naming convention {id}_refactor_{slug}.md
|
||||
- [ ] Refactor items flow through the same pipeline as stories and bugs (upcoming → current → qa → merge → done → archived)
|
||||
- [ ] list_refactors MCP tool lists open refactors in upcoming
|
||||
- [ ] Frontend displays refactor items distinctly from stories and bugs (different label/color)
|
||||
- [ ] Watcher recognizes refactor files and auto-commits moves like stories and bugs
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -2,6 +2,10 @@
|
||||
name: "Agent assignment via story front matter"
|
||||
---
|
||||
|
||||
## Rejection Notes
|
||||
|
||||
**2026-03-16:** Previous coder only updated the serve submodule pointer — no actual implementation. Feature branch also reverted changes from stories 246 and 248. The agent front matter parsing and pipeline assignment logic was never written. Start fresh on a clean branch from master.
|
||||
|
||||
# Story 249: Agent assignment via story front matter
|
||||
|
||||
## User Story
|
||||
@@ -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
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
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
|
||||
@@ -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.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: "Watcher and auto-assign do not reinitialize when project root changes"
|
||||
merge_failure: "Squash-merge resulted in an empty diff — the feature branch has no code changes to merge into master. The feature branch appears to be fully up-to-date with master with no additional commits. The coder agent may not have committed their work, or the changes may have already been merged separately."
|
||||
---
|
||||
|
||||
# Bug 253: Watcher and auto-assign do not reinitialize when project root changes
|
||||
|
||||
## Description
|
||||
|
||||
When the server starts, if the frontend opens the project at the wrong path (e.g. server/ subdirectory instead of project root), the filesystem watcher and auto-assign run against that wrong path. When the frontend corrects itself by calling DELETE /project then open_project with the right path, the watcher and auto-assign do not reinitialize. This means:
|
||||
|
||||
1. The filesystem watcher watches the wrong directory for the entire session
|
||||
2. Auto-assign only runs once at startup (against the wrong root) and never re-runs
|
||||
3. Stories placed in 2_current/ are never auto-assigned to coders
|
||||
4. The archive sweep never fires (same watcher thread)
|
||||
|
||||
This is likely the root cause of bug 251 (archive sweep not working) and explains why coders are not being auto-assigned.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Start the Story Kit server\n2. Open a project in the frontend — note the first open_project sets project_root to the wrong subdirectory\n3. Frontend corrects by calling DELETE /project then open_project with the correct path\n4. Move a story into 2_current/\n5. Observe that no coder is auto-assigned
|
||||
|
||||
## Actual Result
|
||||
|
||||
Watcher and auto-assign remain bound to the initial (wrong) project root. No filesystem events are detected for the correct project directory. Stories in 2_current/ are never picked up.
|
||||
|
||||
## Expected Result
|
||||
|
||||
When project_root changes via open_project, the watcher thread should be stopped and restarted against the new root, and auto_assign_available_work() should re-run.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] When open_project is called with a new path, the filesystem watcher restarts watching the new project root
|
||||
- [ ] auto_assign_available_work() re-runs after a project root change
|
||||
- [ ] If DELETE /project is called, the watcher stops (no zombie watcher on a stale path)
|
||||
- [ ] Stories in 2_current/ are auto-assigned after the project root is corrected
|
||||
@@ -1,6 +1,5 @@
|
||||
---
|
||||
name: /btw Side Question Slash Command
|
||||
merge_failure: "Squash-merge resulted in an empty diff after auto-resolving a conflict in frontend/src/components/Chat.tsx. The feature branch has no code changes beyond master — the changes may have already been incorporated into master via another merge, or the conflict resolution cancelled out the feature's additions. Human investigation needed to determine whether the feature code is already on master or needs to be re-implemented."
|
||||
---
|
||||
|
||||
## User Story
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
---
|
||||
name: "/status Slash Command"
|
||||
merge_failure: "Squash-merge resulted in an empty diff — the feature branch (feature/story-242_story_status_slash_command) has no code changes beyond master. The coder agent's work may not have been committed to the feature branch, or the changes were already merged via another path."
|
||||
---
|
||||
|
||||
# Story 242: /status Slash Command
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
---
|
||||
name: "Enforce cryptographic identity verification for Matrix commands"
|
||||
merge_failure: "Cherry-pick of squash commit onto master failed with \"fatal: bad revision 'merge-queue/246_story_enforce_cryptographic_identity_verification_for_matrix_commands'\". The merge-queue branch was created and the squash commit succeeded, but the branch reference was not accessible during the cherry-pick step. This appears to be an infrastructure/git reference issue in the merge pipeline, not a code conflict. Master is untouched."
|
||||
---
|
||||
|
||||
# Story 246: Enforce cryptographic identity verification for Matrix commands
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
name: "Coder agents must find root causes for bugs"
|
||||
---
|
||||
|
||||
# Story 252: Coder agents must find root causes for bugs
|
||||
|
||||
## User Story
|
||||
|
||||
As a project owner, I want coder agents to always investigate and fix the root cause of bugs rather than layering new code on top, so that fixes are surgical, minimal, and don't introduce unnecessary complexity.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] When a coder agent picks up a bug, it must first investigate to find the root cause (e.g. using `git bisect`, `git log`, reading the relevant code history)
|
||||
- [ ] The coder's commit message must explain what broke and why, not just what was changed
|
||||
- [ ] Coders must not add new abstractions, wrappers, or workarounds when a targeted fix to the original code is possible
|
||||
- [ ] The system prompt or agent instructions for coder agents include clear guidance: "For bugs, always find and fix the root cause. Use git bisect to find breaking commits. Do not layer new code on top of existing code when a surgical fix is possible."
|
||||
- [ ] If a coder cannot determine the root cause, it must document what it tried and why it was inconclusive, rather than guessing and shipping a speculative fix
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- Changes to how stories (non-bugs) are handled
|
||||
- Automated enforcement (this is guidance/instruction, not a gate)
|
||||
Reference in New Issue
Block a user