feat(tasks): adopt canonical task statuses

docs/task-state-canon-migration.md

@@ -0,0 +1,90 @@
+# Task State Canon Migration
+
+Date: 2026-05-25
+Status: implementation source
+
+## Canon Source
+
+State Hub follows the task lifecycle defined by InfoTechCanon:
+
+- `info-tech-canon/infospace/models/task/InfoTechCanonTaskModel.md`
+- `info-tech-canon/seeds/InfoTechCanonTaskModel_RC1_seed.md`
+
+The canon defines symbolic codes and lowercase stored values:
+
+| Code | Stored value | Meaning |
+|------|--------------|---------|
+| `WAIT` | `wait` | Blocked, paused, or waiting on another actor, event, decision, input, or condition. |
+| `TODO` | `todo` | Ready or planned work that is not actively being worked. |
+| `PROG` | `progress` | Active work in focus. |
+| `DONE` | `done` | Completed successfully. |
+| `CNCL` | `cancel` | Stopped because the work is no longer relevant, wanted, or valid. |
+
+State Hub stores lowercase values, not uppercase codes.
+
+## State Hub Profile
+
+State Hub task status is separate from workstream/workplan lifecycle status.
+Workstream frontmatter continues to use:
+
+```text
+proposed, ready, active, blocked, backlog, finished, archived
+```
+
+Task status now uses:
+
+```text
+wait, todo, progress, done, cancel
+```
+
+Compatibility aliases accepted during the migration window:
+
+| Legacy value | Canon value |
+|--------------|-------------|
+| `blocked` | `wait` |
+| `waiting` | `wait` |
+| `in_progress` | `progress` |
+| `cancelled` | `cancel` |
+| `canceled` | `cancel` |
+
+`done` and `cancel` are terminal for normal planning and completion checks.
+`cancel` is final. `done` can be reopened only by an explicit workflow/profile
+rule and should not be treated as normal progress churn.
+
+## Wait Versus Human Intervention
+
+`wait` is broader than the old `blocked` task status. It can mean blocked,
+paused, waiting on another actor, waiting on an event, waiting on input, or
+waiting on a decision.
+
+State Hub keeps these fields separate:
+
+- `status=wait`: the task is not actively progressing;
+- `blocking_reason`: explanatory text about the wait condition;
+- `needs_human=true`: the wait requires direct human action;
+- `intervention_note`: human-facing instruction or resolution note.
+
+A task can be `wait` without `needs_human=true`. A human intervention is
+represented by `needs_human=true`, not by status alone.
+
+## Attached Repo Adaptation Brief
+
+Repos attached to State Hub should update local agent instructions, workplan
+examples, scripts, docs, dashboards, and tests if they mention State Hub task
+statuses.
+
+Migration map:
+
+```text
+blocked    -> wait
+in_progress -> progress
+cancelled  -> cancel
+canceled   -> cancel
+todo       -> todo
+done       -> done
+```
+
+During the compatibility window, State Hub accepts legacy aliases in API and
+workplan-file inputs, but writebacks prefer canonical values. Attached repos
+should report completion by replying to their State Hub inbox message or by
+closing the targeted `[repo:<slug>]` ecosystem task created for the adaptation.