Design

millpond’s design lives in agentplot/blueprints, with the designs of every tool around it. This site shows the design; the design book and the statement define it.

The design bookmillpond's settled design, one chapter per part, written for a reader who was not in the room.

The statementmillpond's invariants as numbered clauses, which the code cites by number. It comes next: plan step P1.

What each document is

• The capture design, design/capture/design.md, covers every part that turns an outside event into landed work: headwater, eddy, millpond, sluice, crew, Flywheel and the first fleet that runs them. plan.md beside it orders the work.
• millpond’s statement, design/millpond/requirements.md, is written from that design: the inbox, the contract’s intake, the seven steps, the reader and curation tools, moves, items and sends, the three setups, and what millpond never does. A fresh model reconstructs millpond from the statement alone, and the questions it asks are ruled and folded back in before the statement lands.
• The design book explains the design chapter by chapter, with the statement as its appendix.

What binds the code

The statement binds. This repository cites its clauses by number and never restates them. The rules a change here keeps, and the decisions behind them, follow the statement into docs/architecture/ and docs/adr/.

Flywheel’s statement owns the capture contract and the record formats, and flywheel-next’s crates implement them once. millpond builds on those crates, so a question about the lines or the records goes to Flywheel’s statement first.