違規類型決定 enforcement 時機 + 機制。把所有違規都丟給 batch 完成後的 reviewer 是錯的；同樣錯的是 只靠生成中抽樣、沒有 stage 0 的主動變體規劃。Emergence 違規需要 兩層防護：

• Stage 0 主動設計層：寫批量前列 N 種 framing variant、分配給對應主題；這層決定 cadence 是否錯開的根因
• Stage 內被動監測層：生成中抽樣 audit、發現 collapse 立即修方向；這層 偵測 而不是 設計

兩層缺一不可：跳過 stage 0、被動抽樣不會自動發現 主題語意 attractor（相似主題天然引出的 framing collapse、見 #122 cadence 同質化 Update 段定義；migration playbook 3/5 collapse 即此實證、見本卡「Update: 被動寫作下…」段）；跳過 stage 內抽樣、stage 0 設計可能在中途 drift 沒被 catch。

backend/07 案例對照：51 個 vendor 字面違規 0、結構違規 0、emergence 違規（cadence 同質化）51/51；後者三個 reviewer 中只有一個 footnote 提到、是因為 reviewer 一次審 51 檔、emergence 訊號夠強才看出 — 如果只審 5 檔、emergence 訊號還不夠強、會被漏掉。

為什麼 emergence-class 違規規則化不了

字面違規可以寫成 regex（rg "✅|❌"）、結構違規可以寫成 grammar 規則（章節必須有 N 個 H2）。Emergence 違規的特徵：

1. 跨檔才能偵測：單檔 cadence 沒問題、N 檔 cadence 對齊才是違規
2. 規則化會 over-fit：寫「段末不可用『四件事任一缺失』」會把這句正常用法也擋掉；寫「段首句句型分佈要 ≥ 3 種」需要先語法剖析、複雜度爆炸
3. 訊號隨樣本數變化：5 檔比對訊號弱、50 檔比對訊號強；linter 沒有「批次」概念、只看單檔
4. 跟風格邊界模糊：cadence 一致 vs cadence 同質、之間是漸層、threshold 因領域而異

結論：emergence 違規不能靠 hook / linter / 字面規則攔、只能靠 流程設計 在生成中 trigger 抽樣 review。

Stage 內抽樣的設計

對 case-first-module-workflow 補強：stage 2（內容生成）內部加入 cadence checkpoint、不要等 stage 3 reviewer 才發現。

關鍵：抽樣不是「Reviewer 在 batch 完成後跑」、是「寫作者在生成中跑」。寫第 5 篇之前先回頭看前 5 篇、發現問題就在第 5 篇修方向、不是寫完 50 篇才回頭改 50 個。

Dogfood evidence (2026-05-18、N=4 sub-threshold 驗證)

本卡浮現後立即跑 4 篇 deep article 小批量 dogfood、用 寫作中抽樣 + pilot phase variant 取代 batch 後 reviewer：

對照前批 backend/07 51 vendor（無寫作中 checkpoint）：

兩個驗證：

1. Stage 內抽樣在 sub-threshold N=4 仍有效：原本 checkpoint 表格寫第 5 / 10 篇抽樣、預設批量 ≥ 5；實測 寫每篇前都做一次 entry framing variant check 在 N=4 也能完全錯開 cadence
2. 生成中抽樣的邊際成本 « batch 後 polish 成本：每篇前 ~1-2 分鐘 cadence check vs batch 後修 51 處 ~30-60 分鐘 — 比例 ~10-15 倍。本卡論斷「修正成本 N 倍」獲實證

Update: N=5 full-threshold checkpoint 排程驗證

第一次 N=4 後立即跑 N=5 full-threshold batch（5 篇 PostgreSQL sub-tool）、驗證 checkpoint 排程在 ≥ 5 真實閾值的表現：

兩批對照：

額外驗證：

3. 進度 10-20% 抽樣訊號偏弱、80% 抽樣最強：N=5 batch 確認 進度 80% audit 是 emergence 訊號最強位置；原 principle 寫「進度 10-20% 抽樣」是過早、實際 寫前 variant 規劃 + 進度 60-80% audit 組合更穩
4. 同 vendor 同 type 是 collapse 最高風險、checkpoint 仍 cover：N=5 batch 共同 context 比 N=4 多（同 vendor / 同 audience / 同 article type）、本卡論斷 emergence 風險 = 共同 context × N 成立；checkpoint 設計能 cover 是因為 variant 規劃在 stage 0、不靠 sample size 補

Update: 被動寫作下 stage-internal checkpoint 仍失效

第三輪 5 篇 migration playbook 中 前 3 篇被動寫作（沒主動規劃 variant）— stage-internal checkpoint 雖然按時 fired、但因為 沒 variant 預先準備、checkpoint 看到的「不同主題」誤以為 framing 會自然錯開、實際 collapse 到「為什麼遷：X/Y/Z driver」格式：

兩個關鍵 finding：

5. Checkpoint 不夠、變體規劃才是 root：stage-internal checkpoint 確實 fire、但 沒準備 variant 時 checkpoint 變被動驗證、不是主動防護；本卡原論斷「checkpoint 取代 batch 後 reviewer」需修正為「checkpoint + 預先 variant 規劃 兩層」
6. 主題語意 attractor 是新失效源：N=5 batch 中前 3 篇都圍繞「為什麼換 vendor」、entry 自然 collapse 到 driver list；這個 attractor 比結構 constraint 更強、未來寫作要 預先列 framing 變體 而不是 依賴 checkpoint 提醒換

修正後的 Stage 內 checkpoint 排程（補 stage 0 變體規劃）：

關鍵：Stage 0 變體規劃是必要 step、不能跳；checkpoint 是 監測 工具、不是 設計 工具。

詳細 SOP 跟 5 種 type 的具體應用見 Migration playbook methodology — 該 methodology 從 5 篇 migration playbook batch 抽出 stage 0 variant 規劃流程、本卡的「checkpoint 不夠」訊號是該流程的觸發實證。

Update（2026-05-19）：第二輪 migration batch 全主動 variant 驗證

第二輪 migration batch（5 篇）寫前主動列 5 種 entry framing variant、cadence audit 結果 0/5 collapse；跟第一輪 3/5 collapse 對照、唯一差異是 variant 規劃完整度：

第二輪確認本卡核心論斷：

5. Checkpoint + Stage 0 兩層在全主動下成功：第二輪 5 篇 stage 0 全列 variant、checkpoint 監測無 collapse alarm、最終 audit 0/5；證實兩層防護在 都執行 下達成 principle 目標
6. Stage 0 規劃的標準動作：第二輪 stage 0 動作為「列 5 種 distinct entry framing 候選、對應 5 篇主題分配」— 不是「想到才換」、是 寫第一篇前就完成 的設計步驟
7. 主題相似性不會自動解決 cadence：第二輪 5 篇都是 migration playbook、主題相似性跟第一輪一樣高；唯一差異是 stage 0 是否做、結果差 60% collapse vs 0% — 確認本卡論斷「checkpoint 不夠變體規劃才是 root」在 主題相似性高 場景下仍成立

Batch 完成後 reviewer 為什麼太晚

三個成本問題：

1. 修正成本 N 倍：51 篇都同質化、修正要動 51 篇；如果第 5 篇就 catch、只動 5 篇
2. Cadence 已內化成「正確答案」：寫完 50 篇後 Claude 已經把 dominant framing 視為「合規最佳解」、要打破比第 5 篇難
3. Reviewer 訊號要求高樣本：5 檔不夠 emergence、50 檔才強訊號；但 50 檔出來時修正成本已經爆

最佳時機：Sample size 剛夠看出 emergence、且修正成本還可控 — 通常是 batch 內 10-20% 進度的位置（51 批量 → 第 5-10 篇）。

跟字面 / 結構違規的時機對照

字面違規（emoji）的 enforcement 鏈：

• 寫作中：Claude 預設不寫 emoji（pre-trained behavior + system prompt）
• Pre-commit：mdtools / regex hook 攔
• CI：full lint sweep

三層防護、字面違規幾乎不可能漏網。

結構違規（章節缺失）的 enforcement 鏈：

• 寫作中：模板 / skeleton 提示
• Pre-commit：lint 章節結構
• Review：人類 / agent 看章節列表

兩層機制、結構違規會被攔。

Emergence 違規目前的 enforcement：

• 寫作中：無（cadence 沒提示）
• Pre-commit：無（regex 攔不到）
• Review：Stage 3 reviewer 可能漏（單 reviewer 視野有限）

只有 stage 3 reviewer 這一層、且不可靠。本卡的修法是在「寫作中」這層加 stage 內抽樣。

不只是寫作：emergence 違規的其他例子

三類違規對應三層 enforcement、不能混用工具。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：違規分字面 / 結構 / emergence 三類、enforcement 時機要對應類型。Emergence 違規規則化不了、不能丟給 hook 或 batch 後 reviewer、要在生成中（batch 進度 10-20% 時）抽樣 catch；最佳時機是 emergence 訊號剛夠強、且修正成本還可控的位置。