Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

eddy on its own

eddy is a tool for meetings first and an adapter second. It stands alone as headwater does: one core that lists and fetches meetings across services, and one plugin per host beside the core. A person who installs only eddy reads their meetings with it. A host that runs millpond takes the same listings as captures through eddy’s Flywheel plugin.

eddy's core and its three plugins eddy's core lists recorded meetings and fetches transcripts, and holds the code every part shares. Three plugins sit beside it. plugins/claude pulls a transcript into a Claude Code session. plugins/herdr shows the day's meetings in a pane. plugins/flywheel holds an adapter part per service, whose capture lines millpond runs, and Flywheel's tick later. Only the Flywheel plugin's parts reach an inbox. THE CORE A PLUGIN PER HOST WHAT IT GIVES eddy's core lists recorded meetings fetches a transcript per service it has a part for the code every part shares plugins/claude Claude Code plugins/herdr herdr plugins/flywheel an adapter part per service A transcript in a session for a person asking about one meeting The day's meetings in a pane across every service with a part Capture lines for millpond run by millpond, later by Flywheel's tick Only the Flywheel plugin's parts reach an inbox. The other two write nothing anywhere.
eddy is one core with a plugin per host. A person reaches meetings through the Claude Code and herdr plugins. millpond reaches them through the Flywheel plugin's adapter parts, and only those parts print captures.

The core

The core knows each meeting service eddy has a part for: how to list the meetings it recorded, and how to fetch one meeting’s transcript. It also holds the code every part shares: the key, the meeting’s details, the raw layout and the rule that skips a meeting too short to hold anything. What every part shares and A meeting’s raw files describe it. Every plugin calls the core, so the pane, the session and an adapter part all see the same meetings under the same keys.

The plugins

eddy keeps one plugin per host under plugins/, beside its core, as headwater does:

PluginHostGives
plugins/claudeClaude Codepulls a meeting’s transcript into a session
plugins/herdrherdrshows the day’s meetings
plugins/flywheelFlywheel, and millpondone adapter part per meeting service

A plugin is the installable unit in every host, and it holds parts of the kinds its host takes. Flywheel’s statement calls it a package (228, 284).

The Claude Code plugin serves a person working in a session who wants one meeting in front of them: what was agreed, who asked for what. It pulls the transcript into that session and records nothing. The herdr plugin shows the day’s meetings, from every service eddy has a part for, in a pane beside the person’s work.

The Flywheel plugin holds the adapter parts, one per meeting service, and nothing else. millpond runs a Flywheel plugin’s adapter parts and ignores the rest of it, so eddy’s parts run under millpond today and under Flywheel’s tick later, with no change (215, 231).

Alone, and beside an inbox

eddy needs no inbox. A person with only eddy’s Claude Code and herdr plugins lists and reads meetings, and nothing about them is kept anywhere.

A host that runs millpond names a meeting part in an inbox’s settings, and the part’s listings become captures. The inbox then works in any of its three setups: on its own, with crew, or with Flywheel (millpond’s three setups). Moving from one setup to the next changes the host and the curator. eddy’s parts stay as they were, so no meeting is captured twice.