sounding

Some work ends in an answer before it ends in a change: whether to take a major release, how to settle what a meeting left open, whether an approach holds once someone tries it. sounding works one such question. It opens a worktree of the repository the question is about, starts one session there with the question and its sources, and ends on a conclusion the operator decides: accept, go on, or drop. A finding beyond the question goes to millpond as a capture of its own. The work an accepted conclusion proposes becomes items, or entries in crew’s plan, and sluice lands it.

Why it exists

A question asked in the middle of other work costs that work its thread. A session that stops to read a major release’s notes, or to try a prototype, leaves its own job half done, and what it learns lives only in its own scrollback. A question worked well needs a place of its own and a session that starts from everything already known about it. It needs an end the operator can decide, and a way for what it found on the side to reach the inbox.

crew’s elaborations (crew ADR 0019) and Flywheel’s (24, 25) give a question that shape: one session, one place, one document the operator decides. sounding holds the shape once, as a tool of its own, so a person alone, millpond, crew and later Flywheel all work questions the same way.

What it promises

• One sounding is one question, worked in one worktree, one session per round, and each round ends on one conclusion.
• /sound opens a sounding while the session that asked goes on with its own work.
• Prototype code never lands from a sounding’s branch. The work the operator accepts reaches main through an item’s worktree or crew’s plan, and through sluice.
• A session never stops without a conclusion, or a note saying where the next round would start.
• A round ends when its timebox runs out, on a conclusion of what the session knows.
• The operator decides every conclusion, and never decides the same one twice (6).
• A conclusion never becomes a signal. Only an offer comes back to the inbox, as a capture of its own (62).

Where it stops

sounding lands no code, writes an inbox only through millpond, and plans across no items. It never decides a conclusion: the operator does. Ordering items across teams is crew’s planner today and Flywheel’s later. millpond keeps the inbox, and sluice tests and lands the work.

The tools beside it

• millpond is the inbox. It sends a sounding an item that asks a question, keeps the accepted conclusion as the item’s record, and takes each offer as a capture. Its book is at ../millpond/.
• headwater reports releases newer than a repository’s pins. A key in its herdr plugin opens a sounding on a release that needs judgment. Its book is at ../headwater/.
• eddy lists recorded meetings. A decision a meeting left open becomes a question with the meeting’s transcript as a source. Its book is at ../eddy/.
• flume launches and tracks one agent in one worktree through a kind’s stages. It makes a sounding’s place and runs it as the kind question. Its book is at ../flume/.
• sluice tests a change as merged and lands it, and never lands a sounding’s branch. Its book is at ../sluice/.
• crew runs teams, plans and bolts. Its planner and design agent call sounding open as crew calls millpond.
• Flywheel is built later. Each of an intent’s elaborations is a sounding.

How to read this book

The chapters follow one sounding: the question and its sources, the place it is worked in, and the three exits its session has. Then come the stop check and the timebox that bound a round, and the operator’s decision on its conclusion. Last come the setups questions arrive from and the surfaces the operator works a sounding through.

A bare number in parentheses cites Flywheel’s statement, design/flywheel-next/requirements.md, whose elaboration sounding keeps the shape of. A rule id such as code.1 cites crew’s docs/architecture/. sounding’s own statement is not written yet; Open questions says what it will hold.