_pending/ 是 gitignored 的 sandbox，不只給 writing 草稿
原本的設計是：夜間 draft-pending 把 writing 草稿寫到 _pending/，
翌日發布工具盤點、核可後 move 到 writing/。
邏輯很乾淨——直到第一輪盤點看到的不只是 writing 草稿：
1 篇 YYYY-MM-DD-*.html（writing 草稿，目標路徑 writing/）、
5 篇沒有日期前綴的 *.html（formula 文章，目標路徑 formulas/）、
1 個 _patch_articles.py（補丁腳本，doc string 明示「住在 _pending/ 直到跑完」）。
這不是 bug——_pending/ 本來就是 gitignored sandbox。
任何流程需要「暫存等核可」的東西都可以放這裡。
問題是發布工具需要能分辨這三種東西，才能決定每種怎麼處理。
分流依據：讀 canonical link，不要猜檔名
第一個直覺是看檔名：有日期前綴的是 writing、沒有的是其他。 但這個規則太脆弱——如果哪天 writing 文章也沒有日期前綴，就誤判了。
更穩的依據是 HTML 裡的 <link rel="canonical">。
每篇文章都有 canonical URL，它明確聲明這篇文章的權威路徑，而且是作者寫的、不會猜錯。
讀 canonical：
canonical 指向 /writing/... → writing 草稿，走 writing 發布流程。
canonical 指向 /formulas/... → formula 文章，另外處理。
.py、.sh、_*.md → 工具或稽核檔，列給人工決定。
這一輪的實際處理：writing 草稿由第一輪發布，formula 文章和補丁腳本列給使用者， 取得授權後走第二輪。
Tier 衝突：文章 eyebrow 是 ground truth
第二輪處理 formula 文章時，把 5 篇文章映射到 formulas/index.html
的 placeholder 卡片。其中 4 篇一對一比對無問題；第 5 篇 universal-gravitation（#79 萬有引力）出現衝突：
index.html placeholder 標的是 Pro。 但文章本身的 eyebrow 寫的是 Free。
兩個資訊源，哪個算數？ Placeholder 是規劃階段的意圖——在文章還沒寫出來的時候，對 Tier 的預估。 文章 eyebrow 是作者在寫完文章之後最終決定的分類，寫進了 HTML 原始碼。 時間上更晚，決定者是同一個人，應該採文章 eyebrow。
規則是：文章 eyebrow 是 Tier ground truth；index.html placeholder 的 Tier 是預估，衝突時跟隨文章。
Tier 改變會 ripple 到計數
把 #79 從 Pro 改成 Free，不能只改 placeholder 那一行。
formulas/index.html 裡有分類計數：物理類別顯示「12 Free / 9 Pro」。
Tier 一改，計數變成「13 Free / 8 Pro」，兩個數字都需要同步更新。
如果只改 placeholder line 忘了計數，頁面資訊就不一致。
這次發現的 patch 策略表： placeholder 存在且 Tier 一致 → 直接替換為 active 卡，計數不動； placeholder 存在但 Tier 不一致 → 替換 + 同步 Tier + 更新計數； 無 placeholder（新公式）→ 在 active 區尾端插入新卡 + 計數 +1。
今天確認的三條規則
_pending/ 是全局 sandbox，發布工具要能分流：不能假設裡面只有 writing 草稿。任何流程都可能把等核可的東西放進來。盤點時先分類，再依類型決定處理路徑。
分流依據讀 canonical link，不猜檔名：canonical URL 是作者明確聲明的權威路徑，比檔名前綴更穩定。讀 canonical 比解析檔名規則更不容易出錯。
文章 eyebrow 是 Tier ground truth：index.html placeholder 是規劃時的預估；文章本身是最終決定。改 Tier 時記得 ripple 到分類計數，不能只改 placeholder 那一行。