The incoming-work front door for a project. Bug reports and feature requests arrive — from a workspace member through an in-app "report a bug / request a feature" widget, or from a signed-in non-member through the 6.12 public-project "Submit a request" form — and land in a triage inbox, a staging queue that is EXCLUDED from the planned tree until an admin acts on it. The admin triages each item: accept it into the backlog, promote it under a sprint / epic / story (set parent + position), decline it, mark it duplicate / merge it into a canonical item, or snooze it. This is a pure motir-core, per-project feature — no AI boundary, no forward dependency.
The locked model (mirrors Linear Triage): a submission IS a work_item (kind bug or task) from the moment it is created, but it carries a triage state that makes it invisible to EVERY normal read — the tree, every board, every list, the ready set, and search all exclude it (Linear: "we exclude triage issues from all views since triage is considered to be outside the normal workflow"). The triage-queue read is the single read that returns ONLY triage items. Promotion is not a copy — it clears the triage marker and sets parent + backlog rank through the shipped workItemsService, so the same item (with its comments, attachments, and history intact) simply appears in the tree.
Scope: the design of both surfaces (6.11.1); the triage-model decision (6.11.2); the schema + the read-exclusion-everywhere invariant (6.11.3); the intake path — the in-app member submit (6.11.4); the triage-actions service — accept / promote / decline / mark-duplicate-merge / snooze (6.11.5); the admin triage inbox UI (6.11.6); the in-app report widget UI (6.11.7); the read-exclusion + actions tests (6.11.8); the submit→triage→promote e2e (6.11.9); and retiring the dropped external-submitter schema + ADR (6.11.10). (The external "Submit a request" surface itself is Story 6.12.)
Out of scope (named so they are not silently lost): AI-assisted auto-triage / dedupe-suggestion (an Epic-7 planner enhancement, not this story); triage-responsibility on-call scheduling (Linear Business-tier; a later 6.x setting); SLA / response-time tracking on submissions; and email/Slack ingestion channels (this story ships the in-app member channel and consumes the 6.12 signed-in submit channel; integration channels reuse the same triage-item creation path later); and anonymous/unauthenticated submission (a work item is created only by a signed-in account — the dropped public portal — pending a future abuse/anonymous-identity model).
PROD project. Confirm it appears in the triage inbox AND is absent from: the issue tree, every board column, every saved/default list, the ready set, and a search that would otherwise match it (e.g. by its title). Then promote it to the backlog → confirm it now appears in the tree/list/search and is gone from the triage queue.submittedByUserId, no tenant access). (The submit surface itself ships in Story 6.12; 6.11 owns the inbox that receives it.)pnpm test (motir-core) — 6.11.8 covers the exclusion at EVERY read (tree/board/list/ready/search), the queue-only read, and each action (promote re-parents + ranks via workItemsService, decline cancels, merge folds + cancels, snooze hides/returns), all on a real Postgres per the standing rule, respecting the per-file coverage gate.workItemsService; the inbox + form UIs reference only --el-* / [data-display-style] tokens and shipped components/ui/* primitives.