Tasks & the lifecycle
Every change answers to a task. Statuses, acceptance criteria, and how PRs auto-link.
Nothing merges into a factory-managed repo without a task behind it. A task
belongs to exactly one repository, carries verifiable acceptance criteria, and
moves through a fixed lifecycle that both humans and agents can read at a
glance: in the platform, over MCP,
or straight from the repo's .sfab/.tasks/ mirror.
The lifecycle
| Status | Meaning |
|---|---|
draft | Being written; not ready to hand to an agent. |
ready | Specified and waiting for dispatch. |
assigned | Picked up; a coding agent (or person) owns it. |
working | A run is in flight. |
review | A PR is open; CI and the AI review are doing their pass. |
changes-requested | The review came back red; the work goes around again. |
needs-input | The factory stopped and the ball is in your court: a run failed past the point of auto-recovery, and a redispatch (or a decision) is the next move. |
approved | Cleared to merge. |
merged | The PR landed. |
done | Verified and closed. |
canceled | Withdrawn. |
Acceptance criteria
A task's body carries its acceptance criteria as a checklist (AC-1, AC-2,
…). They're not decoration: the review judges the change against them, and the
walkthrough agent demonstrates each one in a browser to produce the
proof you check. If it isn't in the criteria, it isn't
in the change.
Branches link PRs to tasks
A pull request links to its task by branch name: the branch starts with the
task's display id, lowercased: {org-slug}-{number}-short-description, e.g.
acme-42-fix-invoice-rounding for task ACME-42. Agent-dispatched work names
its branches this way automatically; if you push a branch by hand, follow the
same convention or the PR won't link and the task's status won't advance on
merge.
That link is what drives the lifecycle: the PR opening moves the task to
review, and the merge advances it. No manual bookkeeping.