拒絕訊息沒有穩定的機器可讀碼：114 個 refusal 只有 5 個帶 E_ 代碼，其餘是自由文字（sister concern from #202）

[kiki830621]

問題

#202 把 114 個 return "Error: …" 的拒絕改成 throw，讓協定層的 isError 正確。但拒絕內容仍是 Error: 前綴的自由文字：

帶 E_ 代碼	數
E_DIRTY_DOC	5 處
E_IMAGE_CONSISTENCY_INSPECTION	3
E_WORD_MCP_LOG_LEVEL	2
E_NO_AUTOSAVE	2
E_IMAGE_CONSISTENCY	1
無代碼（anchor 衝突、text_instance 範圍、invalid regex/scope、caption/equation 讀回失敗…）	100+

client（含 LLM harness 的重試邏輯）想分辨「anchor 衝突——換個 anchor 再試」與「dirty doc——先存或丟棄」仍要 parse 散文；措辭一改，分流就壞。

方向（待討論）

• 給每類拒絕一個穩定代碼（沿用既有 E_ 慣例），放在訊息最前面：Error: E_ANCHOR_CONFLICT — insert_paragraph: received conflicting anchors: …
• 或在 MCP result 加 structured content（_meta / 第二個 content block 帶 {code, tool, detail}），文字不動
• 兩者都要一份代碼台帳（README 或 docs/error-codes.md），並用 sweep test 鎖「每個 ToolRefusal 都帶代碼」

先做 #202（協定層 isError），本票在其上加語意層；不要反過來。

Source: surfaced during /idd-diagnose #202 sister concern surfacing (Step 3.6)

[kiki830621]

兩則來自 #202 verify（https://github.com/PsychQuant/che-word-mcp/pull/213#issuecomment-5520980249）的註記：

1. 計數口徑：本票寫「114 個 refusal」是 diagnose 當下的盤點；實作時多找到 E_IMAGE_CONSISTENCY_INSPECTION 那個 helper 字面，總數是 115（110 單行 + 5 多行）。另有 37 處 JSON 字面形態的拒絕不在這個數字裡，處置另立 214。
2. security S2：兩個拒絕訊息插值了非參數內容——Server.swift:7088 的 autosave 路徑（衍生自 client 自己給的 open 路徑）與 :9902 的段落內文 snippet（長度上限在 ooxml-swift）。既存、拒絕／錯誤以 return "Error: …" 字串回傳時 MCP isError 未設——協定層仍是成功（repo-wide 慣例） #202 未動；設計 structured error payload 時把「訊息可含哪些內容」一併定下來。