docs: FLEET.md — the roster's physical anatomy, as-built #40

Merged
dan-claude-bot merged 1 commit from docs/fleet-anatomy into main 2026-07-22 20:56:32 +00:00
dan-claude-bot commented 2026-07-22 20:55:43 +00:00 (Migrated from github.com)

What

Adds FLEET.md: a descriptive, as-built snapshot of the agent roster and how it physically runs — the five identity/box pairs, the duty-loop skeleton (cron + flock + poll + one-shot sessions), per-role wake conditions, the resilience layer (boot gate, crash-only resume, checkpoint discipline, worktree isolation), and the board conventions (🔎, , claim ritual, handoff).

Why

The fleet's setup currently lives only inside five boxes, applied incrementally by hand. Before it can be solidified into a reusable fleet-management solution, the shape of what exists has to be written down somewhere durable. This file is that record and states the plan explicitly: once ceremony proves itself, each agent will be asked to document its own setup in replicable detail, and those five descriptions get converged into templates.

Scope notes for reviewers

  • Operator-commissioned, outside the issue flow — danmt asked for this directly; there is deliberately no Closes #N. Not a stray.
  • Documentation only; no machinery touched. It is explicitly not doctrine and not part of the vendored .ceremony/ mirror set — it describes the bench, not the roles, so consumer repos never see it.
  • Review it for accuracy against your own box's reality: if FLEET.md says your loop does something it doesn't, that's exactly the kind of finding this PR wants.

🤖 Generated with Claude Code

## What Adds `FLEET.md`: a descriptive, as-built snapshot of the agent roster and how it physically runs — the five identity/box pairs, the duty-loop skeleton (cron + flock + poll + one-shot sessions), per-role wake conditions, the resilience layer (boot gate, crash-only resume, checkpoint discipline, worktree isolation), and the board conventions (`🔎`, `⟲`, claim ritual, handoff). ## Why The fleet's setup currently lives only inside five boxes, applied incrementally by hand. Before it can be solidified into a reusable fleet-management solution, the shape of what exists has to be written down somewhere durable. This file is that record and states the plan explicitly: once ceremony proves itself, each agent will be asked to document its own setup in replicable detail, and those five descriptions get converged into templates. ## Scope notes for reviewers - **Operator-commissioned, outside the issue flow** — danmt asked for this directly; there is deliberately no `Closes #N`. Not a stray. - Documentation only; no machinery touched. It is explicitly **not** doctrine and **not** part of the vendored `.ceremony/` mirror set — it describes the bench, not the roles, so consumer repos never see it. - Review it for accuracy against your own box's reality: if FLEET.md says your loop does something it doesn't, that's exactly the kind of finding this PR wants. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/ceremony#40
No description provided.