1.**Read CLAUDE.md** in the worktree root for project-specific rules.
2.**Check MCP Tools:** Your `.mcp.json` connects you to the huskies server. Use MCP tools for all pipeline operations — never manipulate files directly.
3.**Check your story:** Call `status(story_id)` or `get_story_todos(story_id)` to see what needs doing.
1.**Read the story** via `status(story_id)` — understand the acceptance criteria.
2.**Implement** the feature/fix in your worktree. Commit as you go using `git_add` and `git_commit` MCP tools.
3.**Run tests** via the `run_tests` MCP tool (starts tests in the background). Poll `get_test_result` to check completion. Never run `cargo test` or `script/test` directly via Bash.
4.**Check off acceptance criteria** as you complete them using `check_criterion(story_id, criterion_index)`.
5.**Commit and exit.** The server runs acceptance gates automatically when your process exits and advances the pipeline based on the results.
Huskies is a single Rust binary with an embedded React frontend. Key things to know:
- **Backend:** `server/src/` — Rust, built with Poem (HTTP framework)
- **Frontend:** `frontend/src/` — React + TypeScript, built with Vite
- **Gateway mode:** `huskies --gateway` is a deployment mode of the same binary, NOT a separate application. The gateway backend code lives in `server/src/gateway.rs`. Gateway frontend components live in `frontend/src/` alongside everything else.
- **Stories that say "UI":** These are primarily frontend (TypeScript/React) work. Check what backend endpoints already exist before adding new ones. Keep Rust changes minimal.
- **Stories that say "gateway":** The gateway is just a mode. Don't restructure `gateway.rs` unless the story specifically asks for backend changes.
Huskies has three modes, all from the same binary:
### Standard (single project)
```
huskies [--port 3001] /path/to/project
```
Full server: web UI, MCP endpoint, chat bot, agent pool, pipeline. One project per instance.
### Headless Build Agent
```
huskies --rendezvous ws://host:port/crdt-sync
```
Connects to an existing huskies instance as a worker node. Syncs the CRDT, claims work from the pipeline, runs agents. No web UI, no chat — just a build worker. Use this to add more compute to a project by running extra containers.
### Gateway (multi-project)
```
huskies --gateway [--port 3000] /path/to/config
```
Lightweight proxy that sits in front of multiple project containers. Reads a `projects.toml` that maps project names to container URLs:
```toml
[projects.huskies]
url="http://huskies:3001"
[projects.robot-studio]
url="http://robot-studio:3002"
```
The gateway presents a unified MCP surface to the chat agent. All tool calls are proxied to the active project's container. Gateway-specific tools:
| Tool | Purpose |
|------|---------|
| `switch_project` | Change the active project |
| `gateway_status` | Show active project and list all registered projects |
| `gateway_health` | Health check all containers |
| `init_project` | Scaffold a new `.huskies/` project at a given path — prefer this over asking the user to run `huskies init` on the CLI |
**Initialising a new project via MCP (preferred):** Instead of asking the user to run `huskies init <path>` in a terminal, call `init_project` with the `path` argument. Optionally pass `name` and `url` to register the project in `projects.toml` immediately. After that, start a huskies server at the path and use `switch_project` to make it active before calling `wizard_status`.