Restructuring for Task state model

infospace/models/task/InfoTechCanonTaskModel.md

@@ -113,7 +113,7 @@ Boundary rule:
 
 ```text
 Organization defines who can act and carry responsibility.
-Task defines what work exists and how it becomes actionable, committed, executed, blocked, completed, or abandoned.
+Task defines what work exists and how it becomes actionable, committed, executed, waiting, completed, or canceled.
 ```
 
 ## 3.2 Boundary with Governance
@@ -343,7 +343,7 @@ When a work item is not directly executable, the model SHOULD support extraction
 
 Commitment SHOULD be explicit.
 
-A work item may be captured, considered, planned, committed, delegated, blocked, completed, abandoned, or converted.
+A work item may be waiting, ready to do, in progress, done, or canceled while its commitment remains explicit.
 
 ## 8.6 Actionability and Reachability Are Distinct
 
@@ -357,7 +357,7 @@ Work may be decomposed into smaller work items, but decomposition depth is conte
 
 A bug, story, incident, or request is a type of work item.
 
-Open, in progress, blocked, and done are states.
+WAIT, TODO, PROG, DONE, and CNCL are states.
 
 The model MUST NOT confuse work type with workflow state.
 
@@ -1021,25 +1021,17 @@ The Task Model provides generic workflow concepts. Profiles define concrete work
 
 A **WorkflowState** is a state in a workflow.
 
-Seed states:
+Recommended seed states:
 
-```text
-captured
-clarifying
-option
-ready
-committed
-planned
-in_progress
-waiting
-blocked
-in_review
-approved
-done
-rejected
-abandoned
-converted
-```
+| Code | Recommended 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. |
+
+Profiles MAY map richer local workflow states to these seed states when local tools need more board columns, review lanes, or intake states.
 
 ---
 
@@ -1047,7 +1039,17 @@ converted
 
 A **Transition** is a movement from one workflow state to another.
 
-Transitions SHOULD have criteria when used in mature workflows.
+Recommended seed transitions:
+
+| Current state | Allowed next states | Reason / when to transition |
+|---------------|---------------------|-----------------------------|
+| `WAIT` | `TODO`, `CNCL` | The blocking issue is resolved, or the task is no longer relevant. |
+| `TODO` | `PROG`, `WAIT`, `CNCL` | Work starts, the task becomes blocked, or the task is no longer needed. |
+| `PROG` | `DONE`, `WAIT`, `TODO`, `CNCL` | Work completes, becomes blocked, needs rework, or is canceled. |
+| `DONE` | `PROG` | Reopen only when major changes require renewed active work. |
+| `CNCL` | none | Final state; canceled work should not be reopened. |
+
+Transitions SHOULD have criteria when used in mature workflows. `PROG` SHOULD be the only state where active work is happening. `CNCL` is final. `DONE` is terminal by default and SHOULD only reopen through an explicit profile rule.
 
 ---
 
@@ -1169,23 +1171,36 @@ rationale:
 
 ## 13.1 Work Item Lifecycle States
 
+Recommended concrete lifecycle:
+
+| Code | Lowercase value | Color | Hex | CSS suggestion | Visual meaning |
+|------|-----------------|-------|-----|----------------|----------------|
+| `WAIT` | `wait` | Orange | `#F59E0B` | `bg-orange-500 text-white` | Caution / blocked |
+| `TODO` | `todo` | Blue | `#3B82F6` | `bg-blue-500 text-white` | Ready / planned |
+| `PROG` | `progress` | Purple | `#8B5CF6` | `bg-violet-500 text-white` | Active / in focus |
+| `DONE` | `done` | Green | `#10B981` | `bg-emerald-500 text-white` | Success / complete |
+| `CNCL` | `cancel` | Red | `#EF4444` | `bg-red-500 text-white` | Stopped / canceled |
+
+Softer palette option:
+
+| Code | Hex |
+|------|-----|
+| `WAIT` | `#FB923C` |
+| `TODO` | `#60A5FA` |
+| `PROG` | `#A855F7` |
+| `DONE` | `#34D399` |
+| `CNCL` | `#9CA3AF` |
+
+Recommended flow:
+
 ```text
-captured
-triaged
-clarifying
-option
-ready
-committed
-planned
-in_progress
-waiting
-blocked
-in_review
-approved
-done
-rejected
-abandoned
-converted
+New Task
+   |
+ WAIT ---> TODO ---> PROG ---> DONE
+   ^        ^         ^         ^
+   |________|_________|_________|
+                     |
+                    CNCL
 ```
 
 ## 13.2 Commitment States
@@ -1929,6 +1944,8 @@ VAL-TASK-014: Imported external task concepts SHOULD be represented through mapp
 VAL-TASK-015: Agent-executable tasks SHOULD declare capability, authority, tool, and safety requirements where relevant.
 
 VAL-TASK-016: CompletionEvidence SHOULD reference the work item or outcome it supports.
+
+VAL-TASK-017: Profiles using the seed task lifecycle SHOULD constrain WorkflowState to wait, todo, progress, done, and cancel, with cancel final and done reopenable only by explicit profile rule.
 ```
 
 ---
@@ -1953,7 +1970,7 @@ Creating tasks such as “fix system” or “think about architecture” withou
 
 ## 23.5 Blocked Without Blocker
 
-Marking a task blocked without modeling what blocks it and what would unblock it.
+Moving a task to WAIT without modeling what blocks it and what would unblock it.
 
 ## 23.6 Tool-Captured Semantics
 
@@ -1961,7 +1978,7 @@ Letting Jira, GitHub, or another tool define the internal task model.
 
 ## 23.7 Status as Type
 
-Using workflow states such as “in review” or “blocked” as if they were task types.
+Using workflow states such as “progress” or “wait” as if they were task types.
 
 ## 23.8 Action Without Outcome