MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-142

2.7.2 Decision — the WorkItemType taxonomy + the type→executor default map

Done
Description

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:

  1. The fixed WorkItemType enum (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 (a switch with no default hole) and the 2.7.6 filter facet is a closed set; extensible later by an explicit enum addition + migration, never ad-hoc strings.
  2. type is DISTINCT from kind and LEAF-ONLY. kind (epic/story/task/subtask/bug) is the structural hierarchy; type is the NATURE of executable work and is carried ONLY on leaves (task/subtask/bug). Epics + stories + legacy rows are type = null.
  3. The executor enum + 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 SEEDS executor when a type is first chosen and is OVERRIDABLE; record the map as the single source 2.7.3’s helper encodes.
  4. 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 + executor axes are a DELIBERATE deviation justified by a concrete use case: the Epic-7 AI dispatch layer routes by type (which prompt template) and executor (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.md exists 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.tsPlanItem.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.
Status
Done
Type
Sub-task