huskies: rename project from storkit to huskies
Rename all references from storkit to huskies across the codebase: - .storkit/ directory → .huskies/ - Binary name, Cargo package name, Docker image references - Server code, frontend code, config files, scripts - Fix script/test to build frontend before cargo clippy/test so merge worktrees have frontend/dist available for RustEmbed Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Timmy
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"enabledMcpjsonServers": [
|
||||
"storkit"
|
||||
"huskies"
|
||||
],
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Bash(./server/target/debug/storkit:*)",
|
||||
"Bash(./target/debug/storkit:*)",
|
||||
"Bash(STORKIT_PORT=*)",
|
||||
"Bash(./server/target/debug/huskies:*)",
|
||||
"Bash(./target/debug/huskies:*)",
|
||||
"Bash(HUSKIES_PORT=*)",
|
||||
"Bash(cargo build:*)",
|
||||
"Bash(cargo check:*)",
|
||||
"Bash(cargo clippy:*)",
|
||||
@@ -56,7 +56,7 @@
|
||||
"WebFetch(domain:portkey.ai)",
|
||||
"WebFetch(domain:www.shuttle.dev)",
|
||||
"WebSearch",
|
||||
"mcp__storkit__*",
|
||||
"mcp__huskies__*",
|
||||
"Edit",
|
||||
"Write",
|
||||
"Bash(find *)",
|
||||
|
||||
+3
-3
@@ -2,9 +2,9 @@
|
||||
**/target/
|
||||
**/node_modules/
|
||||
frontend/dist/
|
||||
.storkit/worktrees/
|
||||
.storkit/logs/
|
||||
.storkit/work/6_archived/
|
||||
.huskies/worktrees/
|
||||
.huskies/logs/
|
||||
.huskies/work/6_archived/
|
||||
.git/
|
||||
*.swp
|
||||
*.swo
|
||||
|
||||
+3
-3
@@ -5,10 +5,10 @@
|
||||
# Local environment (secrets)
|
||||
.env
|
||||
|
||||
# App specific (root-level; storkit subdirectory patterns live in .storkit/.gitignore)
|
||||
# App specific (root-level; huskies subdirectory patterns live in .huskies/.gitignore)
|
||||
store.json
|
||||
.storkit_port
|
||||
.storkit/bot.toml.bak
|
||||
.huskies_port
|
||||
.huskies/bot.toml.bak
|
||||
|
||||
# Rust stuff
|
||||
target
|
||||
|
||||
@@ -17,14 +17,14 @@ When you start a new session with this project:
|
||||
- **Keep moving.** After each step is confirmed, immediately proceed to the next wizard step without waiting for the user to ask.
|
||||
2. **Check for MCP Tools:** Read `.mcp.json` to discover the MCP server endpoint. Then list available tools by calling:
|
||||
```bash
|
||||
curl -s "$(jq -r '.mcpServers["storkit"].url' .mcp.json)" \
|
||||
curl -s "$(jq -r '.mcpServers["huskies"].url' .mcp.json)" \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
|
||||
```
|
||||
This returns the full tool catalog (create stories, spawn agents, record tests, manage worktrees, etc.). Familiarize yourself with the available tools before proceeding. These tools allow you to directly manipulate the workflow and spawn subsidiary agents without manual file manipulation.
|
||||
3. **Read Context:** Check `.storkit/specs/00_CONTEXT.md` for high-level project goals.
|
||||
4. **Read Stack:** Check `.storkit/specs/tech/STACK.md` for technical constraints and patterns.
|
||||
5. **Check Work Items:** Look at `.storkit/work/1_backlog/` and `.storkit/work/2_current/` to see what work is pending.
|
||||
3. **Read Context:** Check `.huskies/specs/00_CONTEXT.md` for high-level project goals.
|
||||
4. **Read Stack:** Check `.huskies/specs/tech/STACK.md` for technical constraints and patterns.
|
||||
5. **Check Work Items:** Look at `.huskies/work/1_backlog/` and `.huskies/work/2_current/` to see what work is pending.
|
||||
|
||||
|
||||
---
|
||||
@@ -238,7 +238,7 @@ If a user hands you this document and says "Apply this process to my project":
|
||||
|
||||
Story Kit includes a chat bot that can be connected to one messaging platform at a time. The bot handles commands, LLM conversations, and pipeline notifications.
|
||||
|
||||
**Only one transport can be active at a time.** To configure the bot, copy the appropriate example file to `.storkit/bot.toml`:
|
||||
**Only one transport can be active at a time.** To configure the bot, copy the appropriate example file to `.huskies/bot.toml`:
|
||||
|
||||
| Transport | Example file | Webhook endpoint |
|
||||
|-----------|-------------|-----------------|
|
||||
@@ -248,7 +248,7 @@ Story Kit includes a chat bot that can be connected to one messaging platform at
|
||||
| Slack | `bot.toml.slack.example` | `/webhook/slack` |
|
||||
|
||||
```bash
|
||||
cp .storkit/bot.toml.matrix.example .storkit/bot.toml
|
||||
cp .huskies/bot.toml.matrix.example .huskies/bot.toml
|
||||
# Edit bot.toml with your credentials
|
||||
```
|
||||
|
||||
@@ -74,7 +74,7 @@ Read CLAUDE.md first, then .story_kit/README.md to understand the dev process.
|
||||
## Your Workflow
|
||||
|
||||
### 0. Read the Story
|
||||
- Read the story file at `.storkit/work/3_qa/{{story_id}}.md`
|
||||
- Read the story file at `.huskies/work/3_qa/{{story_id}}.md`
|
||||
- Extract every acceptance criterion (the `- [ ]` checkbox lines)
|
||||
- Keep this list in mind for Step 3
|
||||
|
||||
@@ -115,7 +115,7 @@ An AC fails if:
|
||||
- URL to visit in the browser
|
||||
- Things to check in the UI
|
||||
- curl commands to exercise relevant API endpoints
|
||||
- Kill the test server when done: `pkill -f 'target.*storkit' || true` (NEVER use `pkill -f storkit` — it kills the vite dev server)
|
||||
- Kill the test server when done: `pkill -f 'target.*huskies' || true` (NEVER use `pkill -f huskies` — it kills the vite dev server)
|
||||
|
||||
### 5. Produce Structured Report and Verdict
|
||||
Print your QA report to stdout. Then call `approve_qa` or `reject_qa` via the MCP tool based on the overall result. Use this format:
|
||||
@@ -184,7 +184,7 @@ Read CLAUDE.md first, then .story_kit/README.md to understand the dev process.
|
||||
## Your Workflow
|
||||
|
||||
### 0. Read the Story
|
||||
- Read the story file at `.storkit/work/3_qa/{{story_id}}.md`
|
||||
- Read the story file at `.huskies/work/3_qa/{{story_id}}.md`
|
||||
- Extract every acceptance criterion (the `- [ ]` checkbox lines)
|
||||
- Keep this list in mind for Step 3
|
||||
|
||||
@@ -225,7 +225,7 @@ An AC fails if:
|
||||
- URL to visit in the browser
|
||||
- Things to check in the UI
|
||||
- curl commands to exercise relevant API endpoints
|
||||
- Kill the test server when done: `pkill -f 'target.*storkit' || true` (NEVER use `pkill -f storkit` — it kills the vite dev server)
|
||||
- Kill the test server when done: `pkill -f 'target.*huskies' || true` (NEVER use `pkill -f huskies` — it kills the vite dev server)
|
||||
|
||||
### 5. Produce Structured Report and Verdict
|
||||
Print your QA report to stdout. Then call `approve_qa` or `reject_qa` via the MCP tool based on the overall result. Use this format:
|
||||
@@ -1,4 +1,4 @@
|
||||
# Example project.toml — copy to .storkit/project.toml and customise.
|
||||
# Example project.toml — copy to .huskies/project.toml and customise.
|
||||
# This file is checked in; project.toml itself is gitignored (it may contain
|
||||
# instance-specific settings).
|
||||
|
||||
@@ -37,7 +37,7 @@ max_turns = 50
|
||||
max_budget_usd = 5.00
|
||||
prompt = """
|
||||
You are working in a git worktree on story {{story_id}}.
|
||||
Read CLAUDE.md first, then .storkit/README.md to understand the dev process.
|
||||
Read CLAUDE.md first, then .huskies/README.md to understand the dev process.
|
||||
Run: cd "{{worktree_path}}" && git difftool {{base_branch}}...HEAD
|
||||
Commit all your work before your process exits.
|
||||
"""
|
||||
@@ -6,7 +6,7 @@ Slack integration is configured via `bot.toml` in the project's `.story_kit/` di
|
||||
|
||||
```toml
|
||||
transport = "slack"
|
||||
display_name = "Storkit"
|
||||
display_name = "Huskies"
|
||||
slack_bot_token = "xoxb-..."
|
||||
slack_signing_secret = "..."
|
||||
slack_channel_ids = ["C01ABCDEF"]
|
||||
@@ -29,11 +29,11 @@ Slash commands provide quick access to pipeline commands without mentioning the
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/storkit-status` | Show pipeline status and agent availability |
|
||||
| `/storkit-cost` | Show token spend: 24h total, top stories, and breakdown |
|
||||
| `/storkit-show` | Display the full text of a work item (e.g. `/storkit-show 42`) |
|
||||
| `/storkit-git` | Show git status: branch, changes, ahead/behind |
|
||||
| `/storkit-htop` | Show system and agent process dashboard |
|
||||
| `/huskies-status` | Show pipeline status and agent availability |
|
||||
| `/huskies-cost` | Show token spend: 24h total, top stories, and breakdown |
|
||||
| `/huskies-show` | Display the full text of a work item (e.g. `/huskies-show 42`) |
|
||||
| `/huskies-git` | Show git status: branch, changes, ahead/behind |
|
||||
| `/huskies-htop` | Show system and agent process dashboard |
|
||||
|
||||
All slash command responses are **ephemeral** — only the user who invoked the command sees the response.
|
||||
|
||||
@@ -118,8 +118,8 @@ To support both Remote and Local models, the system implements a `ModelProvider`
|
||||
|
||||
Multiple instances can run simultaneously in different worktrees. To avoid port conflicts:
|
||||
|
||||
- **Backend:** Set `STORKIT_PORT` to a unique port (default is 3001). Example: `STORKIT_PORT=3002 cargo run`
|
||||
- **Frontend:** Run `npm run dev` from `frontend/`. It auto-selects the next unused port. It reads `STORKIT_PORT` to know which backend to talk to, so export it before running: `export STORKIT_PORT=3002 && cd frontend && npm run dev`
|
||||
- **Backend:** Set `HUSKIES_PORT` to a unique port (default is 3001). Example: `HUSKIES_PORT=3002 cargo run`
|
||||
- **Frontend:** Run `npm run dev` from `frontend/`. It auto-selects the next unused port. It reads `HUSKIES_PORT` to know which backend to talk to, so export it before running: `export HUSKIES_PORT=3002 && cd frontend && npm run dev`
|
||||
|
||||
When running in a worktree, use a port that won't conflict with the main instance (3001). Ports 3002+ are good choices.
|
||||
|
||||
+3
-3
@@ -1,8 +1,8 @@
|
||||
---
|
||||
name: "Fly.io Machines API integration for multi-tenant storkit SaaS"
|
||||
name: "Fly.io Machines API integration for multi-tenant huskies SaaS"
|
||||
---
|
||||
|
||||
# Spike 408: Fly.io Machines API integration for multi-tenant storkit SaaS
|
||||
# Spike 408: Fly.io Machines API integration for multi-tenant huskies SaaS
|
||||
|
||||
## Question
|
||||
|
||||
@@ -28,7 +28,7 @@ A thin Rust service using `reqwest` for the Machines API and `axum` for the reve
|
||||
- [ ] Test attaching a persistent volume to a machine and verify it persists across stop/start
|
||||
- [ ] Test secret injection — pass a dummy `credentials.json` as a Fly secret and verify it's readable inside the machine
|
||||
- [ ] Sketch the auth proxy: JWT validation → machine lookup → reverse proxy to machine's private IP; verify WebSocket proxying works
|
||||
- [ ] Measure actual cold start time for a minimal storkit container image
|
||||
- [ ] Measure actual cold start time for a minimal huskies container image
|
||||
- [ ] Document any API quirks, rate limits, or sharp edges discovered during testing
|
||||
|
||||
## Findings
|
||||
+2
-2
@@ -6,13 +6,13 @@ name: "Multi-account OAuth token rotation on rate limit"
|
||||
|
||||
## User Story
|
||||
|
||||
As a storkit user with multiple Claude Max subscriptions, I want the system to automatically rotate to a different account when one gets rate limited, so that agents and chat don't stall out waiting for limits to reset.
|
||||
As a huskies user with multiple Claude Max subscriptions, I want the system to automatically rotate to a different account when one gets rate limited, so that agents and chat don't stall out waiting for limits to reset.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] OAuth login flow stores credentials per-account (keyed by email), not overwriting previous accounts
|
||||
- [ ] GET /oauth/status returns all stored accounts and their status (active, rate-limited, expired)
|
||||
- [ ] When the active account hits a rate limit, storkit automatically swaps to the next available account's refresh token, refreshes, and retries
|
||||
- [ ] When the active account hits a rate limit, huskies automatically swaps to the next available account's refresh token, refreshes, and retries
|
||||
- [ ] The bot sends a notification in Matrix/WhatsApp when it swaps accounts
|
||||
- [ ] If all accounts are rate limited, the bot surfaces a clear message with the time until the earliest reset
|
||||
- [ ] A new /oauth/authorize login adds to the account pool rather than replacing the current credentials
|
||||
@@ -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
|
||||
+2
-2
@@ -7,7 +7,7 @@ agent: coder-opus
|
||||
|
||||
## 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 `.storkit/timers.json` indefinitely — `take_due` never consumes them.
|
||||
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.
|
||||
|
||||
@@ -17,7 +17,7 @@ The bot command successfully adds entries to the in-memory store and persists th
|
||||
|
||||
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 `.storkit/timers.json` — entries are still present
|
||||
3. Check `.huskies/timers.json` — entries are still present
|
||||
4. Check server logs for `[timer]` — no entries found
|
||||
|
||||
## Actual Result
|
||||
+1
-1
@@ -6,7 +6,7 @@ name: "Configurable timezone in project.toml for timer scheduling"
|
||||
|
||||
## User Story
|
||||
|
||||
As a user running storkit 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.
|
||||
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
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ The `prompt_permission` MCP tool returns plain text ("Permission granted for '..
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Start the storkit server and open the web UI
|
||||
1. Start the huskies server and open the web UI
|
||||
2. Chat with the claude-code-pty model
|
||||
3. Ask it to do something that requires a tool NOT in `.claude/settings.json` allow list (e.g. `wc -l /etc/hosts`, or WebFetch to a non-allowed domain)
|
||||
4. The permission dialog appears — click Approve
|
||||
+1
-1
@@ -6,7 +6,7 @@ name: "Retry limit for mergemaster and pipeline restarts"
|
||||
|
||||
## User Story
|
||||
|
||||
As a developer using storkit, I want pipeline auto-restarts to have a configurable retry limit so that failing agents don't loop infinitely consuming CPU and API credits.
|
||||
As a developer using huskies, I want pipeline auto-restarts to have a configurable retry limit so that failing agents don't loop infinitely consuming CPU and API credits.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
+2
-2
@@ -23,7 +23,7 @@ The watcher should periodically check `5_done/` and move items older than 4 hour
|
||||
- All MCP tools and pipeline logic that reference `5_archived` need updating to use `5_done`
|
||||
- Frontend pipeline display if it shows archived/done items
|
||||
- `.story_kit/README.md`: update pipeline stage documentation
|
||||
- Story 116's init scaffolding: `storkit init` must create `5_done/` and `6_archived/` directories
|
||||
- Story 116's init scaffolding: `huskies init` must create `5_done/` and `6_archived/` directories
|
||||
- Any templates or scaffold code that creates the `.story_kit/work/` directory structure
|
||||
|
||||
## Acceptance Criteria
|
||||
@@ -35,7 +35,7 @@ The watcher should periodically check `5_done/` and move items older than 4 hour
|
||||
- [ ] Existing items in old `5_archived/` are migrated to `6_archived/`
|
||||
- [ ] Frontend pipeline display updated if applicable
|
||||
- [ ] `.story_kit/README.md` updated to reflect the new pipeline stages
|
||||
- [ ] `storkit init` scaffolding creates `5_done/` and `6_archived/` (coordinate with story 116)
|
||||
- [ ] `huskies init` scaffolding creates `5_done/` and `6_archived/` (coordinate with story 116)
|
||||
|
||||
## Out of Scope
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user