釋出：status 加 --verdict，把狀態與成敗兩種語意分開 #87

2026-09-04T11:11:43Z

jiantw83 commented

2026-09-04 11:11:43 +00:00

摘要

需求描述：把 develop 累積的變更釋出到 master。助理的內建檢查項照結束碼判成敗，而 wire-cli.sh status 的結束碼帶的是狀態。於是有先天限制的那一支 CLI 每一輪讓那一筆失敗一次——實測一個半小時就爬到 14 次。
計畫名稱：無
計畫頁：無
分析頁：無

這一批的內容

status 加 --verdict 旗標：輸出一字不變，只有結束碼換一套語意——該接的都接了就回 0，先天限制不算；真的缺項目照樣回非零。

版號 0.4.4 到 0.4.5。

同一個通道，兩種意思

status 的結束碼帶的是狀態：0 接好、1 接好但這支 CLI 做不到、5 有東西沒接。那是給人看的三分法，本身沒有錯。錯的是拿它當檢查。

而那一支自己分得很清楚：degraded 是「該接的都接了，這支 CLI 做不到」，unwired 才是「有東西沒接」。前者是狀態，後者是缺陷。讀的那一邊把兩者都當失敗。

這個計數為什麼不能被填滿

失敗次數存在的理由是指出「有一筆壞掉的項目每輪重試而沒人知道」。

那支 CLI 擋不下技能叫用是它的架構限制——技能走的是 agent 內部請求，攔不到；16 個接線項目全部就位，沒有東西要修。實測一個半小時爬到 14 次，照這個速度一天 96 次。 真正壞掉的項目一旦出現，它的計數會混在這個數字裡，看不出誰是誰。

為什麼修在這一邊

狀態與成敗是兩種語意，混在同一個通道上才是根因。

另一條路是讓讀的那一邊認「可接受的非零碼」——那要在待辦簿加一個欄位，而且每個往後填那一欄的人都得先想「我的結束碼是哪一種語意」。修在這裡只需要知道自己的三種狀態哪一種是缺陷，而那個知識本來就在這一支裡。

測試結果

情況	`status`	`status --verdict`
接好（四支）	0	0
接好但這支 CLI 做不到	1	0
有東西沒接	5	5
用法錯誤	2	2

輸出逐字相同，status=degraded 那一行照印——人還是看得到那支 CLI 有限制。
暫時拿掉一個接線項目驗過缺陷那一路沒有被放寬，還原後回 0。
旗標的三條錯誤路徑都回 2：別的子命令帶旗標、認不得的旗標、沒給 CLI 代號。
三支檢核腳本都回結束碼 0。

前置 Push Request

無

## 摘要 - 需求描述：把 develop 累積的變更釋出到 master。助理的內建檢查項照結束碼判成敗，而 `wire-cli.sh status` 的結束碼帶的是狀態。於是有先天限制的那一支 CLI 每一輪讓那一筆失敗一次——實測一個半小時就爬到 14 次。 - 計畫名稱：無 - 計畫頁：無 - 分析頁：無 ## 這一批的內容 `status` 加 `--verdict` 旗標：輸出一字不變，只有結束碼換一套語意——該接的都接了就回 0，先天限制不算；真的缺項目照樣回非零。版號 0.4.4 到 0.4.5。 ## 同一個通道，兩種意思 `status` 的結束碼帶的是狀態：0 接好、1 接好但這支 CLI 做不到、5 有東西沒接。那是給人看的三分法，本身沒有錯。錯的是拿它當檢查。而那一支自己分得很清楚：`degraded` 是「該接的都接了，這支 CLI 做不到」，`unwired` 才是「有東西沒接」。前者是狀態，後者是缺陷。讀的那一邊把兩者都當失敗。 ## 這個計數為什麼不能被填滿失敗次數存在的理由是指出「有一筆壞掉的項目每輪重試而沒人知道」。那支 CLI 擋不下技能叫用是它的架構限制——技能走的是 agent 內部請求，攔不到；16 個接線項目全部就位，沒有東西要修。**實測一個半小時爬到 14 次，照這個速度一天 96 次。** 真正壞掉的項目一旦出現，它的計數會混在這個數字裡，看不出誰是誰。 ## 為什麼修在這一邊狀態與成敗是兩種語意，混在同一個通道上才是根因。另一條路是讓讀的那一邊認「可接受的非零碼」——那要在待辦簿加一個欄位，而且每個往後填那一欄的人都得先想「我的結束碼是哪一種語意」。修在這裡只需要知道自己的三種狀態哪一種是缺陷，而那個知識本來就在這一支裡。 ## 測試結果 | 情況 | `status` | `status --verdict` | | --- | --- | --- | | 接好（四支） | 0 | 0 | | 接好但這支 CLI 做不到 | 1 | **0** | | 有東西沒接 | 5 | **5** | | 用法錯誤 | 2 | 2 | - 輸出逐字相同，`status=degraded` 那一行照印——人還是看得到那支 CLI 有限制。 - 暫時拿掉一個接線項目驗過缺陷那一路沒有被放寬，還原後回 0。 - 旗標的三條錯誤路徑都回 2：別的子命令帶旗標、認不得的旗標、沒給 CLI 代號。 - 三支檢核腳本都回結束碼 0。 ## 相關的另一張 `plugins/meta` 那邊把委派清單那一格換成帶旗標的寫法，並在那一欄的檔頭補一條規則：結束碼只准表示過與不過，不准用來編碼狀態。那一張掛在這一張後面。 ## 前置 Push Request - 無

jiantw83 added 2 commits 2026-09-04 11:11:43 +00:00

feat(接線): status 加 --verdict，把狀態與成敗兩種語意分開 d6f1e0e7ba

status 的結束碼帶的是狀態：0 是接好、1 是接好但這支 CLI 做不到、5 是有東西
沒接。那是給人看的三分法，本身沒有錯。

問題出在被當成檢查用。助理的內建檢查項照結束碼判成敗，非零就是那一筆失敗、
失敗次數加一。於是有先天限制的那一支 CLI 每一輪都讓那一筆失敗一次，一天 96
次，而沒有人修得動——那支 CLI 擋不下技能叫用是它的架構限制，不是接線缺漏，
16 個接線項目全部就位。

那個計數存在的理由是指出「有一筆壞掉的項目每輪重試而沒人知道」。被一個修不動
的數字填滿，就等於用假的壞掉把真的壞掉蓋掉。

修在這一邊而不是修在讀的那一邊：狀態與成敗是兩種語意，混在同一個通道上才是
根因。這個旗標把成敗那一種單獨拉出來，status 保持原樣給人看。

--verdict 之下輸出一字不變——degraded 那一行照印，人看得到——只有結束碼換一套
語意：該接的都接了就回 0，先天限制不算；真的缺項目照樣回 5。

只有 status 收這個旗標，別的子命令帶了回 2：另外三個子命令的結束碼本來就是
成敗語意，多一個旗標只會讓人以為它們也有兩套。

實測：五支 CLI 兩種模式各跑一次，只有帶先天限制那一支從 1 變 0；輸出逐字
相同；暫時拿掉一個接線項目之後 --verdict 回 5，還原後回 0；旗標的三條錯誤
路徑都回 2。

三份 manifest 版號 0.4.4 升到 0.4.5。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Merge pull request 'status 加 --verdict，把狀態與成敗兩種語意分開' (#86 ) from feat/wire-cli-status-verdict-flag into develop 27a3865e87

Reviewed-on: #86

jiantw83 added a new dependency 2026-09-04 11:12:29 +00:00

plugins/meta#78 - 釋出：唯讀盤點那一欄補一條結束碼規則，並換掉一個用結束碼帶狀態的指令

admin approved these changes 2026-09-04 11:17:01 +00:00

admin merged commit c16d30a0cf into master

2026-09-04 11:17:04 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Blocks

#78 釋出：唯讀盤點那一欄補一條結束碼規則，並換掉一個用結束碼帶狀態的指令

plugins/meta

Reference: plugins/hooks#87