A plain thread answers what you send it. The Engineering Toolbox in the composer adds stages to that thread, and each stage turns the same conversation into work you can read before it is built. Selecting a stage does not start it: the work begins when you send a message.
Four ways a thread runs
A plain chat. With no stage selected, the thread stays a conversation. The agent answers, and the permission level you chose decides what it may change without asking you first. Nothing is produced for you to sign.
The engineering sequence. Brainstorm, PRD, and Spec each produce a document in the thread. You read it, annotate it, and approve it, and the implementation follows the version you approved.
An assignment. Assignment splits the work into tasks, each with an owner, the files or areas it touches, and how it will be verified. You review the plan and sign off, then the coordinator runs those tasks with workers.
Auto Pilot. One switch turns the whole sequence on and keeps it moving. The app generates what the work needs, assigns the tasks, and stays in the audit and rework loop until the goal passes or stops on a hard failure.
The engineering sequence
Brainstorm is where the idea gets worked out: the research, the prototypes, and the direction you want. It closes on a session report you can discuss, and a Next step menu that offers Generate PRD or Generate Spec, so you decide which document comes next instead of the app deciding for you.
The PRD states the problem, the goals, the non-goals, and the acceptance criteria, and it keeps its open questions visible. Approving it closes that document. It does not start anything else.
The specification is the contract the implementation follows. Every version is kept, so a review always names the version it was written against. You can comment on a line or on a whole section, then choose Review to send the notes back or Implement to start the work in the same thread. A finished specification does not implement itself: that button is the gate.
Split the work across workers
An assignment is a reviewable task graph. Each task names an owner, the area it changes, what it depends on, and how the work is checked. Above the tasks, the assignment carries the scope its workers run in, so the whole plan can be pointed at a fresh worktree in one choice, and a phase or a single task can be pointed somewhere else.
Sign off & assign is the moment the plan stops being a proposal. The coordinator, the Sr. Engineer, runs the workers from then on. Every worker gets its own thread, so you can open one and read exactly what it did without leaving the assignment.
The mode that carries its own approval
Achievement is the exception to the gate. Turn it on and it owns the specification approval, the recommended decisions, the permission replies inside the tier you selected, the implementation, and the independent audit and rework cycles. It keeps working until the goal passes or reaches a hard failure, and it does not turn an internal question into something you have to answer.
Auto Pilot works the same way across the whole sequence, with one difference: there is nobody to interview, so it generates what it needs and proceeds without waiting for you.
What the artifacts mean for you
The documents are the record. A version you approved stays readable, a review comment stays attached to the version it was written on, and the audit reads the finished work against that approved text.
Progress lives in the coordinator panel. Assignment progress and Assignment tasks list every worker with its state, and a worker that is not reporting shows its own thread status instead. The bell names the project and the thread, so a specification waiting for review, a question parked mid run, and a finished implementation each arrive as their own entry and open back to where the work stopped.
Correcting the direction mid run
There are three ways in. Send a message to the coordinator thread and the Sr. Engineer reads it before the next dispatch. Open a worker thread and write to it directly: the task returns to running, the worker picks the conversation up, and the report carries the new turn. Or annotate the specification and choose Review, which sends the notes back without starting the implementation.
If you would rather iterate with a worker in private, switch its composer footer from Reporting to Not reporting. The thread then finishes its work in the conversation and never hands it back, so no audit starts on it. Switching it back on restores the hand off, from the thread or from the coordinator board.
What a finished worker leaves behind
A finished worker leaves its own thread, its transcript, and its work on a branch in the scope the assignment gave it. When the assignment asked for a dedicated worktree, that branch lives in a checkout of its own for that one task; otherwise the worker shares the coordinator's checkout.
It also leaves a report. The worker submits the evidence its task asked for and hands the task back to the Sr. Engineer, which is what starts the review. From the coordinator board you can open the worker, read what it changed, and decide whether that task is done.
Who decides what ships
The app implements. It writes the specification, splits the work, runs the workers, and audits the result, and it can do all of that without a message from you.
What ships stays a decision you make. The work lands on a branch that stays yours: you read the diff, you accept or reject what the audit concluded, and you decide what to merge. Handing off the implementation does not hand over that decision, and every gate in the sequence exists to keep it with you.