Coding agents text change.

More husky
Husky metaphor in action.
2026-04-03 21:38:58 +01:00 · 2026-04-03 21:13:13 +01:00 · 2026-04-03 21:05:23 +01:00 · 2026-04-03 21:03:54 +01:00 · 2026-04-03 19:12:18 +00:00 · 2026-04-03 17:38:21 +01:00
610 changed files with 8411 additions and 2366 deletions
@@ -1,10 +1,12 @@
 {
-  "enabledMcpjsonServers": ["storkit"],
+  "enabledMcpjsonServers": [
    "huskies"
  ],
  "permissions": {
    "allow": [
-      "Bash(./server/target/debug/storkit:*)",
+      "Bash(./server/target/debug/huskies:*)",
-      "Bash(./target/debug/storkit:*)",
+      "Bash(./target/debug/huskies:*)",
-      "Bash(STORKIT_PORT=*)",
+      "Bash(HUSKIES_PORT=*)",
      "Bash(cargo build:*)",
      "Bash(cargo check:*)",
      "Bash(cargo clippy:*)",
@@ -54,7 +56,7 @@
      "WebFetch(domain:portkey.ai)",
      "WebFetch(domain:www.shuttle.dev)",
      "WebSearch",
-      "mcp__storkit__*",
+      "mcp__huskies__*",
      "Edit",
      "Write",
      "Bash(find *)",
@@ -67,7 +69,8 @@
      "Bash(tail *)",
      "Bash(wc *)",
      "Bash(npx vite:*)",
-      "Bash(npm run dev:*)"
+      "Bash(npm run dev:*)",
      "Bash(stat *)"
    ]
  }
 }
@@ -2,9 +2,9 @@
 **/target/
 **/node_modules/
 frontend/dist/
-.storkit/worktrees/
+.huskies/worktrees/
-.storkit/logs/
+.huskies/logs/
-.storkit/work/6_archived/
+.huskies/work/6_archived/
 .git/
 *.swp
 *.swo
@@ -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
+.huskies_port
-.storkit/bot.toml.bak
+.huskies/bot.toml.bak
 # Rust stuff
 target
@@ -45,3 +45,7 @@ server/target
 *.sln
 *.sw?
 /test-results/.last-run.json
 # Ignore old story files until we feel like deleting them
 .storkit
 .storkit_port
@@ -23,3 +23,6 @@ token_usage.jsonl
 # Chat service logs
 whatsapp_history.json
 # Timers
 timers.json
@@ -9,16 +9,22 @@
 When you start a new session with this project:
-1. **Check for MCP Tools:** Read `.mcp.json` to discover the MCP server endpoint. Then list available tools by calling:
+1. **Check Setup Wizard:** Call `wizard_status` to check if project setup is complete. If the wizard is not complete, guide the user through the remaining steps. Important rules for the wizard flow:
   - **Be conversational.** Don't show tool names, step numbers, or raw wizard output to the user.
   - **On projects with existing code:** Read the codebase and generate each file, then show the user what you wrote and ask if it looks right.
   - **On bare projects with no code:** Ask the user what they want to build, what language/framework they plan to use, and generate files from their answers.
   - **You must actually generate the files.** The workflow for each step is: (1) call `wizard_generate` with no args to get a hint, (2) write the file content yourself based on the conversation, (3) call `wizard_generate` again with the `content` argument containing the full file body, (4) show the user what you wrote, (5) call `wizard_confirm` (they approve), `wizard_retry` (they want changes), or `wizard_skip` (they want to skip). Do not stop after discussing — follow through and write the files.
   - **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.
-2. **Read Context:** Check `.story_kit/specs/00_CONTEXT.md` for high-level project goals.
+3. **Read Context:** Check `.huskies/specs/00_CONTEXT.md` for high-level project goals.
-3. **Read Stack:** Check `.story_kit/specs/tech/STACK.md` for technical constraints and patterns.
+4. **Read Stack:** Check `.huskies/specs/tech/STACK.md` for technical constraints and patterns.
-4. **Check Work Items:** Look at `.story_kit/work/1_backlog/` and `.story_kit/work/2_current/` to see what work is pending.
+5. **Check Work Items:** Look at `.huskies/work/1_backlog/` and `.huskies/work/2_current/` to see what work is pending.
 ---
@@ -232,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 |
 |-----------|-------------|-----------------|
@@ -242,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
 ```
@@ -63,40 +63,62 @@ system_prompt = "You are a full-stack engineer working autonomously in a git wor
 [[agent]]
 name = "qa-2"
 stage = "qa"
-role = "Reviews coder work in worktrees: runs quality gates, generates testing plans, and reports findings."
+role = "Reviews coder work in worktrees: runs quality gates, verifies acceptance criteria, and reports findings."
 model = "sonnet"
 max_turns = 40
 max_budget_usd = 4.00
-prompt = """You are the QA agent for story {{story_id}}. Your job is to review the coder's work in the worktree and produce a structured QA report.
+prompt = """You are the QA agent for story {{story_id}}. Your job is to verify the coder's work satisfies the story's acceptance criteria and produce a structured QA report.
 Read CLAUDE.md first, then .story_kit/README.md to understand the dev process.
 ## Your Workflow
-### 1. Code Quality Scan
+### 0. Read the Story
- Run `git diff master...HEAD --stat` to see what files changed
+- Read the story file at `.huskies/work/3_qa/{{story_id}}.md`
- Run `git diff master...HEAD` to review the actual changes for obvious coding mistakes (unused imports, dead code, unhandled errors, hardcoded values)
+- Extract every acceptance criterion (the `- [ ]` checkbox lines)
- Run `cargo clippy --all-targets --all-features` and note any warnings
+- Keep this list in mind for Step 3
 ### 1. Deterministic Gates (Prerequisites)
 Run these first — if any fail, reject immediately without proceeding to AC review:
 - Run `cargo clippy --all-targets --all-features` — must show 0 errors, 0 warnings
 - Run `cargo test` and verify all tests pass
 - If a `frontend/` directory exists:
  - Run `npm run build` and note any TypeScript errors
  - Run `npx @biomejs/biome check src/` and note any linting issues
  - Run `npm test` and verify all frontend tests pass
-### 2. Test Verification
+### 2. Code Change Review
- Run `cargo test` and verify all tests pass
+- Run `git diff master...HEAD --stat` to see what files changed
- If `frontend/` exists: run `npm test` and verify all frontend tests pass
+- Run `git diff master...HEAD` to review the actual changes
- Review test quality: look for tests that are trivial or don't assert meaningful behavior
+- Flag any incomplete implementations:
  - `todo!()`, `unimplemented!()`, `panic!()` used as stubs
  - Placeholder strings like "TODO", "FIXME", "not implemented"
  - Empty match arms or arms that just return `Default::default()`
  - Hardcoded values where real logic is expected
 - Note any obvious coding mistakes (unused imports, dead code, unhandled errors)
-### 3. Manual Testing Support
+### 3. Acceptance Criteria Review
 For each AC extracted in Step 0:
 - Review the diff and test files to determine if the code addresses this AC
 - PASS: describe specifically how the code addresses it (which file/function/test)
 - FAIL: explain exactly what is missing or incorrect
 An AC fails if:
 - No code change or test relates to it
 - The implementation is stubbed out (todo!/unimplemented!)
 - A test exists but doesn't actually assert the behaviour described
 ### 4. Manual Testing Support (only if all gates PASS and all ACs PASS)
 - Build the server: run `cargo build` and note success/failure
 - If build succeeds: find a free port (try 3010-3020) and attempt to start the server
 - Generate a testing plan including:
  - 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)
-### 4. Produce Structured Report
+### 5. Produce Structured Report and Verdict
-Print your QA report to stdout before your process exits. The server will automatically run acceptance gates. Use this format:
+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:
 ```
 ## QA Report for {{story_id}}
@@ -105,27 +127,38 @@ Print your QA report to stdout before your process exits. The server will automa
 - clippy: PASS/FAIL (details)
 - TypeScript build: PASS/FAIL/SKIP (details)
 - Biome lint: PASS/FAIL/SKIP (details)
 - Code review findings: (list any issues found, or "None")
 ### Test Verification
 - cargo test: PASS/FAIL (N tests)
 - npm test: PASS/FAIL/SKIP (N tests)
- Test quality issues: (list any trivial/weak tests, or "None")
+- Incomplete implementations: (list any todo!/unimplemented!/stubs found, or "None")
 - Other code review findings: (list any issues found, or "None")
 ### Acceptance Criteria Review
 - AC: <criterion text>
  Result: PASS/FAIL
  Evidence: <how the code addresses it, or what is missing>
 (repeat for each AC)
 ### Manual Testing Plan
- Server URL: http://localhost:PORT (or "Build failed")
+- Server URL: http://localhost:PORT (or "Skipped — gate/AC failure" or "Build failed")
- Pages to visit: (list)
+- Pages to visit: (list, or "N/A")
- Things to check: (list)
+- Things to check: (list, or "N/A")
- curl commands: (list)
+- curl commands: (list, or "N/A")
 ### Overall: PASS/FAIL
 Reason: (summary of why it passed or the primary reason it failed)
 ```
 After printing the report:
 - If Overall is PASS: call `approve_qa(story_id='{{story_id}}')` via MCP
 - If Overall is FAIL: call `reject_qa(story_id='{{story_id}}', notes='<concise reason>')` via MCP so the coder knows exactly what to fix
 ## Rules
 - Do NOT modify any code — read-only review only
- If the server fails to start, still provide the testing plan with curl commands
+- Gates must pass before AC review — a gate failure is an automatic reject
- The server automatically runs acceptance gates when your process exits"""
+- If any AC is not met, the overall result is FAIL
-system_prompt = "You are a QA agent. Your job is read-only: review code quality, run tests, try to start the server, and produce a structured QA report. Do not modify code. The server automatically runs acceptance gates when your process exits."
+- Always call approve_qa or reject_qa — never leave the story without a verdict"""
 system_prompt = "You are a QA agent. Your job is read-only: run quality gates, verify each acceptance criterion against the diff, and produce a structured QA report. Always call approve_qa or reject_qa via MCP to record your verdict. Do not modify code."
 [[agent]]
 name = "coder-opus"
@@ -140,40 +173,62 @@ system_prompt = "You are a senior full-stack engineer working autonomously in a
 [[agent]]
 name = "qa"
 stage = "qa"
-role = "Reviews coder work in worktrees: runs quality gates, generates testing plans, and reports findings."
+role = "Reviews coder work in worktrees: runs quality gates, verifies acceptance criteria, and reports findings."
 model = "sonnet"
 max_turns = 40
 max_budget_usd = 4.00
-prompt = """You are the QA agent for story {{story_id}}. Your job is to review the coder's work in the worktree and produce a structured QA report.
+prompt = """You are the QA agent for story {{story_id}}. Your job is to verify the coder's work satisfies the story's acceptance criteria and produce a structured QA report.
 Read CLAUDE.md first, then .story_kit/README.md to understand the dev process.
 ## Your Workflow
-### 1. Code Quality Scan
+### 0. Read the Story
- Run `git diff master...HEAD --stat` to see what files changed
+- Read the story file at `.huskies/work/3_qa/{{story_id}}.md`
- Run `git diff master...HEAD` to review the actual changes for obvious coding mistakes (unused imports, dead code, unhandled errors, hardcoded values)
+- Extract every acceptance criterion (the `- [ ]` checkbox lines)
- Run `cargo clippy --all-targets --all-features` and note any warnings
+- Keep this list in mind for Step 3
 ### 1. Deterministic Gates (Prerequisites)
 Run these first — if any fail, reject immediately without proceeding to AC review:
 - Run `cargo clippy --all-targets --all-features` — must show 0 errors, 0 warnings
 - Run `cargo test` and verify all tests pass
 - If a `frontend/` directory exists:
  - Run `npm run build` and note any TypeScript errors
  - Run `npx @biomejs/biome check src/` and note any linting issues
  - Run `npm test` and verify all frontend tests pass
-### 2. Test Verification
+### 2. Code Change Review
- Run `cargo test` and verify all tests pass
+- Run `git diff master...HEAD --stat` to see what files changed
- If `frontend/` exists: run `npm test` and verify all frontend tests pass
+- Run `git diff master...HEAD` to review the actual changes
- Review test quality: look for tests that are trivial or don't assert meaningful behavior
+- Flag any incomplete implementations:
  - `todo!()`, `unimplemented!()`, `panic!()` used as stubs
  - Placeholder strings like "TODO", "FIXME", "not implemented"
  - Empty match arms or arms that just return `Default::default()`
  - Hardcoded values where real logic is expected
 - Note any obvious coding mistakes (unused imports, dead code, unhandled errors)
-### 3. Manual Testing Support
+### 3. Acceptance Criteria Review
 For each AC extracted in Step 0:
 - Review the diff and test files to determine if the code addresses this AC
 - PASS: describe specifically how the code addresses it (which file/function/test)
 - FAIL: explain exactly what is missing or incorrect
 An AC fails if:
 - No code change or test relates to it
 - The implementation is stubbed out (todo!/unimplemented!)
 - A test exists but doesn't actually assert the behaviour described
 ### 4. Manual Testing Support (only if all gates PASS and all ACs PASS)
 - Build the server: run `cargo build` and note success/failure
 - If build succeeds: find a free port (try 3010-3020) and attempt to start the server
 - Generate a testing plan including:
  - 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)
-### 4. Produce Structured Report
+### 5. Produce Structured Report and Verdict
-Print your QA report to stdout before your process exits. The server will automatically run acceptance gates. Use this format:
+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:
 ```
 ## QA Report for {{story_id}}
@@ -182,27 +237,38 @@ Print your QA report to stdout before your process exits. The server will automa
 - clippy: PASS/FAIL (details)
 - TypeScript build: PASS/FAIL/SKIP (details)
 - Biome lint: PASS/FAIL/SKIP (details)
 - Code review findings: (list any issues found, or "None")
 ### Test Verification
 - cargo test: PASS/FAIL (N tests)
 - npm test: PASS/FAIL/SKIP (N tests)
- Test quality issues: (list any trivial/weak tests, or "None")
+- Incomplete implementations: (list any todo!/unimplemented!/stubs found, or "None")
 - Other code review findings: (list any issues found, or "None")
 ### Acceptance Criteria Review
 - AC: <criterion text>
  Result: PASS/FAIL
  Evidence: <how the code addresses it, or what is missing>
 (repeat for each AC)
 ### Manual Testing Plan
- Server URL: http://localhost:PORT (or "Build failed")
+- Server URL: http://localhost:PORT (or "Skipped — gate/AC failure" or "Build failed")
- Pages to visit: (list)
+- Pages to visit: (list, or "N/A")
- Things to check: (list)
+- Things to check: (list, or "N/A")
- curl commands: (list)
+- curl commands: (list, or "N/A")
 ### Overall: PASS/FAIL
 Reason: (summary of why it passed or the primary reason it failed)
 ```
 After printing the report:
 - If Overall is PASS: call `approve_qa(story_id='{{story_id}}')` via MCP
 - If Overall is FAIL: call `reject_qa(story_id='{{story_id}}', notes='<concise reason>')` via MCP so the coder knows exactly what to fix
 ## Rules
 - Do NOT modify any code — read-only review only
- If the server fails to start, still provide the testing plan with curl commands
+- Gates must pass before AC review — a gate failure is an automatic reject
- The server automatically runs acceptance gates when your process exits"""
+- If any AC is not met, the overall result is FAIL
-system_prompt = "You are a QA agent. Your job is read-only: review code quality, run tests, try to start the server, and produce a structured QA report. Do not modify code. The server automatically runs acceptance gates when your process exits."
+- Always call approve_qa or reject_qa — never leave the story without a verdict"""
 system_prompt = "You are a QA agent. Your job is read-only: run quality gates, verify each acceptance criterion against the diff, and produce a structured QA report. Always call approve_qa or reject_qa via MCP to record your verdict. Do not modify code."
 [[agent]]
 name = "mergemaster"
@@ -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 |
+| `/huskies-status` | Show pipeline status and agent availability |
-| `/storkit-cost` | Show token spend: 24h total, top stories, and breakdown |
+| `/huskies-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`) |
+| `/huskies-show` | Display the full text of a work item (e.g. `/huskies-show 42`) |
-| `/storkit-git` | Show git status: branch, changes, ahead/behind |
+| `/huskies-git` | Show git status: branch, changes, ahead/behind |
-| `/storkit-htop` | Show system and agent process dashboard |
+| `/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`
+- **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 `STORKIT_PORT` to know which backend to talk to, so export it before running: `export STORKIT_PORT=3002 && cd frontend && npm run dev`
+- **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.
@@ -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
@@ -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,21 @@
 ---
 name: "Unblock command handles all stuck states not just blocked flag"
 ---
 # Story 435: Unblock command handles all stuck states not just blocked flag
 ## User Story
 As a project owner, I want the unblock command to clear any stuck state on a story — not just the blocked flag — so that I have a single command to unstick stories regardless of why they're stuck.
 ## Acceptance Criteria
 - [ ] Unblock clears merge_failure field in addition to blocked flag
 - [ ] Unblock clears review_hold field
 - [ ] Unblock reports which fields were cleared in the confirmation message
 - [ ] Unblock works on stories in any pipeline stage (backlog, current, qa, merge, done)
 - [ ] If no stuck state is found (no blocked, merge_failure, or review_hold), returns a clear message saying so
 ## Out of Scope
 - TBD
@@ -0,0 +1,26 @@
 ---
 name: "Unify story stuck states into a single status field"
 ---
 # Refactor 436: Unify story stuck states into a single status field
 ## Current State
 - TBD
 ## Desired State
 Replace the separate blocked, merge_failure, and review_hold front matter fields with a single status field (e.g. status: blocked, status: merge_failure, status: review_hold). Simplifies the unblock command, auto-assign checks, and pipeline advance logic.
 ## Acceptance Criteria
 - [ ] Replace blocked: true, merge_failure: string, and review_hold: true with a single status: field in story front matter
 - [ ] Auto-assign checks a single field instead of three separate ones
 - [ ] Pipeline advance and lifecycle code reads/writes the unified status field
 - [ ] Unblock command clears the status field regardless of which stuck state it was
 - [ ] retry_count remains a separate field (it's a counter, not a state)
 - [ ] Migration: existing stories with old fields are handled gracefully on read
 ## Out of Scope
 - TBD
@@ -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
@@ -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
@@ -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
@@ -17,21 +17,21 @@ const TEMPLATE_MARKER_CONTEXT: &str = "Agentic AI Code Assistant";
 const TEMPLATE_MARKER_STACK: &str = "Agentic Code Assistant";
 ```
-These markers are phrases that appear in the scaffold templates (`server/src/io/fs.rs` lines 233 and 269). The detection logic (`is_template_or_missing` at line 59) checks if the file *contains* the marker string. But these phrases are generic enough that real project content can contain them too — especially when the project being managed IS an agentic code assistant (i.e. storkit managing itself).
+These markers are phrases that appear in the scaffold templates (`server/src/io/fs.rs` lines 233 and 269). The detection logic (`is_template_or_missing` at line 59) checks if the file *contains* the marker string. But these phrases are generic enough that real project content can contain them too — especially when the project being managed IS an agentic code assistant (i.e. huskies managing itself).
 ## The Fix
 Replace the content-based marker detection with a dedicated sentinel comment that only exists in untouched scaffold templates. The sentinel should be something that would never appear in real content, like an HTML comment:
 ```
-<!-- storkit:scaffold-template -->
+<!-- huskies:scaffold-template -->
 ```
 Changes needed:
-1. **`server/src/io/onboarding.rs`**: Replace `TEMPLATE_MARKER_CONTEXT` and `TEMPLATE_MARKER_STACK` with a single `TEMPLATE_SENTINEL` constant set to `"<!-- storkit:scaffold-template -->"`. Update `check_onboarding_status` to use it for both context and stack checks.
+1. **`server/src/io/onboarding.rs`**: Replace `TEMPLATE_MARKER_CONTEXT` and `TEMPLATE_MARKER_STACK` with a single `TEMPLATE_SENTINEL` constant set to `"<!-- huskies:scaffold-template -->"`. Update `check_onboarding_status` to use it for both context and stack checks.
-2. **`server/src/io/fs.rs`**: Add `<!-- storkit:scaffold-template -->` as the first line of both `STORY_KIT_CONTEXT` and `STORY_KIT_STACK` template constants (lines 233 and 269).
+2. **`server/src/io/fs.rs`**: Add `<!-- huskies:scaffold-template -->` as the first line of both `STORY_KIT_CONTEXT` and `STORY_KIT_STACK` template constants (lines 233 and 269).
 3. **`server/src/io/onboarding.rs` tests**: Update the test `needs_onboarding_true_when_specs_contain_scaffold_markers` to use the sentinel instead of the old marker phrases. Also add a test confirming that content containing "Agentic AI Code Assistant" WITHOUT the sentinel does NOT trigger onboarding.
@@ -42,7 +42,7 @@ Changes needed:
 ## Acceptance Criteria
- [ ] Scaffold templates contain the sentinel `<!-- storkit:scaffold-template -->` as first line
+- [ ] Scaffold templates contain the sentinel `<!-- huskies:scaffold-template -->` as first line
 - [ ] `needs_onboarding()` returns false for projects whose specs contain "Agentic AI Code Assistant" but NOT the sentinel
 - [ ] `needs_onboarding()` returns true for untouched scaffold content (which contains the sentinel)
 - [ ] Existing tests updated and passing
--- a/Show More
+++ b/Show More