inkstone/ISEP
2
0
Fork 0
Code Issues 18 Pull Requests 1 Actions Packages Projects Releases 22 Wiki Activity

身為派人去查的人，我要自己在拿到調查結果前寫不出診斷，我才不會用猜的結論把工人的判斷力關掉 #87

New Issue
Closed
opened 2026-08-27 14:31:11 +00:00 by claude-code · 0 comments
claude-code commented 2026-08-27 14:31:11 +00:00
Member
Copy Link
Copy Source

問題

我常常在還沒派人去查之前，就先把「我覺得是什麼問題」寫進票裡。

這會壞掉兩次：

  • 診斷寫完了，工人就不知道自己要做什麼——它會照著我的結論去驗證，而不是去查
  • 我不是那個 repo 的專家，它才是。我的結論通常是猜的，但因為寫在票上，看起來就像事實

leo 2026-08-27：「票裡寫未經調查的診斷」是今天犯的錯之一。

目標

順序倒過來：先派人查 → 拿到查的結果 → 才可以寫診斷。

我的診斷只能建立在別人查回來的東西上面，不能建立在我的印象上面。

驗收條件

  1. 開一張還沒有人查過的票，在裡面寫「根因是 X」→ 要被擋一次
  2. 派人查過、結論貼回票上了，再寫診斷 → 放行
  3. 擋的訊息要講得出「你還沒派人查這件事」，不是籠統的「格式不對」
  4. 只是轉述別人查到的東西（有出處）→ 不能被誤擋

deliverable 類型

code（→ PR）

細節

這條在 SOP 裡的位置：規則 0-2 ＋ 鐵律 2 的後半（「未經調查不寫診斷」）。

鐵律 2 的前半已經有了：subagent-first-guard.sh（PreToolUse Write|Edit|MultiEdit，要改 code 卻一次都沒派工就擋一次）＋ subagent-first-stamp.sh（記下這個 session 真的派過工）。後半沒有任何東西在管。

與既有鐵律相符：CLAUDE.md 的「派工鐵律：寫目的，不寫做法」（leo 2026-08-07 立）講的是同一件事的另一面——「指令越具體，收工方越不會質疑，我等於用權威關掉了它的檢查」。而 micromanage-guard.sh 已經在擋「替對方決定做法」的五種訊號。本票擋的是「替對方決定答案」，是它的近親但不是同一支。

🔴 這一支最容易做成誤攔：leo 2026-08-17 實測過，文字層的閘那天「8 次誤攔、0 次正確攔截」，而且方向穩定——紅線寫得越細，命中關鍵字的機率越高，那些閘在懲罰謹慎。所以這支的判準必須是結構性訊號（這個 session 有沒有派過工去查這張票、票上有沒有帶出處的調查結論），不能是關鍵字比對（「根因」「因為」「應該是」這類詞一律不准當判準）。

參考現成做法：kbdb-asked-stamp.sh / subagent-first-stamp.sh 都是「記下某件事真的發生過」的戳記型 hook，這支可以照抄那個形狀。

🔎 為什麼另開一張票而不是貼進既有的（開票時聲明）：subagent-first-guard 管鐵律 2 前半「不寫 code」，本票是後半「未經調查不寫診斷」。micromanage-guard 擋替對方決定做法，本票擋替對方決定答案。
當時搜尋：調查 診斷 順序 結論 → 命中 65 張。

## 問題 我常常在還沒派人去查之前，就先把「我覺得是什麼問題」寫進票裡。 這會壞掉兩次： - **診斷寫完了，工人就不知道自己要做什麼**——它會照著我的結論去驗證，而不是去查 - **我不是那個 repo 的專家，它才是**。我的結論通常是猜的，但因為寫在票上，看起來就像事實 leo 2026-08-27：「**票裡寫未經調查的診斷**」是今天犯的錯之一。 ## 目標 順序倒過來：先派人查 → 拿到查的結果 → 才可以寫診斷。 我的診斷只能建立在別人查回來的東西上面，不能建立在我的印象上面。 ## 驗收條件 1. 開一張還沒有人查過的票，在裡面寫「根因是 X」→ **要被擋一次** 2. 派人查過、結論貼回票上了，再寫診斷 → 放行 3. 擋的訊息要講得出「你還沒派人查這件事」，不是籠統的「格式不對」 4. 只是轉述別人查到的東西（有出處）→ **不能被誤擋** ## deliverable 類型 code（→ PR） --- <details><summary>細節</summary> **這條在 SOP 裡的位置**：規則 0-2 ＋ 鐵律 2 的後半（「未經調查不寫診斷」）。 **鐵律 2 的前半已經有了**：`subagent-first-guard.sh`（PreToolUse Write|Edit|MultiEdit，要改 code 卻一次都沒派工就擋一次）＋ `subagent-first-stamp.sh`（記下這個 session 真的派過工）。**後半沒有任何東西在管。** **與既有鐵律相符**：`CLAUDE.md` 的「派工鐵律：寫目的，不寫做法」（leo 2026-08-07 立）講的是同一件事的另一面——「指令越具體，收工方越不會質疑，我等於用權威關掉了它的檢查」。而 `micromanage-guard.sh` 已經在擋「替對方決定做法」的五種訊號。**本票擋的是「替對方決定答案」**，是它的近親但不是同一支。 **🔴 這一支最容易做成誤攔**：leo 2026-08-17 實測過，文字層的閘那天「8 次誤攔、0 次正確攔截」，而且方向穩定——**紅線寫得越細，命中關鍵字的機率越高，那些閘在懲罰謹慎**。所以這支的判準必須是**結構性訊號**（這個 session 有沒有派過工去查這張票、票上有沒有帶出處的調查結論），**不能是關鍵字比對**（「根因」「因為」「應該是」這類詞一律不准當判準）。 **參考現成做法**：`kbdb-asked-stamp.sh` / `subagent-first-stamp.sh` 都是「記下某件事真的發生過」的戳記型 hook，這支可以照抄那個形狀。 </details> --- > 🔎 **為什麼另開一張票而不是貼進既有的**（開票時聲明）：subagent-first-guard 管鐵律 2 前半「不寫 code」，本票是後半「未經調查不寫診斷」。micromanage-guard 擋替對方決定做法，本票擋替對方決定答案。 > 當時搜尋：`調查 診斷 順序 結論` → 命中 65 張。
claude-code added this to the SOP 變成閘 milestone 2026-08-27 14:32:33 +00:00
claude-code added the
s
todo
type
governance
 labels 2026-08-27 14:32:34 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Human
👤 這件事需要 leo 親手批示／動手（花錢・不可逆・品味方向・物理動作）。與 s/* 正交
close
duplicate
重複——關新的、留舊的，並指向舊票
close
human-exec
人執票完成，由人手動關
close
merged
PR merge 自動關（正常路徑）
close
split
太大，已拆成數張子票
close
stale
逾期無資訊，自動關閉
close
transferred
走錯棚，已在正確的 repo 重開
close
wontfix
討論後決定不做（只有 leo 可下此判斷）
hub
Tracking issue——聚合一批 leaf 的 scope 容器，本身不掛 milestone、不對應 PR
 human/exec
👤 這張票的『執行者』是人（GUI-only／實體權限／法定簽署），不是審核。交付物是環境狀態改變，不是 PR
p
high
高——擋住交付或有時間壓力
p
low
低——想做，但晚一點沒關係
s
backlog
驗過了、確定要做，但還沒排進任何 sprint
s
doing
進行中——已 self-assign，現在有人在做
s
pending
卡住——等外部／等依賴，不是沒人做
s
review
PR 已開（含 closes #n），等總管 review 並 merge
s
stage
已部署 stage，等 leo 實際驗收
s
todo
已排進 milestone，等人領票
s
triage
新進來的，還沒驗傷——還沒決定要不要做
type
bug
壞掉的東西
type
chore
雜務、整理、不改行為
type
feature
新能力
type
governance
規範、流程、閘本身
No Label
s
todo
type
governance
Milestone
No items
No Milestone SOP 變成閘
Projects
Clear projects
No project
Assignees
Clear assignees
Leo claude-code (claude-code)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: inkstone/ISEP#87
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?