inbox-triagelisted

# inbox-triage — 未処理 inbox を一気に仕分ける (HITL) opshub MCP の `inbox.list`（read tool、ADR-0022）で未処理 inbox を集めた上で `propose.generate`（`mode=inbox_triage`、Phase 12 H4 で追加された dispatch key、ADR-0016 改訂 §決定 (l)(b)）に投げ、候補を host LLM がユーザーに提示する。ユーザーが個別に承認したものだけを `propose.apply`（Phase 12 H1 で MCP に露出、`WriteCategory.PROPOSE_APPLY`、`read_only=false` + `idempotent=true`）で durable state に書き戻す。 `reply-draft` と対をなす HITL write skill。集合 (inbox 全体) を扱う点で `source-extract`（個別 source 1 件）の pair。 ## 何が起きるか 1. ユーザーが「受信箱整理して」「inbox 仕分けて」「未処理アイテム捌いて」のように頼む 2. ホストが本 skill を発火 3. ホストが `inbox.list` で未処理 (`state=open`) item を集める 4. ホストが `propose.generate`（`mode=inbox_triage`、`topic` = inbox 要約）を呼び、各 item に対する候補 (task / decision) を生成 (`ProposalGenerated` event を durable log に書く) 5. ホストが候補をユーザーに整形して提示 6. ユーザーが個別に承認した候補のみ `propose.apply` で保存（HITL、idempotent） opshub 側で外部 SaaS に通知 / 投稿する経路は **存在しない**（ADR-0010 §禁止事項 7）。 ## 呼び出し順 ### Step 1: 未処理 inbox を列挙 ```text tool: inbox.list input: state: "open" limit: 50 ``` 戻り値の `items[]` から「処理が必要そう」なものを host LLM が判定する。期間で絞りたい場合は `created_after` / `created_before`（ISO 8601、`inbox_items.created_at` 半開区間、Phase 12 H1 で追加）を併用する。 ### Step 1b (Phase 18-C、補強): Slack demand 信号で priority 順を補強する Slack 由来の mention / DM は既に Phase 7 connector 経由で取り込まれているため `inbox_items` ではなく `sources` 行として存在する (`source_type=slack_message`)。とはいえ「自分宛に未処理で残っている mention / DM」を inbox の triage 候補と並べて確認したい場合は、`slack.demand.list` を補助的に呼んで priority 順位を補強できる: ```text tool: slack.demand.list input: dem