Module readiness 

Task readiness: a derived projection of the canonical status, and not a second vocabulary for it.

Why there is one at all

crate::plan::ISSUE_STATUSES is the canonical vocabulary — READY, BLOCKED, ACTIVE, VERIFY, DONE, CANCELLED — and it is right for what it is: the six words lib/project.awk derives, held to byte equality with the shell engine by test/cases/99_plan_capabilities.sh. Nothing here changes, replaces or renames any of them; every TaskReadiness carries the canonical status it was derived from, so a caller that wants the canonical word has it on the same object.

What it adds is exactly the distinctions the canonical six already make in the data and cannot express in the word:

• BLOCKED is two situations. The plan’s own derivation appends milestone:<id> to an issue’s blocked_by when the milestone gate holds it, on top of whatever issue dependencies it has. An issue with every dependency DONE, held back only because the outcome it belongs to waits on another outcome, is not the same problem as an issue waiting on a peer: the first is resolved somewhere else entirely. TaskReadiness::Waiting is that case; TaskReadiness::Blocked is the other.
• VERIFY is two situations. The plan reaches VERIFY when verified_at or completed_at is set, and it emits the evidence_missing finding for the second of those when the required evidence is not all there. So VERIFY covers both “the work is done and someone must confirm it” and “someone already declared it complete and the evidence does not back that up” — the second is a defect a person has to act on, the first is a queue. TaskReadiness::Review and TaskReadiness::CompletionBlocked.
• an id the model does not have. plan.issues cannot answer for one at all, and answering BLOCKED or an empty object for a typo is the one answer a work surface must never give. TaskReadiness::Undeclared.

and nothing else. There is no in_review, no needs_triage, no wontfix: three words that no field of any canonical record could distinguish, which is what makes them frontend strings rather than workflow.

The mapping is total and one-way

Every canonical status maps to exactly one readiness, and TaskReadiness::canonical maps back. The three added distinctions are refinements inside a canonical status, never across two, so the round trip through canonical is lossless in the direction that matters: no readiness can claim a canonical status the plan did not derive.

Structs

Blocker

One thing standing between a task and being startable, with what to do about it.

Enums

BlockerKind

What kind of thing is holding a task back. The five are the five the canonical model can actually produce; there is no other.

TaskReadiness

Where a development task stands, as work.

Constants

MILESTONE_BLOCKER

The prefix the plan’s own blocked_by uses for the milestone gate. Stated once, because two readers of the same token is how a prefix quietly changes on one side only.