跨工具共用的 identifier（URL slug、API endpoint、route name、檔案 ID）必須顯式定義在一處 fact、不能依賴各工具各自推導。多工具各自推導 = 推導鏈分歧 = silent 失敗（compile / lint 時看不出、跨工具接縫時才爆）。

具體到 Hugo blog 的 URL slug：

三個推導鏈 — 寫作者寫 [link](/posts/X/) 時、X 應該是哪個？沒有 single source 給答案。

修法：把 slug 從 derivation 升級成 fact — 在 frontmatter 顯式定義 slug: <name>、跟檔名對齊、所有工具基於此 fact 運作、跨檔連結用此 slug。

為什麼會散落

各工具的預設行為都「合理但不一致」

每個工具在自己的領域內都做了「合理的決定」、合起來才產生不一致：

每個決定本身沒錯、合起來形成「沒有單一真相」的狀態。

Hugo 的 urlize 不是純函式

Hugo 的 title → slug 推導用 urlize、規則隨版本演進、對中文 / 全形字元 / 連字符的處理會變。寫的當下推導出來的 slug、未來 hugo 升級後可能變不同 — 這是「runtime 推導 = 隱性依賴 hugo 版本」。

而 frontmatter 的 slug: <value> 是字面值、不依賴任何工具的推導邏輯、跨版本穩定。

「能 build 就不寫」是便利驅動偏移（#67）

Hugo 不寫 slug 也能 build — 寫作的當下、加 slug 是「多餘工作」、看起來沒收益。便利驅動讓寫作者跳過。但這個便利是借用未來的成本 — 跨檔連結時、slug 推導不一致才暴露、那時要付的修復成本遠大於當初寫 slug 的成本。

Fact vs Derivation：slug 該是哪一種

呼應 #44 的區分：

slug 必須是 fact、不是 derivation。理由：

• slug 的「值」是設計選擇 — 用什麼字串作為 URL 一部分、是 SEO / 可讀性 / 穩定性的決定、不該被自動推導左右
• 一旦固定後就不能改（改 slug = URL 改 = 外部連結全部死）
• 「不能改」+「設計決定」= 應該是 fact

hugo 的 title→slug 推導：把一個 fact 偽裝成 derivation。表面上看「我只寫 title、slug 自動算出來」、實際上推導出來的 slug 變成了一個新的 fact（一旦發布就不能改）、但這個 fact 的住址不在程式碼裡、在 hugo runtime 裡。

反模式：分散的 derivation 鏈

多工具各自推導 = silent 不一致

當多個工具各自從不同 source derive 同一個 identifier、寫的當下都通過、跨工具接縫時才爆：

寫的當下看不出、是這個反模式的核心難處。

「規則膨脹」誘惑：教 mdtools 認 hugo 規則

碰到 mdtools 不認 hugo title 推導時、直覺反應是「教 mdtools 也跑 urlize」。這是用字面工具模擬行為層（#82 的反模式）：

• mdtools 是字面 lint、學會 urlize → 增加實作成本、要追 hugo 版本變動
• 解決了表面症狀、但根因（slug 是 derivation）沒動
• 下一個工具（如 search index）加進來、又要再學一次 urlize

正解是消滅 derivation 鏈、把 slug 升成 fact。每個工具直接讀 fact、不需要學別人的推導規則。

「之後再補 slug」的 trigger 缺失

「先這樣、之後系統性 backfill」是 #72 的典型訊號。沒有 trigger 時、debt 永遠累積：

• 175 篇文章沒 slug、每多寫一篇 debt 多一份
• backfill 沒被排上 → 永遠不做
• 直到某天有人引用中文 title 的文章、broken link 才浮現

修法：lint 規則加 missing-slug check、把 trigger 結構性建立（#91 量化 trigger 設計）。

修法：兩層補強

規範層（解根因）

每篇 content 文章 frontmatter 必須有 slug、值跟檔名對齊（不含副檔名）：

1---
2title: "Hugo 部落格支援 Mermaid 流程圖完整實現指南"
3slug: "mermaid-gitgraph"   # 跟檔名 mermaid-gitgraph.md 對齊
4date: 2025-10-08
5---

寫好後：

• Hugo 用 slug: 不再 derive title
• mdtools 用檔名比對 frontmatter slug、字面對齊就過
• 跨檔連結 [...](/posts/mermaid-gitgraph/) 直接基於 slug、不需推算
• SSoT 集中在 frontmatter、檔名是 mirror（自動驗證一致性）

工具層（防呆）

mdtools 加 lint 規則：

把問題從「跨檔 link 時 broken」提前到「寫作時就 catch」。

歷史 backfill

175 篇沒 slug 的文章需要 backfill。可寫 script：

1for f in content/posts/*.md content/work-log/*.md content/record/*.md content/report/*.md; do
2  slug=$(basename "$f" .md)
3  if ! grep -q "^slug:" "$f"; then
4    # 在 date: 後插入 slug: <檔名>
5    sed -i.bak "/^date:/a\\
6slug: \"$slug\"" "$f"
7  fi
8done

人工 review 確認 slug 沒衝突、commit。

跟其他抽象層原則的關係

本卡跟 #82 / #92 共同形成「工具 ceiling pattern 系列」 — 每個工具都有能擋的層 / 擋不到的層、跨層之間需要「升級 fact」或「換工具」、不是「教工具學別人的規則」。

套用到本系統的 case

Case 1：175 篇 0 slug 的累積債

實證資料（2026-04-28 撤查）：

每一篇都是潛在的 broken link 觸發點、debt 未爆出來只因為「英文檔名跟 hugo 推導剛好一樣」。

Case 2：mermaid 流程圖文章的引用 broken

寫 #92 的 case 2 提到 mermaid_gitgraph_type_color_config 文章、想連到既有的 mermaid流程圖.md。實際軌跡：

1. 第一直覺：寫 [...](/posts/hugo-部落格支援-mermaid-流程圖完整實現指南/)（hugo 推導出來的 URL）
2. mdtools L1-broken-link 失敗、它認檔名 mermaid流程圖.md
3. 改寫 [...](/posts/mermaid流程圖/)、hugo build 後變 404（因為 hugo 認 title 推導的 slug）
4. 退而求其次：去掉超連結、改純文字提及

問題的根本是「mermaid流程圖.md 沒寫 slug」 — fact 缺失、就只能在「mdtools 認的字面」跟「hugo 認的推導」中二選一、兩者都不對。

正解：給 mermaid流程圖.md 補 slug: mermaid-gitgraph 或類似、檔名 rename 對齊、所有工具基於同一 fact。

Case 3：跨工具 identifier 的通用 pattern

不只是 hugo blog — 任何「多工具共用 identifier」的情境都同樣 pattern：

每一類的修法都一樣：把 identifier 升成 fact、所有工具基於此 fact、不要讓各工具各自推導。

判讀徵兆

核心：跨工具共用的 identifier 必須是 fact、不是 derivation。Derivation 鏈把單一值散落在多工具的推導邏輯裡、寫的當下看不出問題、跨工具接縫才爆 — 而那時候 debt 已經累積到難以集中修。Fact 升級的成本（每篇加一行 frontmatter）遠小於 derivation 鏈失敗的修復成本（broken link / SEO 損失 / debugging 時間）。

跨段落、跨檔引用一個結構單位（章節、階段、條列項、輪次）時、引用它的語意標題、不引用它的位置編號。「見核心問題」「在操作盤點階段確認」是穩定引用；「見 Stage 3」「Stage 1-3 出現訊號時」是把當下的排列順序寫死進引用點。

編號可以存在、但只承擔兩個角色：當下閱讀的排序導覽（條列 1、2、3）、跟發布方凍結過的外部 contract（RFC 段號、法條條號）。活文件（會演進的規範、skill、教材、設計文件）的編號是結構排列的 derivation — 插入一個新章節、所有後續編號全部位移、散落各處的引用點卻不會跟著動。

這條原則同時定義了標題的責任：每個結構單位都要有說明核心意義的語意標題、讓引用有東西可錨。只有編號沒有語意標題的章節（「Stage 3」「第五章」）、等於強迫所有引用者使用會漂移的錨點。

為什麼編號引用會 silent 失效

編號是 derivation、引用是複本

一個章節的編號由「它前面有幾個章節」決定 — 這是排列的衍生值、不是這個章節自身的事實。把「Stage 3」寫進另一個檔案的引用句、等於把這個 derivation 的快照複製出去當 fact 用；結構一變、所有快照同時過期、而且沒有任何機制通知它們過期了。

失效模式比 broken link 更糟：misdirected、不是 dangling

連結斷掉會報錯；編號錯位會成功解析到錯的內容。讀者照著「見 Stage 3」翻過去、看到的是一個真實存在、語意卻完全不同的階段 — 他沒有任何訊號知道引用已經過期。修復也只能靠人工逐處判讀：grep 找得到所有「Stage」字面、但無法判斷哪些語意還對、哪些已經錯位。

語意標題也會改名 — 兩種斷裂不同級

語意錨的最強反例是「標題也會改名、改名後所有語意引用一樣過期」。這個攻擊成立一半 — 引用確實會過期、但斷裂的型態與偵測條件完全不同。改名讓舊引用斷成 dangling：「見核心問題」找不到目標、grep 與讀者都判得出引用過期了；編號位移斷成 misdirected：成功解析到錯的內容、無人察覺。更關鍵的差異是操作者在場與否 — 改名是對目標單位的顯式操作、改名者當下就知道該掃引用面、修復可以發生在同一個 commit；編號位移是別處插入章節的副作用、被位移的章節沒有人碰過、它的引用過期沒有任何人在場負責。語意錨輸在「也會變」、贏在「變的時候可偵測、有人在場」。

時間維度的累積

寫下引用的當下、編號跟語意完全對得上 — 這正是這個反模式難以自察的原因。漂移發生在後續版本：插入新階段、合併兩章、把一節搬到另一個檔案。文件越活躍、引用點越多、每次重排的人工修復面就越大；漏修一處、就埋下一個 misdirected 引用等讀者踩。

反模式與修法

寫作時的判斷次序：先給結構單位一個承載核心意義的標題（這是標題的本職）、編號只作當下排序；引用時一律取語意名稱；引用點離目標越遠（跨檔、跨 surface）、越是只能用語意錨。

邊界：凍結編號是 fact、可以引用

發布方承諾編號不變的外部規格、編號本身就是 contract：RFC 的 section number、法條的條號、含版本年份的 ISO 條款（如 ISO 9001:2015 — 跨版改版會重編條款、引用時鎖定版本才算凍結）、已出版書籍的章節。這些編號被凍結成 fact、引用它們反而比引用標題穩定（標題可能在翻譯與再版間變動）。內部活文件想獲得同樣性質、要先付出同樣代價：宣告編號凍結、只加不改 — 多數活文件不值得也做不到、所以預設走語意引用。

跟其他抽象層原則的關係

• #156 集合命名用角色、不內嵌數量：命名端 sibling。本卡假設語意標題是穩定 fact、#156 負責讓這個假設成立 — 「核心七問」這種 count-bearing 標題一半是語意、一半是成員數的 derivation、引用端怎麼修都錨在會漂移的字串上。本卡初版的正面範例就用了「見核心七問」而未察覺、由 #156 抓出 — 兩卡是不同認知層的檢查、單獨跑任一個抓不到另一個的違規。
• #44 Single Source of Truth：本卡是 SSoT 在「結構引用」維度的實例。編號是位置的 derivation；把編號寫進多處引用點、等於把 derivation 當 fact 散寫多份複本 — fact（章節的語意身分）只在標題一處、引用就該錨在那裡。
• #93 URL slug 必須顯式定義為 fact：同屬「引用要錨在 fact」家族。#93 把跨工具 identifier 從推導值升級成顯式 fact；本卡把跨段落引用的錨點從位置推導值（編號）換成語意 fact（標題）。兩卡的失效模式同型：推導鏈分歧、silent 失效、compile / lint 階段看不出來。
• #84 Naming 是 iterated artifact：標題是名字。本卡要求標題承載可被引用的語意、等於對標題套用 #84 的 cross-call-site 檢驗 — 從引用者的角度看、這個標題單獨出現時讀者知道它指什麼嗎？只有編號的標題在這個檢驗下直接不及格。
• #97 Metadata surface 要納入寫作 review 範圍：引用句屬於 #97 分類中的 navigation surface（跟 link label、索引條目同層）— 同樣是正文之外、卻直接決定讀者入口正確性的層。重排結構時、review 範圍要把散落各檔的引用句列入掃描面、而不是只改目標檔。

觸發 case

設計一個多階段訪談 skill 時、初版流程四階段、各檔用「Stage 1 的核心七問」「Stage 3 收斂時」互相引用。下一版把流程改成六階段：操作盤點與領域切分插入在前、核心七問從 Stage 1 變成 Stage 3、決策收斂從 Stage 3 變成 Stage 5。

後果具體呈現了上述失效模式：十多處跨檔引用要修、grep「Stage」找得到所有字面、但每一處都要人工判讀語意 — 「Stage 3 收斂時」字面完好、語意卻已指向錯誤階段（舊 Stage 3 是收斂、新 Stage 3 是核心七問）。實際修復中就有兩處漏網、靠第二輪全 repo 掃描才補上。若初版引用寫的是「核心問題」「決策收斂階段」這類語意名稱、這次重排的引用修復成本是零。

判讀徵兆

• 寫出「見 Stage N」「如第 N 點」「上一章提過」「§N」且目標是活文件時 — 改用語意標題引用。
• 章節標題只有編號或編號加泛稱（「階段三」「Part 2」）— 補語意半邊、否則其他文件只能用編號引用該章節。
• Review 掃描可用：rg "Stage [0-9]|第 ?[一二三四五六七八九十0-9]+ ?(章|節|點|步|輪)|§[0-9]" — 命中是候選、要逐處判讀目標是凍結編號還是活文件。
• 結構重排（插入 / 合併 / 搬移章節）的 commit、檢查清單要包含「全 repo 掃引用句」、不是只改目標檔。

集合型結構（問題清單、階段序列、原則組、支柱組）的命名只承載角色與層級、把成員數量留給清單自己呈現。「核心問題」這個名稱承受任意的成員增減；「核心七問」把當前成員數烤進名字、加一問、七就變八：名稱本身先失真、散落各處的引用跟著全部過期。「次要問題」「撞牆階段」「防護底線」同理 — 角色詞完成分層、數量歸清單。

區分核心問題跟次要問題、靠的是「核心 / 次要」這組角色詞；讀者選擇讀哪一組、不需要先知道組內有幾個成員。數字在名稱裡有真實的讀者側價值 — 記憶掛鉤與完整性提示（「五原則我只想起四個、漏了一個」）— 但這個價值在活集合下被漂移風險壓過、只有凍結集合能無風險收割它、這也是品牌名刻意用數字的原因；路由本身、角色詞已經完成。

為什麼數量入名比編號引用更深一層

數量是 membership 的 derivation

一個集合的成員數由「目前有哪些成員」決定 — 跟章節編號由「前面排了幾章」決定同構、都是會隨演進變動的衍生值。差別在寄生位置：編號寄生在引用句、數量寄生在名稱本身。名稱是整個知識系統裡被複製最多次的字串（標題、引用、索引、目錄、對話、commit message 都在複製它）、缺陷跟著名稱繁殖到每一個出現點。

它讓「語意標題是穩定錨」的前提失效

引用該錨在語意標題、因為標題被假設是這個單位的 fact。「核心七問」打破這個假設：標題有一半是語意（核心問題）、一半是 derivation（七）。成員一變、想守住名實一致就得全面改名、改名又回到「散落引用逐處修」的老路；想省事不改名、就留下一個說謊的名字（標題寫七問、實際有八問）、比編號錯位更糟 — 錯在系統的權威命名層。

失真的兩條路都有代價

反模式與修法

寫作時的判斷：命名一個集合時、問「這個數字提供了角色詞沒提供的資訊嗎？」— 答案幾乎都是否。讀者需要知道數量的時刻、是看到清單本身的時刻、清單天然自帶數量。

邊界：三種數字可以留

1. 外部凍結的品牌名：SOLID 五原則、OWASP Top 10、WRAP 四步驟 — 數量由發布方凍結、是名稱 fact 的一部分、跟引用 RFC 段號同理。
2. 數字是概念內容本身：兩次門檻 的二是規則的閾值、不是成員數 — 改了二就是改了概念、這種數字承載語意、該留。
3. 緊鄰清單的行內計數：「確認三件事：」後面直接跟三條列 — 數字跟清單同視野、改清單時順手改數字、漂移會立刻被看見。風險低、但仍是小負債、清單就在下面時「確認下列事項：」更省。
4. 內部宣告凍結的集合：團隊把某個方法論名稱當內部品牌用、可以明文宣告凍結後收割記憶價值 — 代價比凍結編號更嚴：凍結編號還能往後加、凍結數量連加都不能加、成員增減等於名稱重新談判。

判別線是「這個數字是 fact 還是 derivation」：發布方凍結的、概念內容本身的是 fact；內部活集合的成員數是 derivation、不入名。

跟其他抽象層原則的關係

• #155 引用章節用語意標題、不用位置編號：直接 sibling、分工在管線的兩端 — #155 修引用端（錨點選什麼）、本卡修命名端（錨點本身怎麼長）。#155 假設語意標題是穩定 fact、本卡負責讓這個假設成立：count-bearing 標題是「一半 fact 一半 derivation」的混合體、先淨化命名、#155 的引用紀律才有穩定的錨可用。實證：#155 卡初版自己用「見核心七問」當正面範例、修引用端時沒發現錨點內嵌數量。兩卡查的是不同層：引用端的檢查抓不到命名端的缺陷、反過來也一樣。
• #44 Single Source of Truth：成員數量的 truth 在清單本身（數一下就有）；把數量寫進名稱是把這個 derivation 複製成第二個源、且這個源被嵌進最高頻複製的字串裡：是 SSoT 違反裡擴散速度最快的形態。
• #84 Naming 是 iterated artifact：本卡給 #84 的命名 review 加一個檢查維度 — 數量入名是「第一版命名基於當下狹窄 context」的典型產物：寫名字的當下成員剛好七個、七看起來是這個集合的屬性；cross-time 檢驗（成員會不會變）才暴露它是快照。
• #67 寫作便利度跟意圖對齊反相關：「七問」「六階段」順口、有節奏感、好記 — 正是便利驅動的選擇；意圖對齊的名稱（核心問題）平淡但誠實。便利的代價延遲到第一次成員變動才結算。

觸發 case

同一份多階段訪談 skill、同一天內兩次命中：

1. 已發生：skill 初版有「四大支柱」、第二版需求調整後支柱變六個 — 名稱被迫改成「六大支柱」、所有提到四大支柱的地方同步修。改完的新名字仍然內嵌數量、下次支柱增減會原樣重演。
2. 被預見：第二版的「核心七問」「成長六階段」被指出同樣結構 — 核心問題若加一問、「七」就散落在標題、引用、索引、路由表裡等著逐處修。

更深的訊號是第三點：當天稍早為了修「Stage 3」編號引用立了一張卡（引用端）、該卡自己用「見核心七問」當正面範例；在專注檢查引用端時、命名端的同型缺陷完全隱形。確認了這是獨立的檢查維度、不是引用卡的子情況。

判讀徵兆

• 命名或標題出現「N 大 X」「N 問」「N 階段」「N 支柱」「N 原則」「N 步驟」且 X 是內部活集合時 — 抽掉數字、看角色詞夠不夠分層、幾乎都夠。
• Review 掃描可用：rg "[一二三四五六七八九十0-9]+ ?(大|問|階段|支柱|原則|步驟|件事|個維度)" --type md — 掃出來的不全是病灶：外部凍結品牌與概念閾值是 fact、留；內部活集合的成員數是 derivation、改。
• 集合成員增減的 commit、檢查名稱是否還誠實 — 需要同步改名的話、這次改名時順便把數量抽掉、別讓下次再來一遍。

一個結構單位的語意名稱只能有一個 canonical 字串、所有引用使用同一字串。「決策收斂」跟「決策記錄 + scaffold 建議」都是語意名、都通過了「不用編號」的檢查 — 但兩個字串指同一個階段、語意引用的收益就漏了一半：工具掃描要掃兩個 pattern 才完整、漏配置一個就漏一半引用點；結構重排時、修復者要先在腦中建立「這兩個名字是同一個東西」的對應表、而這張表沒有寫在任何地方。

語意引用的承諾是「錨點穩定、且機器與人都能單次比對」。同義雙名保住了穩定、丟掉了單次比對 — 等於把 fact 寫成兩種拼法。

為什麼雙名會自然發生

雙名通常在不同檔案、不同時間寫下：標題在設計流程時取（描述產出物：「決策記錄 + scaffold 建議」）、引用在寫協作檔時取（描述階段角色：「決策收斂階段」）。每一次取名都在自己的當下語境裡合理、分裂要把兩個時間點的產物擺在一起才看得到 — 單檔 review 永遠只看到其中一個名字、所以雙名能安然通過所有單檔檢查。

偵測需要跨檔視角：把每個結構單位的「標題語意半邊」列成清單、grep 全部引用句、比對引用字串是否落在清單內。引用字串語意對、字面不在清單內、就是雙名。

反模式與修法

修法的判斷次序：canonical 字串取「標題的語意半邊」（標題是該單位的 fact 所在）；標題語意半邊太長不適合引用時、先改標題、再統一引用 — 標題改短是一次成本、引用各自簡寫是持續發散。

跟其他抽象層原則的關係

• #155 引用章節用語意標題、不用位置編號：本卡補 #155 的缺口。#155 把錨點從編號換成語意名稱、預設了「語意名稱是單一的」；雙名讓 #155 的修法只完成一半 — 錨點穩定了、可比對性沒跟上。三卡合起來是完整的引用紀律：#155 管引用端（錨什麼）、#156 管命名端的內容（名稱不含 derivation）、本卡管命名端的唯一性（一個單位一個字串）。
• #156 集合命名用角色、不內嵌數量：sibling。#156 處理名稱「內容」的 fact 純度、本卡處理名稱「數量」的唯一性 — 一個名稱可以通過 #156（不含成員數）仍違反本卡（有同義變體）。
• #44 Single Source of Truth：同一語意身分的兩個字串就是同一個 fact 的兩個源 — 比值的多源更隱蔽、因為兩個字串「語意上相等」、讀者看不出這是違規、只有工具比對才會痛。
• #84 Naming 是 iterated artifact：#84 的輪 3 明文檢查「同一個概念在不同檔案用同名嗎」、判讀徵兆也列了「同概念出現兩個以上名字、選一個改另一個」— 本卡是這個檢查項在「結構單位的標題與引用」場景的應用：被檢查的從變數名換成章節 / 階段的語意錨、檢查動作相同。

觸發 case

一份多階段訪談 skill 在一致性 audit 中被抓到兩處：階段標題寫「決策記錄 + scaffold 建議」、兩個協作檔的引用寫「決策收斂階段」；另一個階段的引用在「domain / event 切分」與「領域切分」之間混用。每個字串單獨檢查都合規（語意名、無編號、無數量）— audit reviewer 的原話是「語意可對上、但嚴格來說引用錨與標題語意半邊不同字串、下次重排時要靠人腦對應」。修法：標題語意半邊改成「決策收斂」、全 skill 引用統一；「領域切分」全部改寫為「domain / event 切分」。

判讀徵兆

• 寫引用句時、回頭看目標標題：引用字串跟標題語意半邊逐字相同嗎？語意相同、字面不同 = 雙名。
• 跨檔 review 可操作：列出所有結構單位的語意半邊、rg 每個單位的引用句、引用字串不在清單內的逐處判讀。
• 同單位的引用在不同檔案用不同說法、且沒有任何一處寫明對應 — 雙名已經發生、統一的成本隨引用點數量成長。

同主題內容要落在兩個 surface（人類教材 ↔ agent 協議、公開文章 ↔ 內部 skill）時、每一份要為自己的讀者與用途重寫、不是把句子搬過去。「各寫一份」的規範如果用複製貼上執行、得到的是最差組合：兩份字面綁定（改一邊、另一邊變成過期複本、且沒有任何機制提醒）、卻又各自沒有為自己的 surface 最佳化（教材句直接當協議用、agent 拿到的是給人類讀的敘述而不是可執行的指令）。

語境化的可操作判準：兩個 surface 之間 grep 逐字相同的完整句、命中就是候選。同一個原則、教材版該長成「為什麼 + 案例 + 判讀」、協議版該長成「步驟 + 條件 + 產出格式」— 兩版講同一件事、句子自然長得不一樣；句子一樣、代表至少有一邊在用別人的形狀。

為什麼搬運是預設行為

寫第二份時、第一份就在手邊、而且它「已經寫對了」— 複製是零成本、重寫要重新思考這個 surface 的讀者需要什麼形狀。搬運在當下看起來甚至更安全（兩邊保證一致）；代價在第一次單邊修改時兌現：修了教材版的措辭、skill 版還是舊句、兩邊開始各說各話、而因為當初沒有宣告同源關係、沒有人知道要同步。

「禁止跨 surface 引用」防的是顯性耦合；搬運建立的是隱性耦合 — 更糟、因為看不見。語境化重寫讓兩份真正獨立：主旨對應靠概念、不靠字串。

反模式與修法

欄位與句式跟著用途走之後、兩份的字面自然分開；對照查漏時找的是概念缺口、不是字串差異。

跟其他抽象層原則的關係

• #44 Single Source of Truth：逐字搬運讓同一段論述以兩份完整複本存在、誰是權威沒有任何標記。比一般 SSoT 違反更難修 — 第一步的困難不在改、在發現同源關係存在。
• #122 Cadence 同質化是模板的隱形維度：偵測手段同構 — 都是 grep 句子層的字面重複；差別在範圍：#122 抓同 surface 多檔的句式骨架重複、本卡抓跨 surface 的完整句逐字重複。兩個掃描可以同一輪跑。
• #147 規範化跟自審是兩種認知任務：本卡的 case 正是規範已存在（「各寫一份、語境化在各 surface 內」白紙黑字）、執行時仍搬運 — 立規範的人在執行時用了「各寫一份」的字面（檔案確實是兩個）、漏了「語境化」的實質（句子是同一批）。規範的字面合規與實質合規是兩層檢查。
• #150 教材用中性陳述、不對讀者喊話：register 是語境化最敏感的維度 — 教材的中性陳述、協議的指令語氣、訪談的問句、三種 register 不可互換；搬運最先破壞的就是 register 對位。

觸發 case

一個交付形態判讀主題同時寫進 blog 教學章節與 agent 訪談 skill。Cadence 審查跨 surface 比對、抓到三句完整句逐字相同：「官方首頁文案」反向問、「判讀單位是每條業務流程」、「同一個錯誤的兩個方向」。兩個 surface 的規範明文要求各寫一份語境化 — 檔案確實是兩份、句子卻是搬的。修法把 skill 版三句全部改寫成訪談操作語氣（「請使用者用一句話描述核心流程、然後對照」「gate 逐條業務流程過、混合結論直接寫進決策記錄的交付形態欄」）、修辭句直接刪除 — 改寫後兩邊各自更貼自己的用途、概念對應不變。

判讀徵兆

• 寫第二個 surface 時發現自己在開兩個視窗對照逐段抄 — 關掉第一份、憑概念重寫、寫完再對照查漏。
• 跨 surface 掃描可操作：對兩份檔案跑完整句比對（句號切分後 grep 交集）、逐字相同的非術語句逐處判讀。
• 兩份同主題內容的 register 相同（教材版讀起來像協議、或協議版讀起來像散文）— 即使句子不同、也是語境化不完整的訊號。