Motir

Repo: motir-core. One PR. Docs-only (docs/**) — branch docs/MOTIR-<id>-<slug>. Filed 2026-08-18 by the motir run of MOTIR-2972, which is that card's acceptance criterion 6 taken down its second branch: "or the PR says why the ADR is left alone (it is in motir-core, so a row there is a SECOND repo and therefore a second card; naming it in the PR body and filing that card is the compliant answer)." Filing it is the compliant half; this is the card.

The defect

docs/decisions/work-item-type-taxonomy.md Amendment 1 (2026-08-10) closes with a table of every downstream consumer that owed an update for the fourteen-member enum — schema, domain, DTO, filter grammar, published contracts, seed, presentation metadata, tokens, i18n, surfaces, the playbook — each with an owning card (MOTIR-2630 / 2631 / 2632 / 2633). Verified on origin/main:

$ git show origin/main:docs/decisions/work-item-type-taxonomy.md | grep -c SHARED_PLANNING_RULES
0

motir-ai's src/llm/planningRulePacks.ts holds a prose copy of the same member list, handed verbatim to the hosted planner. It is a consumer of the enum and it is not in the table, which is why it kept sweeping the pre-taxonomy set for eight days after the amendment landed — the drift MOTIR-2972 measured and fixed.

The row is not bookkeeping. The table is the ADR's sweep list, and the next amendment's author will read exactly it. A fifteenth member added tomorrow reproduces this defect in the same place, for the same reason, because nothing in motir-core records that the mirror exists.

motir-ai now carries its own in-repo guard (MOTIR-2972 asserts the rule's set against WORK_ITEM_TYPES, so a stale prose list is a red test there). That guard cannot fire in motir-core, and it cannot tell a motir-core author that a second repo is downstream of the enum they are editing. Only the row does that.

Acceptance criteria

1. Amendment 1's follow-up table gains a row for the hosted planner's mirror — consumer motir-ai src/llm/planningRulePacks.ts's PLAN_ALL_SUBTASK_TYPES_AND_COMPOSITION (the prose set inside SHARED_PLANNING_RULES), owning card MOTIR-2972 — written in the same column shape as the rows already there.
2. The row states, in its description cell, that this consumer is prose in a template literal, in another repository — so no compile-time guard reaches it, unlike workItemTypeMeta.ts's total Record the table's own closing paragraph relies on. A reader who takes the table as complete must be able to see from the row alone why this one needed a card rather than a build failure.
3. The row also names motir-ai src/llm/workItemTypes.ts's WORK_ITEM_TYPES — the typed mirror of the same list, which DID track the amendment — so the next sweeper knows the other repo carries two copies and only one of them is compiler-checked.
4. ORDERING — this card runs AFTER MOTIR-2972 merges, because criterion 1's row cites it as the owning card and a row pointing at unmerged work is the falsehood this table already contains once. It is wired blocked_by that card.
5. No other section of the ADR is edited: §1, §1b and §3 are the decision itself and are unchanged by adding a referrer. Amendment 1's own text is unchanged apart from the table.
6. The PR is docs-only, so the branch carries the docs/ prefix (CI then skips the Playwright + Vitest integration jobs, which no ADR edit needs). The PR title carries this card's MOTIR-<id>.

Context refs

• docs/decisions/work-item-type-taxonomy.md — Amendment 1, its §1b canonical-order table, and the follow-up table at the end (the one edited here) plus the paragraph after it about the compile-time guard.
• READ-ONLY, in motir-ai: src/llm/planningRulePacks.ts (PLAN_ALL_SUBTASK_TYPES_AND_COMPOSITION) and src/llm/workItemTypes.ts (WORK_ITEM_TYPES) — the two copies the new row names.
• MOTIR-2972 — the drift itself, and the card the new row cites as owner.
• MOTIR-2967 — the conservation baseline that can now detect the mirror CHANGING, and whose deferred cross-repo equality check is the mechanical form of what this row does in prose.