一個內部能力改名了。

原本叫：

Server Search

後來 Scope 擴大，團隊把 Human Catalog 裡的名稱改成：

Server Function Search

README 也更新了。

使用說明看起來沒問題。

隔天，一位使用者照新文件問：

「幫我用 Server Function Search 找一下這個操作。」

Agent 回：

找不到這個 Skill。

維護者第一個反應是 Cache 還沒更新。

再查才發現，Agent-facing Routing Index 裡還留著舊名稱。

更麻煩的是，其中一個 Specialist 的 Scope 也還是舊版。

人看到的是新世界。

Agent 還活在舊世界。

Runtime 則剛好介在兩者中間。

文件不同可以，但工作定義不能各自演進

前一篇把 Human-facing Catalog 和 Agent-facing Contract 拆開。

拆開後馬上會遇到下一個問題：

誰負責讓它們還在說同一件事？

一個 Capability 可能同時出現在：

• README / Human Catalog
• Agent Routing Index
• Specialist Skill Contract
• Routing / Ownership Table

當它新增、刪除、改名或改 Scope 時，如果只更新其中一層，很容易出現一種很奇怪的狀態：

每一份文件單獨看都沒有 Syntax Error。

真正執行時卻彼此對不上。

Source 裡把這件事叫做 Synchronization Contract。

目的不是維持文件整齊。

而是避免：

README 說一套、Agent Contract 說一套、Runtime 又走第三套。

Rename 是最容易看見的，Scope Drift 更難抓

名稱不同通常很快會報錯。

真正難的是 Scope 只改了一半。

例如 Human Catalog 已經寫：

This capability supports Interface A and B.

但 Specialist Contract 還只有 A。

使用者會合理期待 B 可以做。

Router 也可能把 B 送進來。

最後 Specialist 才說超出 Scope。

反過來也可能發生。

Agent 已經能處理 B，Human Catalog 卻還沒寫。

能力實際存在，使用者根本不知道可以用。

這兩種錯誤都不是 Tool 壞了。

而是同一份 Capability 在不同 Surface 的定義漂開了。

同步不等於所有文件內容一模一樣

團隊沒有要求：

每次改 Skill，就把同一段文字 Copy 到四個地方。

那只會重新製造 Day 27 的問題。

真正同步的是會影響工作 Contract 的變更。

例如：

Capability added / removed
Name changed
Scope changed
Routing changed
Policy changed
Ownership changed

發生這些事時，就檢查：

Human catalog
Agent index
Specialist contract
Routing / ownership

每一份仍然只保存自己該給那個 Reader 的內容。

只是不能漏掉同一個 Work Change。

他們在 Change Checklist 多了四格

後來 Skill 維護流程裡沒有新增大型治理系統。

只在涉及 Scope / Routing 的 Change 時多了一小段：

[ ] Human catalog checked
[ ] Agent index checked
[ ] Specialist contract checked
[ ] Routing / ownership checked

那個能力下一次又改名。

四格一起被勾完。

使用者看到新名稱。

Agent 用新名稱完成 Routing。

Specialist 也知道新的 Scope。

沒有任何一份文件長得一樣。

但至少這一次，改名之後沒有出現四個版本的同一份工作。