Blocked work

A Blocked Task should tell you what prevents progress. Sometimes it needs your decision. Sometimes it is simply waiting for an outside condition, such as an email reply.

Distinguish a blocker from a dependency

A dependency connects the Task to other work that must reach a release boundary first. Blocked is also a Task status, used when work cannot currently continue for another recorded reason.

See Assignments and dependencies for upstream Tasks and pull-request release rules. Do not remove a dependency merely to hide a waiting signal.

Read the reason before intervening

When an Agent blocks a Task, it must record why. The reason stays in the Task's status history. The Agent can also block work while a spec is being written, revised, or reviewed.

A Blocked status does not create a generic Inbox request or an extra comment. If you need to act, a specific question, approval, delegation, review, or mentioned comment carries that request. Worker and repository failures use their own setup and recovery items.

An approval request alone does not change Task status. Waiting for a decision and recording that execution must stop are separate controls.

Set the next check when timing matters

An Agent can choose a deliberate first recheck when it expects an outside condition to change. Its reason stays in the Task history without generating more Inbox work.

The Task's recheck control shows the next check and lets you move or clear it. Changing the check time does not resolve the underlying blocker.

Without an explicit first-check time, an ordinary Agent-authored block gets a one-hour safety backstop. Urgent work gets a five-minute backstop.

Let unchanged blockers stay quiet

When the same blocker remains, Task Machine updates the next check without repeating the status event, comment, or Inbox request. A materially different blocker records a new reason.

Successful checks become less frequent as the wait continues. Ordinary work progresses from half-hour checks toward a twelve-hour maximum. Urgent work uses shorter intervals, up to four hours. Failed checks follow their own retry schedule.

A Task with an open linked pull request follows pull-request source checks instead of the generic blocker schedule. It returns to the generic schedule after its last open pull request closes or merges.

Resume implementation when there is work to do

A check that finds the outside condition unchanged leaves the Task waiting. When it finds concrete implementation work, it hands the existing Task back for a normal Agent turn rather than asking you to restate the job.

Only a specific question, approval, delegation, or review should need your attention. Task Machine does not turn every check into a generic request for direction.

Decide repair proposals once

A repair proposal can become a dependency while it waits for one Inbox decision. Rechecks may still inspect independently changing source conditions, but they do not repeatedly poll you about the same proposal.

If current evidence makes the repair unnecessary, the dependency can be removed. Otherwise, approval leaves the original Task waiting until the repair finishes. Rejection or retraction wakes the waiting Tasks to reconsider their next step.

Use Run history for the execution record and Inbox for the decision itself.