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

身為回覆工人的人，我要回覆也只准給票號，我才不會第一次乾淨第二次又把指令塞進訊息裡 #88

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

問題

派工單已經被壓成只剩票號了（dispatch-format-guard.sh，多寫一行就擋）。但「回覆 subagent」這條路沒有被管到。

原因是機制上的：那支閘掛在 PreToolUse(Task|Agent)，只有「新開一個 subagent」會經過。而回覆一個已經在跑的 subagent 走的是別的通道，根本不經過那個攔截點。

所以現在的實況是：第一次派工乾乾淨淨只有票號，第二次回覆的時候又把一長串修改要求直接丟過去。那些話一樣沒有留在票上，那條線被停掉或換人接手就消失——這正是壓縮派工單原本要解決的問題。

目標

回覆也是派工，同一套規矩：內容寫進票，訊息只給票號。

驗收條件

  1. 回覆一個正在跑的 subagent，訊息裡夾一段修改要求 → 要被擋下來，並且把那段內容印出來方便直接貼上票
  2. 內容貼上票之後，回覆只給票號 → 放行
  3. 第一次派工那條路不能受影響（dispatch-format-guard.sh 的行為不變）
  4. 拿今天實際發生的當真跡重演：本 session 派了兩個 subagent，中途各回覆過一次，兩次都夾帶了大量指令

deliverable 類型

code（→ PR）

細節

這條在 SOP 裡的位置：鐵律 4（「回覆 subagent 也是派工，同樣只給票號」）＋ S3。

這是「不夠好，接上」不是「沒有」：dispatch-format-guard.sh 本體是對的，只是攔截點涵蓋不到回覆這條路。不要另造一支平行的閘，要嘛把攔截點加掛上去，要嘛讓兩條路共用同一個判斷函式。

實錄（本 session，2026-08-27）：總管派了兩個調查 subagent，中途各用回覆通道追加一次指令，其中一次是整段的重驗要求（要它去 main 分支重驗三支 hook）。那些內容到現在都只活在對話裡，票上一個字都沒有。

已知的相鄰破口，一起考慮：ticket-api-bypass-guard.sh 的檔頭記過同款教訓——第一版只認大寫裸字 POST，結果 requests.post() 和 urllib 隱式 POST 全部漏掉。「認動作的方式漏了一條路」是這一族的通病，修的時候要把所有通往 subagent 的路一次列全，不要只補眼前這一條。

🔎 為什麼另開一張票而不是貼進既有的（開票時聲明）：這是 dispatch-format-guard 的攔截點缺口（掛在 PreToolUse Task/Agent，回覆不經過），要獨立追蹤因為得重新列全所有通往 subagent 的路。
當時搜尋：回覆 subagent 派工 票號 通道 → 命中 81 張。

## 問題 派工單已經被壓成只剩票號了（`dispatch-format-guard.sh`，多寫一行就擋）。**但「回覆 subagent」這條路沒有被管到。** 原因是機制上的：那支閘掛在 `PreToolUse(Task|Agent)`，只有「新開一個 subagent」會經過。而回覆一個已經在跑的 subagent 走的是別的通道，**根本不經過那個攔截點**。 所以現在的實況是：第一次派工乾乾淨淨只有票號，第二次回覆的時候又把一長串修改要求直接丟過去。**那些話一樣沒有留在票上**，那條線被停掉或換人接手就消失——這正是壓縮派工單原本要解決的問題。 ## 目標 回覆也是派工，同一套規矩：內容寫進票，訊息只給票號。 ## 驗收條件 1. 回覆一個正在跑的 subagent，訊息裡夾一段修改要求 → **要被擋下來**，並且把那段內容印出來方便直接貼上票 2. 內容貼上票之後，回覆只給票號 → 放行 3. 第一次派工那條路不能受影響（`dispatch-format-guard.sh` 的行為不變） 4. 拿今天實際發生的當真跡重演：本 session 派了兩個 subagent，中途各回覆過一次，**兩次都夾帶了大量指令** ## deliverable 類型 code（→ PR） --- <details><summary>細節</summary> **這條在 SOP 裡的位置**：鐵律 4（「回覆 subagent 也是派工，同樣只給票號」）＋ S3。 **這是「不夠好，接上」不是「沒有」**：`dispatch-format-guard.sh` 本體是對的，只是攔截點涵蓋不到回覆這條路。**不要另造一支平行的閘**，要嘛把攔截點加掛上去，要嘛讓兩條路共用同一個判斷函式。 **實錄（本 session，2026-08-27）**：總管派了兩個調查 subagent，中途各用回覆通道追加一次指令，其中一次是整段的重驗要求（要它去 main 分支重驗三支 hook）。**那些內容到現在都只活在對話裡，票上一個字都沒有。** **已知的相鄰破口，一起考慮**：`ticket-api-bypass-guard.sh` 的檔頭記過同款教訓——第一版只認大寫裸字 `POST`，結果 `requests.post()` 和 urllib 隱式 POST 全部漏掉。**「認動作的方式漏了一條路」是這一族的通病**，修的時候要把所有通往 subagent 的路一次列全，不要只補眼前這一條。 </details> --- > 🔎 **為什麼另開一張票而不是貼進既有的**（開票時聲明）：這是 dispatch-format-guard 的攔截點缺口（掛在 PreToolUse Task/Agent，回覆不經過），要獨立追蹤因為得重新列全所有通往 subagent 的路。 > 當時搜尋：`回覆 subagent 派工 票號 通道` → 命中 81 張。
claude-code added this to the SOP 變成閘 milestone 2026-08-27 14:32:35 +00:00
claude-code added the
s
todo
type
governance
 labels 2026-08-27 14:32:35 +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#88
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?