MOTIR-142Done
2.7.2 Decision — the WorkItemType taxonomy + the type→executor default map
Estimate: 35m
Type: decision (the ADR that fixes the taxonomy 2.7.3’s enum, 2.7.4’s picker, 2.7.5’s loader mapping, 2.7.6’s filter facet, and — downstream — Story 7.6’s prompt generator all build against). No app behaviour ships here, but the set it freezes is load-bearing.
Write motir-core/docs/decisions/work-item-type-taxonomy.md (mirror the repo’s ADR convention). It MUST fix:
- The fixed
WorkItemTypeenum (ten members).code·design·test·content(copy/docs/translate) ·research(spike/investigation) ·review(QA) ·decision·deploy(infra/ops) ·manual(human SaaS/dashboard/provisioning) ·chore. Record a one-line scope for each so the picker labels + the 7.6 prompt templates have an authoritative gloss. FIXED, not free text — so 7.6’s per-type generator is a TOTAL function (aswitchwith nodefaulthole) and the 2.7.6 filter facet is a closed set; extensible later by an explicit enum addition + migration, never ad-hoc strings. typeis DISTINCT fromkindand LEAF-ONLY.kind(epic/story/task/subtask/bug) is the structural hierarchy;typeis the NATURE of executable work and is carried ONLY on leaves (task/subtask/bug). Epics + stories + legacy rows aretype = null.- The
executorenum + the type→executor DEFAULT map.executor ∈ { coding_agent, human }. Default map:code/test/deploy→ coding_agent;manual/decision/review→ human;design/content/research/chore→ either, default coding_agent. The default SEEDSexecutorwhen a type is first chosen and is OVERRIDABLE; record the map as the single source 2.7.3’s helper encodes. - The Jira-mirror deviation (Principle #11 — the honest paper trail). Record the VERIFIED mirror: in Jira the "issue type" IS the kind hierarchy (epic/story/task/sub-task/bug — Atlassian "What are work types?"), and routing WHO executes is done via the ASSIGNEE field — with Rovo "you can add an agent to the assignee field," so an AI agent "shows up as an assignee, with the same fields and patterns" (support.atlassian.com — "Collaborate on work items with AI agents"). Jira therefore has NO native executor sub-type orthogonal to issue-type. Motir’s separate
type+executoraxes are a DELIBERATE deviation justified by a concrete use case: the Epic-7 AI dispatch layer routes bytype(which prompt template) andexecutor(coding-agent dispatch vs human assignment) — a structural axis the kind-as-type + assignee-as-router shape cannot express without overloading two fields.
Acceptance criteria
motir-core/docs/decisions/work-item-type-taxonomy.mdexists and fixes all four sections: the ten-member enum with per-member gloss, the leaf-only + distinct-from-kind + nullable rule, the executor enum + the full type→executor default map, and the cited Principle-#11 deviation.- The default map is recorded as an explicit table (the single source 2.7.3’s helper implements) — every one of the ten types has a default executor.
- The Jira mirror is CITED (issue-type = kind; executor = assignee, NOT a sub-type), with the concrete Epic-7-dispatch justification — not asserted (notes.html #33: verify the mirror, cite what was observed).
Context refs
- This module header (the locked taxonomy + the deviation rationale).
scripts/plan-seed/types.ts—PlanItem.type/PlanItem.executor(the plan-side fields already carrying these values as the loader input 2.7.5 maps).- Atlassian Support — "What are work types?" (issue-type = the kind hierarchy) + "Collaborate on work items with AI agents" (agent routing via the assignee field) — the cited mirror.
- Story 7.6 (stub) — the per-type prompt generator whose total-function guarantee this fixed enum exists to support.