feat(tasks): adopt canonical task statuses

docs/activity-core-delegation.md

@@ -54,7 +54,7 @@ state hub publishes:
 | `org.statehub.workstream.completed`  | `api/routers/workstreams.py:update_workstream` (on transition)  |
 | `org.statehub.decision.resolved`     | `api/routers/decisions.py:resolve_decision_action`              |
 | `org.statehub.domain.goal.activated` | `api/routers/domain_goals.py:activate_domain_goal`              |
-| `org.statehub.task.stale`            | `scripts/cleanup_stale_tasks.py` (per cancelled task)           |
+| `org.statehub.task.stale`            | `scripts/cleanup_stale_tasks.py` (per canceled task)            |
 
 All events use the shared `EventEnvelope` schema (`api/events/envelope.py`)
 and are published via `publish_event(subject, envelope)`. Publishing is

docs/cron-migration.md

@@ -78,7 +78,7 @@ Notes:
 # activity-definitions/state-hub-stale-task-cleanup.yaml
 id: the-custodian.state-hub-stale-task-cleanup
 description: |
-  Daily sweep that cancels tasks still 'todo|in_progress|blocked' inside
+  Daily sweep that cancels tasks still `wait|todo|progress` inside
   finished or archived workstreams. Each cancellation also emits
   org.statehub.task.stale on NATS for downstream reaction.
 trigger:

docs/task-flow-engine-spec.md

@@ -46,8 +46,8 @@ exit_assertions:
   - id: tasks.all_done
     target: tasks.*.status
     op: all_eq
-    value: [done, cancelled]
-    description: All child tasks are done or cancelled.
+    value: [done, cancel]
+    description: All child tasks are done or canceled.
 ```
 
 Schema:
@@ -127,7 +127,7 @@ exit_blocked: true
 blocking_assertions:
   - id: tasks.all_done
     passed: false
-    reason: "Expected all values at tasks.*.status to be in ['done', 'cancelled']; got ['done', 'todo']."
+    reason: "Expected all values at tasks.*.status to be in ['done', 'cancel']; got ['done', 'todo']."
 reachable:
   - ready
   - active
@@ -136,7 +136,7 @@ unreachable:
     blocking:
       id: tasks.all_done
       passed: false
-      reason: "Expected all values at tasks.*.status to be in ['done', 'cancelled']; got ['done', 'todo']."
+      reason: "Expected all values at tasks.*.status to be in ['done', 'cancel']; got ['done', 'todo']."
 ```
 
 Schema:
@@ -152,13 +152,13 @@ Schema:
 ### Workstreams
 
 Workstreams can express readiness for closure by asserting that child tasks
-are `done` or `cancelled`. They can express dependency blocking by checking that
+are `done` or `cancel`. They can express dependency blocking by checking that
 all dependency workstreams have reached `finished` or `archived`.
 
 ### Tasks
 
 Tasks can express human intervention with the existing `needs_human` flag.
-Returning from `blocked` to `in_progress` is an entry assertion over that same
+Returning from `wait` to `progress` is an entry assertion over that same
 flag. Lightweight completion remains unconstrained because curator intent is
 the deciding signal.
 

docs/task-state-attached-repo-impact.md

@@ -0,0 +1,93 @@
+# Task State Attached Repo Impact
+
+Date: 2026-05-25
+Interface change: `649102a2-4373-4621-9848-cc257e67c262`
+Status: published
+
+## Notice Channel
+
+State Hub published a breaking schema interface change from `state-hub` to all
+active attached repos except `state-hub` itself.
+
+The notice points target repos to `docs/task-state-canon-migration.md` and asks
+their local agents to update any State Hub task-status references:
+
+```text
+blocked -> wait
+in_progress -> progress
+cancelled/canceled -> cancel
+todo -> todo
+done -> done
+```
+
+Workstream/workplan lifecycle status is unchanged and still includes
+`blocked`.
+
+## Classification
+
+Classification was based on `GET /repos/` plus a read-only local scan of active
+repo paths. `legacy-literals` means a repo contains old words such as
+`blocked`, `in_progress`, `cancelled`, `blocked_tasks`, or `TaskStatus`; the
+hit can be task state, workstream state, capability/debt status, or prose, so
+the owning repo agent must review context before editing.
+
+| Repo | Local path | Classification |
+|------|------------|----------------|
+| activity-core | yes | file-backed; legacy-literals |
+| artifact-store | yes | file-backed; legacy-literals |
+| can-you-assist | yes | file-backed; legacy-literals |
+| citation-engine | yes | general notice only |
+| citation-evidence | yes | file-backed |
+| citation-work | yes | general notice only |
+| domain-tree | yes | file-backed; legacy-literals |
+| evidence-anchor | yes | general notice only |
+| evidence-binder | yes | general notice only |
+| evidence-source | yes | general notice only |
+| flex-auth | yes | file-backed; legacy-literals |
+| guide-board | yes | file-backed; legacy-literals |
+| helix-forge | yes | file-backed; legacy-literals |
+| ihp-railiance-probe | yes | file-backed; legacy-literals |
+| info-tech-canon | yes | canon source; file-backed |
+| infospace-bench | yes | file-backed; legacy-literals |
+| inter-hub | yes | file-backed; legacy-literals |
+| issue-core | yes | file-backed; likely State Hub/task lifecycle client; legacy-literals |
+| kaizen-agentic | no | general notice only |
+| key-cape | yes | file-backed; legacy-literals |
+| kontextual-engine | yes | file-backed; legacy-literals |
+| llm-connect | yes | file-backed; legacy-literals |
+| marki-docx | no | general notice only |
+| markitect-filter | yes | file-backed; legacy-literals |
+| markitect-project | yes | file-backed; legacy-literals |
+| markitect-quarkdown | yes | file-backed; legacy-literals |
+| markitect-tool | yes | file-backed; legacy-literals |
+| net-kingdom | yes | file-backed; legacy-literals |
+| open-cmis-tck | yes | file-backed; legacy-literals |
+| open-reuse | yes | file-backed; legacy-literals |
+| ops-bridge | yes | file-backed; legacy-literals |
+| ops-warden | yes | file-backed; legacy-literals |
+| phase-memory | yes | file-backed; legacy-literals |
+| railiance-apps | yes | file-backed; legacy-literals |
+| railiance-cluster | yes | file-backed; legacy-literals |
+| railiance-enablement | yes | file-backed; legacy-literals |
+| railiance-fabric | yes | file-backed; legacy-literals |
+| railiance-hosts | yes | file-backed; legacy-literals |
+| railiance-infra | yes | file-backed; legacy-literals |
+| railiance-platform | yes | file-backed; legacy-literals |
+| repo-scoping | yes | file-backed; legacy-literals |
+| the-custodian | yes | file-backed; likely State Hub/task lifecycle client; legacy-literals |
+| user-engine | yes | file-backed |
+| vergabe-teilnahme | yes | file-backed; legacy-literals |
+| vergabe_teilnahme | yes | file-backed; legacy-literals |
+
+## Requested Repo-Agent Action
+
+Each repo agent should:
+
+1. Read its State Hub inbox notice for interface change
+   `649102a2-4373-4621-9848-cc257e67c262`.
+2. Search local agent instructions, workplans, scripts, docs, tests,
+   dashboards, and API clients for State Hub task-status values.
+3. Replace task-state usage with canonical values and leave unrelated
+   workstream/capability/debt statuses unchanged.
+4. Report completion by replying in State Hub or resolving the interface change
+   for that repo once local adaptation is complete.

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.

docs/workplan-state-model-proposal.md

@@ -16,8 +16,8 @@ This makes file-backed workplans harder to reason about. A workplan can be a
 good proposal but not ready to execute; a ready workplan can become stale after
 the repo changes; parked backlog work should not clutter the current work view.
 
-Task status should remain separate. Tasks can keep using
-`todo`, `in_progress`, `blocked`, `done`, and `cancelled`.
+Task status should remain separate. Tasks use the InfoTechCanon-aligned
+`wait`, `todo`, `progress`, `done`, and `cancel` lifecycle.
 
 ## Proposed Canonical Workplan States