The task work type

The task work type

A task is maintenance work — a dependency bump, a security/CVE update, a runtime or framework upgrade, a config migration, a cleanup — filed with /task under the task label. It is the third work type /warp-drive runs, beside req and bug, and it sits outside the product hierarchy: a sibling of bug, never a child of cap.

The problem it solves

Every piece of work BoB drives autonomously used to be one of two shapes.

A requirement is defined by acceptance criteria: testable outcomes, negotiated up front, that describe new behaviour and trace to a parent capability. A bug is defined by a reproduced failure: a regression test that fails before the fix and passes after, tracing to the behaviour it broke.

“Upgrade Node to 22” is neither. It adds no behaviour a user would notice, so there are no acceptance criteria worth writing. Nothing is broken, so there is nothing to reproduce. What it has is a procedure and a verification: make the change, then show the build runs, the tests pass and the deploy smoke-tests clean on the new runtime.

Before task existed, that work went one of two wrong ways. Either it was forced into a req — inventing checkbox theatre so the groom readiness gate passed and a parent capability had to be conjured to hold it — or it was filed as a plain issue that /warp-drive could not see at all, because discovery admitted only req and bug. Routine upkeep accumulated as manual chores beside an autonomous loop that could have done it.

What a task is

	req	bug	task
For	New product behaviour	A defect in delivered behaviour	Keeping the project healthy
Definition of done	## Acceptance Criteria — outcomes that tick	A regression test, red before and green after	## Verification — steps that must pass
Traces to	A parent capability (Part of #NN)	The requirement it broke, when known	A trigger — an advisory, CVE, EOL date or release link
Parent capability	Required	Not required	Not required
Filed by	/requirement	/report-bug	/task

The Verification steps are still - [ ] checkboxes. That is deliberate: progress counting, /what-next, flight plans and the issue UI all read a task exactly the way they read a requirement. What changes is how the checkboxes are interpreted — as runnable checks the loop executes, not as outcomes a human negotiated.

The body format, actions and labels are the task command reference.

Where it sits in the hierarchy

Vision → Business case → Capability → Requirement → warp-drive chunks
                                        (product intent)

Bug   — a defect in delivered behaviour     ┐ outside the tree:
Task  — maintenance, prompted by a trigger  ┘ no parent capability

The cap→req tree exists to trace work back to product intent: why are we building this, and which capability does it serve? A task has no answer to that question, and inventing one would be dishonest. It exists because something outside the product changed — an advisory was published, a runtime reached end of life, a dependency shipped a release. The Trigger: line in its Notes is its provenance, the way Part of #NN is a requirement’s.

So a task legitimately has no Part of #NN, and that is a well-formed task, not an orphan. /groom never flags a parentless task as an omission and never proposes reparenting it under a capability — doing so would recreate exactly the checkbox theatre the work type exists to end. Grooming a task means what it means for any issue: is it ranked, approved, clear, and are its Verification steps runnable.

How it runs

A task rides the same warp-drive loop as everything else. The state machine did not grow a new pipeline: like bug before it (#518), task is a third value of work_type on the same linear phases, and it varies only two things — the phase labels an operator reads, and the instruction addendum the agent reads.

1. Discovery. An approved task is in the queue alongside approved reqs and bugs, ranked by the same priority rules; flight plans seat it; the /groom readiness gate exempts it from the acceptance-criteria rule and asks instead for a Verification section.
2. Execution. The loop reads the Verification section and the trigger first — the steps are the definition of done, the trigger bounds the scope — then performs the change and only the change.
3. Verification. In testing, every Verification step is run exactly as written, on top of the project’s own checks. A failing step is a failed verification — a blockable event, never a pass.
4. Done. A step is ticked only after it passed. The engine refuses requirement_done while any step is unchecked, and records the verdict on state.task.

In bob warp status the session reads as what it is: coding shows as task_executing, testing as verifying and requirement_complete as task_complete. The mechanics are in the warp-drive how-to and internals.

What it is not

• Not a scheduler. task is how maintenance work is filed and run; it does not discover that a dependency is stale or an advisory is open. Filing tasks automatically from scanners and advisory feeds is downstream work (the scheduled-maintenance routines, #1544).
• Not a loophole for features. If the change alters what a user can do, it has acceptance criteria and belongs in a req under a capability. A config migration that changes documented behaviour still updates the docs, judged per task by the same conditional docs rule a requirement follows.
• Not a todo. A todo is a human action item an agent hands back; a task is agent-runnable work.

Related

• Task command — the /task contract
• Warp-drive how-to — running a task
• Capability #1956 — the work type’s origin: #1957 (command and label), #1958 (discovery and grooming), #1959 (the engine’s third work_type), #1960 (docs)