一位工程師在做自動化時，看到工作單裡有一個很普通的欄位：

Status: Open

需求也很普通：

把符合條件的工作單改成 In Progress。

既然是欄位，就照一般 Update API 改。

其他欄位都是這樣做的。

Owner 可以改。

Priority 可以改。

Comment 也能寫。

結果 Status 不行。

第一次呼叫失敗。

工程師以為是欄位權限問題。

查了一圈才發現，這個系統的 Status Change 不是普通 Field Update。

它屬於 Workflow Transition。

當前狀態能走哪些 Transition、需要哪些欄位、會經過哪些 Validator，都可能不同。

畫面上只看到一個 Status。

背後卻是一個 Action Contract。

看起來像資料欄位，不代表工作上只是資料欄位

這類問題很容易出現在 Integration 裡。

從資料結構看：

status = "Open"

很像任何一個 Attribute。

但從 Work Semantics 看，Status 常常代表流程位置。

從 Open 到 In Progress 可能意味著：

• 目前必須允許這個 Transition
• 某些必要欄位要先存在
• 某個角色才有權做
• 進入下一狀態時要填額外資訊

所以真正的操作不是：

set field value

而比較接近：

current state
→ available transitions
→ required fields / validators
→ execute transition
→ verify new state

Package 裡因此直接留下：

Workflow Transition is not Generic Field Update.

AI 很容易被表面的 Schema 騙過

如果 Agent 只看到一份 Object Schema：

status: string

它很自然會認為這是一個可以 Set 的欄位。

尤其其他 Field 都能用同一套 Update API 時，更容易沿用同一個 Pattern。

但 Work Integrator 需要看的不是「資料長什麼樣」。

而是：

這個欄位的改變，是不是代表一個正式 Workflow Action？

只要答案是 Yes，就不能只靠 Schema 猜操作方式。

要回到 Current Transition Contract。

同一個目標狀態，今天也不一定走昨天那條路

更麻煩的是，即使昨天已經成功把一張 Ticket 從 Open 改到 In Progress，也不能保證今天直接重用同一個 Transition ID。

不同 Project、不同 Current State、不同設定，都可能讓可用 Transition 改變。

所以「我知道目標叫 In Progress」還不夠。

執行前仍要回答：

Current state 是什麼？
現在有哪些 Transition？
哪一條會到目標 State？
這條 Transition 目前需要什麼？

這不是 API 太麻煩。

而是 Workflow 本來就不只是欄位值。

他們最後沒有替 Status 做 Special Case Hardcode

最開始有人想直接把已知 Mapping 寫死：

Open → In Progress = transition 31

這樣最快。

但這個值一旦換 Project 或 Workflow，就可能失效。

最後 Action Skill 的規則改成：

先讀 Current Transitions / Fields，再選符合當下 State 的 Action Contract。

使用者仍然只說：

「切到 In Progress。」

他不用知道 Transition ID。

只是底層不再把 Status 當成普通 String Update。

下一次，系統先看了一眼現在的位置

又一張工作單要被移到待審核。

Agent 沒有先送 Update。

它先讀目前 State。

再讀當下可用的 Transition。

其中一條要求補上 Review Reason。

系統回來問：

「進入待審核前需要一個 Review Reason，目前還沒有。」

使用者補完後，Transition 成功。

畫面最後只看到：

Status: Pending Review

還是一個欄位。

但負責執行的人終於沒有再把它當成「只是改一個欄位」。