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.

Questions arrive from several places and all open the same way. The operator decides every conclusion. Accepted work becomes items or plan entries that sluice lands, and only an offer returns to millpond as a capture of its own.

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.

The question and its sources

A sounding starts from one question and the material that bears on it. sounding open writes both into question.md, and every round’s session starts from that file.

One question

A sounding works one question, whose answer the operator decides before any work the answer implies begins. An item in millpond sometimes asks one: whether to take a major release, or how to settle what a meeting left open. An item that needs no judgment goes to a worktree and becomes a change. An item that asks a question goes to a sounding (millpond’s items).

Ways in

An item millpond sends. millpond’s send takes a sounding as its target, and opens it with the item’s signals and the captures they came from as its sources.
/sound <question> in any Claude Code session. The sounding opens while that session goes on with its own work.
A key in another tool’s herdr plugin, such as headwater’s on a release that needs judgment, with the release’s brief as the source.
crew’s planner and design agent, which call sounding open for an item that asks a question, as crew calls millpond.

Each of them calls sounding open, so a sounding is the same whichever way it began. Where questions come from sets out which ways in each setup has.

question.md

sounding open writes the question and its sources:

the item’s signals, each with its verbatim excerpt (113);
the captures those signals came from, which point at the raw material;
any earlier conclusion on the subject.

A question opened with /sound carries the sources it names, such as the transcript of the meeting that left a decision open.

An earlier conclusion is one the operator accepted. Naming it among the sources starts the session from what the operator already decided on the subject.

Each round’s question

The question grows from round to round. When the operator answers a conclusion with go on, the conclusion moves to rounds/<n>.md, and the operator’s notes join the next session’s question (Deciding a conclusion).

sounding open writes the question and its sources. Each go on adds the operator's notes and keeps the last conclusion under rounds/. The start hook hands a round's session all of it, so a second round starts where the first ended, with the operator's reply.

The Claude Code plugin’s start hook hands each round’s session its question, its sources and its earlier rounds, whichever surface started the round (The operator’s surfaces).

The place

A sounding works in a worktree of the repository its question is about, on the branch sounding/<name>. That worktree is the sounding’s place. The session reads the repository there as it stands, and writes whatever helps it answer the question, prototype code included.

flume makes the place and runs it as the kind question, whose one stage is a sounding’s session ending on sounding conclude (flume’s kinds). sounding owns the question, the exits and the decision; flume owns the worktree and the agent in it.

A worktree of its own

The session that asked keeps its thread. /sound opens a sounding in a worktree of its own, and the session that asked goes on with its own work undisturbed.
A prototype tests an answer against the repository itself. The session can change the code, run it and read what happens, since nothing it writes reaches another worktree.
Every round of one sounding shares the place. Go on starts the next round in the same worktree, so the prototype, the notes and the files carry from one round to the next. Drop records the reason and removes the worktree.

Prototype code never lands from it

Code the session writes in its place tests an answer. It never lands from the sounding’s branch. The work the operator accepts reaches main on a branch of its own: through an item’s worktree or crew’s plan, and through sluice, which tests it as merged before it lands.

sounding’s Claude Code plugin holds the rule inside the session: it refuses a sluice submission from a sounding/* branch. A conclusion says what a prototype showed, and the work it proposes names what to build (Deciding a conclusion).

Only the conclusion leaves the place, for the operator. The work they accept reaches main on a branch of its own and through sluice. A submission from the sounding's own branch is refused before it reaches the queue.

The name

A sounding’s name appears twice: in its branch, sounding/<name>, and in the key of each capture it offers, sounding/<name>/<n> (Three exits). The name ties the branch and every offer to the one question they came from.

Three exits

A sounding’s session is free inside its place. It reaches beyond the place through three commands, its exits: fixed outputs the session gives and sounding acts on (65). The session ends a round with sounding conclude, and may offer and ask along the way.

Exit	What follows
`sounding conclude`	Writes `conclusion.md`: the answer, its evidence, what it would change, the work it proposes, and what stays open. The round ends, and the operator decides the conclusion.
`sounding offer`	Hands a finding beyond the question to `millpond land` as a capture of its own (62), one key per offer. The session goes on (58).
`sounding ask`	Puts a question only the operator can answer on a card. The session waits for the answer, then goes on.

Of the three exits, only conclude ends the round. An offer goes to millpond and the session keeps working; an ask waits for the operator's answer and then goes on.

Conclude

sounding conclude writes conclusion.md and ends the round. A conclusion holds:

the answer to the question;
its evidence;
what the answer would change;
the work it proposes;
what stays open.

The operator decides it (Deciding a conclusion). When the operator accepts, each piece of work the conclusion proposes becomes an item of its own or an entry in crew’s plan, so the conclusion names each piece apart.

Offer

A session finds things beyond its question as it works: a defect in a tool it read, a record gone stale, a second question. A finding about the question belongs in the conclusion. A finding beyond it belongs in the inbox, and sounding offer hands it to millpond land as a capture of its own (62), as millpond’s book has it (Findings, from a sounding).

The capture:

is its own excerpt, so millpond writes its one signal as it lands;
has the kind ask;
names the sounding as who asserted it;
has the key sounding/<name>/<n>.

Each offer takes its own <n>, so two offers are two captures, and one offer landed twice is still one (111).

sounding prints the offer as contract lines with flywheel-next’s capture crate, and pipes them to millpond land where millpond is installed. The lines pass the conformance pack as any adapter’s do (millpond’s contract). From there the finding takes the path every capture takes: curation gives its signal a move (millpond’s curation).

An offer never interrupts the session that gave it (58). The session goes on with its question.

Ask

Some things only the operator can answer: a fact only they hold, or a choice that is theirs to make. sounding ask puts such a question on a card, and the session waits for the answer, then goes on with the round. A sounding waiting on an answer shows as waiting on the operator in sounding’s herdr plugin (The operator’s surfaces).

Which exit when

The session has	It uses
an answer, or what it knows when the timebox runs out	`sounding conclude`
a finding beyond its question	`sounding offer`, and goes on
a question only the operator can answer	`sounding ask`, and waits

The stop check and the timebox

Two bounds keep a round from going nowhere. The stop check holds its end, and the timebox holds its length. Between them, every round leaves something the operator or the next round can start from.

The stop check

The stop check runs when the session tries to stop. sounding’s Claude Code plugin runs it as a hook at the session’s end. It lets the session stop when it has written a conclusion, or a note saying where the next round would start. Otherwise it sends the session back to write one.

A session that stops on a conclusion hands the operator something to decide. A session that stops on a note hands the next round a place to begin. Either way, what the round learned outlives the session’s own scrollback.

The timebox

Each round has a timebox. When it runs out, the session concludes with what it knows: the answer as far as it got, its evidence, and what stays open.

A question that needs more than one round gets one round at a time. The operator reads each round’s conclusion and answers go on when the question deserves another. A round that has used its time comes back to the operator before any more time goes into it.

A round, end to end

A round ends on a conclusion when the session has an answer or its timebox runs out. A session that tries to stop sooner stops only on a conclusion or a note saying where the next round would start; otherwise the stop check sends it back.

A round that ends on a conclusion waits on the operator’s decision. Go on starts the next round in the same place, with the operator’s notes added to the question (Deciding a conclusion).

Deciding a conclusion

The operator decides each conclusion: on a card, in sounding’s herdr plugin, or on crew’s rail. A conclusion gets one decision, and the operator gives it once (6).

Answer	What follows
Accept	Settles the item. millpond keeps the conclusion as the item’s record, and each piece of work the conclusion proposes becomes an item of its own, or an entry in crew’s plan.
Go on	Starts the next round in the same worktree. The conclusion moves to `rounds/<n>.md`, and the operator’s notes join the next session’s question.
Drop	Records the reason and removes the worktree.

Each round ends waiting on the operator. Accept and drop end the sounding; go on starts another round in the same place, with the last conclusion kept and the operator's notes in the question.

Accept

Accept ends the sounding and settles its item. millpond keeps the conclusion as the item’s record, and each piece of work the conclusion proposes becomes an item of its own. In an inbox crew keeps, crew’s planner turns each piece into an entry in its plan. Either way the work reaches main on a branch of its own, through sluice (The place).

The record outlasts the sounding. When a later signal arrives on the same subject, curation answers it by naming the conclusion (116), and the operator is not asked again.

Go on

Go on starts the next round in the same worktree. The conclusion moves to rounds/<n>.md, and the operator’s notes join the next session’s question: what the answer missed, what to try next, what to leave alone. The start hook hands the new session its question, its sources and every earlier round (The question and its sources).

Drop

Drop records the reason and removes the worktree. Nothing from the place lands. Offers the sounding already made stay in the inbox, since each is a capture of its own and an unmoved signal is never discarded (118).

A conclusion is never a signal

An accepted conclusion enters the inbox as a record, never as a signal. Three facts about the inbox require it:

The item’s signals already have their move. Curation joined them into the item, and curation never judges a signal that has a move again (107). A conclusion made into a signal would put the same subject in front of curation a second time.
The operator has already decided it. Approval given once is never asked again (6). A signal would bring the conclusion back as a decision, through curation’s batches and the item it joined.
What the operator accepted settles signals. Curation answers a later signal on the subject with answered, naming the conclusion as the record that settled it (116).

Only offers come back as signals. An offer is about something beyond the question, which no move has judged and no decision has settled, so it starts where every capture starts.

An accepted conclusion enters the inbox as a record, and curation answers later signals by naming it. Only an offer enters as a capture, and only its signal is curation's to move.

From a question to a landed bump

One question, from the release that raised it to the bump that lands:

headwater reports version 5 of a library the repository declares as ^4.2. The release lies outside the declared range, so taking it changes the manifest (headwater’s book).
The release lands in millpond as a capture that is its own excerpt. Curation joins its signal into an item that asks whether to take the release.
millpond sends the item to a sounding, with the release’s signal and capture as its sources.
The session reads the notes, makes the bump in its place, and runs the repository’s checks there to see what breaks.
It concludes: take version 5. Its evidence is what the checks showed, what it would change is the code the new version touches, and the work it proposes is the bump.
The operator accepts. millpond keeps the conclusion as the item’s record, and the bump arrives as a new item.
The bump is made on a branch of its own, and sluice lands it.
The next signal on the subject reaches curation, which answers it by naming the conclusion.

The prototype bump in step 4 never lands. The bump in step 7 does, on its own branch, through sluice.

Where questions come from

sounding works the same in four setups. The setup decides who asks the question and where the operator decides the conclusion.

Setup	Questions from	Conclusions decided on
On its own	the operator’s `/sound`	a card, or sounding’s herdr plugin
With millpond	items millpond sends; a key on a headwater release that needs judgment; `/sound` on a decision a meeting left open, its transcript a source	the same, recorded against the item
With crew	crew’s planner and design agent, calling `sounding open` as crew calls millpond	crew’s rail
With Flywheel	an intent’s elaborations, each one a sounding	Flywheel’s elaboration types, which write the conclusion into the design book and claims

Moving from one setup to the next changes who asks and where the operator decides. The question, the place, the exits and the shape of a conclusion stay as they are.

On its own

sounding needs no other tool. The operator opens a question with /sound from any Claude Code session, the sounding works it in a worktree of its own, and the conclusion comes back on a card or in sounding’s herdr plugin.

An offer still prints its contract lines, and sounding pipes them to millpond land only where millpond is installed. Where an accepted conclusion is kept with no inbox behind it is on Open questions.

With millpond

millpond adds two ways in and a home for every conclusion.

An item that asks a question. millpond’s send takes a sounding as its target, and opens it with the item’s signals and the captures they came from as its sources (millpond’s items).
A key on a headwater release that needs judgment, such as a major release outside the range the repository declares, with the release’s brief as the source. headwater’s herdr plugin offers the key where sounding is installed.
/sound on a decision a meeting left open, with the meeting’s transcript as a source. eddy lists the meeting, and millpond keeps its capture (eddy’s book).

The operator decides on a card or in sounding’s herdr plugin, and the decision is recorded against the item. On accept, millpond keeps the conclusion as the item’s record and makes an item of each piece of work the conclusion proposes. Each offer lands through millpond land.

With crew

crew’s planner and design agent open a sounding for an item that asks a question, calling sounding open as crew calls millpond: through its command line, since crew’s Python uses only the standard library (code.1). Each conclusion shows on crew’s rail, and the work an accepted one proposes becomes entries in crew’s plan.

A question crew works makes no elaboration worktree of crew’s own: the sounding’s worktree is the question’s place. A sounding rests on an item where crew’s elaboration rested on an intent (crew ADR 0019), so the question comes from curation’s join like any other piece of work.

With Flywheel

Each of an intent’s elaborations is a sounding. An elaboration is one session, one conversation, one place (24), and a sounding is one question in one worktree, one session per round. The session’s exits are the same three:

Flywheel’s elaboration	sounding
finishing with deliverables (65)	`sounding conclude`
blocked on a question (65)	`sounding ask`
offering a finding (58, 62)	`sounding offer`
approval given once, never asked again (6)	one decision on each conclusion

Flywheel’s elaboration types stay Flywheel’s. An elaboration’s type decides how it ends (25), and what it concludes is written to the design book and its claims (187). sounding works the question, and the type writes the conclusion where Flywheel keeps it.

The operator’s surfaces

The operator works a sounding from whichever surface is at hand: the command line, a Claude Code session, or herdr. sounding keeps one plugin per host under plugins/ beside its core, plugins/claude and plugins/herdr, as millpond, headwater and eddy keep theirs.

The command line

Command	Run by	Does
`sounding open`	whoever asks: `/sound`, millpond’s `send`, a herdr key, crew	Opens a sounding: its place on `sounding/<name>`, which flume makes, and its `question.md`.
`sounding list`	anyone	Lists the open soundings.
`sounding conclude`	the session	Writes `conclusion.md` and ends the round.
`sounding offer`	the session	Hands a finding beyond the question to `millpond land` as a capture of its own (62).
`sounding ask`	the session	Puts a question only the operator can answer on a card, and waits.
`sounding accept`	the operator	Settles the item and turns the proposed work into items or plan entries.
`sounding go-on`	the operator	Starts the next round, with the operator’s notes in the question.
`sounding drop`	the operator	Records the reason and removes the worktree.

The Claude Code plugin

/sound <question> in every session opens a sounding while the session goes on with its own work.
A start hook gives a sounding’s session its question, its sources and its earlier rounds (The question and its sources).
The stop check runs at the session’s end (The stop check and the timebox).
MCP tools, soundings, conclusion, accept, go_on and drop, let the operator list soundings, read a conclusion and decide it from any session.
A guard refuses a sluice submission from a sounding/* branch (The place).

The herdr plugin

The sidebar lists the open soundings, each with its round and its state: working, waiting on the operator, or parked. They share flume’s sidebar, where a sounding waiting on the operator shows as a row beside every other place in flight (flume’s surfaces).
A workspace per sounding holds the session’s pane with its conclusion beside it.
Keys start, open, accept, send back and drop a sounding, and open its conclusion in plannotator for notes.

flume's sidebar shows every open sounding's round and state. The selected sounding's workspace puts the session beside its conclusion, and the keys decide it there or open it in plannotator for notes.

Send back is go on: it starts the next round, and the operator’s notes join its question (Deciding a conclusion).

Two ways to run

Unattended, the session works alone, and the round ends on a card for the operator.
With the operator, --with-me, the session runs in a pane beside the operator as a conversation.

Glossary

The words of the design, each defined once. sounding has no statement yet, so the capture design (design/capture/design.md) is the binding copy. The words of millpond and of crew are millpond’s book’s, word for word. A number in parentheses cites Flywheel’s statement.

Four words mean one thing in another book and another here. A capture’s source names where its event came from, such as release, while a question’s sources are the material it starts from. millpond’s drop is a move on a signal, while sounding’s is the operator’s answer to a conclusion. The signal kind ask is one of five kinds, while sounding ask is an exit. A signal’s kind is its type, while flume’s is a list of stages, and flume’s kind question is the one that runs a sounding’s session. Each word keeps its meaning in the book it belongs to.

sounding’s words

word	meaning
accept	the operator’s answer that settles a conclusion’s item: millpond keeps the conclusion as the item’s record, and each piece of work it proposes becomes an item, or an entry in crew’s plan
ask	`sounding ask`: the exit that puts a question only the operator can answer on a card; the session waits for the answer
card	a question or a decision put to the operator outside the session’s pane, and answered once
conclude	`sounding conclude`: the exit that writes `conclusion.md` and ends the round
conclusion	what a sounding ends on: the answer, its evidence, what it would change, the work it proposes and what stays open; the operator accepts it, sends it back for another round, or drops it
drop	the operator’s answer that records the reason and removes the sounding’s worktree
exit	one of the three commands through which a session reaches beyond its place: conclude, offer and ask (65)
finding	something a session learns beyond its question; an offer hands it to millpond as a capture (58)
go on	the operator’s answer that starts the next round in the same worktree: the conclusion moves to `rounds/<n>.md` and the operator’s notes join the question; the herdr plugin’s send back
offer	`sounding offer`: the exit that hands a finding beyond the question to `millpond land` as a capture of its own, its own excerpt, of kind `ask`, asserted by the sounding, under the key `sounding/<name>/<n>` (62); the session goes on
parked	the state of a sounding whose session is neither working nor waiting on the operator
place	a sounding’s worktree of the repository its question is about, on the branch `sounding/<name>`, which flume makes and runs as the kind `question`
question	what a sounding works: one question whose answer the operator decides before the work it implies begins; `sounding open` writes it with its sources into `question.md`
record	an accepted conclusion as millpond keeps it on its item; curation names it when it answers a later signal on the subject (116)
round	one session’s run at the question, from its start hook to its conclusion; go on starts the next
sounding	one question, worked by one session in one place, ending on one conclusion; also the tool that runs them
sources	a question’s material: the item’s signals, the captures they came from, any earlier conclusion on the subject, and what `/sound` names
start hook	the Claude Code plugin’s hook that hands a round’s session its question, its sources and its earlier rounds
stop check	the hook at a session’s end that sends it back unless it wrote a conclusion or a note saying where the next round would start
timebox	the limit on one round’s length; when it runs out, the session concludes with what it knows
unattended	the way of running in which the session works alone and each round ends on a card
waiting on the operator	the state of a sounding whose conclusion, or whose ask, the operator has not answered
with the operator	`--with-me`: the way of running in which the session works in a pane beside the operator as a conversation
working	the state of a sounding whose session is working its round

Flywheel’s words

word	meaning
elaboration	in Flywheel, one unit of design work on an intent, worked by one free-flowing session; each one is a sounding (24)
elaboration type	in Flywheel, what decides how an elaboration ends; it writes what the elaboration concludes to the design book and its claims (25, 187)
intent	in Flywheel, one thread of design work about one subject, pursued until the operator closes it

Words from flume’s book

flume’s book defines these, and this page gives its definitions word for word.

word	meaning
flume	the tool that launches and tracks one agent in one worktree through a kind’s stages, on the host it runs on, and tidies the place when the work lands or is dropped (its book)
kind (flume’s)	a list of stages, each naming its prompt and its deliverable: fix, change, question, or one a repository declares

Words from millpond’s book

millpond’s book defines these, and this page gives its definitions word for word.

word	meaning
answered	the move that names the claim or record that settled a signal
bolt	in crew, a team’s branch of work: its units and chores land on it, and it lands on the shared branch
capture	the record of one source event: its key, its source, its event date and a pointer to its raw material; the same event captured twice is one capture (111)
capture contract	the JSON Lines an adapter prints and every host takes, each line holding exactly one of `capture`, `cursor` or `done`
chore	in crew, a piece of work that needs no design of its own, such as a tool’s bump; a `route` move offers one
claim	in Flywheel, a standing statement of what a repository must satisfy; `answered` and `challenge` name one
conformance pack	contract lines and the records a host must write from them, with the meeting checks; every host and every adapter part passes it
curation	a Claude session that proposes one move per signal, in batches, through millpond’s tools; the operator accepts or changes each batch (116)
excerpt	the verbatim text a signal quotes from its source, with its position (113)
inbox	a git repository, or a branch in one, holding captures, signals, moves and items in Flywheel’s record formats
item	the unit of work: the signals curation joined, one or many, with its brief and its sends; Flywheel’s proposed intent (109)
join	the move that makes an item from signals, or grows one still proposed
key	a source event’s identity, the same from every host and every run (111)
kind	a signal’s type, one of constraint, ask, question, commitment and reaction (113); the kind a send names, a fix or a change, is flume’s word for a list of stages
move	the one standing decision on a signal: drop, answered, challenge, join, attach or route, each with a stated consequence (107, 116)
operator	the person who accepts or changes each batch of moves, sends items, and decides each conclusion; on its own, the user
own excerpt	a capture is its own excerpt when its line carries the signal’s fields, so millpond writes its one signal as it lands; a release is one
planner	crew’s agent that orders items across teams and turns each into a chore or a unit
plugin	the installable unit in every host, holding parts; Flywheel’s statement calls it a package, and a named set of parts a bundle (228, 284)
raw material	the event as its source served it, whole: notes, a transcript, a log; the adapter writes it as raw files
send	millpond giving one item to flume, as a fix or a change with its brief, or an item that asks a question to a sounding
signal	one assertion from a capture: its kind, who asserted it, its subjects, the assertion in a sentence, the verbatim excerpt with its position, and the claims it argues with; never changed once written (113)
unit	in crew, one designed piece of a team’s work, landed on its bolt
unmoved	a signal with no move yet

Open questions

What the design does not settle, and where each question is held. A question leaves this page when the operator rules; the ruling lands in the design, and the chapter that rests on it is rewritten whole.

sounding’s statement

sounding’s statement of invariants, design/sounding/requirements.md, is being written from the capture design (design/capture/plan.md, step Q1), while the operator rules decision 11 below. It states the question and its sources, the place, the three exits, the stop check, the timebox, rounds, the operator’s decision, and what sounding never does. A fresh model then reconstructs sounding from the statement alone, and the operator rules the questions it asks.

The statement becomes this book’s appendix, and the chapters cite its clauses by number. Until it lands, the chapters rest on the capture design, design/capture/design.md, and cite Flywheel’s statement, whose elaboration gains a clause saying it runs on sounding (58, 62).

The decision awaiting a ruling

The capture design’s decision 11 awaits the operator’s ruling (design/capture/plan.md, step D2). Each chapter states it as the design has it.

sounding is a standalone tool that works one question in one session, in a worktree of its own, and ends on a conclusion the operator accepts, sends back or drops. millpond sends it an item that asks a question, an accepted conclusion is the item’s record, and only a finding beyond the question comes back as a capture (Deciding a conclusion).

Held by the design

The capture design’s own Open section holds these questions about sounding, beside the details it leaves to sounding’s statement:

A standing sounding, which stays open and starts a round when a signal on its subject lands, as Flywheel’s standing elaborations do (25, 26).
Where else an accepted conclusion lives. A repository may keep it in its own record, as crew’s kits keep openspec/explorations/. With no inbox behind it, as when sounding runs on its own, this is where an accepted conclusion lives at all.
crew’s two open records disagree. crew ADR 0019 rests an elaboration on an intent and the new-territory move, and crew’s curation-and-agenda change leaves intents out and replaces that move with join. A sounding sent from an item settles both, once crew’s record says so (plan steps C1 and C6).

A question’s branch

The design names a sounding’s branch twice over. flume names a place’s branch <kind>/<name>, which for the kind question gives question/<name>. The design also names a sounding’s branch sounding/<name>, and the Claude Code plugin’s guard refuses a sluice submission from sounding/*. The chapters use sounding/<name>, as the design’s section on sounding does; flume’s book holds the same question (flume’s open questions).

Left to the statement

The capture design’s Open section leaves sounding’s own details to its statement (plan step Q1). In full:

the timebox’s length, and who sets it;
how a sounding is named, the <name> in its branch and its keys;
where question.md, conclusion.md and rounds/ sit in the worktree, and whether the session commits them on its branch;
what the note the stop check accepts holds and where it is kept, what parks a sounding, and how a parked one resumes;
what accept does to the worktree and the branch, and whether drop deletes the branch with the worktree;
whether the work a conclusion proposes reads the sounding’s branch when it is built;
the source, event_at and raw material an offer’s capture carries;
which card sounding ask and a conclusion use when sounding runs on its own;
whether a --with-me sounding has a timebox and a stop check, and how it ends;
how the operator’s notes in plannotator reach go on.

Keyboard shortcuts

sounding design