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

eddy lists recorded meetings across meeting services and fetches their transcripts. It holds one part per service: wispr first, then webex and teams. Each part lists the meetings its service recorded since its cursor, keys each meeting, writes its transcript as raw files, and prints one capture line per meeting. millpond takes those lines and records each meeting once, as an unread capture in an inbox (millpond’s book). No model runs while a part lists. A meeting becomes signals later, when a reader session reads its transcript (115).

eddy in one pass Three meeting services, Wispr Flow, Webex and Microsoft Teams, each feed one of eddy's parts. A part lists recorded meetings and fetches each transcript, and prints capture lines that millpond checks, dedupes by key and banks. No model runs inside that listing. What a listing leaves is an unread capture in the inbox, in git, which points at the raw transcript in the host's raw bank, never in git. A reader session takes the unread capture later and writes its signals. SERVICES EDDY'S PARTS MILLPOND WHAT A LISTING LEAVES a listing: arithmetic, and no model runs (115) Wispr Flow MCP over HTTP Webex transcripts API Microsoft Teams Graph transcripts wispr lists, fetches · first webex lists, fetches · later teams lists, fetches · later lines millpond land checks each line dedupes by key banks the raw files Unread captures the inbox, in git; no excerpt, so no signal yet <host>:<path> Raw transcripts as served, and one line per turn; the raw bank, never in git A reader, later a session reads the transcript and writes signals (113) eddy's work ends when millpond holds the capture. Reading a meeting is judgment, so a session does it.
A part lists one service's recorded meetings and fetches each transcript. millpond takes the lines, so each meeting lands once, as an unread capture whose transcript stays on the host. No model runs until a reader takes the capture later.

Why it exists

Decisions that should change a repository’s work are often made in meetings. Each meeting is recorded on whichever service hosted it, and each service keeps its transcripts behind its own interface and its own sign-in.

Two jobs stand between a recorded meeting and the work it should change. Listing is arithmetic: which recordings exist, which are new since the last listing, and when each meeting began. Reading is judgment: which sentences commit someone to something, and who said them. Flywheel’s statement keeps the two apart. Enumerating source events and writing captures runs unattended, and turning a capture into signals is a session’s judgment that never runs unattended (115).

eddy is the unattended half, for meetings. It knows every meeting service it has a part for, and nothing of signals.

What it promises

  • Each meeting lands once. A part keys a meeting by its service and the meeting’s own id, so every host and every run gives one meeting one key, and millpond keeps one capture per key (111).
  • A meeting counts from the day it was held. A capture’s event_at is when the meeting started, never when it was captured (118).
  • A meeting’s words stay on the host. The transcript is raw material. The capture points at it, and none of it enters git (111).
  • Every meeting reaches the inbox unread. No meeting capture carries an excerpt, so millpond writes no signal for it and charges a reader instead (115).
  • One meeting never stops the rest. A part names a meeting it failed to fetch in the run’s last line and goes on to the next.

Where it stops

eddy lists, fetches and prints. millpond writes each capture, banks the raw files and keeps each part’s cursor. eddy writes no record, keeps no list of what it reported, cuts no excerpt and reads no meeting into signals. Which inbox records a part’s meetings, on which host the part runs and how often are the host’s to say, in millpond’s settings or a fleet’s list. eddy never learns which inbox records its meetings.

What becomes of a meeting

A reader reads an unread meeting capture into signals, and curation gives each signal one move, joining some into items (curation and moves). An item goes to one worktree or into crew’s plan, and the work it becomes lands through sluice.

An item that asks a question, such as how to settle what a meeting left open, goes to a sounding (a question, sent to a sounding). One session works the question in a worktree of its own and ends on a conclusion, which the operator accepts, sends back for another round, or drops (sounding’s book). The operator can also open a sounding with /sound on a decision a meeting left open, the meeting’s transcript among its sources. Once a conclusion is accepted, millpond keeps it as the item’s record, and curation answers a later signal on the same subject by naming it (116).

eddy takes part in none of this. Its work ends when millpond holds the capture.

Where it sits

headwater does for releases what eddy does for meetings (headwater’s book). Each stands alone with its own Claude Code and herdr plugins, and each carries a Flywheel plugin whose adapter parts feed millpond. millpond is the inbox both of them print into. sounding takes the questions a meeting leaves open (sounding’s book). Flywheel later runs the same parts on its tick and takes the same lines (215, 231), and a part never knows which host ran it.

How to read this book

The chapters are the design: eddy on its own, a part per service, what every part shares, a meeting’s raw files, running a part, and how others add a service. A glossary and the open questions follow. Their source is the capture design, design/capture/design.md. eddy has no statement of invariants yet, so the book has no appendix. A number in parentheses points into Flywheel’s statement, design/flywheel-next/requirements.md.