Kinds and stages
A kind is a list of stages. Each stage names its prompt, the text its agent starts from, and its deliverable, what flume reads its end from. flume runs a place’s stages in order, a fresh agent for each, and a stage starts only once the stage before it has delivered.
Three kinds
flume ships three kinds, and a repository may declare more.
| Kind | Stages | Its work |
|---|---|---|
| fix | code, then a submission to sluice | a change to the repository that needs no OpenSpec change |
| change | construct, code, verify, then a submission to sluice | an OpenSpec change: written, built task by task, checked against itself, and landed |
| question | a sounding’s session | one question, ending on a conclusion |
The stages
| Stage | Its agent | Its deliverable |
|---|---|---|
| construct | writes the OpenSpec change from the brief: its proposal, design, specs and tasks | the change, committed on the place’s branch |
| code | builds the work: a fix whole, or a change’s tasks one at a time, ticking each as it is done | for a fix, a commit on the branch made since the stage began; for a change, every task ticked |
| verify | checks the code against the change as written, and reports each finding | its report |
| submission | submits the place’s branch to sluice, and reads the outcome | the landing: sluice’s record that the branch landed on its target |
| a sounding’s session | works the question in its place | conclusion.md, written by sounding conclude |
A stage starts only on the deliverable of the stage before it. code never starts before the change is committed, and verify never before every task is ticked, so each stage’s agent finds in the place what its prompt says is there.
A stage’s deliverable is something flume reads in the place or on the
host: a file, a commit, ticked tasks, or a record such as sluice’s
(teams.4). A stage ends on its deliverable says how
flume reads each one.
A fix
A fix is work that needs no design of its own: a release to take, a defect to mend, a file to correct. Its code stage makes the change and commits it on the place’s branch. Its submission stage submits the branch to sluice and ends when the branch lands.
A change
A change is work that needs an OpenSpec change first. construct writes
the change and commits it: its proposal, its design, its specs and its
tasks. code works the tasks and ticks each one in tasks.md as it is
done. verify checks the code against the change as construct wrote it.
The submission stage submits the branch, which then carries the change
and its code together.
flume reads the change’s own files, so status shows its tasks ticked as code works through them (Status and live state).
A question
sounding launches the kind question for each sounding. flume makes the place and starts the round’s session there. sounding’s Claude Code plugin hands the session its question, its sources and its earlier rounds at its start (sounding’s book).
- The stage ends on
conclusion.md, whichsounding concludewrites, or when the session stops on a note saying where the next round would start. sounding’s stop check holds the session to one of the two, so the note is how a question’s session stops short (sounding’s stop check). - Go on starts the stage again in the same place, with a fresh session. The operator’s notes join the question, and the place keeps the prototype and the files from the round before.
- Nothing lands from a question. The kind has no submission stage, and sounding’s plugin refuses a submission from a sounding’s branch (sounding’s place).
sounding’s book names a question’s branch sounding/<name>.
Open questions holds which name flume
gives it.
A repository’s own kinds
A repository may declare kinds of its own in the same form: a name, and a list of stages, each naming its prompt and its deliverable. flume runs a declared kind as it runs the three it ships, one fresh agent per stage, each stage ending on its deliverable. How a repository declares its kinds, and how crew’s stage prompts take that form, is on Open questions.