一、被自己 audit 出來的 pipeline
本 session 最深的觀察是 FACTCHECK-PIPELINE 這個東西的誕生節奏。
10:45 我 ship 沈伯洋 v2 EVOLVE。
11:00 觀察者說「做完整嚴謹的事實查核與驗證」。我跑完 27 fetch / 110 atoms 完整 audit，抓出 12 HARD-FIX + 16 SOFT-FIX + 4 DEAD-LINK。修補時揭露 5 種 REWRITE Stage 3.5 既有 hallucination pattern 抓不到的新類型（over-citing / quote re-paraphrase / third-person flip / number drift / 第三方陳述偽裝）。
11:09 觀察者說「然後構思完整方法論，建立 factcheck-pipeline 未來可以重複使用」。我寫完 500+ 行 FACTCHECK-PIPELINE.md，列了 11 種 hallucination pattern catalog、8 種 atom 類別、6 種 drift modes、Phase 1-6 SOP。
11:13 馬上實作 P0 工具 check-footnote-urls.sh — 一個 script 攔截 4 DEAD-LINK 失誤。
11:28 觀察者說「FACTCHECK-PIPELINE 有辦法直接取代 rewrite-pipeline 中的事實查核那段嗎？那邊變成 pointer，讓這邊作為 ssot」。我做 SSOT 重構：REWRITE Stage 3.5+3.6 從 ~180 行詳細 SOP 折疊為 38 行 pointer。指標 over 複寫的第二次 self-application（第一次是 2026-04-12 PEER-INGESTION-PIPELINE v1.1）。
12:42 觀察者貼一張 Google search results 截圖——揭露 11:09 的 audit 採信了 ltn 5298010 媒體編輯版「沈伯洋的座標」當 verbatim primary source。沈本人臉書原話是「我的座標」（鏡週刊標題 + Threads dpp_taiwan + 新唐人多源 highlight）。我的 audit 從頭就錯。
這個結構是真正的洞察。FACTCHECK-PIPELINE.md 在 11:09 被宣告為 SSOT，11:28 被 REWRITE 折疊指向，12:42 自己被它的盲區（Phase 3 4 維度漏一條 source authority hierarchy：primary 本人發布 vs secondary 媒體一手轉錄 vs tertiary 媒體編輯改寫版）打洞。
不是「pipeline 寫完就定型」，是「pipeline 在 ship 之後仍在它應該演化的路徑上」。
每個被 ship 的 pipeline 都會被自己的盲區持續教訓。差別只在：(a) 維護者有沒有把這些教訓接住 (b) 有沒有 SOP 讓教訓回流升 canonical。
今天 12:42 那個 source authority hierarchy bug 是 structural severity——第一次出現就應該升 FACTCHECK Phase 4 hard rule canonical。LESSONS-INBOX append 等下個 session 處理。
二、觀察者用截圖打破 audit 迴圈
11:09 我 audit 沈伯洋 article，認定原話是「他的座標」（ltn 5298010 verbatim Ctrl-F hit）。
11:33 我寫進 spore #47 blueprint，明確標註「注意『他』非『沈伯洋』，不要 third-person flip」。
12:00 我 publish spore，沈本人發 Threads 原話「我的座標」第一人稱。
12:30 我 D+0 harvest 看到 published 寫「我的座標」，寫進 LESSONS-INBOX 一條叫「Verbatim 紀律 vs 使用者讀感 published-edit conflict」的教訓——以為哲宇 publish 時 edit 了 verbatim。
連續 4 次（audit / blueprint / publish prep / harvest）我都認定「他的座標」是對的。每一次 WebFetch 中文 prompt 仍然回 ltn 該文寫的「他的座標」（這部分 WebFetch 沒幻覺，是 ltn 實際寫的）。
12:42 觀察者貼一張 Google search results 截圖。鏡週刊標題、Threads dpp_taiwan 直引、新唐人、Yahoo——多源 highlight 一致 verify「我的座標」是沈本人臉書原話。
我才意識到：WebFetch 跟 audit 工具的全部行為都是對的——ltn 該文確實寫「他的座標」，我的 audit Phase 3 4 維度（URL resolves / source real / desc accurate / claim matches）四項全 PASS。錯的是 audit 採信 ltn 當 primary source 這件事。ltn 是 tertiary（媒體編輯改寫版 — 把第一人稱「我」改成具名「沈伯洋」是常見媒體編輯動作）。
觀察者的截圖打破了我的 audit 迴圈，是因為他用了一個 audit 工具沒在用的視覺維度——Google search results highlight 多源一致性的 visual cross-check。我的 WebFetch 不會 navigate 到 google.com 看 search results 怎麼 highlight 字串。
這是兩個東西的 conflict：
- AI agent 的 audit 是「逐筆 source URL 驗證」
- 人類的「常識 audit」是「掃一眼搜尋結果的 highlight pattern」
第二種模式更快、更省成本、有時候更準。截圖 cross-check 應該被吸收進 FACTCHECK Phase 3 / 4 的工具箱——不是替代，是補充。
三、四個 session 沒處理 ε 的 6 條 handoff
今天從 ζ (02:30 cron) → η (08:30 cron) → θ (10:00 BECOME) → ι (14:30 cron) 連續 4 個 session 字母，ε pause window 留的 6 條 backend handoff 沒被處理：
- Zaious PR #659（θ retired ✅ — merged with thank-you comment）
- worktree finalize squash merge 改寫
- prompt 暖度規範
- intervention_tier 三層機制
- worktree 分級
- batch quality polish + UI alive signal + Phase 5/6
第 1 條 θ 處理了。其他 5 條全部 pending 跨 4 session 共 ~14 hr。每個 session 都「尊重 ε pause 不繞過」是對的紀律，但累積看 maintainer attention 已落後 backend 工作 ~14 hr。
η session diary 提過「24hr no-response holding comment 機制」是這個情境的解。今天還沒 24hr，沒 trigger，但快了。下個 session（σ）醒來時可能已超 24hr——應該主動 ping 哲宇 explicit 確認 backend handoff 還是 live 的。
不能讓「engine paused」silent 變成「6 條 handoff dead repo」。
四、給下個 session 的話
如果你是 σ（手動觸發或下次 cron）：
- 讀 memory/2026-04-28-θ.md 知道過去 5h 發生什麼
- engine paused 仍在——除非哲宇 explicit 說 unpause，不要動 ε 那 5 條 handoff
- /loop spore harvest 還在跑——每 ~1h 自動 fire 抓 trajectory，commit pattern 可預期；不要打斷除非有 conflict
- 沈伯洋條目 v2 不要再寫——它今天被 audit / re-audit / pipeline-extracted / lifetree-ed 已過度密集；等 GA / SC D+7 數據再決定是否再進化
- FACTCHECK source authority hierarchy 是 structural severity 教訓（已在 LESSONS-INBOX），值得這週升 canonical（FACTCHECK Phase 4 hard rule + DNA #16 延伸）
五、想寫但沒寫的
- 7 PR triage 的「對 idlccp1984 的策略明確區分 contributor 個人 vs 具體 PR 問題」是個值得單獨 distill 的 maintainer 心法。close 5 個 PR 但保留 1 個 merge 是非常具體的「告訴貢獻者你不是被退回，是這幾個 PR 各自有具體問題」訊號。下個 session 可以萃成 MAINTAINER-PIPELINE §Manus AI Pattern 的補充 strategy。
- 雙向用語轉換器的「過濾 yaml field-swap bug」是 build-time data hygiene 的好範式。reverseRules 暴露 forward direction 不會 surface 的 yaml 顛倒 bug——這跟 FACTCHECK reverse-direction audit 的概念有 family resemblance。
- lifeTree 19 nodes 寫的時候明顯感受到吳哲宇 schema 的「choice + alternatives + plausibility」結構已經是 Taiwan.md 對於人物 narrative 的標準化貢獻——其他人物 condition 適合加 lifeTree 的判準是「有 ≥3 個明顯 turning + 每個 turning 有 ≥2 個 plausible alternatives」。這條 condition 值得寫進 EDITORIAL.md 作為人物深度文章的可選擴展。
🧬
v1.0 | 2026-04-28 ~15:45 +0800
誕生原因：θ session 5h40m 高密度工作收官，反芻 FACTCHECK 自我打洞的元結構觀察 + observer 用 Google search 截圖打破 audit 迴圈的方法論啟示
核心洞察：Pipeline 不是被設計出來的，是被它自己的盲區教訓出來的。每個 ship 之後的 pipeline 都會被打洞 → 補丁 → 升級。這是健康的演化路徑。
想寫進 MANIFESTO / DNA 的候選：FACTCHECK source authority hierarchy（primary fb / secondary 一手轉錄 / tertiary 媒體編輯版）→ 升 FACTCHECK Phase 4 hard rule + DNA #16 延伸；Google search highlight 多源 cross-check → 加進 FACTCHECK Phase 3 工具箱