5.8 Work-item mentions & internal links (cross-references)
Today a reference to another work item — in a description, explanation, comment, or title — is plain text ("see 7.4", "blocked by MOTIR-11"). When the referenced item is renamed or renumbered, the prose goes stale and the link between the two items is invisible to the board, ready-set, and relationships panel. This story makes a reference a live Motir internal link that always shows the target's current key + title + status, and that records the relationship so it's a real edge, not just words.
What it ships (motir-core only). In any rich-text field (description, explanation, comments) the user types @ and picks a work item from a unified picker (people and work items — the Linear-faithful unified @, decision-ladder rung 1) — or types/keeps a bare MOTIR-N key anywhere, including the title. On save, every referenced work item is auto-added to Relates to (a relates_to WorkItemLink) unless the pair is already linked in some other relationship (blocked_by / blocks / duplicates / clones) — the user's directive. The reference renders as a live internal-link chip (key · title · status) that opens the quick-view peek; an archived target renders muted/distinct, a deleted target renders struck-through with its bare key, a no-access target degrades to a bare key.
Why it reuses, not rebuilds. This is the exact pattern Story 5.1 shipped for @user mentions, one notch over: the tiptap editor + lib/mentions/parse.ts token machinery, the WorkItemLink model + linkWorkItems service (1.4.4), and the quickSearch link-picker read (6.9.2) all exist. The new token is [MOTIR-11](motir:<workItemId>) (parallel to [@Name](mention:<userId>)), parsed on the SAME write paths that already re-parse user mentions.
SCOPE BOUNDARY. This story OWNS the motir-core capability: the token format, parse-on-write -> auto-relates_to, the @ work-item picker, the live chip render, and bare-key autolink in titles. It ENDS there. It does NOT make the AI planner EMIT these tokens — that is a property of the generation/re-planning engines (7.4 / 7.11), which are unbuilt; when they ship they author descriptionMd and motir-core's parse-on-write (this story) auto-links whatever they reference. The seam is captured via relates_to to 7.4 / 7.11 and a note on each, NOT built here (building it would force a forward dependency on the unbuilt generator). In-app notification of a work-item mention is also out of scope — the relationship edge is the deliverable; a notification channel can fan in off the existing event later, like 5.7 did for user mentions.
Independently testable: a human opens any item, @-mentions another item, saves, and sees the live chip + the new Relates-to row — no AI involved.
Verification recipe: Open a work item -> in the description type @ and pick another item -> save. The reference renders as a chip showing that item's current key/title/status; the Relationships panel shows a new "Relates to" row. Rename the target -> the chip reflects the new title (not stale). Put a MOTIR-N key in the title -> it renders as a link. Archive the target -> the chip is muted; delete it -> the chip is struck through. Re-saving doesn't duplicate the link; an item already linked as "Blocked by" is NOT also auto-related.