huskies: accept 482_refactor_split_agent_definitions_from_project_toml_into_agents_toml

.huskies/work/6_archived/476_refactor_split_agents_pool_lifecycle_rs_into_submodules.md

@@ -0,0 +1,26 @@
+---
+name: "Split agents/pool/lifecycle.rs into submodules"
+agent: coder-opus
+---
+
+# Refactor 476: Split agents/pool/lifecycle.rs into submodules
+
+## Current State
+
+- TBD
+
+## Desired State
+
+pool/lifecycle.rs is 1812 lines with 4 public functions (start_agent, stop_agent, wait_for_agent, remove_agents_for_story) plus 29 tests. start_agent is by far the largest — it handles agent selection, worktree creation, process spawning, and completion callbacks. Split into submodules: start.rs (agent start + selection logic), stop.rs (stop + cleanup), wait.rs (wait_for_agent), with tests co-located in each module.
+
+## Acceptance Criteria
+
+- [ ] pool/lifecycle.rs split into submodules (e.g. start.rs, stop.rs, wait.rs)
+- [ ] Each submodule contains its related tests
+- [ ] All 29 existing tests pass unchanged
+- [ ] Public API unchanged — re-export from pool/mod.rs if needed
+- [ ] No functional changes, purely structural
+
+## Out of Scope
+
+- TBD

.huskies/work/6_archived/482_refactor_split_agent_definitions_from_project_toml_into_agents_toml.md

@@ -0,0 +1,26 @@
+---
+name: "Split agent definitions from project.toml into agents.toml"
+---
+
+# Refactor 482: Split agent definitions from project.toml into agents.toml
+
+## Current State
+
+- TBD
+
+## Desired State
+
+Move all `[[agent]]` blocks from `.huskies/project.toml` into a separate `.huskies/agents.toml`. The server loads agents from agents.toml and merges with project.toml config. Falls back to inline `[[agent]]` blocks in project.toml for backwards compatibility. The watcher should detect changes to agents.toml and hot-reload. This is a prerequisite for bug 481 (scaffold copies default agents to new projects) — agents.toml becomes the embeddable template.
+
+## Acceptance Criteria
+
+- [ ] All [[agent]] blocks moved from .huskies/project.toml to .huskies/agents.toml
+- [ ] Server loads agent config from agents.toml, falls back to inline [[agent]] in project.toml for backwards compat
+- [ ] Watcher detects agents.toml changes and triggers hot-reload
+- [ ] project.toml is significantly smaller (only project settings remain)
+- [ ] agents.toml is the canonical default template for scaffolding (prerequisite for bug 481)
+- [ ] All existing agent functionality unchanged
+
+## Out of Scope
+
+- TBD

.huskies/work/6_archived/483_bug_timer_slash_command_not_wired_up_in_web_ui.md

@@ -0,0 +1,35 @@
+---
+name: "Timer slash command not wired up in web UI"
+---
+
+# Bug 483: Timer slash command not wired up in web UI
+
+## Description
+
+Three async bot commands are not wired up in the web UI's `bot_command.rs` dispatch: **timer**, **htop**, and **rmtree**. They fall through to `dispatch_sync` which calls the registry stub that returns `None`, resulting in "Unknown command."
+
+The fix: add async dispatch branches for all three in `dispatch_command`:
+- `"timer" => dispatch_timer(args, project_root).await`
+- `"rmtree" => dispatch_rmtree(args, project_root, agents).await`
+- `"htop"` — either implement a simplified version or return a "not available in web UI" message (htop is a live dashboard designed for Matrix)
+
+Commands already correctly dispatched: assign, start, delete, rebuild.
+Reset is handled by the frontend (clears local state) — not needed server-side.
+
+## How to Reproduce
+
+1. Open the web UI
+2. Type `/timer list` or `/timer 463 14:00`
+3. See "Unknown command: /timer"
+
+## Actual Result
+
+Unknown command: `/timer`. Type `/help` to see available commands.
+
+## Expected Result
+
+Timer command works in the web UI the same as it does via Matrix.
+
+## Acceptance Criteria
+
+- [ ] Bug is fixed and verified

.huskies/work/6_archived/484_story_story_dependencies_in_pipeline_auto_assign.md

@@ -0,0 +1,26 @@
+---
+name: "Story dependencies in pipeline auto-assign"
+---
+
+# Story 484: Story dependencies in pipeline auto-assign
+
+## User Story
+
+As a user creating stories that depend on each other, I want to specify dependencies in the story front matter so dependent stories stay in backlog until their dependencies are done, then automatically move to current.
+
+Stories with `depends_on` stay in backlog. A dependency check loop (similar to the timer tick) periodically scans backlog for stories whose dependencies have all reached done/archived. When all deps are met, the story is moved to current and the normal auto-assign picks it up — ensuring the worktree is created from post-dependency master.
+
+## Acceptance Criteria
+
+- [ ] New optional `depends_on` field in story front matter accepts a list of story numbers (e.g. `depends_on: [477, 478]`)
+- [ ] Stories with unmet dependencies stay in **backlog**, not current
+- [ ] A dependency check loop (similar to the timer tick loop) periodically scans backlog for stories whose `depends_on` stories have all reached done or archived
+- [ ] When all deps are met, the loop moves the story from backlog to current — the normal auto-assign then picks it up with a worktree based on post-dependency master
+- [ ] Status command shows dependency info for stories waiting on deps
+- [ ] Stories with no depends_on field behave as before (no change)
+- [ ] Bot command `depends <number> <dep1> [dep2...]` to set dependencies from chat (all transports) and web UI slash command
+- [ ] Command wired up in bot_command.rs dispatch for web UI and registered in shared command registry for all chat transports
+
+## Out of Scope
+
+- TBD