Triage query APIs

Duckbill™ exposes versioned /api/v1 read contracts so the web UI and future clients can triage without talking to Graph. See ADR 0023 and ADR 0009.

Routes

Contract	HTTP
HomeSummary	`GET /api/v1/home`
GetNeedsMe	`GET /api/v1/needs-me`
GetRespondQueue	`GET /api/v1/respond`
GetWaitingQueue	`GET /api/v1/waiting`
GetSystemAlerts	`GET /api/v1/system-alerts`
GetConversation	`GET /api/v1/conversations/{id}`
Structured search	`GET /api/v1/search`
Provider health	`GET /api/v1/health`
Command catalog (not executable)	`GET /api/v1/commands`

All routes require an application session. Responses use { data, error }.

Semantics

Needs Me can return ACTION, RESPOND, SYSTEM_ALERT, and low-confidence items.
Respond is conversations the user owes. Marking a MessageInstance read does not remove RESPOND.
Waiting is awaiting others and can age / show overdue.
System Alerts are exception-oriented system mail. Routine Vercel success fixtures are excluded; failures are included.
Search is structured metadata on the local canonical index. No vector database. No provider search.
Results include mailbox and provider, not only subject.
Conversation payloads include available_actions. can_send and can_delete are always false.
Stale sync is labeled when last sync is old or the account is paused/errored.

Future write-back

GET /api/v1/commands documents reserved routes (archive, mark-read, flag, waiting). Stream B owns MailCommand / ProviderMutation. This stream does not send or delete.

Modules

Application query logic: packages/application/src/triage-query.ts, triage-attention.ts, available-actions.ts, triage-http.ts, triage-store.ts. No new tables. Existing canonical tables are enough.