RCF-032：CLAUDE.md 收尾自查掃 inbox HARD STOP（39-B 短期閉環）
建立日期：2026-05-01 觸發條件：1（修改 HARD STOP 規則：收尾七件事步驟 6） 狀態：✅ v1.0（試行期 3 對話） 產出依據：RCF-031 LINE AI 助理 Brief Section 1.3 閉環機制決策；缺口 39（設計目的層 — inbox 寫入後無人讀 = 整套系統無意義）；Session 81 五輪追問收斂
Section 1：升規前狀態
主 CLAUDE.md 收尾七件事步驟 6（對話品質自查）共 4 子項：
- 規則違反掃描
- 改善追溯完成確認
- improvements.md 主動掃描（IMP-007/IMP-017/RCF-015 升規）
- client-patterns.md 新增確認
- 下次對話需注意事項
Section 2：升規後狀態
新增第 4 子項「inbox.md 主動掃描」（原第 4-5 順移為第 5-6）：
- inbox.md 主動掃描：Read knowledge/inbox.md →
計算「待處理項目」區塊內 `- [ ]` 條目數 N →
- N = 0：寫「inbox 已清空 ✅」（單行即可）
- N > 0 且 ≤ 10：列出所有未處理條目（含寫入日期/原始描述）+ 提報「inbox 累積 N 條，是否本次處理？（回應：處理 / 跳過 / 處理第 X-Y 條）」
- N > 10：列出最舊 5 條 + 提報「inbox 積壓超過 10 條（共 N 條），建議觸發「整理知識庫」SKILL 完整路由」
> ⛔ WHY：inbox 是手機/電腦端隨手記下的待處理佇列（RCF-023 建立），若無收尾掃描機制 → 寫入後永遠被遺忘 → 整套 inbox 設計失去意義（缺口 39 設計目的層）。每次對話收尾掃 = 短期閉環方案 39-B；中長期升級 39-A（GitHub Actions 排程）見 RCF-031 Phase 5。
> 不可省略：inbox.md 不存在 → audit-log.md 記錄為異常 + 寫「⚠️ inbox.md 不存在（異常），已 audit-log」；無法 Read → 寫具體錯誤訊息，禁止跳過。
> Tim 回應分支：「處理」→ 收尾七件事完成後啟動「整理知識庫」SKILL Step 6 路由（不打斷當前收尾）；「跳過」→ 不動；「處理第 X-Y 條」→ 收尾後只路由指定條目，其餘保留。
> 同對話自我發現：條目時間戳 = 本對話 → Claude 主動標「本對話新增」方便辨識（避免 Tim 困惑「這條我什麼時候寫的」）。
Section 3：WHY（設計目的層）
問題本質：本案目的是「inbox 不被遺忘」（RCF-023 建立的稽核基礎建設 + RCF-031 LINE AI 助理閉環設計）。若無收尾掃描機制 → inbox 寫入後 Claude 不會主動讀 → Tim 仍需主動觸發「整理知識庫」SKILL → 對「Tim 容易遺忘」的核心問題零幫助。
RCF-031 缺口 39 原文：「LINE Bot 寫入 inbox.md 後，Claude 何時讀？若 Tim 不觸發 → inbox 永遠堆積 → 失去意義 → 整套系統無意義」
閉環方案分層：
- 短期 v1.0（本 RCF）：39-B 每次對話收尾自查時 Claude 主動掃 inbox 提報（規則層升規，零開發成本）
- 中長期 v1.1+：39-A GitHub Actions 排程每日 07:00 自動讀 inbox + Gemini 分類路由（RCF-031 Phase 5 衍生 P3）
Section 4：規則文字最終版
詳見 Section 2，已在主 CLAUDE.md 步驟 6 第 4 子項升規。
Section 5：17 部門同步策略結果
| 部門 | 收尾步驟 6 寫法 | 是否需要 Edit |
|---|---|---|
| content / crm / edu / finance / hr / product / security / strategy / business / legal / social / dev / knowledge（13 個） | 「⛔ 對話品質自查（HARD STOP）— 輸出格式詳見總部 CLAUDE.md」引用形式 | ❌ 自動繼承，不需 Edit |
| growth | 「⛔ 對話品質自查（HARD STOP）」簡化標題（無格式定義） | ❌ 自動繼承，不需 Edit |
| audit/internal + audit/external | 無收尾段落（稽核部門 CLAUDE.md 結構不同，聚焦稽核規則本身） | ❌ 不適用 |
| marketing | 已棄用（2026-04-11 解散，職能移轉至 content + social） | ❌ 不需動 |
結論：0 部門需要 Edit，主 CLAUDE.md 升規後 16 個現役部門 CLAUDE.md 全部自動繼承。
Section 6：與既有機制整合
6.1 收尾掃描 vs「整理知識庫」SKILL 兩層分工
| 觸發 | 處理規模 | 處理方式 |
|---|---|---|
| 每次對話收尾（本 RCF） | ≤ 10 條 | Claude 主動列出 + Tim 即時決策（處理/跳過/部分） |
| 「整理知識庫」SKILL（RCF-023） | 任意條數（積壓多時用） | Step 6 完整路由（八維分析建議 / 品牌分析觸發 / D1-D5 分類 等） |
Tim 容易混淆點：「為什麼有兩個機制都處理 inbox？」答：收尾掃描 = 即時提醒 + 小量處理；SKILL = 完整路由。N > 10 時收尾掃描自動建議觸發 SKILL，閉環健康。
6.2 inbox 條目 vs tasks.md 條目邊界
| 文件 | 性質 | 條目格式 |
|---|---|---|
dev/tasks.md |
已分類正式任務（有優先級 P1-P3） | - [ ] P1/P2/P3：[任務描述] |
knowledge/inbox.md |
未路由的快速捕捉（待分類） | - [ ] [內容] // [說明] |
轉換流程：inbox 條目 → 收尾掃描 / SKILL 路由 → 若升為任務則寫入 tasks.md（含優先級）；若屬學習資源則八維分析 → 知識庫存檔。
6.3 與 IMP-007 / IMP-017 / RCF-015 既有閾值機制關係
本 RCF-032 「inbox.md 主動掃描」與既有「improvements.md 主動掃描」屬同一族（Read + 掃描 + 條件性提報）。格式對齊一致：
- 都需展示「當前狀態」（improvements 展示最後 IMP 編號 / inbox 展示條目數 N）
- 都禁止「無新觀察就跳過寫」（必須明寫「無 / 已清空」）
Section 7：不觸發場景
- inbox.md 不存在：audit-log.md 記錄為異常 + 收尾自查寫「⚠️ inbox.md 不存在（異常），已 audit-log」；不阻擋收尾繼續
- N = 0：單行「inbox 已清空 ✅」即可，不展開列表
- Read 失敗（檔案損毀 / 權限錯）：寫具體錯誤訊息，禁止跳過或假裝清空
Section 8：升規效果預估
| 指標 | 變化 |
|---|---|
| 收尾步驟 6 子項數 | 4 → 5（新增 inbox 主動掃描） |
| 每次對話收尾額外負擔 | 1 個 Read（< 1 秒）+ 條件性輸出（N=0 時 1 行 / N>0 時依條目數） |
| Tim 體驗 | inbox 寫入後不再被遺忘；同對話內新增條目當下提醒 |
| 對 inbox.md 既有 schema 影響 | 零（採 RCF-023 既有 - [ ] / - [x] 行內 list 格式） |
Section 9：3 對話試行期 + 觀察點
試行期：本 RCF v1.0 上線後前 3 對話收尾後，Claude 主動評估：
- 掃描動作是否冗長（影響 Tim 收尾體驗）？
- Tim 回應是否流暢（處理/跳過/部分指令是否清晰）？
- inbox 條目是否有效路由（無重複提報、無遺漏）？
觀察記錄位置：dev/audit-log.md（試行期間每次對話收尾簡短記錄）
升規條件：
- 3 對話全部順暢 → 維持 v1.0
- 1+ 對話發現問題 → 升 v1.1（修正 RCF-032 + audit-log 記錄理由）
Section 10：執行記錄
| 日期 | 動作 | 備註 |
|---|---|---|
| 2026-05-01 | RCF-032 v1.0 建立 + 主 CLAUDE.md 步驟 6 升規 | Session 81，五輪追問 16 缺口處理；0 部門需 Edit（自動繼承） |
| 待定 | 試行期觀察結果 | 3 對話後 audit-log 評估 |