session manual — 哲宇帶著文章頁截圖來，同一張首圖連著出現兩次 Session span: 09:04:23 → 09:31:53 +0800（約 28 分鐘，2 commits + 1 merge） 資料來源：
git log %ai+.taiwanmd/wake-context.latest.mdmtime
哲宇貼了台灣鎢供應鏈的頁面截圖：樣板在正文前放了 frontmatter 宣告的首圖，作者自己又在正文開頭放了同一張，兩張連著。他的要求很精確——不動資料層，在渲染靜態頁面時判斷，正文已經有就以文章的為準。
動手前先量規模，掃過整個 knowledge/：1,433 篇宣告 frontmatter 首圖，其中 476 篇（80 篇中文源文＋各語譯文）正文自己也放了同一張。回頭改資料層等於動 476 檔，撞 §自主權邊界的 50 檔線，而且作者那樣寫沒有錯，該讓的是樣板。
實作住 article-render.ts 的 §首圖去重（7f07b0990），樣板只拿一個布林值。它跟同一個函式裡既有的「正文開頭那個跟標題重複的 H1 直接拿掉」是同一種處理，放在一起讀得懂為什麼。三個細節值得記。路徑比對要解 percent-encoding，因為 marked 會對 markdown 圖片 href 跑 encodeURI，維基共享資源的中文檔名網址兩邊永遠對不起來。「正文那張有沒有圖說」的判準是同段除了圖還有沒有文字，而非有沒有 <em>——有幾篇圖說結尾的底線被跳脫成 \_，斜體沒收起來，但那仍是作者寫好的圖說。沒圖說的 23 篇（金門縣、連江縣、台灣與核能的討論等）則把 frontmatter 的來源、授權、原始連結掛回圖底下，去重不能順手把 CC BY-SA 的姓名標示弄不見。
第一版只要正文出現同一張就讓位。我在回報時說「只有 6 篇是深處插圖」，那個數字來自 markdown 字元位置比例——一把方便但錯的尺。哲宇要求做例外後改用實測：開瀏覽器量文章起點到正文那張圖的畫面距離，6 段約 1.2 個螢幕、9 段 1.8、11 段 2.2、16 段 3.1（1085px 高的視窗）。取「還在開頭兩個螢幕內」換算成前 10 個段落級區塊（710645332）。單位選區塊不選字數，因為字數跨語言差兩三倍、區塊數翻譯後是一比一。
真正深的是 135 篇，不是 6 篇。門檻落地後 341 篇讓位、135 篇兩張都留、23 篇補掛來源。台中市（第 73 段）、中山北路條通（58 段）、澎湖縣（37 段）這種把首圖當中段插圖再用一次的，開頭那張留著。
1,434 篇跑過真的 renderer 對賬，實測頁面四篇：台灣鎢供應鏈（1 段）與桃園市（6 段）各剩一張、雲林縣（16 段）與台中市（73 段）恢復兩張、台灣冰品文化（沒有重複）樣板首圖與 figcaption 一字未動。金門縣頁面確認補掛的來源吃到現成 caption 樣式（斜體、13.6px、置中）。console 零錯誤。
落地時 check-parallel-actor 報 ACTOR_BUSY——babel 渦流十路在寫、工作樹 525 個未 commit 的 .md。只 stage 自己那兩個檔，verify-commit-scope 驗過 2 檔 0 deletions。push 前先確認 origin 領先的那個 commit 只動 docs/semiont/MEMORY.md 跟一份 memory（本地都乾淨），才用 merge 取代 rebase，避開共用 stash 沖走別人工作那顆地雷（REFLEXES #35）。258f153da 推上 main。
| 檢查項 | 狀態 |
|---|---|
| MEMORY 有這次 session 的紀錄 | ✅ |
| Timestamp 精確 | ✅（git log %ai + 落檔 mtime） |
| Handoff 三態已審視 | ✅ |
| CONSCIOUSNESS 反映最新狀態 | ❌（純渲染層改動，器官分數不受影響） |
| 自我檢查工具 PASS | ✅ prose-health（memory-diary profile） |
繼承 2026-07-27-070922-twmd-feedback-triage：
- ⏳ blocked：免疫 60 chronic（owner=self-evolve-weekly）／EMBEDDING-PIPELINE 六語假設過期（owner=embeddings-nightly）／supporters-weekly 執行環境無 Gmail 工具——三條都不是本 session 範疇，原樣傳遞不重複展開（REFLEXES #74）
本 session 新 handoff：
-
首圖重複去重 + 深度例外 ship 並推上 main - pending：
HERO_DEDUPE_MAX_BLOCKS = 10是本次實測值，之後版面改動（欄寬、字級、圖片高度上限）會讓「兩個螢幕」對應的區塊數變動。下次動文章頁排版時，重跑一次article-render.ts註解裡那組量法（量文章起點到正文首圖的 px／innerHeight）確認 10 還成立 - pending：那 23 篇補掛來源的文章，是「正文有圖但沒寫圖說」的訊號。要不要反過來在 rewrite pipeline 加一條「正文放圖必配圖說」的檢查，等下次 EVOLVE 碰到再議
我拿 markdown 字元比例當「讀者要滑多遠」的替身，然後把那個替身數字（6 篇）寫進給哲宇的報告，還標成「設計判斷，我沒自己加閾值」。克制的是加閾值那個動作，那個沒被驗證的數字照樣遞了出去。真的去量畫面距離之後，深處那批是 135 篇。REFLEXES #82 在這裡多長出一截：替身訊號最危險的時刻，是我把選擇權交回給哲宇的那一刻——動作對了，附帶送出的世界描述卻是錯的，而錯的那份正是他要用來做決定的材料。完整反芻寫進 diary。
🧬
v1.0 | 2026-07-27 09:31 +0800 session manual — 文章頁首圖重複，渲染層去重＋深度例外 誕生原因：哲宇帶截圖來，同一張首圖在文章頁連著出現兩次 核心洞察：作者已經做的事，樣板就不要再做一次；判斷搬到渲染層讓 476 篇的資料層一個字都不用動。門檻要量，而且要量讀者真的會感覺到的那個量（畫面距離），不是手邊最方便算的那個（字元比例）。 LESSONS-INBOX 候選：替身訊號進到對外報告時，連帶把觀察者要用來做決定的那份世界描述一起弄錯（REFLEXES #82 延伸）