📚職涯停看聽・知識庫← 總部儀表板
📅最後更新：2026/04/29
📑 目錄

RCF-027 — 壓縮接續規則新增旗標清除步驟（IMP-089 升規）

類型：規則變更 日期：2026-04-29 觸發條件：條件 1 — 修改 HARD STOP 規則（上下文壓縮後強制接續規則新增步驟 0） 相關文件：

  • CLAUDE.md（主文件，⛔ 上下文壓縮後強制接續規則）
  • knowledge/improvements.md（IMP-089 狀態更新）

問題背景

觸發事件：2026-04-29 Session 76 補讀 continuation

在 Session 76 的工作進行中發生 context compression，下一 session 接續時發現 scripts/_pending.flag 仍存在，導致 Edit/Write 工具全面被 query-gate-hook.py 阻擋，需手動 rm _pending.flag 才能繼續。

根本原因分析：

  • _pending.flag 的設計生命週期：兩段式查照開始 → 旗標建立；Tim 說「執行」→ 旗標清除；收尾七件事 → 確認清除
  • Context compression 是「強制截斷」，不經過收尾流程，旗標因此殘留
  • 現有壓縮接續規則（HARD STOP）只要求讀取 tasks.md + 輸出查照格式，未包含旗標狀態確認

已有相關 IMP（均為「授權詞辨識」問題，非「壓縮殘留」）：

  • IMP-031、032、037（授權詞格式導致旗標未清除）
  • IMP-057（純 URL 豁免規則）
  • IMP-071（A/B 授權詞範圍）
  • IMP-089（本次）：壓縮截斷後殘留，屬新模式

考慮過的方案

方案 描述 優點 缺點 採用？
方案 α 收尾七件事 Step 0 新增「確認並清除 _pending.flag」 防止對話結束時殘留 只解決正常結束情境，壓縮截斷仍殘留（壓縮不走收尾） ❌ 未採用（不夠根治）
方案 β（最終採用） 壓縮接續規則的強制執行，新增步驟 0：進入接續 session 時先清除旗標 直接在問題發生點解決；壓縮接續規則是 HARD STOP，執行保證率高；實作成本最低（只改規則文字） 需要 Claude 記得這條規則 ✅ 採用
方案 γ query-gate-hook.py 加入時效性機制（旗標超過 N 分鐘自動失效） 最根治，完全不依賴 Claude 記憶 需比較 file timestamp，hook 複雜度增加；N 值難以確定（壓縮可能發生在幾秒到幾小時後） ❌ 未採用（實作成本高，邊界值難定）

最終決策

採用方案 β：在壓縮接續規則的「強制執行」清單中，插入步驟 0（原步驟 1-4 順延）：

0. 清除殘留旗標：確認 scripts/_pending.flag 是否存在
   → 若存在，立即執行 rm 清除，再繼續後續步驟
   WHY：context compression 是強制截斷，不經過收尾流程，
       旗標若殘留將導致下一 session 的所有 Edit/Write 工具
       全面被 query-gate-hook.py 攔截，無法執行任何修改

選擇 β 而非 γ 的理由：

  • 問題發生頻率低（context compression 不常見），不值得為此增加 hook 複雜度
  • 壓縮接續規則本身是 HARD STOP，執行保證率等同於旗標清除的保證率
  • 方案 γ 的 N 值無法確定（短壓縮 vs 長時間暫停的旗標都可能是合法殘留或誤殘留）

選擇 β 而非 α 的理由：

  • α 只防「正常結束後殘留」，但問題的觸發點是「壓縮截斷」，α 完全不解決這個情境

影響範圍

影響類型 具體項目
修改文件 CLAUDE.md — 壓縮接續規則「強制執行」新增步驟 0 + 「禁止」新增一條 + 快速索引表說明更新
版本號更新 CLAUDE.md v1.1 → v1.2（Condition 1 觸發）
新增文件 knowledge/decisions/RCF-027-pending-flag-compression-residual.md（本文件）
狀態更新 knowledge/improvements.md IMP-089 狀態：⏳ → ✅ 已升規
觸發部門同步 無（Grep 確認：壓縮接續規則僅在主 CLAUDE.md 中定義，無部門引用）
影響的 SKILL 無直接影響（接續後的 SKILL 執行不受影響）

驗證方式

下次 context compression 後的接續行為：

  1. Claude 接續時，第一個動作是 ls scripts/_pending.flag（或等效確認）
  2. 若存在 → 執行 rm → 再讀 tasks.md
  3. 若不存在 → 直接讀 tasks.md（跳過清除步驟）
  4. Edit/Write 工具不應在接續的第一步被阻擋

判斷機制有效的信號：

  • 下一次 context compression 後，Session 能直接進入讀取 tasks.md，無需手動介入清旗標
← 返回 決策記錄