Skip to main content
Every worker attempt that completes produces a result — a structured record of what the worker did, evidence that checks passed, and any observations you’ve recorded during testing. Review is explicit and deliberate: you read the result, optionally inspect or try the code, then make a clear decision to approve or request changes. Nothing is delivered to your project without your explicit approval.

​
What’s in a Result

When a worker finishes, it submits a result containing:
  • Outcome report — a summary of what was done, how the success criteria were addressed, and (if the outcome is partial) a description of what agreed work remains
  • Checks evidence — the output of any verification commands configured for the project, including exit codes and command output, so you can see exactly what passed or failed
  • Limitations — any constraints or caveats the worker identified during implementation
  • Testing observations — notes you record in the task feed while trying the result
If a worker produces a new attempt after you’ve requested changes, the earlier result remains accessible in the task feed. You can always inspect previous versions — history is preserved, not overwritten.

​
The Review Workflow

When a task reaches In Review, it appears in Needs You and you’re ready to evaluate the result. Take as much time as you need — the result waits for your decision.
1

Task reaches In Review

A notification appears in Needs You when a worker submits a result. Open the task to see the result report and checks output.
2

Read the result report and checks output

Review what the worker did, whether checks passed, and any limitations reported. This is always the starting point before taking any further action.
3

Inspect the diff (optional)

Click Inspect diff to see a file-by-file view of exactly what the worker changed. Use this to verify that the implementation matches what you agreed on and that no unexpected files were modified.
4

Try the result (optional)

Click Try result to launch an independent copy of that exact version for manual testing. This gives you a live environment running precisely the worker’s output — separate from your main checkout. Record any observations directly in the task feed.
5

Approve or request changes

Once you’ve seen enough, choose one of two actions:
  • Request Changes — write notes describing what needs to be different. The coordinator can read this feedback and revise the task definition before a new worker attempt runs.
  • Approve and Integrate — approve this exact result and instruct Flowfield to deliver it to your project.

​
Approve and Integrate

When you choose Approve and Integrate, you are naming an exact result candidate and a destination branch. Flowfield validates the result, delivers the approved code to your configured project checkout, and marks the task Done. Approval in your Codex conversation uses the same underlying record as browser approval. There’s no second confirmation step — one approval is enough, wherever it happens.

​
Important Rules About Review

A few rules govern how review actions work — understanding these prevents surprises:
  • Inspection is optional and never grants approval by itself. You can inspect the diff and try the result as many times as you like. Neither action moves the task to Done.
  • Recording a test observation does NOT approve code. Notes in the task feed are for your records and the coordinator’s context. Approval requires the explicit Approve and Integrate action.
  • A changed candidate or destination requires fresh approval. If the result changes — for example, after a correction — the previous approval no longer applies and you must approve the new version.
  • If a checkout blocker prevents delivery, approval is retained for a retry. Local edits or branch conflicts that prevent delivery don’t discard your approval. Fix the blocker and retry delivery — the result explains the next action.
  • Approval from your coding conversation uses the same record as browser approval. If you approve through Codex, no separate browser confirmation is needed.

​
Report-Only Tasks

Not every task produces code. A task whose result is a report — research findings, a design proposal, an analysis — can complete as Done without a code approval step. When a worker submits a report-only result, Flowfield recognizes the completion type and can mark the task Done directly once the result is reviewed.
Done means the agreed outcome has completed, including code delivery where applicable. It is a strong signal — not just “the worker finished”. When you see a task in Done, you can trust that what was agreed is what was delivered.