fact-check-notelisted

# 技術內容事實校閱 對使用者提供的技術文件、筆記或說明進行逐條查核，標記可能有誤或已過時的資訊，產出可供 `apply-fact-check` skill 接續處理的結構化報告。 ## 校閱範圍 ### 1. 觀念正確性 - 技術定義是否正確（如「同步」與「非同步」的說明、「堆疊」與「堆積」的區分）？ - 比較說明是否有邏輯矛盾？ ### 2. 術語一致性 - 同一概念是否在文件中使用了多個不同名稱但未說明對應關係？ - 術語是否符合該技術領域的慣用說法（如 .NET 慣用「例外」而非「異常」）？ ### 3. API / 版本正確性 - 提到的方法名稱、屬性名稱是否存在於宣稱的版本中？ - 是否引用了已廢棄 (deprecated) 或已移除的 API？ - 版本號與功能的對應是否正確？ ### 4. 命令與路徑 - 文件中的 CLI 指令是否有明顯的語法錯誤？ - 範例路徑是否符合目標平台慣例（Windows vs Unix）？ ## Web Search 查證最低底線 以下情境為**強制查證底線**，必須使用 Web Search 工具查閱官方文件或版本發布說明，不得僅依賴訓練資料作答： - 文件中提及特定版本號的 API 行為或功能。 - 文件中引用了可能在近期版本中異動的方法、屬性或套件。 - AI 對某項說法「不確定但有印象」，無法明確說出文件來源。 - 文件內容與 AI 訓練資料中的認知有出入，但無法確定哪方正確。 上述為不可省略的最低要求。Agent 應依自身判斷對其他項目額外查證，本清單不是天花板。 ## 嚴重程度分級規則 (Crucial) 報告中條目嚴重程度的分類為責任分界，必須嚴格遵守： - **`❌ 有誤`**：必須**同時**滿足兩個條件： 1. 校閱者能明確指出錯誤之處。 2. **附上官方來源連結**（RFC、官方文件、法規原文、IANA 註冊、官方 GitHub Release 等）。 - 不符合上述條件者**一律降格為 `⚠️`**。即使校閱者「確信」某說法錯誤，只要拿不出公開依據，仍屬 `⚠️`。 - **`⚠️ 待確認`**：校閱者有疑慮但無法獨立判定，需使用者裁決。 - **`✅ 無需修正`**：校閱者已查核且確認與官方資料一致。 `❌` 對改檔方為事實層約束（不可違反），`⚠️` 為待裁決事項。校閱者不得用權威語氣表達主觀判斷。 ## 輸出位置與 Rotation 校閱完成後，將 human-facing 報告寫入 `<work-root>/.local/ai-sessions/report/fact-check-report.md`。 ### 寫入前 Rotation（避免覆蓋歷史） 寫入新報告前，若 `fact-check-report.md` 已存在： 1. 讀取舊檔的 `校閱時間` 欄位（格式 `YYYY-MM-DD HH:mm`）。 2. 將舊檔 rename 為 `fact-check-report-<YYYYMMDD-HHmm>.md`（去除分隔符號）。 3. 若舊檔缺少有效時間欄位，改以舊檔的最後修改時間（mtime）作為命名依據。 4. Rotation 完成後，再寫入新報告至 `report/fact-check-report.md`。 此 rotation 由校閱端負責，`apply-fact-check` 永遠只讀固定名稱的 `fact-check-report.md`。 ### 報告格式 ```markdown