diff --git a/infospace/models/task/InfoTechCanonTaskModel.md b/infospace/models/task/InfoTechCanonTaskModel.md index f7bbb45..e70779a 100644 --- a/infospace/models/task/InfoTechCanonTaskModel.md +++ b/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 diff --git a/infospace/profiles/small-saas/artifacts/task.onboard-tenant.yaml b/infospace/profiles/small-saas/artifacts/task.onboard-tenant.yaml index 9b075ca..ecf5c70 100644 --- a/infospace/profiles/small-saas/artifacts/task.onboard-tenant.yaml +++ b/infospace/profiles/small-saas/artifacts/task.onboard-tenant.yaml @@ -3,7 +3,7 @@ kind: task title: Onboard Tenant profile: small-saas owner_team: small-saas/team/platform -status: ready +status: todo target_tenant: small-saas/tenant/acme evidence_ids: - small-saas/evidence/access-review-2026-05 diff --git a/infospace/standards/tagging/InfoTechCanonTaggingStandard.md b/infospace/standards/tagging/InfoTechCanonTaggingStandard.md index 51ae5bc..59c6308 100644 --- a/infospace/standards/tagging/InfoTechCanonTaggingStandard.md +++ b/infospace/standards/tagging/InfoTechCanonTaggingStandard.md @@ -871,7 +871,7 @@ Examples: ```text 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 ``` @@ -1323,8 +1323,11 @@ work-type/bug work-type/feature work-type/review work-type/remediation -workflow-state/blocked -workflow-state/in-review +workflow-state/wait +workflow-state/todo +workflow-state/progress +workflow-state/done +workflow-state/cancel commitment-state/committed actionability/needs-clarification reachability/not-reachable @@ -1360,8 +1363,12 @@ work-type/bug -> type: bug work-type/feature -> type: feature work-type/documentation -> type: docs priority/high -> priority: high -workflow-state/blocked -> status: blocked -actionability/needs-info -> status: needs-info +workflow-state/wait -> status: wait +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 good-first-issue -> contribution/good-first help-wanted -> contribution/help-wanted @@ -1411,9 +1418,12 @@ area: ci area: api area: ui area: security -status: blocked -status: needs-info -status: in-review +status: wait +status: todo +status: progress +status: done +status: cancel +actionability: needs-info priority: high risk: security contribution: good-first diff --git a/seeds/InfoTechCanonTaggingStandard_RC1_seed.md b/seeds/InfoTechCanonTaggingStandard_RC1_seed.md index 8ca2ad8..b1c0cae 100755 --- a/seeds/InfoTechCanonTaggingStandard_RC1_seed.md +++ b/seeds/InfoTechCanonTaggingStandard_RC1_seed.md @@ -871,7 +871,7 @@ Examples: ```text 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 ``` @@ -1323,8 +1323,11 @@ work-type/bug work-type/feature work-type/review work-type/remediation -workflow-state/blocked -workflow-state/in-review +workflow-state/wait +workflow-state/todo +workflow-state/progress +workflow-state/done +workflow-state/cancel commitment-state/committed actionability/needs-clarification reachability/not-reachable @@ -1360,8 +1363,12 @@ work-type/bug -> type: bug work-type/feature -> type: feature work-type/documentation -> type: docs priority/high -> priority: high -workflow-state/blocked -> status: blocked -actionability/needs-info -> status: needs-info +workflow-state/wait -> status: wait +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 good-first-issue -> contribution/good-first help-wanted -> contribution/help-wanted @@ -1411,9 +1418,12 @@ area: ci area: api area: ui area: security -status: blocked -status: needs-info -status: in-review +status: wait +status: todo +status: progress +status: done +status: cancel +actionability: needs-info priority: high risk: security contribution: good-first diff --git a/seeds/InfoTechCanonTaskModel_RC1_seed.md b/seeds/InfoTechCanonTaskModel_RC1_seed.md index 021c50f..6e89d30 100755 --- a/seeds/InfoTechCanonTaskModel_RC1_seed.md +++ b/seeds/InfoTechCanonTaskModel_RC1_seed.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