Timmy
5765fb57be
Manual squash-merge of feature/story-478_… into master after the in-pipeline mergemaster runs failed silently. The 478 agent did substantial real work across multiple respawn cycles before being interrupted; commits on the feature branch were intact and verified high-quality but never merged via the normal pipeline path due to compounding bugs: - The first mergemaster attempt ran ($0.82 in tokens) and exited "Done" cleanly but didn't push anything to master — likely the worktree was briefly on master rather than the feature branch when the merge_agent_work MCP tool ran, so it found nothing to merge. - Subsequent timer fires defaulted to spawning coders instead of resuming mergemaster, burning more tokens for no progress. - Bug 510 (split-brain shadows yanking done stories back to current) and bug 501 (timers don't cancel on stop/completion) compounded the cost. What this commit lands: - server/src/crdt_sync.rs (new, ~518 lines): GET /crdt-sync WebSocket handler that subscribes to locally-applied SignedOps and streams them as binary frames. Per-peer bounded queue (256 ops) drops slow peers. - server/src/crdt_state.rs: new public functions subscribe_ops(), all_ops_json(), apply_remote_op() backing the sync handler. Adds the CRDT_OP_TX broadcast channel (capacity 1024). - server/src/main.rs: wires up the sync subsystem at startup. - server/src/http/mod.rs: registers the new endpoint. - server/src/config.rs: adds optional rendezvous field for outbound peers. - server/src/worktree.rs: minor changes from the original branch. - server/Cargo.toml: cfg lint suppression for CrdtNode derive. - crates/bft-json-crdt/src/debug.rs: fix unused-variable warnings. Resolved a trivial test-mod merge conflict in crdt_state.rs (both 478 and 503 added new tests at the end of the test module — kept both sets). Note: this is the squash of the original 478 work that the user explicitly authorized landing. The earlier rogue commit ac9f3ecf — which added a DIFFERENT, broken implementation of the same feature directly to master under the user's identity without consent — was reverted earlier in this session. The forensic tags rogue-commit-2026-04-09-ac9f3ecf and pre-502-reset-2026-04-09 still exist for incident audit. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Huskies
A story-driven development server that manages work items, spawns coding agents, and runs them through a pipeline from backlog to done. Ships as a single Rust binary with an embedded React frontend.
Getting started with Claude Code
-
Download the huskies binary (or build from source — see below).
-
From your project directory, scaffold and start the server:
huskies init --port 3000
This creates a .huskies/ directory with the pipeline structure, project.toml, and .mcp.json. The .mcp.json file lets Claude Code discover huskies' MCP tools automatically.
Huskies also ships an embedded React frontend. Once the server is running, open http://localhost:3000 to see the pipeline board, agent status, and chat interface.
-
Open a Claude Code session in the same project directory, or visit http://localhost:3000/.
-
Tell Claude: "help me set up this project with huskies." Claude will walk you through the setup wizard — generating project context, tech stack docs, and test/release scripts. Review each step and confirm or ask to retry.
Once setup is complete, Claude can create stories, start agents, check status, and manage the full pipeline via MCP tools — no commands to memorize.
Chat transports
Huskies can be controlled via bot commands in Matrix, WhatsApp, and Slack. Configure a transport in .huskies/bot.toml — see the example files:
.huskies/bot.toml.matrix.example.huskies/bot.toml.whatsapp-meta.example.huskies/bot.toml.whatsapp-twilio.example.huskies/bot.toml.slack.example
Prerequisites for building
- Rust (2024 edition)
- Node.js and npm
- Docker (for Linux cross-compilation and container deployment)
cross(cargo install cross) optional, for Linux static builds. Only needed if you are building for a different architecture, e.g. if you want to build a Linux binary from a Mac.
You only need these installed if you want to build Huskies yourself. Alternately, you can just download and run the huskies binary for your system from https://code.crashlabs.io/crashlabs/huskies/releases
Building for production
cargo build --release
The release binary embeds the frontend via rust-embed. Output: target/release/huskies.
For a static Linux binary (musl, zero dynamic deps):
cross build --release --target x86_64-unknown-linux-musl
Docker:
script/docker_rebuild
# or
script/docker_restart
Running in development
# Run tests
script/test
# Run the server
cargo run -- --port 3000
# In another terminal, run the frontend dev server
cd frontend && npm install && npm run dev
Configuration lives in .huskies/project.toml. See .huskies/bot.toml.*.example for transport setup.
Releasing
Requires a Gitea API token in .env (GITEA_TOKEN=your_token).
script/release 0.7.1
This bumps version in Cargo.toml and package.json, builds macOS arm64 and Linux amd64 binaries, tags the repo, and publishes a Gitea release with changelog and binaries attached.
License
GPL-3.0. See LICENSE.