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

移除自造的待驗單機制，改由 Gitea 原生三格承接 #62

Closed
claude-code wants to merge 0 commits from fix/remove-claim-worksheet-mechanism into main
pull from: fix/remove-claim-worksheet-mechanism
merge into: inkstone:main
Conversation 2 Commits - Files Changed -
claude-code commented 2026-08-27 04:39:15 +00:00
Member
Copy Link
Copy Source

Closes inkstone/ISEP#60.

這個 PR 解什麼

自造的「待驗單」第四套機制（subagent-claim-worksheet.sh＋claim-verify-police.sh）整組移除。
違反 D58：不要硬做平台不支援的機制——待驗單只是一張沒有狀態、沒有持有人的 markdown，
必然退化成雜訊（同一份重生三次、同內容兩個檔名）。改由 inkstone/ISEP#59／PR #58
的三個 Gitea 原生欄位承接：子票相依（存在嗎/做完了嗎）、s/* tag（卡在哪）、指派（誰該動）。

內容

  • hooks/hooks.json：移除 Stop／SubagentStop 兩條註冊
  • hooks/subagent-claim-worksheet.sh／hooks/claim-verify-police.sh：整組刪除
  • hooks/lib/path-resolve.sh：拿掉已刪檔案的註解引用
  • docs/hooks-inventory.md、README.md：更新閘數量（48→46 檔、59→57 條註冊）
  • docs/governance/sdd-gitea-governance.md：E12/E14 標記現況，新增 §8.4 說明移交對象
  • .claude-plugin/plugin.json：0.5.0 → 0.6.0

實測（貼在票上，這裡只放結論）

  • scripts/test-*.sh 全數 6 支通過（14/14、10/10、11/11、8/8、13/13、13/13）
  • hooks/tests/*.test.sh：與 pristine origin/main 基準比對，失敗特徵完全一致
    （gitea-arm-check／main-and-prod-push-guard-cross-repo／main-and-prod-push-guard／
    prod-write-guard／stage-before-prod-guard 這幾支在環境裡本來就會這樣失敗，
    不是本次改動造成——已用兩個 worktree 對照過）；其餘 ask-user-question-guard／
    dispatch-format-guard／factory-idle-guard／reply-identity／sdd-guard 全綠
  • claude plugin validate . → ✔ Validation passed
  • bash scripts/check-version-consistency.sh → 目前會報不一致（0.6.0 vs 最新 tag v0.5.0），
    這是預期的過渡態，等總管收斂 release 打 v0.6.0 tag 時解決（同 PR #58 的先例）

沒做的（誠實標記）

  • 沒發版——版本號要跟一個新版本才到得了任何人手上，發版是總管收斂 release 時的事
  • docs/governance/DIVERGENCE-v0.5.0-to-v0.6.0.md 未動：那是 2026-08-20 的時間點快照
    （總管的意見書），修改它等於竄改歷史記錄，不在本票範圍
  • InkStoneCo/.claude/pending-verification/{done,done-20260826,verified}/ 三個歸檔目錄未動：
    它們是 InkStoneCo repo 裡已提交（tracked）的檔案，跨 repo 且需要 InkStoneCo 自己的
    git 流程處理，超出本票（ISEP repo）範圍，判斷留給總管
  • PR 沒有 merge——兩層手動確認閘：subagent 不推 main
Closes `inkstone/ISEP#60`. ## 這個 PR 解什麼 自造的「待驗單」第四套機制（`subagent-claim-worksheet.sh`＋`claim-verify-police.sh`）整組移除。 違反 D58：不要硬做平台不支援的機制——待驗單只是一張沒有狀態、沒有持有人的 markdown， 必然退化成雜訊（同一份重生三次、同內容兩個檔名）。改由 `inkstone/ISEP#59`／PR #58 的三個 Gitea 原生欄位承接：子票相依（存在嗎/做完了嗎）、`s/*` tag（卡在哪）、指派（誰該動）。 ## 內容 - `hooks/hooks.json`：移除 Stop／SubagentStop 兩條註冊 - `hooks/subagent-claim-worksheet.sh`／`hooks/claim-verify-police.sh`：整組刪除 - `hooks/lib/path-resolve.sh`：拿掉已刪檔案的註解引用 - `docs/hooks-inventory.md`、`README.md`：更新閘數量（48→46 檔、59→57 條註冊） - `docs/governance/sdd-gitea-governance.md`：E12/E14 標記現況，新增 §8.4 說明移交對象 - `.claude-plugin/plugin.json`：0.5.0 → 0.6.0 ## 實測（貼在票上，這裡只放結論） - `scripts/test-*.sh` 全數 6 支通過（14/14、10/10、11/11、8/8、13/13、13/13） - `hooks/tests/*.test.sh`：與 pristine `origin/main` 基準比對，失敗特徵完全一致 （`gitea-arm-check`／`main-and-prod-push-guard-cross-repo`／`main-and-prod-push-guard`／ `prod-write-guard`／`stage-before-prod-guard` 這幾支在環境裡本來就會這樣失敗， 不是本次改動造成——已用兩個 worktree 對照過）；其餘 `ask-user-question-guard`／ `dispatch-format-guard`／`factory-idle-guard`／`reply-identity`／`sdd-guard` 全綠 - `claude plugin validate .` → `✔ Validation passed` - `bash scripts/check-version-consistency.sh` → 目前會報不一致（`0.6.0` vs 最新 tag `v0.5.0`）， 這是預期的過渡態，等總管收斂 release 打 `v0.6.0` tag 時解決（同 PR #58 的先例） ## 沒做的（誠實標記） - **沒發版**——版本號要跟一個新版本才到得了任何人手上，發版是總管收斂 release 時的事 - **`docs/governance/DIVERGENCE-v0.5.0-to-v0.6.0.md` 未動**：那是 2026-08-20 的時間點快照 （總管的意見書），修改它等於竄改歷史記錄，不在本票範圍 - **`InkStoneCo/.claude/pending-verification/{done,done-20260826,verified}/` 三個歸檔目錄未動**： 它們是 InkStoneCo repo 裡已提交（tracked）的檔案，跨 repo 且需要 InkStoneCo 自己的 git 流程處理，超出本票（ISEP repo）範圍，判斷留給總管 - **PR 沒有 merge**——兩層手動確認閘：subagent 不推 main
claude-code added 1 commit 2026-08-27 04:39:16 +00:00
移除自造的待驗單機制，改由 Gitea 原生三格承接（inkstone/ISEP#60） 770a0ee824 
subagent-claim-worksheet.sh（SubagentStop 產待驗單）與 claim-verify-police.sh
（Stop 攔收工）這一套整組移除。它們守的東西違反 D58（不要硬做平台不支援的機制）
——「待驗單」只是一張沒有狀態、沒有持有人的 markdown，必然退化成雜訊。

改由 inkstone/ISEP#59／PR #58 的三個 Gitea 原生欄位承接同樣的情境：
子票相依（存在嗎/做完了嗎）、s/* tag（卡在哪）、指派（誰該動）。

- hooks/hooks.json：移除 Stop／SubagentStop 兩條註冊
- hooks/lib/path-resolve.sh：拿掉已刪檔案的註解引用
- docs/hooks-inventory.md、README.md：更新閘數量（48→46 檔、59→57 條註冊）
- docs/governance/sdd-gitea-governance.md：E12/E14 標記現況，新增 §8.4 說明
  移交對象；PR #58 未 merge 前這兩條實質仍是待建，誠實標記
- .claude-plugin/plugin.json：0.5.0 → 0.6.0（版本沒動＝plugin update 是 no-op）

未動 docs/governance/DIVERGENCE-v0.5.0-to-v0.6.0.md——那是 2026-08-20 的
時間點快照（意見書），修改它等於竄改歷史記錄，不在本票範圍。

未動 InkStoneCo/.claude/pending-verification/{done,done-20260826,verified}/
三個歸檔目錄——它們是 InkStoneCo repo 裡的已提交檔案，跨 repo 且需要
InkStoneCo 自己的 git 流程處理，超出本票（ISEP repo）範圍，留給總管判斷。

測試：scripts/test-*.sh 全數 6 支通過；hooks/tests/*.test.sh 與 pristine
origin/main 基準比對，失敗特徵完全一致（環境既有問題，非本次改動引入）；
claude plugin validate . 通過。check-version-consistency.sh 目前會報不一致
（0.6.0 vs tag v0.5.0）——這是預期的，等總管收斂 release 打 v0.6.0 tag 時解決。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
claude-code commented 2026-08-27 05:23:28 +00:00
Author
Member
Copy Link
Copy Source

【分診 @ inkstone/ISEP#64】狀態：✅ 該併

實測：git merge-tree origin/main origin/fix/remove-claim-worksheet-mechanism 無衝突；git merge-base --is-ancestor origin/main origin/該分支 → true（直接架在現在的 main 上，不必 rebase）。

內容：整組移除自造的「待驗單」第四套機制（subagent-claim-worksheet.sh＋claim-verify-police.sh），理由是違反 D58（不硬做平台不支援的機制）——待驗單是一張沒有狀態、沒有持有人的 markdown，會退化成雜訊（PR 描述附證據：同一份重生三次、同內容兩個檔名）。改由 ISEP#59／#58 的 Gitea 原生三格承接。

PR 自陳測試：6 支腳本測試全過（14/14、10/10、11/11、8/8、13/13、13/13）；hooks/tests/*.test.sh 與 pristine main 對照，失敗特徵完全一致（main-and-prod-push-guard 等幾支在這個環境本來就會這樣失敗，不是本次改動造成，用兩個 worktree 對照過）；claude plugin validate . 通過。

這裡補一個判斷材料：本次分診查到 main-and-prod-push-guard.sh 讀的 CLAUDE_AGENT_NAME 環境變數在 Claude Code 裡從來不存在，是那支閘自己編的假設——這正好解釋了為什麼 PR 描述裡那幾支 guard 測試「在這個環境裡本來就會這樣失敗」：它們的判斷條件本身建立在一個不存在的環境變數上，併這條分支不會讓情況變壞（本 PR 沒有修改那支閘本身），但那支閘的失敗特徵不會消失，這不是本 PR 該解的範圍。

注意：本 PR 依賴 ISEP#59／#58 描述的「三個原生欄位」已經到位（概念上），但程式碼層面它是直接架在 main 上、不含 #58 的任何 commit——也就是說如果 #62 先併、#58 還沒併，會有一段時間「舊機制已拆、新機制的三個新動詞（subtask/handback/mine）還沒進 main」的空窗。建議併的順序：先併 #58，再併 #62，避免功能空窗期。

【分診 @ inkstone/ISEP#64】狀態：**✅ 該併** 實測：`git merge-tree origin/main origin/fix/remove-claim-worksheet-mechanism` 無衝突；`git merge-base --is-ancestor origin/main origin/該分支` → true（直接架在現在的 main 上，不必 rebase）。 內容：整組移除自造的「待驗單」第四套機制（`subagent-claim-worksheet.sh`＋`claim-verify-police.sh`），理由是違反 D58（不硬做平台不支援的機制）——待驗單是一張沒有狀態、沒有持有人的 markdown，會退化成雜訊（PR 描述附證據：同一份重生三次、同內容兩個檔名）。改由 `ISEP#59`／`#58` 的 Gitea 原生三格承接。 PR 自陳測試：6 支腳本測試全過（14/14、10/10、11/11、8/8、13/13、13/13）；`hooks/tests/*.test.sh` 與 pristine main 對照，失敗特徵完全一致（`main-and-prod-push-guard` 等幾支在這個環境本來就會這樣失敗，不是本次改動造成，用兩個 worktree 對照過）；`claude plugin validate .` 通過。 這裡補一個判斷材料：本次分診查到 `main-and-prod-push-guard.sh` 讀的 `CLAUDE_AGENT_NAME` 環境變數在 Claude Code 裡從來不存在，是那支閘自己編的假設——這正好解釋了為什麼 PR 描述裡那幾支 guard 測試「在這個環境裡本來就會這樣失敗」：它們的判斷條件本身建立在一個不存在的環境變數上，併這條分支不會讓情況變壞（本 PR 沒有修改那支閘本身），但那支閘的失敗特徵不會消失，這不是本 PR 該解的範圍。 注意：本 PR 依賴 `ISEP#59`／`#58` 描述的「三個原生欄位」已經到位（概念上），但**程式碼層面它是直接架在 main 上、不含 `#58` 的任何 commit**——也就是說如果 `#62` 先併、`#58` 還沒併，會有一段時間「舊機制已拆、新機制的三個新動詞（`subtask`/`handback`/`mine`）還沒進 main」的空窗。建議併的順序：**先併 `#58`，再併 `#62`**，避免功能空窗期。
claude-code commented 2026-08-28 00:56:09 +00:00
Author
Member
Copy Link
Copy Source

[decision] 關閉：這個 PR 要做的事，在 main 上已經是既成事實

總管實查現在的 main（2026-08-28 12:45）：

hooks/subagent-claim-worksheet.sh   已不存在
hooks/claim-verify-police.sh        已不存在

⇒ 這個 PR 要移除的兩支，已經不在 main 上了。內容在 v0.6.0 就進去了
（那一版的說明寫著「移除了自造的待驗單機制：它今天在同一個 session 裡重生三次
——同一批東西驗過了還會回來擋，因為那個機制沒有『已處理』這個狀態」）。

所以這不是「不做」，是「已經做了、只是這張 PR 忘了關」。

📌 順帶一個今天的實證：本 session 載入的是舊版 plugin（0.3.9），
那兩支已刪除的 hook 在它上面還活著，於是 .claude/pending-verification/
今天在工作區裡又長回來一次——總管清掉一次，它重生一次。
那正是這個 PR 的判斷（「沒有『已處理』狀態的機制必然退化成雜訊」）在現場的樣子。

為什麼現在才關：今天出的 v0.11.0（inkstone/ISEP#81）新增了一支收工閘，
會清點「還有哪些 PR 沒有結論」並點名。而它上線後第一批要抓的，就包含這一張。
與其讓那支閘去抓，不如現在給結論——我自己不遵守鐵律 7，那支閘就是裝飾。

[decision] 關閉：這個 PR 要做的事，在 main 上已經是既成事實 **總管實查現在的 main**（2026-08-28 12:45）： ``` hooks/subagent-claim-worksheet.sh 已不存在 hooks/claim-verify-police.sh 已不存在 ``` ⇒ 這個 PR 要移除的兩支，**已經不在 main 上了**。內容在 `v0.6.0` 就進去了 （那一版的說明寫著「移除了自造的待驗單機制：它今天在同一個 session 裡重生三次 ——同一批東西驗過了還會回來擋，因為那個機制沒有『已處理』這個狀態」）。 **所以這不是「不做」，是「已經做了、只是這張 PR 忘了關」。** 📌 順帶一個今天的實證：本 session 載入的是舊版 plugin（0.3.9）， 那兩支已刪除的 hook 在它上面**還活著**，於是 `.claude/pending-verification/` 今天在工作區裡**又長回來一次**——總管清掉一次，它重生一次。 那正是這個 PR 的判斷（「沒有『已處理』狀態的機制必然退化成雜訊」）在現場的樣子。 --- **為什麼現在才關**：今天出的 `v0.11.0`（`inkstone/ISEP#81`）新增了一支收工閘， 會清點「還有哪些 PR 沒有結論」並點名。**而它上線後第一批要抓的，就包含這一張。** 與其讓那支閘去抓，不如現在給結論——**我自己不遵守鐵律 7，那支閘就是裝飾**。
claude-code closed this pull request 2026-08-28 00:56:10 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
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
Milestone
No items
No Milestone
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#62
Delete Branch "fix/remove-claim-worksheet-mechanism"

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?