huskies: accept 463_story_configurable_rate_limit_notification_suppression
This commit is contained in:
dave
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: "Rename project from \"huskies\" to \"huskies\""
|
||||
---
|
||||
|
||||
# Story 455: Rename project from "huskies" to "huskies"
|
||||
|
||||
## User Story
|
||||
|
||||
As a project maintainer, I want to rename the project from \"huskies\" to \"huskies\" so that the product has its new identity throughout the codebase, tooling, and documentation. The new domain is huskies.dev — update all references to huskies.dev accordingly (website, contact email hello@huskies.dev, etc).
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Rust crate name in server/Cargo.toml changed from 'huskies' to 'huskies'
|
||||
- [ ] Binary name changed to 'huskies' (Dockerfile CMD, release script binary names)
|
||||
- [ ] Environment variables renamed: STORKIT_PORT → HUSKIES_PORT, STORKIT_HOST → HUSKIES_HOST
|
||||
- [ ] Docker service name, container_name, image name, and volume names updated in docker-compose.yml
|
||||
- [ ] Docker user/group renamed from 'huskies' to 'huskies' in Dockerfile (groupadd, useradd, home dir /home/huskies/.claude)
|
||||
- [ ] MCP server registration renamed from 'huskies' to 'huskies' in scaffold-generated .mcp.json and in server/src/http/mcp/mod.rs serverInfo name
|
||||
- [ ] All 35+ MCP tool permission patterns updated from mcp__huskies__* to mcp__huskies__* across code and permission configs
|
||||
- [ ] The .huskies/ project directory marker renamed to .huskies/ throughout all Rust source (paths.rs, config.rs, scaffold.rs, watcher.rs, prompts.rs, and all agent/pipeline code)
|
||||
- [ ] Release script updated: Gitea repo path dave/huskies → dave/huskies, changelog regex updated to match ^(huskies|huskies|story-kit): for backwards-compatible history parsing, binary artifact names updated
|
||||
- [ ] Git commit prefix convention updated from 'huskies:' to 'huskies:' in huskies README and agent prompts
|
||||
- [ ] Website updated: page title, headings, and contact email (hello@huskies.dev) if domain changes
|
||||
- [ ] README.md updated: all CLI examples use 'huskies' binary name, all .huskies/ references become .huskies/
|
||||
- [ ] A migration path exists for existing installs: either huskies auto-detects and migrates .huskies/ → .huskies/, or a migration script (script/migrate) is provided
|
||||
- [ ] All Claude Code .mcp.json files in existing worktrees are regenerated via scaffold or migration
|
||||
- [ ] Gitea repository renamed from dave/huskies to dave/huskies (external action required, noted in story)
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: "Stage transition notifications can arrive out of order and show wrong story name"
|
||||
agent: coder-opus
|
||||
---
|
||||
|
||||
# Bug 462: Stage transition notifications can arrive out of order and show wrong story name
|
||||
|
||||
## Description
|
||||
|
||||
When a story moves through stages quickly (e.g. QA → Merge → Done), the stage transition notifications can arrive out of order in Matrix chat. The Done notification appears before the Merge notification.
|
||||
|
||||
Two issues:
|
||||
|
||||
1. **Out-of-order delivery**: When two notifications are sent close together, the Matrix homeserver can deliver them in the wrong order. The notification handler processes events sequentially and awaits each send, but the homeserver does not guarantee ordering for near-simultaneous messages.
|
||||
|
||||
2. **Missing story name on stale notifications**: The second notification shows the raw item_id instead of the story name because `read_story_name` looks in the stage directory from the event (e.g. `4_merge/`), but the file has already moved to the next stage (e.g. `5_done/`).
|
||||
|
||||
3. **`inferred_from_stage` guesses the source stage** instead of tracking the actual from-stage. This means skipped stages would show incorrect transitions.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Have a story in QA that passes quickly
|
||||
2. Story moves QA → Merge → Done in rapid succession
|
||||
3. Observe notifications in Matrix
|
||||
|
||||
## Actual Result
|
||||
|
||||
Notifications arrive in wrong order (Done before Merge). The later notification shows the raw item_id instead of the story name:
|
||||
|
||||
🎉 #32 upgrade TypeScript... — Merge → Done
|
||||
#32 32_story_upgrade_typescript_and_tsconfig... — QA → Merge
|
||||
|
||||
## Expected Result
|
||||
|
||||
Notifications arrive in chronological order. All notifications show the story name. Ideally, rapid transitions are coalesced into a single notification for the final stage.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] read_story_name falls back to searching all stages when the expected stage directory has no match
|
||||
- [ ] Consider deduplicating rapid transitions within a short window (e.g. only notify for the final stage)
|
||||
- [ ] Track actual from-stage in WatcherEvent instead of guessing via inferred_from_stage
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
name: "Configurable rate limit notification suppression"
|
||||
---
|
||||
|
||||
# Story 463: Configurable rate limit notification suppression
|
||||
|
||||
## User Story
|
||||
|
||||
As a ..., I want ..., so that ...
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] New boolean config field in project.toml (e.g. rate_limit_notifications) defaults to true
|
||||
- [ ] When false, RateLimitWarning chat notifications are suppressed
|
||||
- [ ] RateLimitHardBlock and StoryBlocked notifications are always sent regardless of the setting
|
||||
- [ ] Stage transition notifications are unaffected
|
||||
- [ ] Config is hot-reloaded when project.toml changes
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
name: "Timer rejects backlog stories — should move to current on fire"
|
||||
---
|
||||
|
||||
# Bug 464: Timer rejects backlog stories — should move to current on fire
|
||||
|
||||
## Description
|
||||
|
||||
The `timer` bot command requires stories to be in `work/2_current/` before scheduling. When a user tries to schedule a backlog story (e.g. `timer 463 12:45`), it returns:
|
||||
|
||||
"Story **463_story_...** is not in `work/2_current/`. Move it to current before scheduling a timer."
|
||||
|
||||
The timer should accept backlog stories. When the timer fires, it should move the story from backlog to current and let auto-assign start an agent.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Have a story in backlog (e.g. 463)
|
||||
2. Run `timer 463 12:45`
|
||||
3. Observe rejection message
|
||||
|
||||
## Actual Result
|
||||
|
||||
Timer command rejects stories not in `work/2_current/`.
|
||||
|
||||
## Expected Result
|
||||
|
||||
Timer command accepts backlog stories. When the timer fires, it moves the story to current and auto-assign picks it up.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Timer bot command accepts stories in backlog or current
|
||||
- [ ] Timer tick loop calls move_story_to_current before start_agent for backlog stories
|
||||
- [ ] Unit tests cover scheduling and firing for backlog stories
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: "Timer tick loop never fires due entries"
|
||||
agent: coder-opus
|
||||
---
|
||||
|
||||
# Bug 465: Timer tick loop never fires due entries
|
||||
|
||||
## Description
|
||||
|
||||
The timer tick loop (`spawn_timer_tick_loop`) is spawned by the Matrix bot runner, the Matrix bot is confirmed running (processing messages), but timers never fire. Past-due entries remain in `.huskies/timers.json` indefinitely — `take_due` never consumes them.
|
||||
|
||||
The tick loop uses `tokio::spawn` which swallows panics silently. If `move_story_to_current` or `start_agent` panics on the first tick (when all past-due entries fire at once), the entire task dies with no log output. The PTY debug spam may also push any `[timer]` log entries out of the ring buffer.
|
||||
|
||||
The bot command successfully adds entries to the in-memory store and persists them to disk, but the tick loop never processes them.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Set a timer via bot command: `timer 463 HH:MM` (a time in the near future)
|
||||
2. Wait past the scheduled time
|
||||
3. Check `.huskies/timers.json` — entries are still present
|
||||
4. Check server logs for `[timer]` — no entries found
|
||||
|
||||
## Actual Result
|
||||
|
||||
Timer entries remain in timers.json indefinitely. No `[timer] Timer fired` log entries appear. The story is never moved to current and no agent is started.
|
||||
|
||||
## Expected Result
|
||||
|
||||
Within 30 seconds of the scheduled time, the tick loop should call `take_due`, remove the entry from disk, move the story to current (if in backlog), and start an agent.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Add panic-catching (catch_unwind or tokio CancellationToken) to the tick loop so failures are logged
|
||||
- [ ] Add a startup log line confirming the tick loop is running and how many pending timers were loaded
|
||||
- [ ] Verify take_due runs on each 30-second tick by adding periodic debug logging
|
||||
- [ ] Integration test: create a past-due timer entry, run the tick loop, assert the entry is consumed
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
name: "Configurable timezone in project.toml for timer scheduling"
|
||||
---
|
||||
|
||||
# Story 466: Configurable timezone in project.toml for timer scheduling
|
||||
|
||||
## User Story
|
||||
|
||||
As a user running huskies in a container where TZ defaults to UTC, I want to configure my project's timezone in project.toml so that timer HH:MM inputs are interpreted in my actual timezone.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Add a `timezone` field to project.toml (e.g. `timezone = "Europe/London"`)
|
||||
- [ ] next_occurrence_of_hhmm uses the configured timezone instead of chrono::Local
|
||||
- [ ] Falls back to chrono::Local if no timezone is configured
|
||||
- [ ] Timer confirmation message displays the time in the configured timezone
|
||||
- [ ] timer list command shows times in the configured timezone
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
Reference in New Issue
Block a user