What "done" means for a Scrum task

Review rounds no longer file board tasks on the side, with one ruled exception left standing. A finding gets fixed inside the task under review. Whether to open new work is a planning decision, and it happens outside the review loop.

Some background first. I track work on a task board, and no commit is too small for a review round. The default reader is a subagent of the session, handed the range of the change. When the diff is substantial, or the same subject has gone two rounds without converging, the reader for that round is Codex instead. Whoever reads raises candidate issues.

One commit, four tasks

On 2026-09-06, the review rounds of one task opened four tasks in a single board commit.

• Three came out of a digest pin audit.
• The fourth came out of an unrelated gap in what the rules said about CI.

Each one was defensible on its own merits. The trouble is that none of them was a planning decision anyone had taken. They landed on the board because a round happened to see them.

Why this is a problem

There are two failure modes here, pointing in opposite directions: one pushes work that belongs to the task out of it, the other pulls work onto the board that nobody should be deciding right now.

Pushing out. A finding the change itself caused or exposed was sometimes filed as a follow up task. The task closes while work it owns is still open, and the defect moves to a queue nobody is accountable for. The record from when the rule was made gives an example and calls it the sharpest version: a regression introduced by a repair in round four is round four’s own work. Round five finding it does not make it someone else’s problem.

Pulling in. A round notices something unrelated and files it on the spot. The backlog then grows by discovery instead of by decision.

The history record for this rule has one line I think gets it exactly right: discovery is not authority. Seeing something does not give you the right to decide it gets done.

How the rule reads

The record from when the rule was made puts it bluntly: review iterations are how a task is completed, not a source of tasks. The rule text itself goes like this.

On ownership:

• A finding belongs to the task under review.
• Review asks whether the current task is correct and complete. It is not a way to make work.
• A follow up task is never how unfinished work leaves a task.

On the board:

• Review does not add to the board, one ruled exception aside. The exception exists; its details are outside the scope of this post.
• Filing a task, whether through board_add.py or /scrum add, is a planning or triage decision, taken deliberately and outside the review loop.
• Actionable, important or worth improving is not the test.

The board rules also carry a general scope test that I find more useful than any of the above: if this change is left undone, can the task still truthfully be called complete? If not, it stays in the task and gets finished there. A new task is filed only for what is genuinely independent.

Classify first, then act

The two rules, a finding belongs to the task under review and review does not add to the board, were set on 2026-09-06. The next day, 2026-09-07, added a step: review became five named stages, and in the first one a person freezes the task’s intent and scope and writes it down as a contract before any AI reader looks at a diff. The contract says what may change, what must stay true, and what a later finding has to violate to count.

Every candidate issue is first asked whether it is a finding. A finding names the clause of the architecture contract it violates, or shows already authorized behavior failing on a concrete path, with evidence.

Everything else is an observation: a different design, a wider interface, a capability the contract never asked for. An observation:

• never blocks a stage from ending;
• never authorizes a change on its own;
• is never filed as a new board task by the round that raised it;
• is recorded in the observation ledger on the task register.

This split was not added on a hunch. The evidence came from another task’s review register. Without a finding and observation split, rounds 2 through 4 returned 4, 4 and 6 candidate issues, and five of them were design proposals handled as if they were defects. One rule grew from 17 lines to 31 chasing them before it was shrunk back down. Once the classification question was applied, every candidate issue that survived was a violation a command could check, and every design proposal was recorded and left non-blocking.

What changed

Before, two things could add tasks to the board. A finding the change caused or exposed was sometimes filed as a follow up task and pushed out of the task. Anything unrelated got filed the moment a round saw it.

Now, when a round raises an issue, the first question is whether it names a violated clause or shows behavior failing on a concrete path. A finding gets fixed in this task. An observation goes to the task ledger, and a person decides. Whether a new task gets opened is settled outside the loop.

The task that wrote the finding ownership rule ran under it first. It went through seven review rounds and ended clean. It refused to file tasks for what its own rounds found, for a simple reason: every finding was caused by the change and was fixed inside it. The two independent problems it noticed along the way, unrelated to the change, were only reported and not filed, as the new rule says.

Where it lands, and what is still open

Where it lands: review answers one question, whether this task is done, and does not decide what gets worked on next.

I went back and checked the two problems the rule-writing task reported instead of filing. The failing test had its own task on the board. The stale review wording sat in two places: one was already carried by another task, and the other had a task of its own. All of those tasks are closed now.

What is still open, stated plainly:

• The task that wrote this rule closed with a few observations from its final round still open. At the time they did not block anything, and they were not fixed.
• This time both reported problems happened to have a task to land in. The rule says such a problem may be reported, and recorded as an observation on the task where keeping it is worth something; it does not say to whom, or who picks it up.

Apart from the one exception mentioned at the start, opening a task is not review’s job; it is a planning or triage decision made outside the loop. The classification added the next day works the same way: an observation’s default disposition is recorded, and only a person changes it. The rule separates discovering from deciding, but the deciding end still rests on a person alone.