Restructuring for Task state model

This commit is contained in:
2026-05-27 17:57:23 +02:00
parent 8e591132f8
commit 0ce66ef784
5 changed files with 151 additions and 97 deletions

View File

@@ -113,7 +113,7 @@ Boundary rule:
```text ```text
Organization defines who can act and carry responsibility. 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 ## 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. 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 ## 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. 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. 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. A **WorkflowState** is a state in a workflow.
Seed states: Recommended seed states:
```text | Code | Recommended value | Meaning |
captured |------|-------------------|---------|
clarifying | `WAIT` | `wait` | Blocked, paused, or waiting on another actor, event, decision, input, or condition. |
option | `TODO` | `todo` | Ready or planned work that is not actively being worked. |
ready | `PROG` | `progress` | Active work in focus. |
committed | `DONE` | `done` | Completed successfully. |
planned | `CNCL` | `cancel` | Stopped because the work is no longer relevant, wanted, or valid. |
in_progress
waiting Profiles MAY map richer local workflow states to these seed states when local tools need more board columns, review lanes, or intake states.
blocked
in_review
approved
done
rejected
abandoned
converted
```
--- ---
@@ -1047,7 +1039,17 @@ converted
A **Transition** is a movement from one workflow state to another. 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 ## 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 ```text
captured New Task
triaged |
clarifying WAIT ---> TODO ---> PROG ---> DONE
option ^ ^ ^ ^
ready |________|_________|_________|
committed |
planned CNCL
in_progress
waiting
blocked
in_review
approved
done
rejected
abandoned
converted
``` ```
## 13.2 Commitment States ## 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-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-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 ## 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 ## 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 ## 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 ## 23.8 Action Without Outcome

View File

@@ -3,7 +3,7 @@ kind: task
title: Onboard Tenant title: Onboard Tenant
profile: small-saas profile: small-saas
owner_team: small-saas/team/platform owner_team: small-saas/team/platform
status: ready status: todo
target_tenant: small-saas/tenant/acme target_tenant: small-saas/tenant/acme
evidence_ids: evidence_ids:
- small-saas/evidence/access-review-2026-05 - small-saas/evidence/access-review-2026-05

View File

@@ -871,7 +871,7 @@ Examples:
```text ```text
priority/high and priority/low assigned together priority/high and priority/low assigned together
status/done and status/blocked assigned together status/done and status/wait assigned together
type/bug and type/feature assigned when the profile allows only one work type type/bug and type/feature assigned when the profile allows only one work type
``` ```
@@ -1323,8 +1323,11 @@ work-type/bug
work-type/feature work-type/feature
work-type/review work-type/review
work-type/remediation work-type/remediation
workflow-state/blocked workflow-state/wait
workflow-state/in-review workflow-state/todo
workflow-state/progress
workflow-state/done
workflow-state/cancel
commitment-state/committed commitment-state/committed
actionability/needs-clarification actionability/needs-clarification
reachability/not-reachable reachability/not-reachable
@@ -1360,8 +1363,12 @@ work-type/bug -> type: bug
work-type/feature -> type: feature work-type/feature -> type: feature
work-type/documentation -> type: docs work-type/documentation -> type: docs
priority/high -> priority: high priority/high -> priority: high
workflow-state/blocked -> status: blocked workflow-state/wait -> status: wait
actionability/needs-info -> status: needs-info workflow-state/todo -> status: todo
workflow-state/progress -> status: progress
workflow-state/done -> status: done
workflow-state/cancel -> status: cancel
actionability/needs-info -> actionability: needs-info
risk/security -> risk: security risk/security -> risk: security
good-first-issue -> contribution/good-first good-first-issue -> contribution/good-first
help-wanted -> contribution/help-wanted help-wanted -> contribution/help-wanted
@@ -1411,9 +1418,12 @@ area: ci
area: api area: api
area: ui area: ui
area: security area: security
status: blocked status: wait
status: needs-info status: todo
status: in-review status: progress
status: done
status: cancel
actionability: needs-info
priority: high priority: high
risk: security risk: security
contribution: good-first contribution: good-first

View File

@@ -871,7 +871,7 @@ Examples:
```text ```text
priority/high and priority/low assigned together priority/high and priority/low assigned together
status/done and status/blocked assigned together status/done and status/wait assigned together
type/bug and type/feature assigned when the profile allows only one work type type/bug and type/feature assigned when the profile allows only one work type
``` ```
@@ -1323,8 +1323,11 @@ work-type/bug
work-type/feature work-type/feature
work-type/review work-type/review
work-type/remediation work-type/remediation
workflow-state/blocked workflow-state/wait
workflow-state/in-review workflow-state/todo
workflow-state/progress
workflow-state/done
workflow-state/cancel
commitment-state/committed commitment-state/committed
actionability/needs-clarification actionability/needs-clarification
reachability/not-reachable reachability/not-reachable
@@ -1360,8 +1363,12 @@ work-type/bug -> type: bug
work-type/feature -> type: feature work-type/feature -> type: feature
work-type/documentation -> type: docs work-type/documentation -> type: docs
priority/high -> priority: high priority/high -> priority: high
workflow-state/blocked -> status: blocked workflow-state/wait -> status: wait
actionability/needs-info -> status: needs-info workflow-state/todo -> status: todo
workflow-state/progress -> status: progress
workflow-state/done -> status: done
workflow-state/cancel -> status: cancel
actionability/needs-info -> actionability: needs-info
risk/security -> risk: security risk/security -> risk: security
good-first-issue -> contribution/good-first good-first-issue -> contribution/good-first
help-wanted -> contribution/help-wanted help-wanted -> contribution/help-wanted
@@ -1411,9 +1418,12 @@ area: ci
area: api area: api
area: ui area: ui
area: security area: security
status: blocked status: wait
status: needs-info status: todo
status: in-review status: progress
status: done
status: cancel
actionability: needs-info
priority: high priority: high
risk: security risk: security
contribution: good-first contribution: good-first

View File

@@ -113,7 +113,7 @@ Boundary rule:
```text ```text
Organization defines who can act and carry responsibility. 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 ## 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. 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 ## 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. 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. 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. A **WorkflowState** is a state in a workflow.
Seed states: Recommended seed states:
```text | Code | Recommended value | Meaning |
captured |------|-------------------|---------|
clarifying | `WAIT` | `wait` | Blocked, paused, or waiting on another actor, event, decision, input, or condition. |
option | `TODO` | `todo` | Ready or planned work that is not actively being worked. |
ready | `PROG` | `progress` | Active work in focus. |
committed | `DONE` | `done` | Completed successfully. |
planned | `CNCL` | `cancel` | Stopped because the work is no longer relevant, wanted, or valid. |
in_progress
waiting Profiles MAY map richer local workflow states to these seed states when local tools need more board columns, review lanes, or intake states.
blocked
in_review
approved
done
rejected
abandoned
converted
```
--- ---
@@ -1047,7 +1039,17 @@ converted
A **Transition** is a movement from one workflow state to another. 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 ## 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 ```text
captured New Task
triaged |
clarifying WAIT ---> TODO ---> PROG ---> DONE
option ^ ^ ^ ^
ready |________|_________|_________|
committed |
planned CNCL
in_progress
waiting
blocked
in_review
approved
done
rejected
abandoned
converted
``` ```
## 13.2 Commitment States ## 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-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-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 ## 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 ## 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 ## 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 ## 23.8 Action Without Outcome