storkit: accept 423_story_auto_schedule_timer_on_rate_limit_to_resume_after_reset
This commit is contained in:
dave
@@ -1,30 +0,0 @@
|
||||
---
|
||||
name: "Split matrix/bot.rs into focused modules"
|
||||
---
|
||||
|
||||
# Refactor 417: Split matrix/bot.rs into focused modules
|
||||
|
||||
## Current State
|
||||
|
||||
- TBD
|
||||
|
||||
## Desired State
|
||||
|
||||
Refactor the monolithic server/src/chat/transport/matrix/bot.rs (1926 lines) into focused submodules.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] history.rs contains ConversationRole, ConversationEntry, RoomConversation, PersistedHistory, load_history, save_history and their unit tests
|
||||
- [ ] context.rs contains BotContext struct
|
||||
- [ ] run.rs contains run_bot main event loop
|
||||
- [ ] messages.rs contains on_room_message, handle_message, format_user_prompt, is_permission_approval and their unit tests
|
||||
- [ ] mentions.rs contains mentions_bot, contains_word, is_reply_to_bot and their unit tests
|
||||
- [ ] verification.rs contains check_sender_verified, on_to_device_verification_request, handle_sas_verification and their unit tests
|
||||
- [ ] format.rs contains markdown_to_html, format_startup_announcement and their unit tests
|
||||
- [ ] mod.rs re-exports all public types
|
||||
- [ ] Unit tests live in their respective module files
|
||||
- [ ] No public API changes — all existing imports continue to work
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
name: "Split pool/auto_assign.rs into submodules"
|
||||
---
|
||||
|
||||
# Refactor 418: Split pool/auto_assign.rs into submodules
|
||||
|
||||
## Current State
|
||||
|
||||
- TBD
|
||||
|
||||
## Desired State
|
||||
|
||||
Refactor the monolithic server/src/agents/pool/auto_assign.rs (1813 lines) into focused submodules.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] auto_assign.rs contains auto_assign_available_work and its unit tests
|
||||
- [ ] reconcile.rs contains reconcile_on_startup and its unit tests
|
||||
- [ ] watchdog.rs contains run_watchdog_once, spawn_watchdog, check_orphaned_agents and their unit tests
|
||||
- [ ] scan.rs contains scan_stage_items, is_story_assigned_for_stage, count_active_agents_for_stage, find_free_agent_for_stage, is_agent_free and their unit tests
|
||||
- [ ] story_checks.rs contains read_story_front_matter_agent, has_review_hold, is_story_blocked, has_merge_failure and their unit tests
|
||||
- [ ] mod.rs wires the submodules and re-exports all public items
|
||||
- [ ] Unit tests live in their respective module files
|
||||
- [ ] No public API changes — all existing imports continue to work
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
-29
@@ -1,29 +0,0 @@
|
||||
---
|
||||
name: "Matrix bot crashes on transient network error instead of retrying"
|
||||
---
|
||||
|
||||
# Bug 419: Matrix bot crashes on transient network error instead of retrying
|
||||
|
||||
## Description
|
||||
|
||||
The Matrix bot treats a transient sync error as fatal and stops entirely. A single failed HTTP request to the homeserver kills the bot, requiring a full server rebuild to recover.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Run storkit with Matrix bot enabled\n2. Homeserver becomes temporarily unreachable (network blip, DNS hiccup, server restart)\n3. Bot hits sync error and crashes
|
||||
|
||||
## Actual Result
|
||||
|
||||
Bot logs "Fatal error: Matrix sync error: error sending request for url (...)" and stops responding. No retry, no recovery.
|
||||
|
||||
## Expected Result
|
||||
|
||||
Bot logs a warning, backs off with exponential delay, and retries the sync. Only crash on unrecoverable errors (invalid credentials, banned, etc).
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Transient network errors (connection refused, timeout, DNS failure) trigger a retry with exponential backoff
|
||||
- [ ] Bot logs a warning on each failed retry attempt
|
||||
- [ ] Bot resumes normal operation once the homeserver is reachable again
|
||||
- [ ] Unrecoverable errors (401, 403) still cause a clean shutdown with a clear error message
|
||||
- [ ] Bot sends a notification after recovering from a network outage
|
||||
-23
@@ -1,23 +0,0 @@
|
||||
---
|
||||
name: "loc for a specified file — bot command and web UI slash command"
|
||||
---
|
||||
|
||||
# Story 420: loc for a specified file — bot command and web UI slash command
|
||||
|
||||
## User Story
|
||||
|
||||
As a developer, I want to send `loc <filepath>` to the bot or use it as a slash command in the web UI to see the line count for a specific file, so I can quickly check how large a file is without leaving my workflow.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] loc <filepath> returns the line count for the specified file
|
||||
- [ ] Relative paths are resolved against the project root
|
||||
- [ ] If the file does not exist, returns a clear error
|
||||
- [ ] Works from all transports (Matrix, WhatsApp, Slack)
|
||||
- [ ] Works as a slash command in the web UI
|
||||
- [ ] loc with no argument retains existing behavior (top files by line count)
|
||||
- [ ] Exposed as an MCP tool so agents can query file line counts programmatically
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
name: "Timer command for deferred agent start"
|
||||
---
|
||||
|
||||
# Story 421: Timer command for deferred agent start
|
||||
|
||||
## User Story
|
||||
|
||||
As a ..., I want ..., so that ...
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Bot command `timer <story_id> <HH:MM>` schedules a one-shot deferred start for the given story at the next occurrence of that time (server-local timezone)
|
||||
- [ ] Bot command `timer list` shows all pending timers with story ID and scheduled time
|
||||
- [ ] Bot command `timer cancel <story_id>` removes the pending timer for that story
|
||||
- [ ] Timers are persisted to .storkit/timers.json so they survive server restarts
|
||||
- [ ] A 30s tick loop (tokio task, same pattern as watchdog) checks for due timers and calls start_agent when triggered
|
||||
- [ ] When a timer fires, the story must already be in current — timer does not move stories between stages
|
||||
- [ ] Fired timers are removed after execution (one-shot, not recurring)
|
||||
- [ ] Multiple timers for the same time are supported and respect agent slot contention via auto-assign
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
name: "Unblock command to reset blocked stories"
|
||||
---
|
||||
|
||||
# Story 422: Unblock command to reset blocked stories
|
||||
|
||||
## User Story
|
||||
|
||||
As a ..., I want ..., so that ...
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Bot command `unblock <story_id>` clears blocked flag and resets retry_count to 0 on the story front matter
|
||||
- [ ] Replies with confirmation including story ID and name
|
||||
- [ ] Returns clear error if story is not found or not blocked
|
||||
- [ ] Works from all transports (Matrix, WhatsApp, Slack)
|
||||
- [ ] Exposed as an MCP tool so agents can unblock stories programmatically
|
||||
- [ ] Works as a slash command in the web UI
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
-22
@@ -1,22 +0,0 @@
|
||||
---
|
||||
name: "Auto-schedule timer on rate limit to resume after reset"
|
||||
---
|
||||
|
||||
# Story 423: Auto-schedule timer on rate limit to resume after reset
|
||||
|
||||
## User Story
|
||||
|
||||
As a ..., I want ..., so that ...
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] When a rate_limit_event with a hard block (not just allowed_warning) is received from the PTY stream, parse the reset time from rate_limit_info
|
||||
- [ ] Automatically create a timer (via TimerStore from story 421) for the blocked story at the parsed reset time
|
||||
- [ ] If a timer already exists for that story, update it to the later reset time rather than creating a duplicate
|
||||
- [ ] Log the auto-scheduled timer with story ID, agent name, and scheduled resume time
|
||||
- [ ] Notify chat transports that the story was rate-limited and will auto-resume at the scheduled time
|
||||
- [ ] When the timer fires and restarts the agent, the existing worktree and committed work are preserved
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
-23
@@ -1,23 +0,0 @@
|
||||
---
|
||||
name: "Rate limit traffic light status and hard block alerts"
|
||||
agent: coder-opus
|
||||
---
|
||||
|
||||
# Story 424: Rate limit traffic light status and hard block alerts
|
||||
|
||||
## User Story
|
||||
|
||||
As a ..., I want ..., so that ...
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Remove repetitive per-message throttle warnings (allowed_warning) from chat transports entirely
|
||||
- [ ] Pipeline status messages show a coloured dot next to each work item: green for running normally, yellow for throttled, red for hard blocked, white/grey for idle/no agent
|
||||
- [ ] Hard block events (429 / rate_limit_exceeded) still send an individual chat notification with a red icon, including the reset time
|
||||
- [ ] Throttle and block state tracked per-agent so the status dot updates in real time
|
||||
- [ ] Server-side logging of throttle warnings is preserved for debugging
|
||||
- [ ] Traffic light dots in status report should be small/compact, not large emoji
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
name: "Chat notification when a story blocks with reason"
|
||||
---
|
||||
|
||||
# Story 425: Chat notification when a story blocks with reason
|
||||
|
||||
## User Story
|
||||
|
||||
As a project owner monitoring agent progress via chat, I want to receive a notification when a story gets blocked, including the reason, so that I can decide whether to unblock it or investigate the failure.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] When a story transitions to blocked state, send a chat notification to all configured transports
|
||||
- [ ] Notification includes the story ID, story name, and the reason for blocking (e.g. gate failure output, max retries exceeded, empty diff)
|
||||
- [ ] Notification uses a red or warning icon to distinguish from normal status messages
|
||||
- [ ] Works across Matrix, WhatsApp, and Slack transports
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
-77
@@ -1,77 +0,0 @@
|
||||
---
|
||||
name: "Mergemaster pipeline marks story done without verifying code landed on master"
|
||||
retry_count: 1
|
||||
---
|
||||
|
||||
# Bug 426: Mergemaster pipeline marks story done without verifying code landed on master
|
||||
|
||||
## Description
|
||||
|
||||
The mergemaster pipeline can mark a story as done even when the feature code never makes it to master. The cherry-pick step in merge.rs may fail or be skipped, but the pipeline still advances the story to done via the filesystem watcher. There is no post-merge verification that the code actually exists on master before marking done.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
Observed on stories 422 and 403. For 422: mergemaster created merge-queue branch, resolved 2 conflicts in chat/commands/mod.rs and http/mcp/mod.rs, passed quality gates, created merge-queue commit cb2ef6b (4 files, 333 insertions including unblock.rs). But the done commit on master (05db012) only moves the story file — zero code changes. There is no 'storkit: merge 422' commit on master at all. The feature branch (db3157f) still has the code but it was never cherry-picked onto master.
|
||||
|
||||
## Manual Merge Notes
|
||||
|
||||
When manually cherry-picking 422 onto master, two conflicts arose:
|
||||
|
||||
1. `server/src/chat/commands/mod.rs` — both 421 (timer) and 422 (unblock) added entries to the same BotCommand registry. Resolution: keep both.
|
||||
2. `server/src/http/mcp/mod.rs` — 420 (loc_file) and 422 (unblock) both bumped the tool count assertion from 49→50. Resolution: keep loc_file assertion, bump count to 51.
|
||||
|
||||
Additionally, the cherry-pick could not proceed at all because master was on the `merge-queue/424` branch with 3 unresolved files (notifications.rs, ws.rs, watcher.rs). A concurrent in-progress merge left the working tree dirty, which likely caused the original cherry-pick to fail silently. This suggests a race condition: the filesystem watcher commits (story file moves) can leave master in a state where the cherry-pick step in merge.rs fails.
|
||||
|
||||
## Full Audit of Done Stories (2026-03-28)
|
||||
|
||||
Audited all 9 stories in `5_done/` to check whether their code actually landed on master:
|
||||
|
||||
| Story | Merge Commit | Code on Master |
|
||||
|-------|-------------|----------------|
|
||||
| 417 — Split matrix/bot.rs | `665c036` (9 files, +1973/-1926) | YES |
|
||||
| 418 — Split pool/auto_assign.rs | `d375c4b` (7 files, +1901/-1813) | YES |
|
||||
| 419 — Matrix bot network error | `1193b7a` (1 file, +121/-3) | YES |
|
||||
| 420 — loc file command | `d6f8239` (5 files, +112/-32) | YES |
|
||||
| 421 — Timer command | `cf5424f` (7 files, +836) | YES |
|
||||
| 422 — Unblock command | `6c6bc35` (4 files, +336) — manual cherry-pick | YES |
|
||||
| 423 — Auto-schedule timer on rate limit | `b44f3a3` + `8ab2e19` (6 files, +375/-8) — manual cherry-pick | YES |
|
||||
| **424 — Rate limit traffic light** | **None** | **NO — moved back to backlog for redo** |
|
||||
| 425 — Chat notification on story block | `98b5475` (5 files, +184/-15) | YES |
|
||||
| **427 — Text normalization for line breaks** | **None** | **NO — phantom done, code never landed** |
|
||||
|
||||
**4 out of 10 stories (422, 423, 424, 427) had broken merges.** 422 and 423 were fixed via manual cherry-pick. 424 was moved back to backlog for a fresh run. 427 also hit the same bug — marked done without code on master.
|
||||
|
||||
## Actual Result
|
||||
|
||||
Story moved to done with no code on master. The merge-queue commit exists on a detached branch but was never applied to master. No merge commit appears in git log on master.
|
||||
|
||||
## Expected Result
|
||||
|
||||
Pipeline should verify that the cherry-pick produced a merge commit on master before advancing to done. If cherry-pick fails or is missing, the story should remain in merge stage with a merge_failure flag.
|
||||
|
||||
## Suggested Fix
|
||||
|
||||
The code path is: `merge.rs::run_squash_merge` → `pipeline/merge.rs::start_merge_agent_work` → `lifecycle.rs::move_story_to_archived`.
|
||||
|
||||
`run_squash_merge` (merge.rs:354) cherry-picks the merge-queue commit onto `project_root` and checks `cp.status.success()`. If it returns `success: true`, `start_merge_agent_work` (pipeline/merge.rs:106) immediately calls `move_story_to_archived`, which moves the story file to `5_done/`. The watcher then commits "storkit: done".
|
||||
|
||||
The gap: between the cherry-pick returning success and the story moving to done, nobody verifies the cherry-pick actually produced a code commit on master. Possible failure modes:
|
||||
|
||||
1. `project_root` is not on master (e.g. checked out to a merge-queue branch from a concurrent merge)
|
||||
2. Cherry-pick exits 0 but produces an empty commit (no code diff)
|
||||
3. Cherry-pick succeeds on the wrong branch
|
||||
|
||||
**Fix:** After the cherry-pick in `run_squash_merge` succeeds (line 384), before returning `success: true`:
|
||||
|
||||
1. Verify `project_root` is on master: `git rev-parse --abbrev-ref HEAD` must equal the base branch
|
||||
2. Verify the HEAD commit on master contains the expected merge message (e.g. matches `storkit: merge <story_id>`) or has a non-empty diff
|
||||
3. If either check fails, abort the cherry-pick and return `success: false`
|
||||
|
||||
This keeps the fix entirely within `run_squash_merge` — no changes needed to the pipeline advance or lifecycle code.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Pipeline must not move a story to done unless a merge commit containing the feature code exists on master
|
||||
- [ ] If cherry-pick fails or produces no code diff on master, the merge must be reported as failed
|
||||
- [ ] Add a post-merge verification step that checks git log on master for the expected merge commit before advancing to done
|
||||
- [ ] When verification fails, emit a merge_failure and leave the story in the merge stage for retry
|
||||
-20
@@ -1,20 +0,0 @@
|
||||
---
|
||||
name: "Server-side text normalization for chat message line breaks"
|
||||
---
|
||||
|
||||
# Story 427: Server-side text normalization for chat message line breaks
|
||||
|
||||
## User Story
|
||||
|
||||
As a user reading bot messages in Matrix, I want single newlines between sentences to render correctly, so that messages don't show up with words joined together like "sentence one.Sentence two".
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Add a text normalization step before markdown-to-HTML conversion in the Matrix transport that converts single newlines between non-empty prose lines into double newlines
|
||||
- [ ] Preserve intentional single-newline formatting in bullet lists, headings, table rows, and code fences
|
||||
- [ ] Apply the same normalization in WhatsApp and Slack transports
|
||||
- [ ] Unit tests covering prose paragraphs, bullet lists, code blocks, and mixed content
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
name: "Split pool/pipeline.rs into submodules"
|
||||
---
|
||||
|
||||
# Refactor 428: Split pool/pipeline.rs into submodules
|
||||
|
||||
## Current State
|
||||
|
||||
- TBD
|
||||
|
||||
## Desired State
|
||||
|
||||
Refactor the monolithic server/src/agents/pool/pipeline.rs (1789 lines) into focused submodules.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] advance.rs contains run_pipeline_advance, spawn_pipeline_advance, should_block_story and their unit tests
|
||||
- [ ] completion.rs contains run_server_owned_completion, report_completion and their unit tests
|
||||
- [ ] merge.rs contains start_merge_agent_work, run_merge_pipeline, get_merge_status, set_merge_failure_reported and their unit tests
|
||||
- [ ] mod.rs re-exports all public items and wires the submodules
|
||||
- [ ] Unit tests live in their respective module files
|
||||
- [ ] No public API changes — all existing imports continue to work
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
-27
@@ -1,27 +0,0 @@
|
||||
---
|
||||
name: "Interactive project setup wizard for new storkit projects"
|
||||
agent: coder-opus
|
||||
---
|
||||
|
||||
# Story 429: Interactive project setup wizard for new storkit projects
|
||||
|
||||
## User Story
|
||||
|
||||
As a developer adopting storkit on an existing project, I want a guided setup process that scaffolds the .storkit directory and has an agent generate project-specific configuration files, so that I can get up and running without manually writing specs and scripts.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] storkit init scaffolds .storkit/ directory structure, project.toml, and .mcp.json without clobbering any existing files (especially CLAUDE.md)
|
||||
- [ ] Setup wizard tracks progress through ordered steps, resumable if interrupted
|
||||
- [ ] Step 1: scaffold .storkit/ directory structure and project.toml
|
||||
- [ ] Step 2: agent reads codebase and generates specs/00_CONTEXT.md, user confirms or requests revision
|
||||
- [ ] Step 3: agent reads tech stack and generates specs/tech/STACK.md, user confirms or requests revision
|
||||
- [ ] Step 4: agent creates script/test that runs the project's actual test suite, user runs it to verify, then confirms
|
||||
- [ ] Step 5: agent creates script/release tailored to the project's deployment, user confirms
|
||||
- [ ] Step 6: agent creates script/test_coverage if the stack supports it, user confirms
|
||||
- [ ] Each step gates on user confirmation before advancing to the next
|
||||
- [ ] Existing CLAUDE.md is preserved — storkit appends its content or leaves it untouched
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
-27
@@ -1,27 +0,0 @@
|
||||
---
|
||||
name: "Status command traffic light dots not coloured in Matrix"
|
||||
---
|
||||
|
||||
# Bug 430: Status command traffic light dots not coloured in Matrix
|
||||
|
||||
## Description
|
||||
|
||||
The traffic light dots in the status command use plain Unicode characters (○ ● ◑ ✗) which render without colour in Matrix. The HTML formatted_body should use data-mx-color to colour them green/yellow/red.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
Send the status command to the bot in Matrix. Observe the dots are monochrome.
|
||||
|
||||
## Actual Result
|
||||
|
||||
Dots render as plain monochrome Unicode characters.
|
||||
|
||||
## Expected Result
|
||||
|
||||
Dots render in colour: green (● running), yellow (◑ throttled), red (✗ blocked), grey (○ idle). Use font tag with data-mx-color attribute for Matrix HTML formatted_body.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] HTML formatted_body uses <font data-mx-color="#colour">dot</font> for each traffic light state
|
||||
- [ ] Green (#00cc00) for running, yellow (#ffaa00) for throttled, red (#cc0000) for blocked, grey (#888888) for idle
|
||||
- [ ] Plain text fallback remains unchanged (Unicode dots for non-HTML transports)
|
||||
Reference in New Issue
Block a user