status 加 --verdict,把狀態與成敗兩種語意分開 #86

Merged
admin merged 1 commits from feat/wire-cli-status-verdict-flag into develop 2026-09-04 10:09:52 +00:00
Member

摘要

  • 需求描述:助理的內建檢查項照結束碼判成敗,而 wire-cli.sh status 的結束碼帶的是狀態。於是有先天限制的那一支 CLI 每一輪讓那一筆失敗一次、一天 96 次,而沒有人修得動。這張把兩種語意分開。
  • 計畫名稱:無
  • 計畫頁:無
  • 分析頁:無

變更內容

檔案 為什麼改
tools/wire-cli.sh status 加 --verdict 旗標;用法說明與結束碼表各補一段
三份 manifest 版號 0.4.4 升到 0.4.5

同一個通道,兩種意思

誰 結束碼的意思
wire-cli.sh status 狀態:0 接好、1 接好但這支 CLI 做不到、5 有東西沒接
讀的那一邊 成敗:0 過、非零失敗

status 的三分法本身沒有錯,它是給人看的盤點。錯的是拿它當檢查。

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

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

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

那支 CLI 擋不下技能叫用是它的架構限制——技能走的是 agent 內部請求,攔不到;16 個接線項目全部就位,沒有東西要修。被一個修不動的數字每天加 96 次,就等於用假的壞掉把真的壞掉蓋掉。

為什麼修在這一邊

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

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

旗標的行為

--verdict 之下輸出一字不變——degraded 那一行照印,人看得到——只有結束碼換一套語意:

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

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

測試結果

  • 五支 CLI 兩種模式各跑一次:只有帶先天限制那一支從 1 變 0,其餘四支兩種都是 0。
  • 輸出逐字相同(diff 無輸出),status=degraded 那一行照印。
  • 暫時拿掉一個接線項目:--verdict 回 5,還原後回 0。缺陷那一路沒有被放寬。
  • 旗標的三條錯誤路徑都回 2:別的子命令帶旗標、認不得的旗標、沒給 CLI 代號。
  • lint-scripts.sh、check-behaviors.sh、ste100-lint.sh 三支都回結束碼 0。

相關的另一張

plugins/meta 那邊同時把委派清單那一格換成帶旗標的寫法,並在那一欄的檔頭補一條規則:結束碼只准表示過與不過,不准用來編碼狀態。 那是這一次真正缺的規則,兩張都合併之後才完整。

前置 Push Request

  • 無
## 摘要 - 需求描述:助理的內建檢查項照結束碼判成敗,而 `wire-cli.sh status` 的結束碼帶的是狀態。於是有先天限制的那一支 CLI 每一輪讓那一筆失敗一次、一天 96 次,而沒有人修得動。這張把兩種語意分開。 - 計畫名稱:無 - 計畫頁:無 - 分析頁:無 ## 變更內容 | 檔案 | 為什麼改 | | --- | --- | | `tools/wire-cli.sh` | `status` 加 `--verdict` 旗標;用法說明與結束碼表各補一段 | | 三份 manifest | 版號 0.4.4 升到 0.4.5 | ## 同一個通道,兩種意思 | 誰 | 結束碼的意思 | | --- | --- | | `wire-cli.sh status` | **狀態**:0 接好、1 接好但這支 CLI 做不到、5 有東西沒接 | | 讀的那一邊 | **成敗**:0 過、非零失敗 | `status` 的三分法本身沒有錯,它是給人看的盤點。錯的是拿它當檢查。 而那一支自己分得很清楚:`degraded` 是「該接的都接了,這支 CLI 做不到」,`unwired` 才是「有東西沒接」。**前者是狀態,後者是缺陷。** 讀的那一邊把兩者都當失敗。 ## 這個計數為什麼不能被填滿 失敗次數存在的理由是指出「有一筆壞掉的項目每輪重試而沒人知道」。 那支 CLI 擋不下技能叫用是它的架構限制——技能走的是 agent 內部請求,攔不到;16 個接線項目全部就位,沒有東西要修。**被一個修不動的數字每天加 96 次,就等於用假的壞掉把真的壞掉蓋掉。** ## 為什麼修在這一邊 狀態與成敗是兩種語意,混在同一個通道上才是根因。 另一條路是讓讀的那一邊認「可接受的非零碼」——那要在待辦簿加一個欄位,而且每個往後填那一欄的人都得先想「我的結束碼是哪一種語意」。修在這裡只需要知道自己的三種狀態哪一種是缺陷,而那個知識本來就在這一支裡。 ## 旗標的行為 `--verdict` 之下**輸出一字不變**——`degraded` 那一行照印,人看得到——只有結束碼換一套語意: | 情況 | `status` | `status --verdict` | | --- | --- | --- | | 接好 | 0 | 0 | | 接好但這支 CLI 做不到 | 1 | **0** | | 有東西沒接 | 5 | 5 | | 用法錯誤 | 2 | 2 | 只有 `status` 收這個旗標,別的子命令帶了回 2:另外三個子命令的結束碼本來就是成敗語意,多一個旗標只會讓人以為它們也有兩套。 ## 測試結果 - 五支 CLI 兩種模式各跑一次:只有帶先天限制那一支從 1 變 0,其餘四支兩種都是 0。 - **輸出逐字相同**(`diff` 無輸出),`status=degraded` 那一行照印。 - 暫時拿掉一個接線項目:`--verdict` 回 5,還原後回 0。缺陷那一路沒有被放寬。 - 旗標的三條錯誤路徑都回 2:別的子命令帶旗標、認不得的旗標、沒給 CLI 代號。 - `lint-scripts.sh`、`check-behaviors.sh`、`ste100-lint.sh` 三支都回結束碼 0。 ## 相關的另一張 `plugins/meta` 那邊同時把委派清單那一格換成帶旗標的寫法,並在那一欄的檔頭補一條規則:**結束碼只准表示過與不過,不准用來編碼狀態。** 那是這一次真正缺的規則,兩張都合併之後才完整。 ## 前置 Push Request - 無
jiantw83 added 1 commit 2026-09-04 10:06:36 +00:00
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>
admin merged commit 27a3865e87 into develop 2026-09-04 10:09:52 +00:00
admin deleted branch feat/wire-cli-status-verdict-flag 2026-09-04 10:09:52 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Reference: plugins/hooks#86