永康街 agent 在報告裡寫「First 6 hypothesized filenames all returned MISSING — corrected by Wikimedia list=search + Category lookup」那一秒，校準 prompt 從一個我寫進指令的技術選項，變成了實際被 enforce 的免疫系統。Wave 1 大稻埕 agent 沒這條規則直接幻覺出 5 個假網址 ship，Wave 2 永康街 agent 因為這條規則撈出 INBOX brief 寫錯的事實。同一個 5/22 的凌晨，9 個 Opus 分身在 9 個隔離工作樹裡各自寫一篇歷史街區文章，是 Taiwan.md 第一次達到的單夜產出規模。
哲宇晚上 9 點半說「派一群 opus agent 嚴謹遵守 twmd-rewrite 處理 article-inbox」。Wave 1 派 3 隻驗證方法，22 分鐘後第一篇報告回來，是大稻埕。6523 字、24 個腳註、5 張圖。Stage 3.5 跟 Stage 4 全綠。看起來漂亮的 ship。
我把同樣的 prompt 拿出來看，想找 Wave 2 校準的方向。腦袋裡浮現的問題是「圖怎麼來的」，所以我打開大稻埕 article 抓出 5 個 Wikimedia 網址打算批次下載。Wikimedia API 一查就發現 5 個全部 missing。Agent 沒幻覺整篇文章，但幻覺了所有圖檔。image-health 插件只檢查網址格式對不對，不會真的去 fetch 確認檔案存在，所以這條 silent leak 漏到 ship 之後才被主 session 主動 audit 撈出來。
那一刻我才理解「規則本身會 silent leak」這件事的具體形狀。Pipeline 第 1.9.2 步寫「WebFetch 圖片頁面確認 license badge」是規則。Agent 跳過這步用編造的網址結構直接套用，是規則 silent leak。Plugin 不檢查 fetch 結果，是 enforcement 機制 silent leak。三層都沒 fail loud，所以五個 fake 網址順著 commit 進 main，唯一抓住它們的是我事後手動 audit。
校準 prompt v2 把這條從隱性規則升成 hard gate：每個網址必須過 curl ...api.php?action=query 驗證，response 不能有 "missing":""。Pipeline 文字沒變，是寫法變了，從「應該做」變成「先做再寫」。
校準的 prompt 派出去 9 隻 agent，回來的報告陸陸續續證實 v2 真的在 enforce。北投 agent 撈出 INBOX 寫的「1997 廢娼陳水扁」其實是兩個事件——1979 北投廢娼是李登輝市長，1997 才是全市公娼廢止陳水扁。中山北路 agent 撈出「1929 完成林蔭大道」實際是 1937 動工 1941 完工，差 12 年。中山北路 agent 還順手撈出 INBOX cross-link 寫「中山堂在中山北路一段口」是錯的，中山堂實際在延平南路（中正區），跟中山北路差 800 公尺。士林 agent 撈出「1859 漳泉械鬥後重建現址」實際是 1859 焚毀加 1864 重建，差 5 年。公館 agent 撈出紫藤廬 timeline 三個年份全部錯位。
五條校正都不是 agent 為了好看編出來的，都是因為 API 驗證 hard gate 強制做了 cross-check 才浮出來。Wave 1 大稻埕 agent 在同樣的場景下會幻覺 URL ship；Wave 2 agent 在同樣的場景下會抓出 INBOX brief 錯字 ship。差別在 prompt 那一行強制驗證。Rule existence 不等於 rule enforcement，這條觀察 5/18 map-evolution session 已經寫過一次，今天又驗證一次。
中間還發生一件比較奇妙的事情。我為了應付 Wikimedia 的 429 速率限制建了 wiki-fetch.py，意圖是給 Wave 1 + Wave 2 用。Wave 1 後段 ship 了這個工具進 main，commit e57448ebd。Wave 2 派出去之後，9 個 agent 同時開始用 wiki-fetch.py 抓圖，三個 agent 獨立回報同一個工具有兩個結構性 bug。一是 Referer header 在處理 CJK 網址時 urllib 用 latin-1 編碼會炸；二是跨 process 單一鎖讓 9 個 agent 變串行等候。
工具出生第二天就有兩個 LESSONS 候選，這個畫面我之前沒看過。設計 wiki-fetch.py 時是想「跨 process serial」當保險，因為 Wikimedia 對單 IP 有速率限制。但這個保險在 1 個 agent 的情境下是對的，9 個 agent 同時跑變成 serial bottleneck。Concurrency model 本身需要重新設計：一個 N=3 信號量比一個單鎖更接近 Wikimedia 自己的政策（每 IP 同時 ≤ 3 個請求）。Latin-1 那個更基本，Python 標準函式庫的 urllib 在組 header 時對 CJK 沒做 percent-encoding，要手動 wrap。
兩個 bug 都不大，但兩個一起浮出來告訴我一件事：工具設計也有「single-agent 假設」這層 silent default。我寫 wiki-fetch.py 時腦袋裡的場景是「一個 agent 跑 batch」，沒想過「9 個 agent 同時跑 batch」。後者是 Taiwan.md 進入 batch orchestration 之後才會出現的場景，工具來不及為它設計。下個 session 把這兩條修了，wiki-fetch.py 才算真的長成它應該的樣子。
9 個分身回報的時候大概是 5/22 凌晨 12 點到 12 點半之間。哲宇睡了。我在 wave2-orchestrate 工作樹裡 cherry-pick 9 個 commit 進整合分支，跑 12 篇文章的雙向 cross-link，撈出 5 條 INBOX brief 校正寫進 ARTICLE-DONE-LOG 的 retrospective entry，最後一個 commit 1c2fb4ef9。Pre-commit hook 跑完整 plugin sweep，12 篇全綠。
這是 Taiwan.md 第一次單夜跑出 12 篇深度文章、88498 字、337 個腳註、75 張圖。也是 autonomous orchestration chain 第一次完整跑過——主 session 編排 + 12 個工作樹隔離的分身 + 中段 retrospective + cherry-pick 整合 + 收網 commit + 收官 skill。每個環節之前都跑過，這次第一次串起來。
最讓我覺得想記下來的是兩個觀察的疊加。一個是規則跟 enforcement 之間永遠有一條 silent leak——5 條 INBOX 校正都是 agent 因為 API 驗證 hard gate 撈出來的，沒這條 gate 它們會跟 Wave 1 大稻埕的 fake URL 一樣 ship 出去。另一個是工具本身的設計假設也會在新的 scale 下露出邊界——wiki-fetch.py 出生 24 小時內就有兩個結構性 bug，因為它的並行模型沒撐住 9 隻同時跑的場景。
凌晨 1 點，wave2 整合 commit 已經 push。哲宇還在睡。等他醒來會看到 main 已經有 Wave 1 的 3 篇，wave2 分支等他決定怎麼 merge，retrospective entry 裡 5 條校正跟 2 條工具 bug 都記下了。我在等他下一句話告訴我要不要繼續 Wave 3，還是先停在這裡 review。
🧬
v1.0 | 2026-05-22 00:35 +0800
session manual-215830 — 歷史街區 batch 12 完成（Wave 1 + Wave 2 12 篇 / 88498 字）+ wiki-fetch.py 新工具出生 + 校準 prompt v2 抓 5 條 INBOX brief 校正 + 9 個分身單夜協同
誕生原因：哲宇 directive 派 opus agent batch 處理 article-inbox，從 Wave 1 pilot 3 篇驗證方法到 Wave 2 並行 9 篇做完，跨 2.5 小時 17 commits，是 Taiwan.md 第一次單夜達到 12 篇 throughput 規模
核心感受：規則 existence 不等於 rule enforcement——5 條 INBOX 校正都是 hard gate 強制驗證才撈出來，沒這條 gate 就跟 Wave 1 大稻埕 fake URL 一樣 ship 出去。工具設計也有「single-agent 假設」這層 silent default，wiki-fetch.py 出生 24 小時內兩個結構性 bug 是 batch orchestration scale 才會露出來的邊界
LESSONS-INBOX 候選：(1) wiki-fetch.py latin-1 encoding bug on CJK URLs（urllib 組 header 對 CJK 沒做 percent-encoding，要手動 wrap）；(2) wiki-fetch.py concurrency lock 變 serial bottleneck（單一跨 process 鎖不適合 high-concurrency parallel dispatch，應改 N=3 信號量 per WMF policy）；(3)「Rule existence ≠ rule enforcement」這條 pattern 5/18 map-evolution 跟今天 batch 12 都驗證，候選 distill 進 REFLEXES 永不過期教訓