A stage ends on its deliverable
A stage ends when its deliverable exists, or when its agent stops short
and says what it needs. It never ends because its pane went quiet
(teams.4). When the deliverable exists, flume ends the stage’s agent
and starts the next stage.
Why the pane says nothing
An agent’s pane goes quiet for many reasons. The agent may wait on a long build, think through a hard step, or finish a turn with the work half done. A quiet pane says nothing about whether the work exists. The deliverable does, so flume reads the deliverable where the work lives: in the place, or on the host.
Reading a deliverable
| Stage | flume reads |
|---|---|
| construct | the OpenSpec change’s files, committed on the place’s branch |
| code, in a fix | a commit on the branch made since the stage began |
| code, in a change | the change’s tasks.md at the branch’s head, every task ticked |
| verify | its report |
| submission | sluice’s record of the place’s branch: landed on its target |
| a sounding’s session | conclusion.md |
flume reads a deliverable at one commit. It reads the branch’s head
once, then reads the ticks and the commit’s time at that head. An
agent’s last tick that lands between two reads never shows a
deliverable that is not there (teams.4).
For a change, flume reads the OpenSpec change’s own files and agrees
with what openspec reports on the same worktree (plan.12).
Stopping short
An agent may stop without its deliverable: a question only the operator can answer, a step outside its place, a brief that cannot be done as written. It stops and says what it needs. flume reads that from its transcript, records what the agent needs with the place, and shows the agent as waiting.
An agent that stops short ends flume’s wait on the stage without the
deliverable, so flume starts no next stage. A tell answers the agent
in its pane, and it goes on with the stage. flume retry starts the
stage again with a fresh agent and its prompt
(Prompt delivery).
Stuck
A stage quiet past flume’s limit, with no deliverable and no word of what it needs, is reported stuck. flume ends nothing: the agent may be in a long build, and ending it would lose the work it is doing. The operator, or the caller, decides what follows: a tell, a stop, or a retry.
Moving on
When the deliverable exists, flume ends the stage’s agent and starts
the next stage’s fresh agent with its prompt. Whoever waits on the
place learns of the end with the deliverable itself: a caller reading
flume status sees the stage ended and what it delivered in the same
reading (teams.4).
After a fix’s or a change’s last stage the work has landed, and the place waits only to be tidied (Tidying). A question’s place stays while the operator decides its conclusion, since go on runs the stage again there (Kinds and stages).