Compare commits
18 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 2cd3af2764 | |||
| 2fb18e9f48 | |||
| aec7f3a980 | |||
| 34e7c45eb4 | |||
| 500b95d80d | |||
| 7b96f238b6 | |||
| 627f924342 | |||
| 5c3dea6e6c | |||
| c5e82c2617 | |||
| 065bb8f729 | |||
| e4e3d69acf | |||
| ff705c2313 | |||
| d238b72882 | |||
| 4a8f3093da | |||
| 09979b2357 | |||
| 3b763c829c | |||
| 50876ffa4f | |||
| 45bf7b4a52 |
@@ -2,12 +2,17 @@
|
||||
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
||||
"name": "inkstone",
|
||||
"description": "InkStoneCo 自用的 Claude Code 環境",
|
||||
"owner": { "name": "Leo" },
|
||||
"owner": {
|
||||
"name": "Leo"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"name": "isep",
|
||||
"description": "InkStone Environment Plugin —— 機械閘/command/skill/腳本的唯一真相源",
|
||||
"author": { "name": "Leo" },
|
||||
"description": "InkStone Environment Plugin —— leo 的 Claude Code 環境唯一真相源:42 支機械閘(52 條註冊)、7 支 slash command、2 支 skill、25 支腳本,外加治理規範與標籤真相源。本機與雲端裝同一份,沒有子集。",
|
||||
"author": {
|
||||
"name": "Leo",
|
||||
"url": "https://uncle6.me"
|
||||
},
|
||||
"category": "productivity",
|
||||
"source": "./"
|
||||
}
|
||||
|
||||
@@ -1,6 +1,16 @@
|
||||
{
|
||||
"name": "isep",
|
||||
"description": "InkStone Environment Plugin —— leo 的 Claude Code 環境唯一真相源:41 支機械閘、7 支 slash command、2 支 skill、23 支腳本。本機與雲端裝同一份。",
|
||||
"version": "0.1.0",
|
||||
"keywords": ["inkstone", "guardrails", "hooks", "gitea", "arcrun"]
|
||||
"description": "InkStone Environment Plugin —— leo 的 Claude Code 環境唯一真相源:42 支機械閘(52 條註冊)、7 支 slash command、2 支 skill、25 支腳本,外加治理規範與標籤真相源。本機與雲端裝同一份,沒有子集。",
|
||||
"version": "0.2.0",
|
||||
"keywords": [
|
||||
"inkstone",
|
||||
"guardrails",
|
||||
"hooks",
|
||||
"gitea",
|
||||
"arcrun"
|
||||
],
|
||||
"author": {
|
||||
"name": "Leo",
|
||||
"url": "https://uncle6.me"
|
||||
}
|
||||
}
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
|
||||
| | 數量 | 是什麼 |
|
||||
|---|---|---|
|
||||
| `hooks/` | 41 支 + `hooks.json` | 全部機械閘(PreToolUse/Stop/SubagentStop/SessionStart/PostToolUse 共 51 條註冊) |
|
||||
| `hooks/` | 42 支 + `hooks.json` | 全部機械閘(PreToolUse/Stop/SubagentStop/SessionStart/PostToolUse 共 52 條註冊) |
|
||||
| `commands/` | 7 支 | `/wiki-recall` `/ship-check` `/cp-write` … |
|
||||
| `skills/` | 2 支 | |
|
||||
| `scripts/` | 23 支 | `ticket`/`github-arm.sh`/`gitea-bootstrap.sh` … |
|
||||
@@ -43,6 +43,14 @@ hook 一律用官方的 `${CLAUDE_PLUGIN_ROOT}`,**不准寫死絕對路徑、
|
||||
🔴 **只改這裡,然後兩邊 `/plugin update`。**
|
||||
不要再改 `InkStoneCo/.claude/hooks/`——那個目錄退場中。
|
||||
|
||||
## 狀態
|
||||
## 版本
|
||||
|
||||
- 0.1.0 — 從 `InkStoneCo/.claude/` 搬過來,51 條 hook 路徑全部改成 `${CLAUDE_PLUGIN_ROOT}`
|
||||
**「ISEP 現在是哪一版」只有一個地方答得出來:[Gitea Releases](https://git.uncle6.me/inkstone/ISEP/releases)。**
|
||||
每一版的內容、改了什麼、驗過什麼都寫在那裡的 release note,不寫在這份 README。
|
||||
|
||||
這份 README 本來寫死過「狀態:0.1.0」,但 repo 一個 tag 都沒打(`release_counter=0`)——
|
||||
leo 當場指出這是違規:宣稱交付卻沒有 tag 撐它(`inkstone/ISEP#6`)。
|
||||
現在改成結構性防漂移:`.claude-plugin/plugin.json` 的 `version` 欄位永遠跟最新 tag 一致,
|
||||
`scripts/check-version-consistency.sh` 會擋下兩者對不上的狀態,
|
||||
`hooks/release-tag-guard.sh` 則在打 tag 的當下直接擋住不一致的 tag——
|
||||
細節與判準都寫在那兩支腳本開頭的註解。
|
||||
|
||||
@@ -0,0 +1,171 @@
|
||||
# 雲端 session 怎麼載到 ISEP —— inkstone/ISEP#5
|
||||
|
||||
對照 `docs/governance/sdd-gitea-governance.md` §11.3「載入契約」三條硬規則
|
||||
(L11.3.1/L11.3.2/L11.3.3)與其驗收標準(L11.3.4:能貼出雲端實際載到的清單,
|
||||
逐條對上 ISEP 的註冊條數)。本檔記錄機制、實測結果、還缺什麼。
|
||||
|
||||
## 舊模型死在哪(不要重蹈)
|
||||
|
||||
`InkStoneCo/.claude/cloud-shell/`(`generate-shell-payload.py` + 薄殼)的模型是:
|
||||
真身 hook/command/skill → 產生器跑出「薄殼該長的樣子」→ 人推一份**複製本**進
|
||||
GitHub 私 repo `youlinhsieh/inkstoneco`。這條鏈上兩個環節都「要有人記得」:
|
||||
|
||||
- 忘了重跑產生器 → 產物落後真身
|
||||
- 產物沒推 → 薄殼落後產物
|
||||
|
||||
`inkstone/InkStoneCo#57` 的實測:薄殼比真身少 7 支閘,其中兩支才立一天。
|
||||
`#14` 更早:雲端 33 支閘一支都沒生效。**兩次同一個病**:任何「複製一份」的設計,
|
||||
新鮮度只能靠人記得,而人會忘。
|
||||
|
||||
## 新機制:讓 Claude Code 自己的 plugin marketplace 去裝真身
|
||||
|
||||
不做複製,改用 Claude Code 原生支援、且經官方文件證實可行的路徑:
|
||||
|
||||
1. **ISEP 本身已經是一個合法 plugin**(`.claude-plugin/plugin.json` +
|
||||
`.claude-plugin/marketplace.json`,另一張票的產物),hook 一律用
|
||||
`${CLAUDE_PLUGIN_ROOT}`,不寫死路徑。
|
||||
2. Cloud environment 的 **Setup script**(code-on-web 原生功能,
|
||||
在 Claude Code 啟動**之前**跑,跑在同一台會被拍成快照的 VM 上)裡跑:
|
||||
```
|
||||
claude plugin marketplace add https://git.uncle6.me/inkstone/ISEP.git --scope user
|
||||
claude plugin install isep@inkstone --scope user
|
||||
```
|
||||
這兩行**不是複製**——跟本機 `claude plugin install` 是同一條路徑,裝的內容
|
||||
100% 來自 ISEP 這個 repo 的 HEAD,沒有第二份、沒有產生器、沒有「子集」。
|
||||
3. Setup script 跑完,Anthropic 把整個檔案系統(含 `~/.claude/plugins/`)拍成快照,
|
||||
之後每個新 session 直接沿用快照,**在 Claude Code 啟動當下**(不是「clone 完才補」)
|
||||
plugin 就已經在磁碟上——`command`/`skill` 啟動時的目錄掃描掃得到,不再是
|
||||
`#14` 那個「hook 可以晚到、skill/command 不行」的破口(見 L11.3.2)。
|
||||
|
||||
私有 repo 的認證:不把 token 寫進任何檔案,改用官方文件建議的 CI/CD 寫法——
|
||||
用 `GITEA_TOKEN_CLAUDE_CODE`(既有機器帳號 token,`InkStoneCo#14` 已建立的同一把,
|
||||
沒有新造)在 Setup script 裡做一次 git URL 重寫:
|
||||
|
||||
```sh
|
||||
git config --global url."https://x-access-token:${GITEA_TOKEN_CLAUDE_CODE}@git.uncle6.me/".insteadOf \
|
||||
"https://git.uncle6.me/"
|
||||
```
|
||||
|
||||
`marketplace add` 用乾淨網址(不帶 token),認證完全交給上面那條重寫,
|
||||
所以 `known_marketplaces.json` 裡存的來源網址也不帶 token
|
||||
(本機實測驗過,見下面「已驗」第 2 輪)。
|
||||
|
||||
完整腳本:`docs/cloud-setup-script.sh`(貼進 code-on-web 的 Setup script 欄位用)。
|
||||
|
||||
## 已驗(本機,隔離環境,不影響本機正在跑的任何 session)
|
||||
|
||||
🔴 **怎麼保證沒有干擾**:全程把 `$HOME` 指到 scratchpad 底下的隔離目錄
|
||||
(`isep-test-home`/`isep-test-home2`),從未寫到真正的 `~/.claude/`,
|
||||
也沒有動到 `InkStoneCo/.claude/` 那份舊設定。兩者互不相干,
|
||||
本機目前跑著的其他 session/agent 全程沒受影響。
|
||||
|
||||
**第 1 輪**(token 直接嵌在 marketplace URL 裡,沿用 ISEP 這個 git checkout
|
||||
本來就有的、已解析好的 origin 憑證——不是我另外造的憑證,是既有機制解析出來的那份):
|
||||
|
||||
```
|
||||
$ claude plugin marketplace add "https://claude-code:<token>@git.uncle6.me/inkstone/ISEP.git" --scope user
|
||||
Adding marketplace…Refreshing marketplace cache (timeout: 120s)…
|
||||
Cloning repository (timeout: 120s): https://***:***@git.uncle6.me/inkstone/ISEP.git
|
||||
Clone complete, validating marketplace…
|
||||
✔ Successfully added marketplace: inkstone (declared in user settings)
|
||||
|
||||
$ claude plugin install isep@inkstone --scope user
|
||||
Installing plugin "isep@inkstone"...✔ Successfully installed plugin: isep@inkstone (scope: user)
|
||||
|
||||
$ claude plugin list
|
||||
Installed plugins:
|
||||
❯ isep@inkstone
|
||||
Version: 0.0.0
|
||||
Scope: user
|
||||
Status: ✔ enabled
|
||||
```
|
||||
|
||||
**第 2 輪**(重跑一次,改用實際要交付的「乾淨 URL + git config url.insteadOf 重寫」
|
||||
寫法,驗證 §建議腳本 那段真的可行,而不是理論上可行):
|
||||
|
||||
```
|
||||
$ git config --global url."https://x-access-token:<token>@git.uncle6.me/".insteadOf "https://git.uncle6.me/"
|
||||
$ claude plugin marketplace add https://git.uncle6.me/inkstone/ISEP.git --scope user
|
||||
✔ Successfully added marketplace: inkstone (declared in user settings)
|
||||
$ claude plugin install isep@inkstone --scope user
|
||||
✔ Successfully installed plugin: isep@inkstone (scope: user)
|
||||
|
||||
$ cat ~/.claude/plugins/known_marketplaces.json
|
||||
{
|
||||
"inkstone": {
|
||||
"source": { "source": "git", "url": "https://git.uncle6.me/inkstone/ISEP.git" },
|
||||
...
|
||||
}
|
||||
}
|
||||
```
|
||||
⇒ 存在磁碟上的 marketplace 來源紀錄**不帶 token**——符合 L11.3.3「憑證只准取名字」。
|
||||
|
||||
**逐條對照**(`claude plugin details isep@inkstone` 的輸出 + 直接數快取目錄裡的檔案,
|
||||
對照 ISEP 這次測試當下的 Gitea `main` HEAD):
|
||||
|
||||
| | 裝到本機隔離環境的 | ISEP `main` 當下的來源 | 對上了嗎 |
|
||||
|---|---|---|---|
|
||||
| Skills | 9(`cp-write`/`deep-recall`/`issue-handle`/`sdd-check`/`ship-check`/`wiki-capture`/`wiki-init`/`wiki-recall`/`wiki-update`) | `commands/` 7 支 + `skills/` 2 支 = 9 | ✅ 逐支比對名稱一致 |
|
||||
| Commands 目錄 | 7 個 `.md` | 7 個 `.md` | ✅ `diff` 兩邊檔名清單完全一致 |
|
||||
| Skills 目錄 | `deep-recall`/`ship-check` 2 個 | 同 | ✅ |
|
||||
| Hook 腳本(`hooks/*.sh` 實體檔) | 42 支 | 42 支 | ✅ `ls` 兩邊都是 42 |
|
||||
| `hooks.json` 裡註冊的 hook 腳本路徑(去重) | 39 支唯一路徑 | 39 支 | ✅ `diff` 兩邊 grep 結果完全一致 |
|
||||
|
||||
(42 支實體檔 vs 39 支被 `hooks.json` 引用:差的 3 支是 `hooks.json` 自己
|
||||
+ `pre-write-guard.sh`/`pre-write-guard.template.sh` 這類非直接掛註冊的輔助檔,
|
||||
兩邊都一樣,不是漏裝。)
|
||||
|
||||
**意外的額外證據**:測試途中 ISEP 的 `main` 因為別的票(`#6`/`#9` 等)合併而往前推進
|
||||
(多出 `hooks/release-tag-guard.sh`、`docs/governance/`…),**下一次 `claude plugin
|
||||
marketplace update` / 重裝立刻拿到新內容**——證明這條路徑讀的是 Gitea 當下的 HEAD,
|
||||
不是任何時間點的快照複製本。
|
||||
|
||||
## 沒驗到的(明講,不含糊)
|
||||
|
||||
- ❌ **沒有在真正的 code-on-web 雲端 session 裡跑過。** 本機能做到的最接近測試是
|
||||
「隔離 `$HOME` + 真的私有 repo + 真的 `claude plugin` CLI」,但 Cloud environment
|
||||
的 Setup script 欄位、Environment variables 欄位是 claude.ai 帳號層級的設定,
|
||||
我沒有去改——那是 leo 的 dashboard,不是這台機器上的檔案,我也判斷這件事
|
||||
不屬於「可以自己裁」的範圍(不是 GitHub push,但同樣是帳號層級設定,
|
||||
比照 D20 的精神交給 leo 動手)。
|
||||
- ❌ **沒有驗到「hook 真的攔下第一個工具呼叫」這一步的完整 runtime 行為**——
|
||||
只驗到「plugin 在磁碟上正確就位、`claude plugin list` 回報 enabled」。
|
||||
完整跑一個已登入的 `claude -p` session需要這台機器的 Claude Code 登入憑證
|
||||
(存在 macOS Keychain,不是可複製的檔案),我判斷把它匯出到隔離測試環境
|
||||
超出這張票該做的事,沒有做。
|
||||
Q5(plugin 是否在 SessionStart 前同步就位、保證第一個工具呼叫就有效)
|
||||
這格的證據來自官方文件(`plugin-marketplaces.md` §Pre-populate plugins for
|
||||
containers:「At startup, Claude Code registers marketplaces found in the
|
||||
seed's `known_marketplaces.json`... This works in both interactive mode and
|
||||
non-interactive mode with the `-p` flag.」),**不是我自己重現的 runtime 實測**。
|
||||
- ❌ **Environment caching 的 ~7 天新鮮度窗口沒有解**——setup script 只在
|
||||
「這個 environment 第一次開 session」跑一次,之後沿用快照,直到快照過期
|
||||
(約 7 天)或 leo 改了 setup script/allowed network hosts 才重跑。
|
||||
這代表 ISEP 若在窗口期內更新,雲端會暫時停在舊版本,直到快照重建。
|
||||
這不是本票要解的「載不載得到」問題,而是另一種新鮮度問題,**留給 leo 決定
|
||||
要不要另開票**(例如:leo 定期手動點一下「rebuild environment」,或接受
|
||||
7 天週期)。
|
||||
|
||||
## 需要 leo 做的(帳號層級設定,非 GitHub push,但同樣是我不該自己動的地方)
|
||||
|
||||
去 code-on-web 的 **Cloud environments** 設定(`claude.ai` 帳號設定,不是
|
||||
GitHub、不是 Gitea):
|
||||
|
||||
1. 選 InkStoneCo 這條線在用的 environment(或建一個新的),
|
||||
**Environment variables** 欄位加一行:`GITEA_TOKEN_CLAUDE_CODE=<既有那把值>`
|
||||
(名字沿用 `InkStoneCo#14` 已建立的那把,不要新造;值只有 leo 知道要填什麼,
|
||||
我這邊沒有也不該有)。
|
||||
2. **Setup script** 欄位貼 `docs/cloud-setup-script.sh` 的內容。
|
||||
3. 開一個新 session(或用 dashboard 的「rebuild environment」逼快照重建),
|
||||
驗 `claude plugin list` 顯示 `isep@inkstone enabled`,且照 §逐條對照 那張表
|
||||
再核一次數字。
|
||||
|
||||
## 這張票沒動、也不會動的東西
|
||||
|
||||
- 沒有動 `youlinhsieh/inkstoneco`(GitHub 薄殼 repo)——這個新機制**完全不需要
|
||||
改它**:安裝目標是 `--scope user`(VM 家目錄),跟 session 從哪個 cwd 啟動無關。
|
||||
舊模型需要在薄殼裡放 `.claude/settings.json` 指標,新模型不需要。
|
||||
- 沒有 push 到 GitHub、沒有 push 到本 repo的 `main`。全部改動只在
|
||||
`leaf/5-cloud` 這條分支。
|
||||
- 沒有把任何 token 值寫進這個 repo 的任何檔案(`docs/cloud-setup-script.sh`
|
||||
只引用環境變數名字 `GITEA_TOKEN_CLAUDE_CODE`)。
|
||||
@@ -0,0 +1,38 @@
|
||||
#!/usr/bin/env bash
|
||||
# 貼進 code-on-web「Cloud environments → 你的環境 → Setup script」欄位的內容。
|
||||
# 不是 ISEP 的一部分(不會被 Claude Code 當 hook/command/skill 掃描),
|
||||
# 純粹是給 leo 複製貼上的參考檔,見 docs/cloud-session-bootstrap.md。
|
||||
#
|
||||
# 前提(要先在同一個 Cloud environment 的 Environment variables 欄位加好):
|
||||
# GITEA_TOKEN_CLAUDE_CODE ← 既有機器帳號 token,名字沿用 InkStoneCo#14 已建立的那把,
|
||||
# 不要新造一把。值本身不寫在這支腳本或任何檔案裡。
|
||||
#
|
||||
# 這支腳本做兩件事:
|
||||
# 1. 設定 git URL 重寫,讓任何對 git.uncle6.me 的 clone 都能用 GITEA_TOKEN_CLAUDE_CODE 認證
|
||||
# (官方文件對「CI/CD 裝私有 marketplace」建議的寫法,見 references 段)。
|
||||
# 2. 直接把 ISEP 裝成 user-scope plugin ——不是「複製一份」,是跟本機一樣走
|
||||
# `claude plugin marketplace add` + `claude plugin install`,裝的東西
|
||||
# 100% 來自 inkstone/ISEP 這個 repo 本身,沒有第二份內容。
|
||||
#
|
||||
# 何時跑:只在「這個 Cloud environment 第一次開 session」時跑一次,
|
||||
# 跑完 Anthropic 會把整個檔案系統拍成快照,之後的 session 直接沿用快照
|
||||
# (不重跑,除非改了這支腳本本身、改了 allowed network hosts、或快照滿 7 天過期)。
|
||||
# ⇒ 這是唯一會讓「ISEP 改了但雲端還是舊的」重新出現的地方,
|
||||
# 緩解法見 docs/cloud-session-bootstrap.md「已知限制」段。
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
if [ -z "${GITEA_TOKEN_CLAUDE_CODE:-}" ]; then
|
||||
echo "❌ 找不到 GITEA_TOKEN_CLAUDE_CODE —— 去 Cloud environment 的 Environment variables 加這個名字" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 官方文件建議的私有 marketplace 認證寫法:只重寫這個 host 的 URL,不動其他 git 操作。
|
||||
git config --global url."https://x-access-token:${GITEA_TOKEN_CLAUDE_CODE}@git.uncle6.me/".insteadOf \
|
||||
"https://git.uncle6.me/"
|
||||
|
||||
# 用乾淨網址(不帶 token)加 marketplace,實際認證交給上面那條 URL 重寫。
|
||||
claude plugin marketplace add https://git.uncle6.me/inkstone/ISEP.git --scope user
|
||||
claude plugin install isep@inkstone --scope user
|
||||
|
||||
echo "✅ ISEP 已裝成 user-scope plugin,之後每個 session 啟動時直接生效。"
|
||||
@@ -0,0 +1,218 @@
|
||||
# 我改了 claude.ai 那版的哪些地方,為什麼
|
||||
|
||||
> leo 2026-08-20 交辦:「你查看是否合理,提出意見,因為這個是計劃,
|
||||
> 有些已經有、有些還沒有、有些有了不符合⋯⋯則你要改一版你的版本。」
|
||||
>
|
||||
> 本檔是**我的意見書**。原稿存檔在 `_draft-claude-ai-v0.5.0.md`,
|
||||
> 修訂後的現行規範是 `sdd-gitea-governance.md`(v0.6.0)。
|
||||
|
||||
---
|
||||
|
||||
## 先講結論
|
||||
|
||||
- **骨架是對的,照單全收**
|
||||
- 物件模型(SDD → tracking → leaf → PR → release,milestone 橫切當 time 軸)
|
||||
- 「封路優於守規」這條公理——它跟你 08-17 那句「封的是動作,不是文字」是同一件事
|
||||
- 「人是特殊 executor」把 `gate/human`(審核者)與 `exec/human`(執行者)拆開
|
||||
- 🔴 **這是原稿最有價值的一條**。現行的 `Human` 標籤把兩件事混在一起:
|
||||
「你來按放行」跟「這件事只有你的手能做」——前者你可以晚點按,
|
||||
後者你不按整條線就停在那。混在一起你看不出哪張真的在擋路。
|
||||
- 時態分工(SDD 未來式/Gitea 現在式/Wiki 過去式)
|
||||
- **有 14 處對不上現場,我改了**。下面逐條。
|
||||
- **有 2 處是你的裁決題,我先按我的判斷做了,理由寫在票上,你覺得不對就打回。**
|
||||
|
||||
---
|
||||
|
||||
## A. 事實錯誤(原稿寫的東西,現場不存在或不長那樣)
|
||||
|
||||
### A1. 標籤名幾乎全是憑空的
|
||||
|
||||
- 我實查(2026-08-20):`inkstone/ISEP` 當時 **0 個標籤**;`inkstone/InkStoneCo` 有 10 個
|
||||
- 現有:`Human` `duplicate` `p/high` `p/low` `s/backlog` `s/doing` `s/pending` `s/stage` `s/todo` `s/triage`
|
||||
- 原稿要的 `gate/human` `s/review` `close/*` `hub` `type/*`——**一個都不存在**
|
||||
- 為什麼會這樣:claude.ai 看不到 codebase 也連不上 Gitea,標籤名只能用猜的。這不是它的錯,是那個 surface 的限制。
|
||||
- **我怎麼改**:把標籤集寫成 `labels.yaml` 當唯一真相源,並且**先建出來再說**——ISEP 已經實建 23 個並驗證存在。名字取捨見 A2–A4。
|
||||
|
||||
### A2. `gate/human` → 不改名,維持 `Human`
|
||||
|
||||
- 你 08-17 才把 `s/leo` 改名成 `Human`,而且明講**它是正交維度不是流程狀態**,
|
||||
你自己是靠 Gitea 原生「指派給您的」+這個標籤在看跨 repo 的待辦。
|
||||
- 改名成 `gate/human` 會做兩件壞事:既有票全部要重貼標籤;你現在的看板習慣當場失效。
|
||||
- **我怎麼改**:`Human` 原封不動(語意=你是審核者)。另外**新增** `human/exec`
|
||||
表示「這張票的執行者是人」。兩者可以疊,也可以只有其一。
|
||||
|
||||
### A3. 狀態機只有三態,會把現場四個態擠掉
|
||||
|
||||
- 原稿:`s/todo → s/doing → s/review → closed`。
|
||||
- 現場正在用的還有 `s/triage`(還沒驗傷)、`s/backlog`(要做但沒排 sprint)、
|
||||
`s/pending`(卡在外部)、`s/stage`(已上 stage 等你驗)。
|
||||
三個 repo 加起來 179 張 open 票掛在這些態上。
|
||||
- **我怎麼改**:狀態機擴成七態,原稿的三態是其中的主幹道。
|
||||
|
||||
### A4. `s/review` 和 `s/stage` 是兩件事,原稿把它們當成一件
|
||||
|
||||
- `s/review` = **PR 開了,等總管 merge**(程式碼還沒進 main)
|
||||
- `s/stage` = **已經部署到 stage,等 leo 實際打開來驗**(程式碼早進 main 了)
|
||||
- 原稿只有前者,等於把「等你驗收」這個態砍掉——那正是你唯一會看的那個態。
|
||||
- **我怎麼改**:兩個都留,並在狀態機裡標明先後。
|
||||
|
||||
### A5. E1–E16 的 hook 全是憑空命名,現場有 41 支真的
|
||||
|
||||
- 原稿的封路清單只寫「用什麼封」,沒有一個對得上真檔名。
|
||||
- 實際對照(我逐支比對過檔名,不是猜的):
|
||||
|
||||
| 原稿 | 現場有沒有 | 對應到哪支 |
|
||||
|---|---|---|
|
||||
| E1 直接 push 預設分支 | ◐ 有但語意相反 | `main-and-prod-push-guard.sh`(擋 subagent,放行總管) |
|
||||
| E6 代理越過人閘 | ◐ 部分 | `irreversible-dispatch-guard.sh`/`prod-write-guard.sh` |
|
||||
| E11 地端雲端漂移 | ◐ 管的是別的 | `skill-deploy-drift-guard.sh`(管 skill,不管 manifest) |
|
||||
| E12 宣稱交付但票未關 | ◐ 部分 | `delivery-police.sh`/`claim-verify-police.sh` |
|
||||
| E14 subagent 空口宣稱 | ✅ **已經有了** | `subagent-claim-worksheet.sh`+`empty-handed-stop-guard.sh` |
|
||||
| E2 E3 E4 E5 E7 E8 E9 E10 E13 E15 E16 | ❌ 沒有 | — |
|
||||
|
||||
- **我怎麼改**:修訂版的封路清單一律標「現況:已有 `<檔名>` / 待建」,
|
||||
已有的不重造(重造就是第 42 支互相打架的閘)。
|
||||
|
||||
### A6. §11.1 的目錄結構與實際 repo 不符
|
||||
|
||||
- 原稿畫的是 `governance-plugin/`,實際 repo 叫 `ISEP`。
|
||||
- 原稿沒提到的、實際存在的:`commands/`(7 支)、`skills/`(2 支)、`scripts/`(23 支)。
|
||||
- 原稿列的、實際不存在的:`labels.yaml`、`templates/`、`jobs/`、`manifest.json`。
|
||||
- 🔴 **順手抓到的髒東西**:`scripts/install.sh` 其實是 **system-dev-template 的安裝器**
|
||||
(內容在裝 wiki/SDD,跟 plugin 無關),搬家時混進來的。修訂版標明它是待清理項。
|
||||
|
||||
### A7. §11.4.4 叫 install.sh 去 `systemctl restart gitea`
|
||||
|
||||
- 我沒有查證 Gitea 跑在哪台、是不是 docker、我有沒有那台的 shell。**所以我不知道這行能不能跑。**
|
||||
- 但更根本的問題:原稿自己在 §11.4.3 說「模板通道壞掉不影響治理正確性」——
|
||||
既然如此,就不該為它在安裝腳本裡放一個會失敗、會嚇人、還可能重啟到別人東西的動作。
|
||||
- **我怎麼改**:模板通道降級成 optional 的獨立腳本,不掛在 install 流程上。
|
||||
|
||||
### A8. Telegram「小六 bot 通道」
|
||||
|
||||
- 原稿直接寫了通道名。**我沒有核實過那是不是現役通道名**,所以修訂版不寫死通道名,
|
||||
改成指向 `wiki/agent-memory.md` 的通知通道段(真相源在那裡,這裡只放指針)。
|
||||
|
||||
---
|
||||
|
||||
## B. 與你既有鐵律直接打架的(照原稿走,第一天就會違規)
|
||||
|
||||
### B1. §11.2.5「薄殼只裝 manifest 標記 shell-safe 的子集」— 🔴 這條我整條刪掉
|
||||
|
||||
- **這是舊薄殼模型的殘留,而且它會把你剛拆掉的病裝回去。**
|
||||
- 你 08-20 的原話是「同一個 plugin 你用,薄殼也用,**保證兩邊同步**」。
|
||||
「只裝子集」= 兩邊不一樣 = 就是 `InkStoneCo#57`(薄殼少 7 支閘)那張票的成因本身。
|
||||
- 原稿其他地方(P11.2.1「安裝同一個 release」、P11.2.4「整包替換禁止 cherry-pick」)
|
||||
跟這條**自相矛盾**——它自己也知道不該有子集。
|
||||
- **我怎麼改**:刪除,並在修訂版明文寫「沒有子集,只有同一份」。
|
||||
|
||||
### B2. §12.1 說 SDD 的寫入者是「人」、代理僅提案
|
||||
|
||||
- 現況相反:SDD 幾乎都是 AI 寫的,你是審的那個。照字面走,第一天就全面違規。
|
||||
- **我怎麼改**:改成「代理可寫,但範圍/驗收/非目標的變更必經人閘」——
|
||||
管的是**哪些欄位需要你點頭**,不是誰握筆。
|
||||
|
||||
### B3. E9 留言 ≤600 字元、同票同 session >3 則就 reject
|
||||
|
||||
- 這條的方向是對的(推理進 wiki,留言只帶指標),但**數字太緊,而且它懲罰誠實**。
|
||||
- 你 08-17 自己的診斷:文字層的閘那天 **8 次誤攔、0 次正確攔截**,
|
||||
而且「紅線寫得越細,命中關鍵字的機率越高 ⇒ 那些閘在懲罰謹慎」。
|
||||
- **我怎麼改**:超長不 reject,改成**擋下來並要求把長內容移去 wiki 再留指標**;
|
||||
則數上限拿掉(改用「同一張票同一 session 第 4 則起要先讀前 3 則」的提示,不是硬擋)。
|
||||
|
||||
### B4. E13「`s/review` 佇列非空即 block 總管 stop」
|
||||
|
||||
- 這條會讓總管**永遠停不下來**:你在上課、沒人 merge,佇列就一直非空。
|
||||
- 而且它跟現有的 `empty-handed-stop-guard.sh`(判準是「這回合有沒有 tool call」)疊在一起,兩支會互相踩。
|
||||
- **我怎麼改**:判準改成「有**我自己開的** `s/review`,而**這一回合我完全沒碰它**」才擋——
|
||||
擋的是遺忘,不是擋等待。
|
||||
|
||||
### B5. M4.3「Timebox 不可延長,到期強制關 milestone、搬票、打 tag」
|
||||
|
||||
- 對你的作息(上課日只有中午晚上各看一眼)**這條會製造假交付**:
|
||||
scope 縮到剩一張票也照樣打 tag,那個 tag 打開來沒東西。
|
||||
- 而且它依賴排程 job,而我不確定有沒有 runner(見 C1)。
|
||||
- **我怎麼改**:到期**不自動關、不自動打 tag**,改成強制做一次「降 scope 對帳」並通知你;
|
||||
打 tag 永遠是「驗過了」才發生的動作。
|
||||
|
||||
---
|
||||
|
||||
## C. 技術可行性我實查過的
|
||||
|
||||
### C1. 排程 job(E5/E8/E16/stale/digest)需要 Gitea Actions runner — **我還沒查有沒有**
|
||||
|
||||
- 誠實標記:**這格我沒驗。** 我不知道這台 Gitea 有沒有掛 runner。
|
||||
- 另外你的 D20 紅線「禁排程輪詢」管的是 **GitHub**(自架 Gitea 不受 flag 影響),
|
||||
所以規則上不衝突,但**能不能跑是另一回事**。
|
||||
- **我怎麼改**:第一版所有 job 都做成 `scripts/` 底下可手動跑、也可由 SessionStart hook 順手跑的東西,
|
||||
**不依賴 runner**。等確認有 runner 再升級成排程。這樣壞掉的成本是「沒人跑」,不是「以為有人跑」。
|
||||
|
||||
### C2. Gitea 1.26.4 支援 label `exclusive` — ✅ 查證過,可用
|
||||
|
||||
- 所以原稿 P11.4.5「`s/*` 與 `close/*` 一律 exclusive,非法狀態不可表示」**成立**,我照做了。
|
||||
- 現有 10 個標籤全部 `exclusive: false`,這次會被改成 true。
|
||||
|
||||
### C3. Gitea 有 issue dependency API — ✅ 查證過(`/issues/{index}/dependencies`)
|
||||
|
||||
- 所以 R2.5「順序關係用原生 dependency」可行。
|
||||
|
||||
### C4. Gitea **沒有**跨 repo 搬 issue 的 API — ❌ 查證過
|
||||
|
||||
- 只有 repo transfer,沒有 issue transfer。
|
||||
- 影響:`InkStoneCo#40`(forge-discipline 母規格)、`#57`、`#14` **搬不到 ISEP**。
|
||||
- **我怎麼改**:不搬,用互鏈。ISEP 的 hub 票 `#1` 指回那三張。
|
||||
|
||||
---
|
||||
|
||||
## D. 原稿沒寫、但非有不可的(你的需求 1–3 的核心)
|
||||
|
||||
### D1. plugin 到底怎麼被載入 — 原稿整份沒提
|
||||
|
||||
- 你的需求是「雲端每次執行拉 `github.com/youlinhsieh/inkstoneco`,
|
||||
CC plugin 要把 loading 需要的放進去」。
|
||||
- 原稿 §11 講的是「分發」(release、manifest、checksum),
|
||||
**完全沒講 Claude Code 這個 host 怎麼發現並掛載這個 plugin**。
|
||||
- 而這正是 `InkStoneCo#14` 那張票的病根:Claude Code 只在 session 啟動當下讀一次 cwd 的 `.claude/`。
|
||||
- **我怎麼改**:修訂版加一節「載入契約」,並且這件事另立 `ISEP#5` 專票去做實測。
|
||||
|
||||
### D2. 版本號的一致性沒有任何機制
|
||||
|
||||
- 原稿 §9 說「plugin 版本 = 規範版本」,但沒說怎麼保證。
|
||||
- 而**今天就出事了**:README 宣稱 0.1.0、`plugin.json` 寫 0.1.0、Gitea 上 **release 數 = 0**。
|
||||
- **我怎麼改**:修訂版把 E12 改寫成「版本三處一致」的閘(`plugin.json` / tag / release 存在),
|
||||
並把「release note 寫在 release 裡、不寫 README」寫進規範(你 08-20 的原話)。另立 `ISEP#6`。
|
||||
|
||||
### D3. ISEP 是 private repo,雲端拿不到就什麼都不用談
|
||||
|
||||
- 原稿沒提憑證。**這是整條線最可能默默失敗的一格。**
|
||||
- 修訂版寫進「載入契約」,實作走既有 credential 機制(D36:只拿名字不碰值)。
|
||||
|
||||
---
|
||||
|
||||
## E. 兩個裁決題(我先按自己的判斷做了,你打回我就改)
|
||||
|
||||
### E1. E1「PR-only,禁止直接 push 預設分支」要不要套到所有 repo?
|
||||
|
||||
- **衝突點**:你的 CLAUDE.md 明寫「總管推 main **自己裁**(但要逐筆看過那些 commit)」,
|
||||
原稿要求全部走 PR。兩者不能同時成立。
|
||||
- **我的判斷**:**只有 ISEP 這個 repo 走 PR-only,其他 repo 維持現行。**
|
||||
- 理由:ISEP 是所有環境的唯一真相源,它壞掉是**所有 session 一起壞**——
|
||||
這個 repo 值得多一道摩擦。其他 repo 壞掉只影響自己。
|
||||
- 一刀切到 14 個 repo 會在你最忙的時候把整條線卡在「等總管開 PR」。
|
||||
- **這題命中四題公式的「跨專案結構」**,所以我標成裁決題寫在這裡;
|
||||
但照你 08-17 的規矩(不確定 → 假設 → 記錄 → 繼續走),我不停下來等。
|
||||
|
||||
### E2. 現有 `duplicate` 標籤要不要被 `close/duplicate` 取代?
|
||||
|
||||
- **我的判斷**:新的照建,舊的**不刪只封存**(`is_archived`)。
|
||||
- 理由:刪標籤會把它從所有歷史票上摘掉——那是不可逆的,而且會讓舊票的關閉理由憑空消失。
|
||||
|
||||
---
|
||||
|
||||
## 附:我沒動的東西(原稿寫得比我好的)
|
||||
|
||||
- §1 物件模型的那張圖與職責表——直接沿用
|
||||
- §5 關閉分類 taxonomy(七種 `close/*`)——名稱與語意全部沿用
|
||||
- §7 討論路由的那棵決策樹——沿用
|
||||
- §10.1「OP 是票的唯一狀態容器,留言是 append-only 的 delta」——沿用,這條解掉了「一張票要讀 40 則留言才知道現況」
|
||||
- §12.4 單向依賴(Wiki 壞不影響 Gitea,Gitea 壞不影響 SDD,通知丟不影響一切)——沿用
|
||||
@@ -0,0 +1,314 @@
|
||||
<!-- 存檔:不要修改本檔。 -->
|
||||
|
||||
> 📦 **這是原稿存檔,不是現行規範。**
|
||||
> 由 claude.ai 於 2026-08-20 寫成(v0.5.0 draft),leo 交給總管落地。
|
||||
> **現行規範是同目錄的 `sdd-gitea-governance.md`(v0.6.0)**,
|
||||
> 兩者的逐條分歧與理由寫在 `DIVERGENCE-v0.5.0-to-v0.6.0.md`。
|
||||
>
|
||||
> 保留原稿的理由:它的物件模型與封路哲學是這套治理的骨架,
|
||||
> 修訂版只動「與現場實況對不上」的部分。要追某條規則的來歷,看這裡。
|
||||
|
||||
---
|
||||
|
||||
# SDD × Gitea 治理規範
|
||||
|
||||
version: 0.5.0
|
||||
status: draft(本文件自身的修改依 §9 走 issue)
|
||||
scope: 適用於所有安裝本 plugin 的環境(地端 CC 與雲端薄殼)
|
||||
distribution: 本規範隨治理 plugin 發佈,plugin repo 為唯一編輯點(§11)
|
||||
|
||||
---
|
||||
|
||||
## 0. 公理
|
||||
|
||||
1. **意圖真相在 SDD,狀態真相在 Gitea,知識真相在 Wiki。** 時態分工:SDD 未來式、Gitea 現在式、Wiki 過去式(§12)。禁止交叉寫入。
|
||||
2. **Issue 是唯一任務介面。** 任何工作不經 issue 不得開始。issue = spec,PR = deliverable,release = 交付原子單位。
|
||||
3. **封路優於守規。** 凡可結構性擋掉的違規路徑,不依賴代理或人的自律。
|
||||
4. **兩軸正交。** Tracking issue 管 scope 軸,milestone 管 time 軸。
|
||||
5. **治理本體只有一份。** 封裝於治理 plugin;地端與雲端皆為安裝目標,不是編輯目標(§11)。
|
||||
6. **審核不是任務,是路徑。** 審核 = review PR 並 merge,為交付唯一必經動作(§3.0)。
|
||||
7. **人是特殊 executor。** 人的兩種介入——審核者(`gate/human`)與執行者(`exec/human`)——分別建模;人執票走同一狀態機,派工通道為 Telegram(§6)。
|
||||
|
||||
---
|
||||
|
||||
## 1. 物件模型(五層 + 一橫切)
|
||||
|
||||
```
|
||||
SDD 文件(docs/)
|
||||
└─ Tracking issue(label: hub) ← scope 軸
|
||||
└─ Leaf issue ← 最小工作單位
|
||||
└─ PR(closes #n) ← deliverable
|
||||
└─ Release tag ← 交付原子單位
|
||||
|
||||
Milestone ────────────────────────────── ← time 軸,橫切上樹
|
||||
```
|
||||
|
||||
| 物件 | 職責 | 明確不做 |
|
||||
|---|---|---|
|
||||
| SDD 文件 | 意圖、範圍、非目標、驗收哲學、驗收腳本位置 | 不含 leaf task、不記進度 |
|
||||
| Tracking issue | scope 聚合、討論容器、驗收閘 | 不掛 milestone、不直接對應 PR |
|
||||
| Leaf issue | 一個 PR 的 spec(或一個人執動作,§6.2) | 不再拆子票(要拆=升格,§5.5) |
|
||||
| Milestone | 一個可測試版本的 timebox | 不承載討論、不表達語意分組 |
|
||||
| PR | 實作 + 測試,merge 時自動關 leaf | 不手動關票 |
|
||||
| Release | milestone 關閉時打 tag | — |
|
||||
|
||||
---
|
||||
|
||||
## 2. 連結規則
|
||||
|
||||
- **R2.1** SDD 的 tasks/journey 段落只連 tracking issue,禁止連 leaf。
|
||||
- **R2.2** 每張 leaf 必屬**恰好一個** tracking issue(task list 登記 + leaf 首行回鏈 `Parent: #n`)。
|
||||
- **R2.3** 每張 leaf 最多屬一個 milestone。未排程 = 不掛(即 backlog)。
|
||||
- **R2.4** Tracking issue 不掛 milestone。其子票可分屬多個 milestone。
|
||||
- **R2.5** 順序關係一律用 Gitea 原生 dependency,禁止只寫文字。
|
||||
|
||||
---
|
||||
|
||||
## 3. 完成語意與票的狀態機
|
||||
|
||||
### 3.0 狀態機(每個轉移 = 一個可 hook 的 API 動作)
|
||||
|
||||
```
|
||||
s/todo ──領票──▶ s/doing ──完成──▶ s/review ──總管 merge──▶ closed
|
||||
(executor (開 PR + (closes #n
|
||||
self-assign 轉 label) 自動關票)
|
||||
+ 轉 label)
|
||||
```
|
||||
|
||||
- **S3.0.1(領票)** Executor(subagent 或人)領任務 = self-assign + 轉 `s/doing`。禁止留言認領——留言不改變狀態。
|
||||
- **S3.0.2(完成)** 宣告完成 = 開 PR(含 `closes #n`)+ 轉 `s/review`。**留言說做完不構成完成。**(人執票例外見 §6.2)
|
||||
- **S3.0.3(審核)** 總管審核 = review PR 並 merge,merge 即自動關票。審核沒有其他形式,也沒有獨立審核票。
|
||||
- **S3.0.4** 審核不通過:PR request changes,票退回 `s/doing`,續作。禁止關 PR 重開新票(保留審核軌跡)。
|
||||
|
||||
### 3.1–3.3 完成語意
|
||||
|
||||
- **D3.1** Leaf 關閉 = local_done。唯一觸發:PR merge 且含 `closes #n`(人執票例外 §6.2)。禁止手動關閉(例外見 §5、§6.2)。
|
||||
- **D3.2** Tracking issue 關閉 = path_done:(1) 子票全關(必要);(2) SDD 驗收腳本通過(充分);(3) `gate/human` 已放行。
|
||||
- **D3.3** 子票全關但驗收未過:tracking 保持開啟,開新 leaf 修復掛回。禁止「先關再說」。
|
||||
|
||||
---
|
||||
|
||||
## 4. Milestone 規則(= sprint = 可測試版本)
|
||||
|
||||
- **M4.1** 命名 `vX.Y`,必設 due date。
|
||||
- **M4.2** Deliverable:所有掛入 leaf 關閉後,可從預設分支打出通過驗收腳本的版本。
|
||||
- **M4.3** **Timebox 不可延長。** 到期:強制關閉 → 未完成 leaf 搬下一 milestone → 打 tag(即使 scope 縮水)。排程 job 執行。
|
||||
- **M4.4** Milestone 關閉 = release tag,一對一。「已交付」唯一合法形式是 tag 存在;打 tag 前置 open issues = 0(E12)。
|
||||
- **M4.5** Description 只寫版本目標一句 + tracking 連結。討論回 tracking issue。
|
||||
|
||||
---
|
||||
|
||||
## 5. Issue 關閉分類(taxonomy)
|
||||
|
||||
關閉必掛恰好一個 `close/*`:
|
||||
|
||||
| Label | 語意 | 關閉者 |
|
||||
|---|---|---|
|
||||
| `close/merged` | PR merge 自動關 | 系統 |
|
||||
| `close/human-exec` | 人執票完成,人手動關(§6.2) | 人 |
|
||||
| `close/duplicate` | 重複,指向舊票(新關舊留) | 人或代理 |
|
||||
| `close/wontfix` | 討論後不做 | 人 |
|
||||
| `close/stale` | 逾期無資訊 | 排程 job |
|
||||
| `close/split` | 拆分後關(§5.5) | 人 |
|
||||
| `close/transferred` | 屬別的 repo | 人或代理 |
|
||||
|
||||
- **C5.5(拆分)** (a) 升格 tracking(加 `hub`)或 (b) 關閉掛 `close/split`,子票掛原 parent。
|
||||
- **C5.6** `close/wontfix` 只有人可執行。代理只能提議。
|
||||
|
||||
---
|
||||
|
||||
## 6. 人的兩種介入(gate/human 與 exec/human)
|
||||
|
||||
### 6.1 gate/human——人是審核者(overlay)
|
||||
|
||||
- **H6.1.1** `gate/human` + assignee = richblack:工作由代理完成,人只放行或否決。
|
||||
- **H6.1.2** 代理不得關閉帶此標籤的 issue、不得 merge 帶此標籤的 PR(hook + Gitea 權限雙重擋)。
|
||||
- **H6.1.3** 只有人可移除標籤;移除即放行。
|
||||
- **H6.1.4** 必設節點(可增不可減):tracking issue 關閉前、`close/wontfix`、milestone 建立與 scope 圈選、治理 plugin 修改 PR、**部署至 prod 的 PR**。
|
||||
|
||||
### 6.2 exec/human——人是執行者(票的屬性)
|
||||
|
||||
- **H6.2.1** 當 deliverable 所需的「tool」只有人擁有(GUI-only 設定、實體權限開通、法定簽署),票掛 `exec/human` + assignee = richblack。人視為一個特殊 subagent,走 §3.0 同一狀態機。
|
||||
- **H6.2.2** 人執票的 deliverable 是**環境狀態改變**,不是 PR。完成方式:人在票上留 `[decision] 已完成:做了什麼` → 人手動關票,系統自動掛 `close/human-exec`(此為 E3 唯一合法的手動關票路徑,hook 放行條件:label 含 `exec/human` 且操作者為人)。
|
||||
- **H6.2.3** 驗證不靠自述:人執票通常是下游票的 dependency;關票解鎖後,接手代理執行時若設定未生效會 fail fast——下游失敗即自動 reopen 人執票並重新通知。有驗收腳本者,orchestrator 於關票後立即執行驗證。
|
||||
- **H6.2.4** 代理判定「這件事我做不到、只有人能做」時:開 `exec/human` 票 + 設好 dependency + 觸發通知,然後**繼續做不被 block 的其他票**,不空轉等待。
|
||||
|
||||
### 6.3 Telegram 通知(人閘的開路配套)
|
||||
|
||||
- **H6.3.1** 觸發:`gate/human` 或 `exec/human` 被掛上且 assignee = richblack 時,hook 即時發 Telegram(走小六 bot 通道)。
|
||||
- **H6.3.2** 訊息格式(BLUF,與 §10.2 同構):
|
||||
|
||||
```
|
||||
🔔 #123 需要你|[gate] 或 [exec]
|
||||
一句話:這張票要你做什麼(≤40 字)
|
||||
動作:review PR #45 並 merge / 到 CF 後台開啟 X 權限
|
||||
卡誰:此票 block 了 #124 #125
|
||||
連結:https://git.uncle6.me/...
|
||||
```
|
||||
|
||||
- **H6.3.3** 節流:同票同狀態只通知一次;24 小時未處理提醒一次;之後併入每日 digest(一則彙總所有 pending 人閘),不轟炸。
|
||||
- **H6.3.4** E13 的 orchestrator 連續 block 升級、E12 的交付被擋,同走此通道。
|
||||
- **H6.3.5** 通知是投影不是狀態:Telegram 訊息遺失不影響治理正確性,真相永遠在 Gitea 票上(單向依賴,同 §12.4)。
|
||||
|
||||
---
|
||||
|
||||
## 7. 討論路由(社群模式相容)
|
||||
|
||||
```
|
||||
新 issue → 討論 →
|
||||
├─ 可做,獨立 → 掛入 tracking,排 milestone → 走 §3
|
||||
├─ 可做,有依賴 → 同上 + dependency(§2.5)
|
||||
├─ 只有人能做 → 掛 exec/human + dependency + 通知(§6.2)
|
||||
├─ 重複 → close/duplicate
|
||||
├─ 不做 → close/wontfix(人閘)
|
||||
├─ 太大 → 升格 hub 或拆分(§5.5)
|
||||
└─ 走錯棚 → close/transferred
|
||||
```
|
||||
|
||||
多票收斂:建 tracking issue(scope),不是直接建 milestone。當且僅當「這批票 = 恰好一個可出貨版本」才同時建 milestone,tracking 保留作討論與驗收容器。
|
||||
|
||||
---
|
||||
|
||||
## 8. 封路清單(結構性強制)
|
||||
|
||||
| # | 封什麼路 | 用什麼封 |
|
||||
|---|---|---|
|
||||
| E1 | 直接 push 預設分支 | branch protection: PR-only |
|
||||
| E2 | PR 不關聯 issue | PR 模板必含 `closes #`,CI 缺漏即 fail |
|
||||
| E3 | 手動關 leaf | hook 攔截;僅放行 `close/*` 例外與 §6.2 人執路徑(exec/human + 操作者為人) |
|
||||
| E4 | 被 block 的票先關 | Gitea issue dependency 開啟 |
|
||||
| E5 | Milestone 延期 | 排程 job:到期自動關 + 搬票 + 打 tag |
|
||||
| E6 | 代理越過人閘 | PreToolUse hook + orchestrator token 無 code write 權限 |
|
||||
| E7 | SDD 內出現 leaf 連結 | pre-commit lint |
|
||||
| E8 | Tracking issue 掛 milestone | 排程 job 摘除並告警 |
|
||||
| E9 | 留言不合格式或超長 | hook:首行不匹配 `^\[(decision|question|blocker|progress|proposal)\]` 或 > 600 字元 reject;同票同 session > 3 則 reject |
|
||||
| E10 | 就地修改治理檔案 | 安裝目錄唯讀 + hook,導向 plugin repo 開 issue |
|
||||
| E11 | 地端雲端版本漂移 | SessionStart hook 比對 manifest,不一致 fail-fast |
|
||||
| E12 | 宣稱交付但票未關 | release tag / 關 milestone hook:open issues > 0 即 reject,列出未關票號,同步 Telegram |
|
||||
| E13 | 審核被遺忘 | Orchestrator Stop hook:`s/review` 佇列非空即 block stop;連續 block 逾 N 次 → `gate/human` + Telegram 升級 |
|
||||
| E14 | Subagent 空口宣稱完成 | SubagentStop hook:領票須處於 `s/review` 且掛含 `closes #n` 的 PR,否則回報「未達交付態」 |
|
||||
| E15 | 代理硬做只有人能做的事 | 對 GUI-only / 憑證外資源的操作路徑,代理端無對應 tool 或 token;唯一出口是開 `exec/human` 票(§6.2.4) |
|
||||
| E16 | 標籤漂移(repo 標籤與規範不符) | 排程 job 走 Gitea labels API,依 plugin `labels.yaml` 校正所有受治理 repo:缺的補、改的還原、多的告警;不依賴模板檔與重啟(§11.4) |
|
||||
|
||||
---
|
||||
|
||||
## 9. 本規範的迭代
|
||||
|
||||
- 存於治理 plugin repo `docs/`;各環境為唯讀安裝副本。
|
||||
- 修改:plugin repo 開 leaf(掛 governance tracking)→ PR → `gate/human` → merge → release → 各端升級。
|
||||
- 版本:規則增刪 = minor,措辭 = patch,公理 = major。**plugin 版本 = 規範版本。**
|
||||
- 每次 milestone 回顧:規範有無被繞過?有 → 補 §8,不加「請遵守」。
|
||||
|
||||
---
|
||||
|
||||
## 10. 留言規範
|
||||
|
||||
### 10.1 OP 唯一狀態原則
|
||||
|
||||
- OP 是票的唯一狀態容器,持續編輯;留言是 append-only 稽核 log,只記 delta。了解一張票只讀 OP。
|
||||
- 討論收斂即寫回 OP,留言留 `[decision] 已更新 OP:改了 X,因為 Y`。
|
||||
|
||||
### 10.2 留言格式(BLUF + 類型標籤,全文 ≤ 600 字元)
|
||||
|
||||
```
|
||||
[類型] 一句話結論(≤40 字)
|
||||
|
||||
理由:
|
||||
- (最多 3 個 bullet,每個 ≤ 1 行)
|
||||
|
||||
下一步: (一行,或「無」)
|
||||
詳細: (連結至 PR / commit / wiki,禁止貼內文)
|
||||
```
|
||||
|
||||
類型枚舉:`decision` `question` `blocker` `progress` `proposal`。
|
||||
能用 OP task list 打勾表達的進度不留言;重大 `proposal` 加掛 `gate/human`。
|
||||
|
||||
### 10.3 推理軌跡出口
|
||||
|
||||
推理、嘗試、失敗分析走 wiki-capture 進 Wiki/KBDB,留言以 `詳細:` 指向。**推理進 wiki,結論進留言,留言只帶指標。**
|
||||
|
||||
---
|
||||
|
||||
## 11. 治理 Plugin(單點分發與同步)
|
||||
|
||||
### 11.1 結構
|
||||
|
||||
```
|
||||
governance-plugin/
|
||||
├── docs/sdd-gitea-governance.md
|
||||
├── labels.yaml # 標籤唯一真相(§11.4)
|
||||
├── hooks/ # E1–E16
|
||||
├── templates/ # issue / PR / 留言 / Telegram 通知模板
|
||||
├── jobs/ # E5 / E8 / E16 / stale / digest
|
||||
├── manifest.json # 版本 + checksum + shell-safe 清單
|
||||
└── install.sh
|
||||
```
|
||||
|
||||
### 11.2 分發規則
|
||||
|
||||
- **P11.2.1** 地端與雲端安裝**同一個 release**;來源只有 plugin repo release tag。
|
||||
- **P11.2.2** 治理修改只發生在 plugin repo;執行環境發現需調整 → 去 plugin repo 開 issue(E10)。
|
||||
- **P11.2.3** Session 啟動比對 manifest(E11);不一致 fail-fast,不降級執行。
|
||||
- **P11.2.4** 升級是原子動作:整包替換,禁止 cherry-pick。
|
||||
- **P11.2.5** 薄殼只裝 manifest 標記 `shell-safe` 的子集;薄殼不自行決定。
|
||||
|
||||
### 11.3 與既有 plugin 收斂
|
||||
|
||||
治理規則集中本 plugin;各專案 dispatch/harness hook 一律 import 本 plugin,不得複製(複製即 fork,fork 即漂移)。
|
||||
|
||||
### 11.4 標籤分發(labels.yaml)
|
||||
|
||||
- **P11.4.1(唯一真相)** 全部標籤定義(名稱、顏色、描述、exclusive)只存在於 plugin repo 的 `labels.yaml`。本規範附錄與 Gitea 上所見皆為投影;修改標籤 = 修改 labels.yaml,走 §9 流程。
|
||||
- **P11.4.2(雙通道分發)** 同一份 labels.yaml 走兩條通道:
|
||||
1. **模板通道(便利,弱)**:install/升級時部署至 Gitea 伺服器 `$GITEA_CUSTOM/options/label/governance.yaml`,供建新 repo 時 GUI 一鍵播種。**此通道生效需重啟 Gitea**,且僅為一次性播種,不校正既有 repo。
|
||||
2. **API 通道(真相,強)**:排程 job(E16)走 labels API 掃所有受治理 repo,依 labels.yaml 校正——缺的補、改的還原、多出的非規範標籤留言告警(不自動刪,避免誤殺專案自用標籤)。**不需重啟,對既有 repo 立即生效。**
|
||||
- **P11.4.3(依賴方向)** 正確性只依賴 API 通道。忘記重啟的後果僅是「建新 repo 的 GUI 下拉是舊版」,而新 repo 納入治理後第一次 E16 掃描即被校正——模板通道壞掉不影響治理正確性(同 §12.4 單向依賴)。
|
||||
- **P11.4.4(升級程序)** plugin release 若含 labels.yaml 變更,install.sh 依序執行:(1) 部署模板檔;(2) 重啟 Gitea(`systemctl restart gitea`,寫在腳本裡,不靠人記得);(3) 立即觸發一次 E16 全量 sync;(4) 驗證:抽查一個 repo 的標籤集與 labels.yaml 一致才回報升級成功。
|
||||
- **P11.4.5(平台級不變量)** `s/*` 與 `close/*` 一律 `exclusive: true`:同 scope 同票至多一個標籤,由 Gitea 平台保證(轉移時自動摘除舊標籤)。狀態唯一性與關閉分類唯一性因此無需 hook 維護——非法狀態不可表示。
|
||||
|
||||
---
|
||||
|
||||
## 12. 書寫路由(SDD × Gitea × Wiki)
|
||||
|
||||
### 12.1 時態原則
|
||||
|
||||
| 載體 | 時態 | 回答的問題 | 變動頻率 | 寫入者 |
|
||||
|---|---|---|---|---|
|
||||
| SDD | 未來式 | 要做什麼、為什麼、怎樣算完成 | 低(人閘審) | 人(代理僅提案) |
|
||||
| Gitea | 現在式 | 誰在做、做到哪、卡在哪、順序 | 高(狀態機) | 人與代理 |
|
||||
| Wiki | 過去式 | 怎麼想、試過什麼、學到什麼 | append-only | 主要是代理 |
|
||||
|
||||
### 12.2 路由判準(寫之前問一句:這段內容改變的是什麼?)
|
||||
|
||||
- 「要做什麼」(範圍、驗收、非目標)→ SDD,必經 issue + 人閘(改意圖 = 改合約)
|
||||
- 「現在狀態」(認領、進度、卡點、定案)→ Gitea(OP 或合規留言)
|
||||
- 「我們知道什麼」(推理、失敗、可復用教訓)→ Wiki
|
||||
|
||||
### 12.3 典型錯置與矯正
|
||||
|
||||
| 錯置 | 矯正 |
|
||||
|---|---|
|
||||
| SDD 長出 task 清單、進度勾選 | 移至 Gitea;E7 攔截 |
|
||||
| Issue 留言寫滿推理長文 | 移至 Wiki 留指標;E9 攔截 |
|
||||
| Wiki 記錄「目前進度」 | 刪除;進度只存在於 Gitea。Wiki 引用票寫「當時」 |
|
||||
| Issue OP 修改驗收標準 | 退回:先開 SDD 修改 issue(人閘),定案後 OP 才同步 |
|
||||
| 代理直接編輯 SDD | SDD 目錄對代理唯讀,提案走 issue |
|
||||
|
||||
### 12.4 連結方向(單向依賴)
|
||||
|
||||
SDD → 只連 tracking(R2.1)。Gitea → 可連 SDD 錨點與 wiki。Wiki → 可連票號與 commit,皆為歷史快照語意。Telegram 通知 → 純投影(H6.3.5)。**Wiki 壞不影響 Gitea,Gitea 壞不影響 SDD,通知丟不影響一切。**
|
||||
|
||||
---
|
||||
|
||||
## 附:Label 全集(快照;唯一真相為 plugin `labels.yaml`,§11.4)
|
||||
|
||||
```
|
||||
hub # tracking issue 標記
|
||||
s/todo s/doing s/review # 狀態機三態(Stage,§3.0),exclusive;closed 為系統態
|
||||
gate/human # 人是審核者(§6.1)
|
||||
exec/human # 人是執行者(§6.2)
|
||||
close/* # 七種關閉分類(§5),exclusive
|
||||
type/* # type/bug type/feature type/governance
|
||||
```
|
||||
|
||||
本附錄不逐項列 close/*,以免與 labels.yaml 形成第二份清單而漂移。
|
||||
@@ -0,0 +1,427 @@
|
||||
# SDD × Gitea 治理規範
|
||||
|
||||
```
|
||||
version: 0.6.0
|
||||
status: 現行(本檔的修改依 §9 走 issue)
|
||||
scope: 所有安裝 ISEP 的環境(本機 CC 與雲端 CC)
|
||||
distribution: 隨 ISEP 發佈,ISEP repo 是唯一編輯點(§11)
|
||||
lineage: v0.5.0 draft by claude.ai(存檔 _draft-claude-ai-v0.5.0.md)
|
||||
→ v0.6.0 由總管對照現場實況修訂,逐條分歧見 DIVERGENCE-v0.5.0-to-v0.6.0.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 0. 公理
|
||||
|
||||
1. **意圖真相在 SDD,狀態真相在 Gitea,知識真相在 Wiki。** 時態分工:SDD 未來式、Gitea 現在式、Wiki 過去式(§12)。禁止交叉寫入。
|
||||
2. **Issue 是唯一任務介面。** 任何工作不經 issue 不得開始。issue = spec,PR = deliverable,release = 交付原子單位。
|
||||
3. **封路優於守規。** 凡可結構性擋掉的違規路徑,不依賴代理或人的自律。
|
||||
🔴 **封的是「動作」,不是「措辭」**(leo 2026-08-17):自然語言的變體無限,blacklist 追不完;動作有限且可枚舉。
|
||||
4. **兩軸正交。** Tracking issue 管 scope 軸,milestone 管 time 軸。
|
||||
5. **治理本體只有一份,而且沒有子集。** 封裝於 ISEP;本機與雲端都是**安裝目標**,不是編輯目標(§11)。
|
||||
🔴 **不存在「薄殼只裝一部分」這種東西**——那正是 `InkStoneCo#57` 的成因。
|
||||
6. **審核不是任務,是路徑。** 審核 = review PR 並 merge,是交付的唯一必經動作(§3.0)。
|
||||
7. **人是特殊 executor。** 人的兩種介入——審核者(`Human`)與執行者(`human/exec`)——分別建模,走同一狀態機(§6)。
|
||||
|
||||
---
|
||||
|
||||
## 1. 物件模型(五層 + 一橫切)
|
||||
|
||||
```
|
||||
SDD 文件(docs/)
|
||||
└─ Tracking issue(label: hub) ← scope 軸
|
||||
└─ Leaf issue ← 最小工作單位
|
||||
└─ PR(closes #n) ← deliverable
|
||||
└─ Release tag ← 交付原子單位
|
||||
|
||||
Milestone ────────────────────────────── ← time 軸,橫切上樹
|
||||
```
|
||||
|
||||
| 物件 | 職責 | 明確不做 |
|
||||
|---|---|---|
|
||||
| SDD 文件 | 意圖、範圍、非目標、驗收哲學、驗收腳本位置 | 不含 leaf task、不記進度 |
|
||||
| Tracking issue | scope 聚合、討論容器、驗收閘 | 不掛 milestone、不直接對應 PR |
|
||||
| Leaf issue | 一個 PR 的 spec(或一個人執動作,§6.2) | 不再拆子票(要拆=升格,§5.5) |
|
||||
| Milestone | 一個可測試版本的 timebox | 不承載討論、不表達語意分組 |
|
||||
| PR | 實作 + 測試,merge 時自動關 leaf | 不手動關票 |
|
||||
| Release | milestone 驗收通過後打 tag | 不在 README 裡宣稱版本(§4.6) |
|
||||
|
||||
---
|
||||
|
||||
## 2. 連結規則
|
||||
|
||||
- **R2.1** SDD 的 tasks/journey 段落只連 tracking issue,禁止連 leaf。
|
||||
- **R2.2** 每張 leaf 必屬**恰好一個** tracking issue(tracking 的 task list 登記 + leaf 首行回鏈 `Parent: #n`)。
|
||||
- **R2.3** 每張 leaf 最多屬一個 milestone。未排程 = 不掛(即 backlog)。
|
||||
- **R2.4** Tracking issue 不掛 milestone。其子票可分屬多個 milestone。
|
||||
- **R2.5** 順序關係一律用 Gitea 原生 dependency(`/issues/{n}/dependencies`,已驗證可用),禁止只寫文字。
|
||||
- **R2.6** 跨 repo 的票**不搬**——Gitea 沒有 issue transfer API(已驗證)。改用互鏈:在收斂方開 hub,OP 內以 `owner/repo#N` 全稱指回。
|
||||
🔴 票號一律寫全稱,裸號跨 repo 會撞號。
|
||||
|
||||
---
|
||||
|
||||
## 3. 完成語意與票的狀態機
|
||||
|
||||
### 3.0 狀態機
|
||||
|
||||
```
|
||||
s/triage ──驗傷通過──▶ s/backlog ──排進 milestone──▶ s/todo
|
||||
│ 領票(self-assign)
|
||||
▼
|
||||
s/doing ──開 PR(closes #n)──▶ s/review
|
||||
▲ │ 總管 merge
|
||||
│ ▼
|
||||
s/pending closed
|
||||
(卡外部/等依賴) │ 若這一版要 leo 實驗
|
||||
▼
|
||||
s/stage
|
||||
```
|
||||
|
||||
七個態,全部 `exclusive: true`(Gitea 平台保證同票至多一個,非法狀態不可表示):
|
||||
|
||||
| 態 | 意思 | 誰轉進來 |
|
||||
|---|---|---|
|
||||
| `s/triage` | 新進來的,還沒驗傷 | 任何人開票 |
|
||||
| `s/backlog` | 確定要做,還沒排 sprint | 驗傷者 |
|
||||
| `s/todo` | 已排進 milestone,等人領 | 總管 |
|
||||
| `s/doing` | 有人在做(已 self-assign) | executor 自己 |
|
||||
| `s/review` | PR 已開,等總管 merge | executor 自己 |
|
||||
| `s/stage` | 已部署 stage,等 leo 實際驗收 | 總管 |
|
||||
| `s/pending` | 卡住——等外部/等依賴 | 任何人,但要寫明卡什麼 |
|
||||
|
||||
- **S3.0.1(領票)** 領任務 = self-assign + 轉 `s/doing`。**留言認領不算**——留言不改變狀態。
|
||||
- **S3.0.2(完成)** 宣告完成 = 開 PR(含 `closes #n`)+ 轉 `s/review`。**留言說做完不構成完成**(人執票例外見 §6.2)。
|
||||
- **S3.0.3(審核)** 總管審核 = review PR 並 merge,merge 即自動關票。沒有獨立的審核票。
|
||||
- **S3.0.4(退回)** 審核不通過:PR request changes,票退回 `s/doing`,續作。**禁止關 PR 重開新票**(會弄丟審核軌跡)。
|
||||
- **S3.0.5(`s/review` vs `s/stage`)** 兩者是不同的等待,不可互相取代:
|
||||
`s/review` = 程式碼還沒進 main,等**總管**;`s/stage` = 已上測試環境,等 **leo 打開來看**。
|
||||
|
||||
### 3.1–3.3 完成語意
|
||||
|
||||
- **D3.1** Leaf 關閉 = local_done。唯一觸發:PR merge 且含 `closes #n`(人執票例外 §6.2)。禁止手動關閉。
|
||||
- **D3.2** Tracking issue 關閉 = path_done:(1) 子票全關【必要】;(2) 驗收腳本通過【充分】;(3) `Human` 已放行。
|
||||
- **D3.3** 子票全關但驗收未過:tracking 保持開啟,開新 leaf 修復並掛回。**禁止「先關再說」。**
|
||||
|
||||
### 3.4 🔴 總管的收工義務(本規範最常被違反的一條)
|
||||
|
||||
> leo 2026-08-20 原話:「先前你建立 milestone,但當 subagent 完成工作,你審核後卻沒有關票,
|
||||
> 導致 milestone 0% 完工,等說了才去關票,**這些都是大問題**。」
|
||||
|
||||
- **審核通過的當下就要關票,不是收工前補、不是被提醒才補。**
|
||||
- 判準:**milestone 的百分比就是 leo 唯一看得到的進度**。票沒關 = 對他而言那件事沒發生。
|
||||
- 「我審完了但還沒關」不是一個合法狀態——審完 = merge = 票自動關;沒關就表示你沒真的審完。
|
||||
|
||||
---
|
||||
|
||||
## 4. Milestone 規則(= sprint = 可測試版本)
|
||||
|
||||
- **M4.1** 命名 `vX.Y`,必設 due date。
|
||||
- **M4.2** Deliverable = **一個可測的新版本號**。所有掛入 leaf 關閉後,可從預設分支打出通過驗收的版本。
|
||||
- **M4.3** **Timebox 到期不自動關、不自動打 tag。** 到期強制做一次降 scope 對帳(未完成 leaf 搬下一 milestone)並通知 leo。
|
||||
🔴 自動打 tag 會製造假交付——tag 永遠只在「驗過了」之後發生。
|
||||
- **M4.4** Milestone 關閉 = release tag,一對一。「已交付」唯一合法形式是 **tag 存在且裝得起來**;打 tag 前置 open issues = 0(§8 E12)。
|
||||
- **M4.5** Description 只寫版本目標一句 + tracking 連結。討論回 tracking issue。
|
||||
- **M4.7(降 scope 必須留痕)** 🔴 **把票移出里程碑,必須同時寫進該里程碑的 description。**
|
||||
格式:原本幾張、移走哪幾張、為什麼、移去哪裡。
|
||||
- **禁的不是降 scope**——卡人閘時降 scope 就是 M4.3 要的。禁的是**降得無聲無息**。
|
||||
- 為什麼寫在 description 不是寫在票裡:**leo 看的是百分比那個畫面**,
|
||||
他不會為了確認 100% 是不是真的而去逐張點票。**痕跡要留在他會經過的地方。**
|
||||
- 來由(2026-08-20 實犯):`v0.2.0` 本來 6 張,`#5` 卡人閘被移出 ⇒ 分母 6 變 5 ⇒ 顯示 100%。
|
||||
leo 當場問「為什麼還有很多 issues 開放中」。
|
||||
🔴 這與 §3.4(審核完沒關票 ⇒ 數字偏低)是**同一個病的兩面**:
|
||||
畫面上的數字不等於實際狀態,而 leo 只看得到畫面。
|
||||
- 機械閘:`inkstone/ISEP#24`。
|
||||
|
||||
- **M4.6** 🔴 **release note 寫在 Gitea Releases 裡,不寫在 README。**(leo 2026-08-20:「release 不是寫在 readme,要放在 release 裡」)
|
||||
README 不得自行宣稱版本號——那會產生第二份會漂移的版本真相。
|
||||
|
||||
---
|
||||
|
||||
## 5. Issue 關閉分類
|
||||
|
||||
關閉必掛恰好一個 `close/*`(`exclusive: true`):
|
||||
|
||||
| Label | 語意 | 關閉者 |
|
||||
|---|---|---|
|
||||
| `close/merged` | PR merge 自動關(正常路徑) | 系統 |
|
||||
| `close/human-exec` | 人執票完成,人手動關(§6.2) | 人 |
|
||||
| `close/duplicate` | 重複,指向舊票(關新留舊) | 人或代理 |
|
||||
| `close/wontfix` | 討論後決定不做 | **只有 leo** |
|
||||
| `close/stale` | 逾期無資訊 | job |
|
||||
| `close/split` | 拆分後關(§5.5) | 人或代理 |
|
||||
| `close/transferred` | 屬別的 repo,已在那邊重開 | 人或代理 |
|
||||
|
||||
- **C5.5(拆分)** (a) 升格 tracking(加 `hub`)或 (b) 關閉掛 `close/split`,子票掛原 parent。
|
||||
- **C5.6** `close/wontfix` 只有人可執行。代理只能提議。
|
||||
- **C5.7** 既有的 `duplicate` 標籤**封存不刪**(刪除會把它從所有歷史票上摘掉)。
|
||||
|
||||
---
|
||||
|
||||
## 6. 人的兩種介入
|
||||
|
||||
### 6.1 `Human`——人是審核者(正交 overlay)
|
||||
|
||||
- **H6.1.1** `Human` + assignee = Leo:工作由代理完成,人只放行或否決。
|
||||
- **H6.1.2** 🔴 **`Human` 不是流程狀態,是正交維度**(leo 2026-08-17)——可疊在任何 `s/*` 上,不與 `s/*` 二選一。
|
||||
- **H6.1.3** 代理不得關閉帶此標籤的 issue、不得 merge 帶此標籤的 PR。
|
||||
- **H6.1.4** 只有人可移除標籤;移除即放行。
|
||||
- **H6.1.5** 必設節點(可增不可減):tracking issue 關閉前、`close/wontfix`、milestone 建立與 scope 圈選、**部署至 prod 的 PR**。
|
||||
- **H6.1.6(ISEP 自身的修改:閘在 release,不在每個 PR)**
|
||||
原稿把「治理 plugin 修改 PR」列為必設人閘。**照字面走會讓 leo 變成每個 PR 的瓶頸**——
|
||||
那正是北極星第一條要拔掉的東西(「為了更聰明而讓 leo 更忙」的設計一律違背)。
|
||||
但完全拿掉,代理就能**悄悄放寬管自己的規則**——那是 leo 被咬過的那類病。
|
||||
兩者兼顧的做法:
|
||||
- 治理與閘的變更,**總管可以 merge**(loop 不停)
|
||||
- 但**每一個 release note 必須逐條列出這一版改了哪些治理規則與哪些閘**,
|
||||
且 `docs/governance/` 的 diff 要在 release note 裡點名
|
||||
- **release 就是那道人閘**:leo 驗版本時一次看到所有規則變更,該打回就打回
|
||||
⇒ **把同步的逐 PR 審批,改成非同步的逐版本審批。** 沒有東西是悄悄改掉的,而 loop 不會停。
|
||||
- **H6.1.7** 🔴 **交棒給 leo = 三個機械動作,缺一件等於沒交棒**(leo 2026-08-17):
|
||||
① 總管自己先在 stage 驗過 → ② 把票**指派給 Leo** → ③ 掛 `Human`。
|
||||
在對話裡說「你可以驗了」不算——那句話會捲走,assignee 與標籤不會。
|
||||
順序不可顛倒:沒驗過就指派 = 把第一次驗證推給他。
|
||||
|
||||
### 6.2 `human/exec`——人是執行者(票的屬性)
|
||||
|
||||
- **H6.2.1** 當 deliverable 所需的能力只有人擁有(GUI-only 設定、實體權限開通、法定簽署、terminal consent),
|
||||
票掛 `human/exec` + assignee = Leo。人視為特殊 subagent,走 §3.0 同一狀態機。
|
||||
- **H6.2.2** 人執票的 deliverable 是**環境狀態改變**,不是 PR。完成方式:人在票上留 `[decision] 已完成:做了什麼` → 人手動關票 → 掛 `close/human-exec`。
|
||||
這是唯一合法的手動關票路徑。
|
||||
- **H6.2.3** 驗證不靠自述:人執票通常是下游票的 dependency;關票解鎖後,接手代理若發現設定沒生效即 fail fast,**下游失敗自動 reopen 人執票**。
|
||||
- **H6.2.4** 🔴 代理判定「這件事只有人能做」時:開 `human/exec` 票 + 設好 dependency + 通知,然後**繼續做其他不被 block 的票**,不空轉等待。
|
||||
|
||||
### 6.3 Telegram 通知(人閘的開路配套)
|
||||
|
||||
- **H6.3.1** 觸發:`Human` 或 `human/exec` 被掛上且 assignee = Leo 時,即時發 Telegram。
|
||||
通道與帳號**不寫死在本檔**,真相源是 `wiki/agent-memory.md` 的通知通道段。
|
||||
- **H6.3.2** 訊息格式(白話鐵律:標題一眼懂、代號必附一句人話):
|
||||
|
||||
```
|
||||
🔔 #123 需要你|[放行] 或 [只有你能做]
|
||||
一句話:這張票要你做什麼(≤40 字,不准只寫代號)
|
||||
動作:review PR #45 並 merge / 到 CF 後台開啟 X 權限
|
||||
卡誰:此票 block 了 #124 #125
|
||||
連結:https://git.uncle6.me/...
|
||||
```
|
||||
|
||||
- **H6.3.3** 節流:同票同狀態只通知一次;24 小時未處理提醒一次;之後併入每日 digest。
|
||||
🔴 但「等了幾天」要標出來——對 leo 重複=服務,不催這件事就不會發生。
|
||||
- **H6.3.4** 通知是**投影不是狀態**:訊息遺失不影響治理正確性,真相永遠在 Gitea 票上。
|
||||
|
||||
---
|
||||
|
||||
## 7. 討論路由
|
||||
|
||||
```
|
||||
新 issue(s/triage)→ 驗傷 →
|
||||
├─ 可做,獨立 → 掛入 tracking,排 milestone → 走 §3
|
||||
├─ 可做,有依賴 → 同上 + dependency(R2.5)
|
||||
├─ 只有人能做 → human/exec + dependency + 通知(§6.2)
|
||||
├─ 重複 → close/duplicate
|
||||
├─ 不做 → close/wontfix(只有 leo)
|
||||
├─ 太大 → 升格 hub 或拆分(C5.5)
|
||||
└─ 走錯棚 → 在正確 repo 重開,本張 close/transferred(R2.6:不能搬)
|
||||
```
|
||||
|
||||
多票收斂:建 tracking issue(scope),**不是直接建 milestone**。
|
||||
當且僅當「這批票 = 恰好一個可出貨版本」才同時建 milestone。
|
||||
|
||||
🔴 **開工第一個動作是建里程碑並拉既有 issue,不是開新票**(leo 2026-08-19)。
|
||||
里程碑**一張新任務都不准增**;撈不到對應的票 ⇒ 那才是真缺口 ⇒ 去票池補一張,不是在里程碑裡編。
|
||||
|
||||
🔴 **票名一律 User Story**:`身為<誰>,我要<什麼>,我才<為什麼>`。
|
||||
不准自創分類前綴(`【版本】`、`👤 裁決題:` 都被廢除過)。
|
||||
|
||||
---
|
||||
|
||||
## 8. 封路清單(每條標明現況,已有的不重造)
|
||||
|
||||
| # | 封什麼路 | 用什麼封 | 現況 |
|
||||
|---|---|---|---|
|
||||
| E1 | 直接 push 預設分支 | branch protection:PR-only | ◐ 現有 `main-and-prod-push-guard.sh` 語意相反(擋 subagent、放行總管)。**本版只對 ISEP 開 PR-only**,見 §8.1 |
|
||||
| E2 | PR 不關聯 issue | PR 模板必含 `closes #`,缺漏即 fail | ❌ 待建 |
|
||||
| E3 | 手動關 leaf | hook 攔截;只放行 `close/*` 與 §6.2 人執路徑 | ❌ 待建 |
|
||||
| E4 | 被 block 的票先關 | Gitea issue dependency | ✅ 平台原生,已驗證可用 |
|
||||
| E5 | Milestone 悄悄過期 | job:到期做降 scope 對帳 + 通知(**不自動關、不自動打 tag**) | ❌ 待建(先做成手動腳本,見 §8.2) |
|
||||
| E6 | 代理越過人閘 | PreToolUse hook | ◐ 現有 `irreversible-dispatch-guard.sh`/`prod-write-guard.sh` 覆蓋一部分 |
|
||||
| E7 | SDD 內出現 leaf 連結 | pre-commit lint | ❌ 待建 |
|
||||
| E8 | Tracking issue 掛 milestone | job 摘除並告警 | ❌ 待建 |
|
||||
| E9 | 留言變成推理長文 | hook:超長**不 reject**,要求移去 wiki 再留指標 | ❌ 待建(放寬版,見 §8.3) |
|
||||
| E10 | 就地修改治理檔案 | 安裝目錄唯讀 + hook,導向 ISEP 開 issue | ❌ 待建 |
|
||||
| E11 | 本機雲端版本漂移 | SessionStart hook 比對版本,不一致 fail-fast | ◐ 現有 `skill-deploy-drift-guard.sh` 管的是 skill 不是 plugin 版本 |
|
||||
| E12 | 宣稱交付但沒有 release | 版本三處一致閘:`plugin.json` = tag = release 存在;且 milestone open issues > 0 不准打 tag | ◐ 現有 `delivery-police.sh`/`claim-verify-police.sh` 部分覆蓋 |
|
||||
| E13 | 審核被遺忘 | Stop hook:**我自己開的** `s/review` 存在且**這回合完全沒碰它** → 擋一次 | ◐ 現有 `empty-handed-stop-guard.sh` 判準不同,兩者要合併不要疊加 |
|
||||
| E14 | Subagent 空口宣稱完成 | SubagentStop hook | ✅ **已有** `subagent-claim-worksheet.sh` + `empty-handed-stop-guard.sh` |
|
||||
| E15 | 代理硬做只有人能做的事 | 代理端無對應 tool 或 token;唯一出口是開 `human/exec` 票 | ◐ 部分(credential 機制已擋一部分,D36) |
|
||||
| E16 | 標籤漂移 | 走 Gitea labels API 依 `labels.yaml` 校正:缺的補、改的還原、多的**只告警不刪** | ❌ 待建(`ISEP#4`) |
|
||||
|
||||
### 8.1 E1 的適用範圍(裁決記錄)
|
||||
|
||||
**只有 ISEP 走 PR-only;其他 repo 維持現行「總管推 main 自己裁」。**
|
||||
|
||||
- 理由:ISEP 壞掉 = **所有 session 一起壞**,值得多一道摩擦;其他 repo 壞掉只影響自己。
|
||||
- 一刀切到 14 個 repo 會在 leo 最忙的時候把整條線卡在「等總管開 PR」。
|
||||
- 這條命中四題公式的「跨專案結構」⇒ 已記為裁決題(`DIVERGENCE` §E1),leo 可打回。
|
||||
|
||||
### 8.2 所有 job 第一版都不依賴 Gitea Actions runner
|
||||
|
||||
- 做成 `scripts/` 底下可手動跑、也可由 SessionStart hook 順手跑的東西。
|
||||
- 理由:**這台 Gitea 有沒有掛 runner,本規範撰寫時未經查證。**
|
||||
依賴一個不確定存在的東西,壞掉的形式是「以為有人在跑」——比「沒人跑」貴得多。
|
||||
- 確認有 runner 後才升級成排程,升級走 §9。
|
||||
|
||||
### 8.3 E9 為什麼放寬(不是偷懶)
|
||||
|
||||
leo 2026-08-17 實測:文字層的閘那天 **8 次誤攔、0 次正確攔截**,且方向穩定——
|
||||
**紅線寫得越細,命中關鍵字的機率越高 ⇒ 那些閘在懲罰謹慎。**
|
||||
所以 E9 擋的是「長內容放錯地方」這個**動作**,處置是**導引**(移去 wiki 留指標),不是 reject。
|
||||
|
||||
---
|
||||
|
||||
## 9. 本規範的迭代
|
||||
|
||||
- 存於 ISEP `docs/governance/`;各環境為唯讀安裝副本。
|
||||
- 修改路徑:ISEP 開 leaf(掛 governance tracking)→ PR → `Human` 放行 → merge → release → 各端升級。
|
||||
- 版本:規則增刪 = minor,措辭 = patch,公理 = major。**ISEP plugin 版本 = 本規範版本。**
|
||||
- 每次 milestone 回顧問一句:**規範有沒有被繞過?** 有 → 補 §8 的封路,**不加一句「請遵守」**。
|
||||
|
||||
---
|
||||
|
||||
## 10. 留言規範
|
||||
|
||||
### 10.1 OP 唯一狀態原則
|
||||
|
||||
- **OP 是票的唯一狀態容器**,持續編輯;留言是 append-only 的稽核 log,只記 delta。
|
||||
- 了解一張票只讀 OP。討論收斂即寫回 OP,留言留 `[decision] 已更新 OP:改了 X,因為 Y`。
|
||||
|
||||
### 10.2 留言格式(BLUF + 類型標籤)
|
||||
|
||||
```
|
||||
[類型] 一句話結論(≤40 字)
|
||||
|
||||
理由:
|
||||
- (最多 3 個 bullet,每個 ≤1 行)
|
||||
|
||||
下一步:(一行,或「無」)
|
||||
詳細:(連結至 PR/commit/wiki,禁止貼內文)
|
||||
```
|
||||
|
||||
類型:`decision` `question` `blocker` `progress` `proposal`。
|
||||
能用 OP 的 task list 打勾表達的進度**不留言**;重大 `proposal` 加掛 `Human`。
|
||||
|
||||
### 10.3 推理軌跡出口
|
||||
|
||||
推理、嘗試、失敗分析走 wiki-capture 進 Wiki/KBDB,留言以 `詳細:` 指向。
|
||||
**推理進 wiki,結論進留言,留言只帶指標。**
|
||||
|
||||
---
|
||||
|
||||
## 11. ISEP(單點分發與同步)
|
||||
|
||||
### 11.1 實際結構(2026-08-20 實況,不是理想圖)
|
||||
|
||||
```
|
||||
ISEP/
|
||||
├── .claude-plugin/
|
||||
│ ├── plugin.json # 版本號真相源之一(§8 E12 要三處一致)
|
||||
│ └── marketplace.json # host 發現這個 plugin 的入口
|
||||
├── docs/governance/ # 本規範 + 原稿存檔 + 分歧說明
|
||||
├── labels.yaml # 標籤唯一真相(§11.4)
|
||||
├── hooks/ # 41 支 + hooks.json(51 條註冊)
|
||||
├── commands/ # 7 支 slash command
|
||||
├── skills/ # 2 支
|
||||
├── scripts/ # 23 支
|
||||
└── system-dev/wiki/ # ISEP 自己的知識庫(只記 ISEP 的事)
|
||||
```
|
||||
|
||||
🧹 **已知待清理**:`scripts/install.sh` 實際是 **system-dev-template 的安裝器**(在裝 wiki/SDD),
|
||||
搬家時混進來的,與 plugin 無關。
|
||||
|
||||
### 11.2 分發規則
|
||||
|
||||
- **P11.2.1** 本機與雲端安裝**同一個 release**;來源只有 ISEP 的 release tag。
|
||||
- **P11.2.2** 治理修改只發生在 ISEP;執行環境發現需調整 → 回 ISEP 開 issue(E10)。
|
||||
- **P11.2.3** Session 啟動比對版本(E11);不一致 fail-fast,不降級執行。
|
||||
- **P11.2.4** 升級是原子動作:整包替換,禁止 cherry-pick。
|
||||
- **P11.2.5** 🔴 **沒有子集。** 本機與雲端裝的是**逐位元組相同**的一份。
|
||||
(原稿的「薄殼只裝 shell-safe 子集」已刪除——那條是舊薄殼模型的殘留,
|
||||
正是 `InkStoneCo#57`「薄殼比真身少 7 支閘」的成因本身。)
|
||||
|
||||
### 11.3 載入契約(原稿缺這節,而這是最容易默默失敗的一格)
|
||||
|
||||
Claude Code **只在 session 啟動當下**讀一次 cwd 的設定。因此:
|
||||
|
||||
- **L11.3.1** 雲端 session 的 cwd 是 GitHub 上的啟動 repo,ISEP 必須在**那個時刻**就被 host 認得。
|
||||
- **L11.3.2** 「事後 clone 進來」對 hook 可行(hook 是每次工具呼叫才解析路徑),
|
||||
對 **command/skill 不可行**(它們啟動時就被掃描)——這是 `InkStoneCo#14` 的根因。
|
||||
- **L11.3.3** ISEP 是 **private** repo,任何載入路徑都必須先解決憑證。
|
||||
憑證只准取名字(D36),**不得寫進任何檔案、commit 或 issue**。
|
||||
- **L11.3.4** 驗收標準:能貼出**雲端那邊實際載到的清單**,逐條對上 ISEP 的註冊條數。
|
||||
「我推上去了」不是驗收。
|
||||
|
||||
### 11.4 標籤分發(labels.yaml)
|
||||
|
||||
- **P11.4.1(唯一真相)** 全部標籤定義(名稱、顏色、描述、exclusive)只存在於 ISEP 的 `labels.yaml`。
|
||||
Gitea 上所見皆為投影;改標籤 = 改 `labels.yaml`,走 §9。
|
||||
- **P11.4.2(分發通道)** **API 通道是唯一依賴**:走 labels API 掃所有受治理 repo 校正。
|
||||
Gitea 伺服器端的模板檔(建新 repo 時 GUI 播種)是**可選的便利品**,
|
||||
獨立腳本、不掛在安裝流程上——它需要重啟 Gitea,而重啟的成本與風險不該由安裝觸發。
|
||||
- **P11.4.3(依賴方向)** 正確性只依賴 API 通道。模板通道壞掉的後果僅是「建新 repo 的下拉是舊版」,
|
||||
而新 repo 納管後第一次 sync 即被校正。
|
||||
- **P11.4.4(不刪原則)** 🔴 **同步永不刪除標籤**——刪除會把它從所有歷史票上摘掉,不可逆。
|
||||
非規範標籤只列出告警。
|
||||
- **P11.4.5(平台級不變量)** `s/*`、`close/*`、`p/*`、`type/*` 一律 `exclusive: true`
|
||||
(Gitea 1.26.4 支援,已驗證):同 scope 同票至多一個,由平台保證——**非法狀態不可表示**,無需 hook 維護。
|
||||
`Human`、`human/exec`、`hub` 是正交維度,**不 exclusive**。
|
||||
|
||||
---
|
||||
|
||||
## 12. 書寫路由(SDD × Gitea × Wiki)
|
||||
|
||||
### 12.1 時態原則
|
||||
|
||||
| 載體 | 時態 | 回答的問題 | 變動頻率 | 誰寫 |
|
||||
|---|---|---|---|---|
|
||||
| SDD | 未來式 | 要做什麼、為什麼、怎樣算完成 | 低 | 代理可寫,**範圍/驗收/非目標的變更必經人閘** |
|
||||
| Gitea | 現在式 | 誰在做、做到哪、卡在哪、順序 | 高 | 人與代理 |
|
||||
| Wiki | 過去式 | 怎麼想、試過什麼、學到什麼 | append-only | 主要是代理 |
|
||||
|
||||
(原稿寫「SDD 寫入者是人、代理僅提案」——與現況相反,照字面走第一天就違規。
|
||||
管的應該是**哪些欄位需要 leo 點頭**,不是誰握筆。)
|
||||
|
||||
### 12.2 路由判準(寫之前問一句:這段內容改變的是什麼?)
|
||||
|
||||
- 「要做什麼」(範圍、驗收、非目標)→ SDD,必經 issue + 人閘(改意圖 = 改合約)
|
||||
- 「現在狀態」(認領、進度、卡點、定案)→ Gitea(OP 或合規留言)
|
||||
- 「我們知道什麼」(推理、失敗、可復用教訓)→ Wiki
|
||||
|
||||
### 12.3 典型錯置與矯正
|
||||
|
||||
| 錯置 | 矯正 |
|
||||
|---|---|
|
||||
| SDD 長出 task 清單、進度勾選 | 移至 Gitea;E7 攔截 |
|
||||
| Issue 留言寫滿推理長文 | 移至 Wiki 留指標;E9 導引 |
|
||||
| Wiki 記錄「目前進度」 | 刪除;進度只存在於 Gitea。Wiki 引用票時寫「當時」 |
|
||||
| Issue OP 修改驗收標準 | 退回:先開 SDD 修改 issue(人閘),定案後 OP 才同步 |
|
||||
| **README 宣稱版本號** | 刪除;版本只存在於 release(M4.6)。2026-08-20 實犯 |
|
||||
|
||||
### 12.4 連結方向(單向依賴)
|
||||
|
||||
SDD → 只連 tracking(R2.1)。Gitea → 可連 SDD 錨點與 wiki。Wiki → 可連票號與 commit(歷史快照語意)。
|
||||
Telegram → 純投影。**Wiki 壞不影響 Gitea,Gitea 壞不影響 SDD,通知丟不影響一切。**
|
||||
|
||||
---
|
||||
|
||||
## 附:Label 全集(快照;唯一真相為 `labels.yaml`)
|
||||
|
||||
```
|
||||
狀態機(exclusive) s/triage s/backlog s/todo s/doing s/review s/stage s/pending
|
||||
關閉分類(exclusive) close/merged close/human-exec close/duplicate close/wontfix
|
||||
close/stale close/split close/transferred
|
||||
人(正交,不 exclusive) Human ← 人是審核者
|
||||
human/exec ← 人是執行者
|
||||
優先(exclusive) p/high p/low
|
||||
種類(exclusive) type/bug type/feature type/governance type/chore
|
||||
結構(正交) hub ← tracking issue 標記
|
||||
封存不刪 duplicate ← 由 close/duplicate 取代,保留在歷史票上
|
||||
```
|
||||
@@ -32,6 +32,14 @@
|
||||
{
|
||||
"type": "command",
|
||||
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/leo21c-write-guard.sh"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/release-tag-guard.sh"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/ticket-api-bypass-guard.sh"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
Executable
+81
@@ -0,0 +1,81 @@
|
||||
#!/bin/sh
|
||||
# release-tag-guard.sh — PreToolUse(Bash):打 tag 那一刻擋下版本不一致
|
||||
#
|
||||
# 立這道閘的來由(inkstone/ISEP#6,2026-08-20):
|
||||
# README.md 曾寫死「狀態:0.1.0」,但這個 repo `release_counter=0`、
|
||||
# 一個 tag 都沒打。leo 當場指出這是違規,且命中規範自己的 E12
|
||||
# (宣稱交付但沒有 tag);leo 補充:「release 不是寫在 readme,要放在 release 裡」。
|
||||
#
|
||||
# 這支閘解的不是「README 寫錯字」,是**結構性防漂移**:
|
||||
# 「ISEP 現在是哪一版」只有一個地方答得出來= Gitea Releases(git tag)。
|
||||
# `.claude-plugin/plugin.json` 的 `version` 欄位必須跟這個 tag 完全一致,
|
||||
# 不然又回到「版本號在不同地方各說各話」的老路——只是這次換成
|
||||
# 「manifest 一個號碼、tag 又一個號碼」而不是「README 一個號碼、repo 裡沒 tag」。
|
||||
# 同一套判準也寫在 `scripts/check-version-consistency.sh`(可以隨時手動跑,
|
||||
# 不必等到打 tag那一刻);這支 hook 是「結構性做不到」的那一半——
|
||||
# 在真正動手打 tag 的當下擋住,而不是靠事後補跑腳本才發現。
|
||||
#
|
||||
# 🔴 紅線:**這支 hook 不打 tag、不建 release**——它只在別人(人類/總管)要打 tag 時
|
||||
# 檢查一致性。真正打哪個版本號的 tag,是總管驗過整個 milestone 之後的動作。
|
||||
#
|
||||
# 設計紀律(沿用本 repo既有 guard 的兩條,見 main-and-prod-push-guard.sh 註解):
|
||||
# • **先排除「談論/讀取/刪除/列出」**,只擋「真的要打一個新 tag」的那個命令形狀。
|
||||
# • **抽不出版本號就不擋**(fail-open on 解析失敗,不是 fail-open on 檢查結果)——
|
||||
# 避免因為指令格式特殊(例如帶簽名 `-s`、多行訊息)誤攔到人,
|
||||
# 那正是「閘被誤攔多次會被繞過」的病根(README 段落引的 D95 同一款教訓)。
|
||||
set -eu
|
||||
|
||||
INPUT="$(cat)"
|
||||
CMD=$(printf '%s' "$INPUT" | python3 -c '
|
||||
import sys, json
|
||||
try: print(json.load(sys.stdin).get("tool_input", {}).get("command", "") or "")
|
||||
except Exception: print("")
|
||||
' 2>/dev/null || printf '')
|
||||
|
||||
[ -z "$CMD" ] && exit 0
|
||||
|
||||
# ── 先排除不是「打新 tag」的動作 ──────────────────────────────────────
|
||||
case "$CMD" in
|
||||
sed\ *|cat\ *|grep\ *|head\ *|tail\ *|wc\ *|less\ *|ls\ *|awk\ *|rg\ *|echo\ *) exit 0 ;;
|
||||
*"git tag -d"*|*"git tag --delete"*|*"git tag -l"*|*"git tag --list"*|*"git tag -n"*) exit 0 ;;
|
||||
*" --dry-run"*|*"--dry-run "*) exit 0 ;;
|
||||
esac
|
||||
|
||||
case "$CMD" in
|
||||
*"git tag "*) ;;
|
||||
*) exit 0 ;;
|
||||
esac
|
||||
|
||||
# ── 從命令裡萃取版本號(第一個 vX.Y.Z 或 X.Y.Z 樣式的 token)───────────
|
||||
TAGNAME=$(printf '%s' "$CMD" | grep -oE 'v?[0-9]+\.[0-9]+\.[0-9]+' | head -1 || printf '')
|
||||
[ -n "$TAGNAME" ] || exit 0 # 抽不出版本號=不是本閘管的形狀,不擋(見上方設計紀律)
|
||||
|
||||
VER=${TAGNAME#v}
|
||||
|
||||
PROJ="${CLAUDE_PROJECT_DIR:-$(pwd)}"
|
||||
PLUGIN_JSON="$PROJ/.claude-plugin/plugin.json"
|
||||
[ -f "$PLUGIN_JSON" ] || exit 0 # 不在 ISEP repo 裡(沒有這個檔案)=不是本閘管的 repo
|
||||
|
||||
PJVER=$(python3 -c "import json;print(json.load(open('$PLUGIN_JSON')).get('version',''))" 2>/dev/null || printf '')
|
||||
[ -n "$PJVER" ] || exit 0
|
||||
|
||||
if [ "$PJVER" != "$VER" ]; then
|
||||
cat >&2 <<MSG
|
||||
🚫 版本不一致,擋下這次打 tag(inkstone/ISEP#6:版本結構性防漂移閘)
|
||||
|
||||
你想打的 tag:$TAGNAME(版本號 $VER)
|
||||
.claude-plugin/plugin.json 現在的 version:$PJVER
|
||||
|
||||
兩者必須完全一致——「ISEP 現在是哪一版」只有 Gitea Releases 答得出來,
|
||||
而 Releases 的 tag 名稱跟 plugin.json 的宣稱要是同一個數字,不然又是各說各話。
|
||||
|
||||
【怎麼過】把 .claude-plugin/plugin.json 的 version 改成 $VER,
|
||||
連同這次要發的其他改動一起 commit,再重新打 tag $TAGNAME。
|
||||
(或者你要打的其實是 $PJVER 這個號碼,那就把 tag 名稱改對。)
|
||||
|
||||
驗法一致的獨立腳本:scripts/check-version-consistency.sh
|
||||
MSG
|
||||
exit 2
|
||||
fi
|
||||
|
||||
exit 0
|
||||
Executable
+81
@@ -0,0 +1,81 @@
|
||||
#!/bin/bash
|
||||
# ticket-api-bypass-guard.sh — 開票的「側門」也要經過同一道搜尋閘
|
||||
#
|
||||
# 來由(leo 2026-08-20 當場問「如何防止」):
|
||||
# `scripts/ticket new` 早就強制「開票前先搜」(/tmp/.ticket-where-ok 戳記,30 分鐘失效)。
|
||||
# 但總管當天開了 12 張與舊票重疊的新票——因為他**沒用那支工具,直接打 Gitea API**。
|
||||
# ⇒ 規範有、閘也有,但閘長在「工具」上,而那個動作有兩條路,只封了一條。
|
||||
# leo:「你在讓事情複雜化」/「每張票開以前都要搜尋現有票,你為什麼會開了不搜?」
|
||||
#
|
||||
# 這支封的是**動作**:任何 Bash 指令只要在對 Gitea 的 issues 端點做寫入,
|
||||
# 就要有一個新鮮的搜尋戳記。它不強迫你用 scripts/ticket,只強迫你搜過。
|
||||
# (同 InkStoneCo#36:「守 prod 的閘,包一層腳本就繞過去了——它看的是指令長相」。
|
||||
# 本支同樣只看得到指令文字,這是 PreToolUse 這層的天花板;
|
||||
# 所以判準取「端點 + 寫入動詞」兩個都命中才擋,讓純讀取一律放行。)
|
||||
#
|
||||
# 放行(刻意,這些都不是「開票」):
|
||||
# - 只讀不寫(GET):撈清單、看票、對帳
|
||||
# - 對既有票的留言/改標籤/關票(/issues/<N>/... 這種帶票號的子路徑)
|
||||
# - scripts/ticket 自己(它有自己的閘,重複擋只會互相打架)
|
||||
# - 指令裡出現 ticket-api-ok(逃生口,會留在指令歷史上)
|
||||
set -uo pipefail
|
||||
|
||||
INPUT=$(cat)
|
||||
CMD=$(printf '%s' "$INPUT" | python3 -c "
|
||||
import sys,json
|
||||
try: print(json.load(sys.stdin).get('tool_input',{}).get('command',''))
|
||||
except Exception: print('')
|
||||
" 2>/dev/null)
|
||||
[ -n "$CMD" ] || exit 0
|
||||
|
||||
# 逃生口(留痕)
|
||||
case "$CMD" in *ticket-api-ok*) exit 0 ;; esac
|
||||
# scripts/ticket 有自己的閘
|
||||
case "$CMD" in *scripts/ticket*|*"ticket where"*|*"ticket new"*|*"ticket say"*) exit 0 ;; esac
|
||||
|
||||
# ① 有沒有打到 Gitea 的 issues 端點(不帶票號的那個=建立新票的路徑)
|
||||
printf '%s' "$CMD" | grep -qE 'repos/[^ "'"'"']*/issues([?"'"'"'`,)\\[:space:]]|$)' || exit 0
|
||||
|
||||
# ② 指令裡有沒有 POST 這個詞(純 GET 一律放行)
|
||||
# 刻意只認一個裸字:跳脫引號、heredoc、python、curl、各種包裝的寫法無限多,
|
||||
# 逐個補 pattern 追不完(leo 2026-08-17:「自然語言的變體是無限的,blacklist 永遠追不完」)。
|
||||
# ①已經確定這是「開票那條端點」,純讀取的指令不會出現 POST ⇒ 一個字就夠,而且沒有跳脫的破口。
|
||||
printf '%s' "$CMD" | grep -qw 'POST' || exit 0
|
||||
|
||||
# ③ 要有新鮮的搜尋戳記(與 scripts/ticket 共用同一個,30 分鐘)
|
||||
STAMP=/tmp/.ticket-where-ok
|
||||
NOW=$(date +%s)
|
||||
FRESH=no
|
||||
if [ -f "$STAMP" ]; then
|
||||
AT=$(python3 -c "import json;print(int(json.load(open('$STAMP'))['at']))" 2>/dev/null || echo 0)
|
||||
[ $((NOW - AT)) -le 1800 ] && FRESH=yes
|
||||
fi
|
||||
[ "$FRESH" = "yes" ] && exit 0
|
||||
|
||||
cat >&2 <<'MSG'
|
||||
🚫 你正在用 Gitea API 直接開新票,而這一輪沒有搜尋紀錄
|
||||
|
||||
leo 2026-08-16:「**寫開票前先去搜尋要開在哪裡,不然你永遠會亂開新票**」
|
||||
leo 2026-08-20:「**每張票開以前都要搜尋現有票,你為什麼會開了不搜?這個規範不是早就有 hook 了?**」
|
||||
|
||||
規範有,閘也有——但那道閘長在 `scripts/ticket` 這支工具裡,
|
||||
而你走的是 API 這條側門。**本閘就是把那道門也封上。**
|
||||
|
||||
實錯(2026-08-20 同日):總管用 API 開了 12 張票,事後盤點**每一張都跟舊票重疊**,
|
||||
全部只能關掉指回舊票。leo:「**你在讓事情複雜化**」。
|
||||
|
||||
── 怎麼過(擇一)───────────────────────────────
|
||||
1. 先搜(預設,戳記 30 分鐘有效,之後 API 也放行):
|
||||
scripts/ticket where <關鍵字...>
|
||||
🔴 搜到了就**貼進那張票**,不要開新的:
|
||||
scripts/ticket say <owner/repo#N> -F <內文檔>
|
||||
|
||||
2. 真的是新的一條線 → 直接用那支工具開,它會幫你把該檢查的檢查完:
|
||||
scripts/ticket new <repo> -F <內文檔> --title <標題>
|
||||
|
||||
3. 這次確實不是在開新票(例如批次改標籤/關票/留言)
|
||||
→ 指令裡加 `ticket-api-ok` 說明理由,留痕放行。
|
||||
|
||||
放行的情況(本閘不管):純讀取(GET)、對既有票 /issues/<N>/ 的留言與標籤、scripts/ticket 自己。
|
||||
MSG
|
||||
exit 2
|
||||
Executable
+87
@@ -0,0 +1,87 @@
|
||||
#!/bin/sh
|
||||
# check-version-consistency.sh — ISEP 版本一致性檢查(inkstone/ISEP#6)
|
||||
#
|
||||
# 立這支的來由(2026-08-20):README.md 曾寫死「狀態:0.1.0」,
|
||||
# 但這個 repo `release_counter=0`、一個 tag 都沒打。leo 當場指出這是違規,
|
||||
# 且命中規範自己的 E12(宣稱交付但沒有 tag);leo 補充:
|
||||
# 「release 不是寫在 readme,要放在 release 裡」。
|
||||
#
|
||||
# 判準只有一句:**「ISEP 現在是哪一版」只有一個地方答得出來= Gitea Releases(git tag)。**
|
||||
# 其他地方要嘛指過去、要嘛跟它機械同步,不准各自宣告一個號碼。
|
||||
#
|
||||
# 1. `.claude-plugin/plugin.json` 的 `version` 欄位,必須跟「最新的 tag」完全一致。
|
||||
# 還沒打過任何 tag 時(現在就是這個狀態),version 欄位必須是哨兵值 `0.0.0`
|
||||
# ──意思是「這份 manifest 誠實承認:目前沒有一個經過驗證、掛在 Gitea Releases
|
||||
# 上的版本」。不准提前寫一個沒人驗過的號碼(那正是這張票抓到的違規本身)。
|
||||
# 真正打 tag 的那天,`.claude-plugin/plugin.json` 的 version 要跟那個 tag
|
||||
# 同一個 commit 就改掉,兩者一起進 release。
|
||||
# 2. `README.md` 不准再自己宣告版本號(例如「- 0.1.0 —」這種樣式的行)。
|
||||
# 讀者要查現在是哪一版,去 Releases 頁面,不是讀 README。
|
||||
#
|
||||
# 用法:scripts/check-version-consistency.sh
|
||||
# 離開碼:0=一致(可以放心說「這裡查得到版本」);1=不一致(stderr 講清楚錯在哪、
|
||||
# 該改哪個檔案)。可以隨時手動跑,也是 hooks/release-tag-guard.sh 在打 tag
|
||||
# 那一刻用來擋下不一致 tag 的同一套判準(複製了一份精簡邏輯,避免 hook
|
||||
# 每次 Bash 呼叫都要 fork 這支腳本)。
|
||||
|
||||
set -eu
|
||||
|
||||
PROJ="$(cd "$(dirname "$0")/.." && pwd)"
|
||||
PLUGIN_JSON="$PROJ/.claude-plugin/plugin.json"
|
||||
README="$PROJ/README.md"
|
||||
|
||||
FAIL=0
|
||||
|
||||
# --- 1. plugin.json 讀得到、version 欄位存在 ---
|
||||
if [ ! -f "$PLUGIN_JSON" ]; then
|
||||
echo "❌ 找不到 $PLUGIN_JSON" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
PJVER=$(python3 -c "import json;print(json.load(open('$PLUGIN_JSON')).get('version',''))" 2>/dev/null || printf '')
|
||||
if [ -z "$PJVER" ]; then
|
||||
echo "❌ .claude-plugin/plugin.json 沒有 version 欄位(或不是合法 JSON)" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# --- 2. 跟最新 tag 比對 ---
|
||||
LATEST_TAG=$(cd "$PROJ" && git tag --list 'v*' --sort=-v:refname 2>/dev/null | head -1 || printf '')
|
||||
|
||||
if [ -z "$LATEST_TAG" ]; then
|
||||
# 沒有任何 tag:唯一合法的 plugin.json version 是哨兵值 0.0.0
|
||||
if [ "$PJVER" != "0.0.0" ]; then
|
||||
echo "❌ 版本不一致:" >&2
|
||||
echo " repo 裡沒有任何 tag(release_counter=0,還沒有一個正式 release)" >&2
|
||||
echo " 但 .claude-plugin/plugin.json 的 version 卻宣稱「$PJVER」" >&2
|
||||
echo " → 這就是 inkstone/ISEP#6 抓到的違規本身:宣稱一個版本,卻沒有 tag 撐它。" >&2
|
||||
echo " → 修法:version 改回 0.0.0(=尚未發過正式版),等真正打 tag 那天再同步改成那個號碼。" >&2
|
||||
FAIL=1
|
||||
fi
|
||||
else
|
||||
TAGVER=${LATEST_TAG#v}
|
||||
if [ "$PJVER" != "$TAGVER" ]; then
|
||||
echo "❌ 版本不一致:" >&2
|
||||
echo " Gitea 上最新的 tag 是 $LATEST_TAG(版本 $TAGVER)" >&2
|
||||
echo " 但 .claude-plugin/plugin.json 的 version 是「$PJVER」" >&2
|
||||
echo " → 兩者必須完全一致,不然「ISEP 現在是哪一版」又變成各說各話。" >&2
|
||||
FAIL=1
|
||||
fi
|
||||
fi
|
||||
|
||||
# --- 3. README 不准自己宣告版本號 ---
|
||||
HIT=$(grep -nE '^\s*-\s*v?[0-9]+\.[0-9]+\.[0-9]+\s*(—|-)' "$README" 2>/dev/null || printf '')
|
||||
if [ -f "$README" ] && [ -n "$HIT" ]; then
|
||||
echo "❌ README.md 還在自己宣告版本號(不准,release 只放在 Gitea Releases):" >&2
|
||||
echo "$HIT" >&2
|
||||
FAIL=1
|
||||
fi
|
||||
|
||||
if [ "$FAIL" -eq 0 ]; then
|
||||
if [ -n "$LATEST_TAG" ]; then
|
||||
echo "✅ 版本一致:plugin.json=$PJVER,最新 tag=$LATEST_TAG,README 沒有自行宣告版本。"
|
||||
else
|
||||
echo "✅ 版本一致:plugin.json=$PJVER(哨兵值,尚無 tag 是合法狀態),README 沒有自行宣告版本。"
|
||||
fi
|
||||
fi
|
||||
|
||||
exit "$FAIL"
|
||||
@@ -0,0 +1,34 @@
|
||||
# ADR-0001:ISEP 自建 wiki,不繼承 InkStoneCo 的內容
|
||||
|
||||
- **狀態**:已採納
|
||||
- **日期**:2026-08-20
|
||||
- **票**:`inkstone/ISEP#3`
|
||||
|
||||
## 背景
|
||||
|
||||
ISEP 是獨立 repo,裝的是「環境」(hooks/commands/skills/scripts),本來刻意不放
|
||||
「知識」(wiki/docs/`_archive`)——見 `README.md`「裝什麼」段。但接手 ISEP 的 session
|
||||
(含雲端)若要查「這裡的決定、踩過的坑、現在什麼狀態」,過去只能回頭 clone InkStoneCo
|
||||
頂層知識庫,多一層跳轉、且 ISEP 自己的事並不天然屬於 InkStoneCo 頂層(那裡管的是跨專案決策)。
|
||||
|
||||
## 決策
|
||||
|
||||
ISEP 建立自己的 `system-dev/wiki/`,骨架取自 `inkstone/system-dev-template` 的 wiki
|
||||
template(三層 + 標籤橫切:`INDEX.md`/`TAXONOMY.md`/`status.md`/`mistakes.md`/
|
||||
`principles.md`/`cards/<bucket>/`),照它的規約裝,不自創格式。
|
||||
|
||||
**紅線**:這份 wiki 只記 ISEP 自己的事。不把 InkStoneCo 頂層 wiki 的內容複製過來——
|
||||
複製即 fork,fork 即漂移,跟「真身薄殼合一」(見 `cards/isep/真身薄殼合一.md`)要解的病
|
||||
是同一種結構性錯誤,只是對象從 hook 換成知識庫。
|
||||
|
||||
## 後果
|
||||
|
||||
- 好處:接手 session 在 ISEP 內就能查到 ISEP 自己的歷史,不必先 clone 別的 repo。
|
||||
- 代價:多一份骨架要維護(跟 InkStoneCo 頂層、以及其他裝了 template 的子 repo 一樣)。
|
||||
- 邊界:跨專案的決策、鐵律、部署架構全局,仍然只在 InkStoneCo 頂層記錄,ISEP 不重複。
|
||||
|
||||
## 相關
|
||||
|
||||
- `cards/isep/真身薄殼合一.md`
|
||||
- `cards/isep/repo邊界與紅線.md`
|
||||
- `cards/isep/hook路徑規約.md`
|
||||
@@ -0,0 +1,10 @@
|
||||
# wiki 機敏防護 L1:整檔排除,寫進 system-dev/wiki/ 前先過這份名單
|
||||
# 命中 pattern 的原文檔整份不讀、不編入 wiki(跟 L2 行內標記、L3 hook 掃描是三層防護的第一層)
|
||||
|
||||
.env
|
||||
.env.*
|
||||
*.pem
|
||||
*.key
|
||||
*secret*
|
||||
*credential*
|
||||
*token*
|
||||
@@ -0,0 +1,28 @@
|
||||
# ISEP wiki 索引
|
||||
|
||||
> 這是 ISEP 自己的知識庫,只記 ISEP 自己的事(環境設定 repo 本身的決策/踩坑/狀態)。
|
||||
> **不是** InkStoneCo 頂層 wiki 的複製品——跨專案的事仍去 InkStoneCo 頂層查,見
|
||||
> `cards/isep/repo邊界與紅線.md`。
|
||||
|
||||
## 三個 push 檔(session 開場自動注入,見 `hooks/session-start-recall.sh`)
|
||||
|
||||
- [`status.md`](./status.md) — 當前進度、下次第一件事(全文注入)
|
||||
- [`principles.md`](./principles.md) — 行動前必服從的原則(全文注入)
|
||||
- [`mistakes.md`](./mistakes.md) — 已知踩過的坑(標題清單注入,全文按需查)
|
||||
|
||||
## 相容視圖
|
||||
|
||||
- [`decisions-summary.md`](./decisions-summary.md) — 決策速查表,指向 `cards/` 裡的完整卡片
|
||||
|
||||
## 按桶瀏覽
|
||||
|
||||
- [`cards/isep/00-INDEX.md`](./cards/isep/00-INDEX.md) — ISEP 環境治理 + wiki 自身這一桶的全部卡片
|
||||
|
||||
## 按標籤瀏覽
|
||||
|
||||
見 `TAXONOMY.md` 的軸線定義;目前卡片:
|
||||
|
||||
- **環境治理**:[[真身薄殼合一]]、[[hook路徑規約]]
|
||||
- **wiki自身**:[[repo邊界與紅線]]
|
||||
- **決策**:[[真身薄殼合一]]、[[repo邊界與紅線]]
|
||||
- **規約**:[[hook路徑規約]]、[[repo邊界與紅線]]
|
||||
@@ -0,0 +1,17 @@
|
||||
# 標籤字典(TAXONOMY)
|
||||
|
||||
> 受控擴充:卡片的 frontmatter `tags:` 只能從這裡挑;裝不下的先確認不是既有標籤的同義詞,
|
||||
> 確實是新軸才加進來(附定義)再用。ISEP 是「環境 + 治理」repo,不是一般業務專案,
|
||||
> 軸線跟著這個性質走。
|
||||
|
||||
## 領域(主軸,1-3 個)
|
||||
|
||||
- **環境治理**:hooks/commands/skills/scripts 這套 plugin 本身怎麼組織、怎麼改、怎麼同步本機與雲端。
|
||||
- **wiki 自身**:這套 wiki 骨架怎麼裝、怎麼維護、跟 InkStoneCo 頂層 wiki 的邊界在哪。
|
||||
- **部署同步**:本機 plugin ↔ 雲端 plugin 怎麼保持一致(`/plugin update`、marketplace 安裝)。
|
||||
|
||||
## 形態(副軸,0-2 個)
|
||||
|
||||
- **決策**:為什麼選這個做法不選那個。
|
||||
- **踩坑**:實際撞過、已經修正的錯誤。
|
||||
- **規約**:往後要遵守的具體寫法規則(如路徑寫法)。
|
||||
@@ -0,0 +1,12 @@
|
||||
# ISEP 環境治理與 wiki 自身
|
||||
|
||||
> 桶子索引——只連不重寫,卡片全文見各自檔案。
|
||||
|
||||
## 環境治理
|
||||
|
||||
- [[真身薄殼合一]] — 為什麼環境設定收斂成一個 plugin、本機雲端裝同一份。
|
||||
- [[hook路徑規約]] — hook 找自己用 `${CLAUDE_PLUGIN_ROOT}`、找專案檔案用 `$CLAUDE_PROJECT_DIR`,不可混用。
|
||||
|
||||
## wiki 自身
|
||||
|
||||
- [[repo邊界與紅線]] — ISEP 裝什麼/不裝什麼;wiki 為什麼是例外、例外的邊界在哪。
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
tags: [環境治理, 規約]
|
||||
gloss: hook 路徑規約是 ISEP 裡「hook 找自己用什麼變數、找專案檔案用什麼變數」的強制寫法。
|
||||
---
|
||||
# hook 路徑規約
|
||||
|
||||
← [[isep/00-INDEX]]
|
||||
|
||||
**來源**:`README.md`「路徑規約(薄殼一直壞掉的根)」段
|
||||
**最後更新**:2026-08-20
|
||||
|
||||
## 摘要
|
||||
hook 腳本裡有兩種完全不同的「路徑需求」,必須用不同變數,混用就是舊薄殼一直壞掉的根因。
|
||||
|
||||
## 重點
|
||||
- **hook 找自己(或要 source 的其他 hook 檔)→ 一律用官方 `${CLAUDE_PLUGIN_ROOT}`**。
|
||||
這是 plugin 安裝到哪裡,跟正在操作哪個專案無關,任何情境下都成立。
|
||||
- **禁止寫死絕對路徑**:本機測試時寫死看起來能跑,換一台機器或雲端就斷。
|
||||
- **禁止用 `$CLAUDE_PROJECT_DIR` 指 hook 自己**:這個變數指的是「目前操作的專案在哪」,
|
||||
雲端執行時 cwd 不是本機那個真身目錄,用它找 hook 自己一定找不到——
|
||||
這正是舊薄殼「雲端 33 支 guard 一支都沒生效」的根因(見 [[真身薄殼合一]])。
|
||||
- **腳本內部要指專案裡的檔案(`system-dev/wiki/`、`system-dev/docs/` 等)才用
|
||||
`$CLAUDE_PROJECT_DIR`**:這時候是對的,因為那些檔案本來就該住在被操作的那個 repo 裡,
|
||||
不是住在 plugin 安裝目錄裡。
|
||||
- ISEP 0.1.0 一次把 51 條 hook 路徑登記全部改成 `${CLAUDE_PLUGIN_ROOT}`,零漏網。
|
||||
|
||||
## 實體
|
||||
- **`${CLAUDE_PLUGIN_ROOT}`** — 官方變數,指 plugin 實際被安裝到的目錄,本機雲端都成立。
|
||||
- **`$CLAUDE_PROJECT_DIR`** — 指目前正在操作的專案根目錄,本機雲端可能是不同的路徑。
|
||||
|
||||
## 關聯
|
||||
### 內文知識關係
|
||||
- ${CLAUDE_PLUGIN_ROOT} >> 用於定位 >> hook 自己
|
||||
- $CLAUDE_PROJECT_DIR >> 用於定位 >> 專案內檔案
|
||||
### 卡片關係
|
||||
- [[hook路徑規約]] >> 修正自 >> [[真身薄殼合一]]
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
tags: [wiki自身, 決策, 規約]
|
||||
gloss: repo 邊界與紅線是 ISEP 這個 repo「裝什麼、不裝什麼、wiki 記什麼、不記什麼」的界線定義。
|
||||
---
|
||||
# repo 邊界與紅線
|
||||
|
||||
← [[isep/00-INDEX]]
|
||||
|
||||
**來源**:`README.md`「裝什麼」段、`inkstone/ISEP#3` 票內文
|
||||
**最後更新**:2026-08-20
|
||||
|
||||
## 摘要
|
||||
ISEP 是「環境」repo(hooks/commands/skills/scripts),本來刻意不放「知識」(wiki/docs/
|
||||
_archive)。`inkstone/ISEP#3` 在這條界線上開了一個明確定義過的例外:ISEP 需要**自己的**
|
||||
wiki,但那份 wiki 只能記 ISEP 自己的事,不能變成 InkStoneCo 頂層 wiki 的複製品。
|
||||
|
||||
## 重點
|
||||
- **裝的東西(環境)**:41 支 hook(`hooks.json` 註冊 51 條)、7 支 slash command、2 支 skill、
|
||||
23 支腳本。全部只改這裡,改完兩邊(本機/雲端)各自 `/plugin update`,
|
||||
不再改 `InkStoneCo/.claude/hooks/`(退場中)。
|
||||
- **原本不裝的東西**:`.env`(違反 D36「金鑰只有一個家」)、`wiki/`、`docs/`、`_archive/`——
|
||||
這些被歸類為「知識」而非「環境」。
|
||||
- **`#3` 開的例外**:ISEP 現在有 `system-dev/wiki/`,理由是「接手 ISEP 的 session(含雲端)
|
||||
要能在 repo 內就查到『這裡的決定、踩過的坑、現在什麼狀態』,不必先 clone InkStoneCo」。
|
||||
這不是推翻原本的分類,是承認 ISEP 本身也是一個有歷史、有決策、會踩坑的專案,
|
||||
需要一份屬於它自己的知識庫——跟裝進去的 hooks/commands 一樣,都是「這個 repo 自己的東西」。
|
||||
- **紅線沒有放寬**:ISEP 的 wiki **只記 ISEP 自己的事**。不把 InkStoneCo 頂層 wiki
|
||||
(`status.md`/`mistakes.md`/`decisions-summary.md` 等)的內容抄過來——複製即 fork,
|
||||
fork 即漂移,跟 [[真身薄殼合一]] 要解的病是同一種結構性錯誤,只是這次的對象換成知識庫。
|
||||
查跨專案的事仍然去 InkStoneCo 頂層;查 ISEP 自己的事才查這裡。
|
||||
- 素材骨架取自 `inkstone/system-dev-template`(見該 repo 的 wiki template),照它的規約裝
|
||||
(三層 + 標籤橫切:`INDEX.md`/`TAXONOMY.md`/`status.md`/`mistakes.md`/`principles.md`/
|
||||
`cards/<bucket>/`),不是自己另外發明一套格式。
|
||||
|
||||
## 實體
|
||||
- **環境**(environment)— hooks/commands/skills/scripts,本機雲端要同步的那層。
|
||||
- **知識**(knowledge)— wiki/docs,只跟這個 repo 自己被讀到什麼有關,不強求同步到別處。
|
||||
|
||||
## 關聯
|
||||
### 內文知識關係
|
||||
- 環境 >> 對立於 >> 知識
|
||||
- ISEP 的 wiki >> 只記 >> ISEP 自己的事
|
||||
### 卡片關係
|
||||
- [[repo邊界與紅線]] >> 延續同一種錯誤形狀 >> [[真身薄殼合一]]
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
tags: [環境治理, 決策]
|
||||
gloss: 真身薄殼合一是把「本機在跑的環境設定」與「雲端另外產生的一份環境設定」收斂成同一個 Claude Code plugin 的決定。
|
||||
---
|
||||
# 真身薄殼合一
|
||||
|
||||
← [[isep/00-INDEX]]
|
||||
|
||||
**來源**:`README.md`、commit `c263866`(ISEP 0.1.0)
|
||||
**最後更新**:2026-08-20
|
||||
|
||||
## 摘要
|
||||
在 ISEP 出現之前,同一套 Claude Code 環境設定(hooks/commands/skills/scripts)存在兩份:
|
||||
本機真身 `InkStoneCo/.claude/`,以及由 `generate-shell-payload.py` 另外產生、塞進 GitHub 私 repo
|
||||
給雲端用的「薄殼」。兩份必然漂移,且已經實測漂移過兩次。
|
||||
|
||||
## 重點
|
||||
- **薄殼比真身少 7 支閘**:`inkstone/InkStoneCo#57` 實測結果,其中兩支閘是前一天才立的——
|
||||
代表新立的規矩,雲端根本沒收到。
|
||||
- **雲端 33 支 guard 一支都沒生效**:`inkstone/InkStoneCo#14`,更早發現的同一個病,比上面那次更嚴重。
|
||||
- **解法不是修同步機制,是拿掉「兩份」這個結構**:ISEP 這個獨立 repo 本身就是唯一真相源,
|
||||
本機與雲端用同一個 plugin 安裝機制裝進去。改動只有一個地方能改。
|
||||
- **總管自己也吃這套**(leo 原話:「你自己可以 dogfooding」)——壞掉時是總管先踩到,
|
||||
不是雲端替他踩到才發現。
|
||||
- ISEP **不放** `.env`(金鑰另有家,見 D36)、`wiki/`、`docs/`、`_archive/`——那些原本被歸類為
|
||||
「知識」不是「環境」。**但 `inkstone/ISEP#3` 之後這條有了例外**:ISEP 需要自己的 wiki 才能被
|
||||
接手的 session 直接查到「這裡的事」,見 [[repo邊界與紅線]]。
|
||||
|
||||
## 實體
|
||||
- **ISEP**(InkStone Environment Plugin)— leo 的 Claude Code 環境唯一真相源 repo,2026-08-20 建立。
|
||||
- **真身**(`InkStoneCo/.claude/`)— 舊的、本機在跑的那份環境設定,現已退場中。
|
||||
- **薄殼**(shell payload)— 舊的、由腳本產生塞進 GitHub 私 repo 給雲端用的那份環境設定副本。
|
||||
|
||||
## 關聯
|
||||
### 內文知識關係
|
||||
- 真身 >> 與...漂移於 >> 薄殼
|
||||
- ISEP >> 取代 >> 真身
|
||||
- ISEP >> 取代 >> 薄殼
|
||||
### 卡片關係
|
||||
- [[真身薄殼合一]] >> 是...的前提 >> [[hook路徑規約]]
|
||||
- [[真身薄殼合一]] >> 帶出例外 >> [[repo邊界與紅線]]
|
||||
@@ -0,0 +1,22 @@
|
||||
# 決策摘要
|
||||
|
||||
> 這份是相容視圖(見 `wiki-init` 的 push/pull 判準:決策已降級為 cards 內容,這裡只放指標)。
|
||||
> 完整內容住在 `cards/isep/`,這裡只列「有這件決策、去哪張卡」。
|
||||
|
||||
## 真身薄殼合一 — 2026-08-20
|
||||
**結論**:環境設定(hooks/commands/skills/scripts)只留一份,裝在 ISEP 這個獨立 repo,
|
||||
本機與雲端裝同一個 Claude Code plugin。
|
||||
**原因**:兩份必然漂移,且漂移已經實際發生兩次(`InkStoneCo#57`、`#14`)。
|
||||
**詳細**:`cards/isep/真身薄殼合一.md`
|
||||
|
||||
## hook 路徑一律 ${CLAUDE_PLUGIN_ROOT} — 2026-08-20
|
||||
**結論**:hook 指自己用 `${CLAUDE_PLUGIN_ROOT}`;指專案內檔案(wiki/docs)才用 `$CLAUDE_PROJECT_DIR`。
|
||||
**原因**:寫死路徑或誤用 `$CLAUDE_PROJECT_DIR` 指自己=雲端 cwd 不是真身,路徑斷掉。
|
||||
**詳細**:`cards/isep/hook路徑規約.md`
|
||||
|
||||
## ISEP 自建 wiki,不繼承 InkStoneCo 的內容 — 2026-08-20
|
||||
**結論**:ISEP 裝一套自己的 `system-dev/wiki/`(依 `system-dev-template` 的骨架),只記 ISEP
|
||||
自己的決定與坑,不搬運 InkStoneCo 頂層 wiki 的內容。
|
||||
**原因**:wiki 是知識不是環境;複製過來即 fork,fork 即漂移——跟「真身薄殼合一」是同一個病,
|
||||
只是這次的對象換成知識庫而不是 hook。
|
||||
**詳細**:`cards/isep/repo邊界與紅線.md`;票 `inkstone/ISEP#3`。
|
||||
@@ -0,0 +1,37 @@
|
||||
# 已知誤解 / 踩過的坑
|
||||
|
||||
> 這是 ISEP 自己的坑,不是 InkStoneCo 的(不轉抄,複製即 fork,fork 即漂移)。
|
||||
> 撞到新坑就 append 一條;session 開場只推最近幾條標題(見 `hooks/session-start-recall.sh` push 5/5),全文在這裡。
|
||||
|
||||
⚠️ MISTAKE: 「環境設定」曾經拆成兩份,各自會漂
|
||||
症狀: 本機在跑 `InkStoneCo/.claude/`(真身),雲端跑的是 `generate-shell-payload.py`
|
||||
另外產生塞進 GitHub 私 repo 的一份(薄殼)。`inkstone/InkStoneCo#57` 實測:薄殼比真身
|
||||
少 7 支閘,其中兩支是前一天才立的;`#14` 更早查到雲端 33 支 guard 一支都沒生效。
|
||||
正確做法: 只留一份——ISEP 這個 repo 本身就是唯一真相源,本機與雲端裝同一個 plugin。
|
||||
改動一律只改這裡,然後兩邊各自 `/plugin update`。不要再改
|
||||
`InkStoneCo/.claude/hooks/`(退場中,早晚會刪)。
|
||||
原因: 「一份東西兩個副本」在沒有機制強制同步的情況下必然漂移——差異不是誰疏忽,
|
||||
是結構本身允許漂移發生。
|
||||
日期: 2026-08-20(ISEP `c263866` 建立時就是為了解這個病)
|
||||
|
||||
⚠️ MISTAKE: hook 路徑寫死會在雲端斷
|
||||
症狀: 舊版 hook 若用 `$CLAUDE_PROJECT_DIR/.claude/hooks/...` 或寫死的絕對路徑指向 hook
|
||||
腳本自己,雲端執行時的 cwd 不是本機那個真身目錄,路徑就對不到、hook 直接失效
|
||||
(正是上一條「雲端 33 支 guard 一支都沒生效」的根因)。
|
||||
正確做法: hook 指自己(找到自己在哪、要 source 的其他 hook 檔)一律用官方
|
||||
`${CLAUDE_PLUGIN_ROOT}`。腳本內部要指**專案裡的檔案**(如 `system-dev/wiki/`、
|
||||
`system-dev/docs/`)才用 `$CLAUDE_PROJECT_DIR`——那些檔案本來就该住在被操作的
|
||||
那個 repo 裡,跟 hook 自己的路徑是两回事,别混。
|
||||
原因: 兩種路徑指的是完全不同的東西(「plugin 安裝到哪」vs「正在操作哪個專案」),
|
||||
混用就是這條坑的直接原因。
|
||||
日期: 2026-08-20(README「路徑規約」段記錄,ISEP 0.1.0 把 51 條 hook 路徑全部改過一輪)
|
||||
|
||||
## ⚠️ MISTAKE: 「裝好了」不等於「它在跑」
|
||||
|
||||
2026-08-20 實查:ISEP repo 建好、README 寫著 0.1.0、41 支閘都在裡面——
|
||||
但 `claude plugin list` 裡**根本沒有 ISEP**。本機仍然在跑 `InkStoneCo/.claude/`,
|
||||
Gitea 上**一個 release tag 都沒有**。
|
||||
|
||||
⇒ 「東西做出來了」與「有人在用它」是兩件事,而只有後者算交付。
|
||||
⇒ 判準:**去執行環境查它有沒有被載入**(`claude plugin list` / `claude plugin details`),
|
||||
不要從 repo 裡有什麼檔案去推論。
|
||||
@@ -0,0 +1,7 @@
|
||||
# 設計原則(行動前必服從,全文注入,一行一條)
|
||||
|
||||
- 只改 ISEP,不改 `InkStoneCo/.claude/hooks/`(那個目錄退場中);改完兩邊各自 `/plugin update`。
|
||||
- hook 指自己一律用 `${CLAUDE_PLUGIN_ROOT}`,不寫死絕對路徑;指專案內檔案(wiki/docs)才用 `$CLAUDE_PROJECT_DIR`。
|
||||
- 本 repo 不放 `.env`/任何金鑰真身(D36「金鑰只有一個家」);也不放 `_archive/`。
|
||||
- ISEP 的 wiki 只記 ISEP 自己的事,不複製 InkStoneCo 的 wiki 內容(複製即 fork,fork 即漂移)。
|
||||
- 環境(hooks/commands/skills/scripts)與知識(wiki/docs)雖然裝在同一個 repo,改動理由不同——環境變更要同步本機+雲端兩份,知識變更只影響這個 repo 自己被讀到什麼。
|
||||
@@ -0,0 +1,45 @@
|
||||
# 當前狀態
|
||||
> 更新時間:2026-08-20
|
||||
|
||||
## 這是什麼專案
|
||||
ISEP(InkStone Environment Plugin):leo 的 Claude Code 環境唯一真相源——41 支機械閘、
|
||||
7 支 slash command、2 支 skill、23 支腳本,打包成一個 plugin,本機與雲端裝同一份。
|
||||
建立於 2026-08-20(`c263866`)。**版本號只看 Gitea Releases**,不在任何檔案裡宣稱(治理規範 M4.6)。
|
||||
|
||||
## 正在做
|
||||
- [🔄] `inkstone/ISEP#3`:讓 ISEP 自己有一套可查的 wiki(本次改動)——
|
||||
接手 ISEP 的 session 不必回頭 clone InkStoneCo 才查得到「這裡的決定/踩過的坑」。
|
||||
|
||||
## milestone v0.2.0 的其餘票(2026-08-20 撈的快照,動手前用 Gitea 核實別信這份)
|
||||
- `#2` 規範全文搬進 ISEP 的 `docs/`(目前只有 wiki,還沒有 `docs/`)
|
||||
- `#4` 各 repo 標籤統一,不用每次猜標籤名
|
||||
- `#5` 雲端 session 一啟動要載到 ISEP 的閘與 command
|
||||
- `#6` 每次交貨要有 release tag + release note
|
||||
|
||||
## 下次 session 第一件事
|
||||
查 Gitea `inkstone/ISEP` 的 `labels=s/todo,s/doing`,核對上面列的票是否還開著、狀態有沒有變,
|
||||
再從其中選一張接著做。**不要相信這份快照的票號清單本身**,只信「去查 Gitea」這個動作。
|
||||
|
||||
## 待負責人確認
|
||||
(無)
|
||||
|
||||
## 已知問題
|
||||
| 問題 | 優先級 | 狀態 |
|
||||
|------|--------|------|
|
||||
| Claude Code 能不能從私有 Gitea repo 裝 marketplace(要憑證)——README 明寫「尚未驗證」 | 🟡 | 待 `#1`/`#5` 相關票驗證 |
|
||||
| `system-dev/wiki/PANORAMA.md`(跨 repo wiki 全景圖)尚未產生——`scripts/wiki-panorama.sh --write` 要先建 `.panorama-repos.txt` roster,屬另一支票的地盤,本次未動 | ⚪ | 待補 |
|
||||
|
||||
## 🔴 目前是「兩份閘都在跑」的中間狀態(2026-08-20)
|
||||
|
||||
本機已經裝上 ISEP plugin(`claude plugin list` 看得到 `isep@inkstone`,enabled),
|
||||
但 `InkStoneCo/.claude/settings.json` 的 41 支閘**還沒拆**。⇒ 同一條規則會擋兩次。
|
||||
|
||||
**這是刻意的,不是忘了**:plugin 的 hook 是 session 啟動時載入,
|
||||
裝它的那個 session 驗不到它真的會觸發。沒驗到就拆,最壞情況是下一個 session 一支閘都沒有。
|
||||
|
||||
**下一個 session 第一件事**:照 `inkstone/ISEP#19` 的驗法確認 plugin 的閘真的會擋,
|
||||
確認了才拆舊的。**在那之前,看到閘訊息出現兩次是正常的。**
|
||||
|
||||
已比對過的等價性(2026-08-20 逐支):
|
||||
- hook 檔案:41 支檔名完全相同,ISEP 多一支 `release-tag-guard.sh`
|
||||
- 註冊條數:PreToolUse 29→30、SessionStart 2、Stop 10、SubagentStop 7、PostToolUse 3,其餘完全相同
|
||||
Reference in New Issue
Block a user