Who owns what
Each part of capture owns one job and never reaches into another’s. Each format and rule is written once and used by every part that needs it.
Each part’s job
| Part | Owns | Never |
|---|---|---|
| An adapter | One source. It lists the source’s events, keys each one, fetches the raw material, and marks a capture that is its own excerpt. | Writes records, keeps a list of what it reported, cuts an excerpt, or reads a capture into signals (115). |
| headwater | Releases and advisories for what a repository declares. It stands alone with its Claude Code and herdr plugins, and its Flywheel plugin holds an adapter part. | Knows which inbox records its releases. |
| eddy | Recorded meetings across meeting services, with a part per service. It stands alone as headwater does. | Reads a meeting into signals. |
| millpond | Runs adapters and takes the capture contract. Dedupes by key, banks raw material, and writes each capture, plus the one signal of a capture that is its own excerpt. Keeps the inbox, checks a reader’s excerpts, writes moves and items, records each send and its outcome, and records each run. | Judges what a capture says, starts an agent, or plans across items. |
| flume | Places on the host it runs on: makes a worktree ready, starts each stage’s agent in it with its prompt confirmed, moves on when the stage’s deliverable exists, and tidies the place. Reports each place’s state. | Decides what to launch, plans across items, or lands anything itself. |
| A reader, a session | Reads a capture that is not its own excerpt into signals, through millpond (113, 217e). | Lists a source. |
| Curation, a session | Proposes one move per signal, in batches, through millpond’s tools (116). | Writes captures or signals. |
| sounding | One question in one session, in a worktree of its own, ending on a conclusion. It offers each finding beyond its question to millpond as a capture. | Lands code, writes the inbox except through millpond, or plans across items. |
| The operator | Accepts or changes each batch of moves, sends an item, and decides each conclusion. | Picks through signals one at a time. |
| crew | Teams, plans and bolts. Its planner turns items into chores and units across teams. | Writes an inbox’s records except through millpond. |
| sluice | Tests a change as merged and lands it. | Knows where the change came from. |
| The fleet | Says which adapter part runs for which inbox, on which host, and when. Hands headwater the pins that only Nix can read. Watches every run from the doctor. | Runs an adapter’s logic itself. |
Code built once
| Part | Built in | Used by |
|---|---|---|
| The contract’s types and key rules, JSON in flight and rec at rest, a sha256 content hash, and the excerpt cut | flywheel-next’s capture crate | millpond, Flywheel, headwater’s and eddy’s adapter parts |
| The signal, move and item records and the inbox’s layout | flywheel-next’s signals crate | millpond, Flywheel |
| The folder drop, the meeting file and the signals-folder import | flywheel-next’s adapters crate | millpond, Flywheel |
| Cadence: five-field cron, caught up once | flywheel-next’s cadence | millpond tick, Flywheel’s tick |
| The conformance pack: lines in, records expected | flywheel-next | millpond and Flywheel as hosts, every adapter part |
| Raw banking with a host-qualified pointer, the checks on a capture, and the verbatim check on a reader’s excerpt | millpond, from crew’s checks | Flywheel, for 217h and 217e |
| Finding releases and reading their notes | swancloud’s release adapter | headwater’s lookups and its Flywheel plugin |
| One question, one session, one conclusion: the question, its rounds and the conclusion’s shape | sounding, from crew ADR 0019 | crew, Flywheel’s elaborations |
| Places, a fresh agent per stage, prompt delivery, stages that end on their deliverable, and tidying | flume, from crew’s teams.2–4, teams.11, teams.15 and plan.9, 10, 12, 17 | millpond, headwater, sounding, crew |
The conformance pack is how a part proves it keeps the contract: a set of contract lines and the records a host must write from them, with the meeting checks a meeting part passes. millpond passes it as a host, and so does Flywheel; headwater’s, eddy’s and anyone’s adapter parts pass it as adapters.
millpond keeps its own Claude Code and herdr plugins under plugins/
beside its core, as headwater and eddy keep theirs. Its built-in
adapters are commands of its own, so it has no Flywheel plugin.