Tasks

A story says what must become true. A task says do this now.

Nothing here is a new artefact either. task is the fourth level of the same work breakdown the tracker has always had — initiative → epic → story → task.

Codes

<epic>.<story>.<task>, zero-padded to two digits: 01.01.03, 06.02.01.

Same scheme, same reasons as the work register: positional, never derived from a name, never reassigned. A task code sorts under its story and reads as a path — 06.02.01 is the first task of the second story of the sixth epic, and nothing has to be looked up to know that.

The third level is the only level that may be renumbered, because tasks are regenerable. If a regeneration produces a different decomposition, the old codes go with the old tasks. That is the one asymmetry between this level and the three above it.

Where they live

Beside the owning module's register, under docs/tasks/, one file per epic — the filename begins with the same zero-padded epic number as its heading in that module's docs/work-register.md.

<module>/docs/
  work-register.md           what must become true, grouped by WBS epic
  tasks/07-handover.md       what to do next for epic 07, and in what order

The documentation set stays self-contained: a clone of the repository carries the rules, the work and the state of the work, with nothing to log into. That matters more than it looks. A task that exists only in a hosted tracker cannot be regenerated alongside its story, cannot be reviewed in the same pull request as the code that closes it, and cannot be read by whoever inherits the repository in three years.

What a task is

A unit of work with a verifiable end state, small enough that starting it does not require another decision, and traceable to exactly one story.

Three tests, and a task that fails any one of them is not a task:

The second is the one that actually bites. A task holding an unresolved decision is a question wearing a checkbox, and it will sit in the list looking like progress. Send it upstream: to the story if it is a scope question, to the open questions if only the client can answer, to a decision record if it is expensive to reverse.

The four rules

1 — A task never restates a rule. It points at its story; the story cites requirement identifiers; the requirement holds the rule. Three levels, one copy. A task that explains why has copied something.

2 — Tasks are disposable and regenerable. Delete every task of a story, regenerate, and nothing is lost. If something would be lost, it was never a task: it was a decision, a constraint or an acceptance criterion sitting in the wrong file. This is the whole reason tasks are allowed to be verbose where stories are not — they cost nothing to throw away.

3 — The readiness gate applies one level down. A story that is blocked gets no tasks. Writing tasks against an unresolved decision is how a feature nobody asked for gets built, and it is worse here than at the story level: at the story level a premature entry looks like planning; at the task level a list of small concrete things reads as permission to start.

4 — Tasks slice the story's tracer bullet, they do not add to it. The story is one vertical slice through every layer along one narrow path. Its tasks are the layers of that slice — schema, server, screen, test — never a second feature that seemed related.

Deriving them

The story already contains its own first decomposition: the slice line names the vertical path. Tasks refine that line; they do not replace it.

For each story, in this order:

1. Read the requirements it cites, not the story's prose. The prose is a summary; the requirement is the rule, and the task must satisfy the rule.
2. Name the end state of each layer the slice crosses. Data first, because it is the layer whose omission costs a migration, then the act, then what a person sees, then the test that holds it.
3. Check each candidate against the three tests above. Fold the ones that fail into their neighbour, or send them upstream.
4. Order them so that each leaves the repository working. A task that only makes sense once the next one lands is one task, not two.
5. Stop at the story boundary. Anything left over that still feels necessary is either another story, or a requirement nobody wrote.

Aim for three to seven tasks per story. Fewer and the story was a task; more and the story was an epic — either way the finding is about the story, not the decomposition, and it goes back up.

The file

The presentation is mandatory: one file per epic, one section per story, and one # | Task | Finished when table per unblocked story. Never return a flat task list.

# Tâches — <épopée>

Régénérables. Elles ne portent aucune règle : la règle vit dans les exigences,
citées par la story. Une tâche qui explique *pourquoi* a recopié quelque chose.

## 01.01 — Poser le vocabulaire et le modèle du dossier

**Story** — [`01.01`](../work-register.md#01--socle)

| # | Tâche | Fini quand |
| --- | --- | --- |
| `01.01.01` | … | … |
| `01.01.02` | … | … |

Three columns, and the third is not optional: finished when is what makes the task verifiable by someone who was not in the conversation.

Blocked stories appear in the file by name, with no table, and the reason they carry no tasks. An epic whose stories are all blocked gets a file saying so, rather than no file — absence reads as an oversight, a sentence reads as a decision.

Red flags — stop

• A task that names no story. It belongs to something; find out what, or it is scope arriving through the back door.
• A task list for a blocked story. The gate exists at this level too, and it is easier to breach here because a list of small things feels harmless.
• A task quoting an acceptance criterion. Two copies, and they will disagree.
• "Investigate…" or "Look into…" as a task. That is a question with an owner, not work with an end state. If it must exist, its end state is the answer is written down, and say where.
• A decomposition that reorganises the story. If deriving tasks made you want to change the story's scope, the finding is about the story. Change it, then derive again.
• Estimates. They belong to the plan, not to the breakdown. A task list that carries them becomes a schedule nobody agreed to.