headwater is one of a family of tools that turn what happens outside a
repository into work that lands in it. Each tool stands alone, and each
one’s site is its own.
The Flywheel family: one loop from what is noticed to what lands headwater reports a new release of mise and eddy lists a recorded planning call; each prints a capture, and millpond keeps both. The release is its own excerpt, so it becomes one signal; a reader reads the meeting into three signals. Curation joins two of them into one item and makes the third, a question, an item of its own. Each item runs down the flume, which launches one agent in one worktree for it: the bump in one worktree, the export in a planner's plan, and the question in a sounding, whose accepted conclusion comes back to millpond as a new item. sluice tests each change as merged and lands both on main, and flume tidies the bump's worktree. The landed bump moves the pin back to headwater, which stops reporting that release. Flywheel is the Method the whole loop belongs to. Flywheel the Method all of it belongs to 1 NOTICE 2 INBOX 3 LAUNCH 4 WORK 5 LAND 6 THE LOOP CLOSES the landed bump moves the pin to 2026.10.10 headwater mise 2026.10.10 new release · reported pinned · not reported eddy Wispr · planning recorded · 32 min millpond the inbox captures signals items own excerpt reader curation flume one worktree an agent on one branch a planner's plan a chore for a team sounding works one question conclusion accepted landed · tidied sluice tests each as merged lands what passed mise CSV main bump mise CSV export keep JSON Parquet? release meeting sent sent bump mise CSV export bump mise CSV export 2 signals Parquet? Parquet The Flywheel family: one loop from what is noticed to what lands headwater reports a new release of mise and eddy lists a recorded planning call; each prints a capture, and millpond keeps both. The release is its own excerpt, so it becomes one signal; a reader reads the meeting into three signals. Curation joins two of them into one item and makes the third, a question, an item of its own. Each item runs down the flume, which launches one agent in one worktree for it: the bump in one worktree, the export in a planner's plan, and the question in a sounding, whose accepted conclusion comes back to millpond as a new item. sluice tests each change as merged and lands both on main, and flume tidies the bump's worktree. The landed bump moves the pin back to headwater, which stops reporting that release. Flywheel is the Method the whole loop belongs to. Flywheel the Method all of it belongs to 1 NOTICE 2 INBOX 3 LAUNCH 4 WORK 5 LAND 6 THE LOOP CLOSES the landed bump moves the pin to 2026.10.10 headwater mise 2026.10.10 new release · reported pinned · not reported eddy Wispr · planning recorded · 32 min millpond the inbox captures signals items own excerpt reader curation flume one worktree an agent on one branch a planner's plan a chore for a team sounding works one question conclusion accepted landed · tidied sluice tests each as merged lands what passed mise CSV main bump mise CSV export keep JSON Parquet? release meeting sent sent bump mise CSV export bump mise CSV export 2 signals Parquet? Parquet The Flywheel family: one loop from what is noticed to what lands headwater reports a new release of mise and eddy lists a recorded planning call; each prints a capture, and millpond keeps both. The release is its own excerpt, so it becomes one signal; a reader reads the meeting into three signals. Curation joins two of them into one item and makes the third, a question, an item of its own. Each item runs down the flume, which launches one agent in one worktree for it: the bump in one worktree, the export in a planner's plan, and the question in a sounding, whose accepted conclusion comes back to millpond as a new item. sluice tests each change as merged and lands both on main, and flume tidies the bump's worktree. The landed bump moves the pin back to headwater, which stops reporting that release. Flywheel is the Method the whole loop belongs to. Flywheel the Method all of it belongs to 1 NOTICE 2 INBOX 3 LAUNCH 4 WORK 5 LAND 6 THE LOOP CLOSES the landed bump moves the pin to 2026.10.10 headwater mise 2026.10.10 new release · reported pinned · not reported eddy Wispr · planning recorded · 32 min millpond the inbox captures signals items own excerpt reader curation flume one worktree an agent on one branch a planner's plan a chore for a team sounding works one question conclusion accepted landed · tidied sluice tests each as merged lands what passed mise CSV main bump mise CSV export keep JSON Parquet? release meeting sent sent bump mise CSV export bump mise CSV export 2 signals Parquet? Parquet One loop, from what is noticed to what lands. Flywheel is the Method it belongs to.
1 headwater and eddy notice events and print captures.2 millpond keeps them as an inbox: captures become signals, and curation joins signals into items.3 millpond sends each item down flume , which launches one agent in one worktree for it, and tidies the place once the work lands.4 An item is worked in its worktree or a planner's plan. A question goes to a sounding , whose conclusion comes back as new items. 5 sluice tests the work as merged and lands it.6 The landed bump moves the pin, so headwater stops reporting that release. Pause One core, every surface: alone or feeding an inbox headwater’s one core reports the release pkg:npm/react@19.2.1, and Claude Code, herdr, the command line and the Flywheel plugin each show it under that same name. Alone: a key in herdr starts an agent in its own worktree, which bumps react to 19.2.1, and sluice lands the bump. With an inbox: the Flywheel plugin hands the release to millpond under the key release/npm/react/19.2.1; a second scan reports it again under the same key and millpond keeps it once; the plan turns it into work, and sluice lands the bump. Either way the pin moves to 19.2.1 and the release leaves every surface. ALONE WITH AN INBOX the pin moves to 19.2.1 headwater one core scan · report · brief Claude Code herdr command line Flywheel plugin pkg:npm/react@19.2.1 pkg:npm/react@19.2.1 pkg:npm/react@19.2.1 pkg:npm/react@19.2.1 f agent in a worktree bump react to 19.2.1 millpond release/npm/react/19.2.1 second scan, same key: kept once an item, then the plan sluice lands Alone: a key in herdr starts an agent in a worktree, and sluice lands its bump. With an inbox: millpond keeps the release once, and the plan turns it into work. Either way the landed bump moves the pin, and the release leaves every surface. One core, every surface: alone or feeding an inbox headwater’s one core reports the release pkg:npm/react@19.2.1, and Claude Code, herdr, the command line and the Flywheel plugin each show it under that same name. Alone: a key in herdr starts an agent in its own worktree, which bumps react to 19.2.1, and sluice lands the bump. With an inbox: the Flywheel plugin hands the release to millpond under the key release/npm/react/19.2.1; a second scan reports it again under the same key and millpond keeps it once; the plan turns it into work, and sluice lands the bump. Either way the pin moves to 19.2.1 and the release leaves every surface. ALONE WITH AN INBOX the pin moves to 19.2.1 headwater one core Claude Code herdr command line Flywheel plugin pkg:npm/react@19.2.1 pkg:npm/react@19.2.1 pkg:npm/react@19.2.1 pkg:npm/react@19.2.1 f agent in a worktree bump react to 19.2.1 millpond release/npm/react/19.2.1 second scan, same key: kept once sluice lands Alone: a key in herdr starts an agent in a worktree, and sluice lands its bump. With an inbox: millpond keeps the release once, and the plan turns it into work. Either way the landed bump moves the pin, and the release leaves every surface. headwater needs none of the others. With its Claude Code and herdr plugins
it is the whole loop: a sidebar of unread releases, a brief a fixer reads,
and a key that starts an agent in a worktree of its own to make the bump
and submit it to sluice.
In a repository whose work runs through a plan, headwater’s Flywheel plugin
hands each release to millpond instead. On each run, headwater capture
prints a capture for every release newer than its pin, its notes as the
excerpt, under a key made from the release’s Package URL,
release/<type>/<namespace>/<name>/<version>. millpond keeps each key
once, so a release headwater reports every day lands once. There the fix key hands the release to millpond as well, and
no agent starts outside the plan.
headwater never learns which inbox records its releases, and millpond
never asks a source itself. The pin closes the loop either way: when the
bump lands, the release leaves every report.
swancloud, a NixOS fleet, pins its tools in Nix, where no manifest names
them. A watch list generated from those pins gives headwater each tool’s
upstream repository, tag pattern and pin. Its entries keep the key the
fleet’s own release adapter has used since its first landing,
release/<name>/<version>, so millpond sees each release it already
holds as the same one.
