Work-item-link (5.8) chips ONLY the explicit [label](motir:<id>) token — a bare MOTIR-<n> wires the relates_to edge but never renders as a chip; normalize bare keys on write
The gap (surfaced from the 7.4 re-plan + manual authoring). The work-item-link feature (5.8, MOTIR-1399) parses a bare MOTIR-<n> on write to auto-create the relates_to edge (MOTIR-1403), but it does NOT rewrite the bare key — so a bare MOTIR-<n> stays PLAIN TEXT and never renders as a chip. Only the explicit [label](motir:<id>) token (the item's INTERNAL cuid, not the MOTIR-<n> key) chips, via WorkItemRefChip. So anyone authoring a chip must hand-resolve the cuid — which repeatedly bit the planner (and the manual motir plan workflow): bare keys were written, the edges wired, but no chips appeared.
Fix — NORMALIZE bare keys on write. Extend the write-path ref-parser (MOTIR-1403, motir-core/lib/mentions/workItemRefs.ts) so a parsed bare MOTIR-<n> is REWRITTEN to the canonical [label](motir:<id>) token (resolve key→id ONCE, store canonical) — so a bare key both wires the edge AND renders as a chip. Apply on the MCP create_work_item / update_work_item write-path (and the in-app editor save). Idempotent: an already-explicit motir:<id> token is left unchanged; an unknown key stays plain text.
Materialize side. The generator (MOTIR-845) emits motir-ref:<tempRef> for intra-plan siblings (resolved at materialize, MOTIR-1418) + bare/real keys for existing items — the same normalize must apply to bare REAL keys at materialize so generated descriptions chip too.
Tests. A description with a bare MOTIR-<n> round-trips through create/update and comes back as the canonical [label](motir:<id>) token (chips on render); the relates_to edge is still created; an already-explicit token is unchanged; an unknown key is left plain.
Until this lands, the runbook (plan-procedure.md + plan-rules.md) was corrected to instruct authors to emit the explicit [label](motir:<id>) token, not a bare key.