一支 Automation 已經成功建立過幾十張工作單。

需要的欄位都知道。

Mapping 也驗證過。

所以開發的人把它們存了下來：

Category → field_17
Owner Type → field_31
Target Group → option_204

隔天又收到一筆相同類型的 Request。

Agent 沿用昨天的 Mapping。

這一次 Create 失敗。

第一個反應是 API 不穩。

但手動建立同樣的工作單卻正常。

再查 Current Metadata 才發現：

其中一個欄位今天對這個 Project 根本不可用。

另一個 Option 也因設定不同換了識別碼。

昨天的資料沒有錯。

只是它被當成了永久 Contract。

「曾經驗證過」不等於「永遠有效」

很多 API Integration 一開始都會做一件合理的事：

把已經確認過的 Schema、Field、Mapping 記下來。

不然每次都重新查，感覺很浪費。

對真正穩定的 Contract，這當然合理。

但 Package 裡的 Jira Knowledge Rule 特別留下另一種情況：

Create / Edit Metadata 會受 instance configuration / permission 影響；建立前應讀 Current Metadata，不能把曾驗證的欄位表當永久 global schema。

也就是有些「規格」其實不是靜態規格。

它是 Current State 的一部分。

AI 特別容易把成功案例變成固定規則

昨天一個 Case 成功：

field_17 = Category
option_204 = Group A

模型很容易從這裡抽出：

建立這類工作單時，使用 field_17 和 option_204。

如果後面沒有再加 Scope，這句話看起來像一條穩定 Rule。

但真正成立的可能只是：

在昨天那個 Project、那組 Permission、那個 Metadata State 下，這個 Mapping 有效。

這也是 Dynamic ID 和 Current Metadata 必須留在執行層的原因。

不是所有已知資料都適合升格成永久知識。

Current Contract 應該在 Write 前確認

真正要改的不是「不要 Cache」。

而是分清楚什麼可以被視為 Stable Knowledge，什麼需要在 State-changing 前重新 Resolve。

例如使用者說：

建一張新的工作單，Owner 設成某個 Team。

人類意圖很穩定。

但底層可能需要當下才知道：

Current create fields
Current allowed options
Current identifiers
Current permission-dependent requirements

這些東西如果會隨環境改變，就不應要求使用者記，也不應只靠昨天的成功結果猜。

他們沒有把所有 Metadata 都每秒重抓

最後的調整沒有那麼極端。

不是每一步都重新讀完整系統設定。

只在真正準備做 Create / Edit 前，重新 Resolve 會影響這次 Write 的 Current Metadata。

昨天的 Mapping 仍然可以當 Cache、Hint 或測試參考。

但它不再是「不需要確認的真相」。

下一次建立工作單時，Agent 先做了一個短 Precheck。

畫面上只多了一行：

Current write contract resolved.

使用者完全不需要知道 Field ID 改了。

Automation 也沒有重新學一套流程。

真正不同的只有一件事：

它不再假設昨天能寫進去的東西，今天一定還是同一份 Contract。