Fleet Operations
Running the harness across many repos ("the fleet") is itself a set of harnessed operations, driven by skills.
Releases
The harness is versioned like any other package:
make releaseverifies a clean tree and a greenmake check, derives the next semver from Conventional Commits via git-cliff, updatesCHANGELOG.mdandVERSION, tags, and prints the push command. It does not push automatically — pushing a tag triggers deploys.- Consumers pull a new version with
apm install(pinned or tracking latest).
Fleet-update
The fleet-update skill rolls a new harness version across every consumer repo: open a branch per repo, bump the nshiffer/harness dependency, run make check, and open a PR with the raw gate output attached. Repos that go red are surfaced, not silently skipped.
Gardener cadence
The gardener skill scans a repo against its Golden Principles and flags drift — duplicated helpers, boundary validation gaps, functions that have grown two purposes. Run it on a regular cadence (e.g. per sprint) as cheap, continuous hygiene, not a big-bang cleanup.
Harness review on major model releases
Every harness component encodes an assumption about what the model cannot do on its own. When a materially more capable model ships, that assumption may no longer hold. On each major model release, review the harness and strip the pieces that are no longer load-bearing — guardrails the new model does not need are now just friction. The harness should shrink over time, not only grow.
Status and health
Registered repos appear in status.shwrk.com's projects.json and are polled at their /health endpoint. Because a non-ok status returns 503, a plain status-code poll is enough to drive the dashboard: 200 = up, anything else = down.