Compare commits

..

6 Commits

Author SHA1 Message Date
Leo 410771e883 E5 對齊 M4.3:到期只通知,不移票 2026-08-20 17:50:15 +08:00
Leo 64dae34efa v0.8.0 修訂:刪 M4.7、M4.3 改寫(里程碑內容不增不減)、§15 精簡成方向性規劃
leo 2026-08-20 兩則指正:
① 「milestone 確定後怎麼可以再把東西移除?定下工作自己刪掉是什麼意思?根本就沒有什麼降」
  ⇒ M4.7(降 scope 留痕)整段刪除——它把一個不該存在的操作合法化了。
  M4.3 改成:到期只通知 leo;內容增減都是 leo 的裁決,不是總管的操作。
② 「規劃書要大的規劃,方向性,不是寫廢話」
  ⇒ §15 從逐領域十行大表精簡成:四句方向+六里程碑順序表+三矛盾定案+三件待裁。
2026-08-20 17:42:51 +08:00
Leo 6d61c10cb8 治理規範 v0.8.0:三源整合定案(§15,leo 核准)
leo:「把 claude.ai 的規劃、舊有票的需求、現在已經有的機制全部整合,
修正出最終版規劃,核准再動工。」

- §15.1 逐領域十欄對照(A–J),每格標定案
- §15.2 三處矛盾的解法:#40 只減不增 vs E 清單要新閘(→伺服器端優先);
  warn-first vs 全 block(→四層定位,#48 是前提);E5 自動打 tag(維持否決)
- §15.3 已成立清單;§15.4 動工順序;§15.5 三件待裁(不擋群 0)
- 最大發現:claude.ai 兩份規劃都沒有「觀測」這一章,而舊票最痛的就是它
2026-08-20 17:40:52 +08:00
claude-code e7bea04862 Merge pull request '治理規範 v0.7.0:全局遍歷與 mapping 併入本檔' (#28) from docs/plan into main
治理規範 v0.7.0
2026-08-20 09:32:50 +00:00
Leo 6244baef25 治理規範 v0.7.0:全局遍歷與 mapping 併入本檔(不另立文件)
leo 2026-08-20:「我要你修正 sdd-gitea-governance.md 變成新版,不是要你重寫一版」——
總管原本把遍歷結果寫成獨立的 PLAN.md,那正是 §13.3 記的病「同一件事有兩份」,
當場刪除,內容併進本檔。

- §0 公理補第 8 條:票就是問題,衡量進度的是舊問題關掉幾張,不是出了幾個版本
- §13 現況遍歷:14 repo/156 open/45 張管理票分六群,排序按「什麼擋住什麼」,
  每條標來源票號與現況;含 #40 憲法七項對帳(總管自己違反兩項,如實記)
- §14 mapping:17 張新票只有 1 張真的推進舊問題(且僅半張);結論是不新增任何票
- §13.9 warn 可行性查證:hookify 的 warn 走 systemMessage 不進 AI,
  additionalContext 才進得去——#40 §3 可行,但要用對欄位
2026-08-20 17:32:29 +08:00
claude-code cf2b8e948c Merge pull request 'v0.2.1:43 支閘白話盤點+測試手冊+補兩個實撞的洞' (#27) from release/v0.2.1 into main
v0.2.1
2026-08-20 09:08:21 +00:00
+219 -15
View File
@@ -1,12 +1,16 @@
# SDD × Gitea 治理規範
```
version: 0.6.0
version: 0.8.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
→ v0.7.0 併入全局遍歷(14 repo156 open/45 張管理票分六群,§13)與新舊票 mapping(§14);
依 leo 指正:規劃不另立文件,修正本檔就是新版
→ v0.8.0 三源整合定案(§15):claude.ai 兩份規劃 × 舊票需求 × 既有機制,
逐領域對照、三處矛盾解法、動工順序——leo 2026-08-20 核准
```
---
@@ -22,6 +26,10 @@ lineage: v0.5.0 draft by claude.ai(存檔 _draft-claude-ai-v0.5.0.md
🔴 **不存在「薄殼只裝一部分」這種東西**——那正是 `InkStoneCo#57` 的成因。
6. **審核不是任務,是路徑。** 審核 review PR 並 merge,是交付的唯一必經動作(§3.0)。
7. **人是特殊 executor。** 人的兩種介入——審核者(`Human`)與執行者(`human/exec`)——分別建模,走同一狀態機(§6)。
8. **票就是問題;開發的目的是解決票上的問題。**leo 2026-08-20
衡量進度的是**舊問題關掉幾張**,不是出了幾個版本、開了幾張新票。
來由(同日實犯):總管開 17 張新票、出 2 個版本,事後 mapping 只有 1 張真的推進了舊問題——
其餘不是重複,就是「替自己想做的事編的 user story」。§14 是那次的完整對帳。
---
@@ -117,21 +125,12 @@ s/triage ──驗傷通過──▶ s/backlog ──排進 milestone──▶ s
- **M4.1** 命名 `vX.Y`,必設 due date。
- **M4.2** Deliverable **一個可測的新版本號**。所有掛入 leaf 關閉後,可從預設分支打出通過驗收的版本。
- **M4.3** **Timebox 到期不自動關、不自動打 tag。** 到期強制做一次降 scope 對帳(未完成 leaf 搬下一 milestone)並通知 leo。
🔴 自動打 tag 會製造假交付——tag 永遠只在「驗過了」之後發生。
- **M4.3** **Timebox 到期不自動關、不自動打 tag、也不把票移出** 到期只做一件事:通知 leo。
🔴 **里程碑的內容一經確定就不增不減**leo 2026-08-20:「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 不得自行宣稱版本號——那會產生第二份會漂移的版本真相。
@@ -242,7 +241,7 @@ s/triage ──驗傷通過──▶ s/backlog ──排進 milestone──▶ s
| E2 | PR 不關聯 issue | PR 模板必含 `closes #`,缺漏即 fail | ❌ 待建 |
| E3 | 手動關 leaf | hook 攔截;只放行 `close/*` 與 §6.2 人執路徑 | ❌ 待建 |
| E4 | 被 block 的票先關 | Gitea issue dependency | ✅ 平台原生,已驗證可用 |
| E5 | Milestone 悄悄過期 | job:到期做降 scope 對帳 通知**不自動關、不自動打 tag**) | ❌ 待建(先做成手動腳本,見 §8.2) |
| E5 | Milestone 悄悄過期 | job:到期只通知 leo**不自動關、不打 tag、不移票**M4.3) | ❌ 待建(先做成手動腳本,見 §8.2) |
| E6 | 代理越過人閘 | PreToolUse hook | ◐ 現有 `irreversible-dispatch-guard.sh``prod-write-guard.sh` 覆蓋一部分 |
| E7 | SDD 內出現 leaf 連結 | pre-commit lint | ❌ 待建 |
| E8 | Tracking issue 掛 milestone | job 摘除並告警 | ❌ 待建 |
@@ -412,6 +411,211 @@ Telegram → 純投影。**Wiki 壞不影響 GiteaGitea 壞不影響 SDD
---
## 13. 現況遍歷與工作分群(2026-08-20 全局實撈)
> 遍歷範圍:`inkstone` org **14 個 repo、156 張 open 票**。判為「管理」的 **45 張**收在本節。
> 判準:管**閘/票/派工/版本紀律/環境**的;產品功能與產品 bug 不在此列(§13.8 列出被排除的,供反對)。
>
> 🔴 **排序不是按票號,是按「什麼擋住什麼」**:上面的群沒解,下面的群做了也看不到效果。
> 本節是唯一把六群串起來的地方——Gitea 沒有跨 repo milestone(已查證),
> 各 repo 的同名里程碑都指回這裡。
### 13.0 六群一頁看完
```
群 0 閘正在害人 每天都在消耗,而且會讓其他群的成果被誤判
↓ 不修這群,任何新機制都會被同一批誤攔咬到
群 1 沒有資料說話 修了也不知道有沒有變好;leo 開場看不到全局
↓ 這群是「有沒有進步」的前提
群 2 同一件事有兩份 兩份必然漂移,漂了之後看起來還是綠的
↓ 環境/repo/文件/版本號,四種都在發生
群 3 人閘卡住 leo 他的啟動力是最稀缺的,卡在他身上整條線就停
群 4 派工與交付紀律 有了前面幾群,這群才驗證得了
群 5 票與文件歸位 收尾
```
**憲法另計**`inkstone/InkStoneCo#40` 不屬於任何一群——它規定「規則長什麼樣、怎麼增減」,管的是六群**怎麼做**。
### 13.1 群 0 ─ 閘正在害人(里程碑:`讓閘擋對東西`)
**共同形狀**:閘比對的是**指令長什麼樣**,不是**實際會發生什麼**
⇒ 同時漏擋(真動作藏在子行程/腳本裡)與誤攔(只是提到就被擋)。
leo 08-17 診斷見公理 3;08-17 實測:文字層的閘 **8 次誤攔、0 次正確攔截**
且方向穩定——**紅線寫得越細,命中關鍵字的機率越高 ⇒ 這些閘在懲罰謹慎**。
| 條目 | 來源票 | 現況(08-20) |
|---|---|---|
| 同一道閘同時漏擋真動作、誤擋只是提到它的句子 | `InkStoneCo#56` | 未動 |
| 紅線裡複述關鍵字被當成下令 | `InkStoneCo#23` | 未動|08-20 又撞 3 次,累計第 11 次 |
| 閘自己壞了:路徑解析失敗仍照擋,印 `/nonexistent` | `InkStoneCo#22` | 未動 |
| 守 prod 的閘,包一層腳本就繞過去 | `InkStoneCo#36` | 未動 |
| 空手停下:改判「這回合有沒有動作」不判文字 | `InkStoneCo#55` | 部分(`empty-handed-stop-guard.sh` 在跑) |
| gate workflow 六閘初稿待審 | `InkStoneCo#1` | triage |
**已實測、待套用的兩條判準**
① 關鍵字要在「指令位置」才算執行(`#23``prod-write-guard.sh` 驗證過;08-20 在 `release-tag-guard.sh` 重現 8/8
② 🔴 **heredoc 的 body 是資料不是指令**——08-20 三次誤攔全是這個形狀,**目前沒有任何一支閘實作**。
### 13.2 群 1 ─ 沒有資料說話(里程碑:`讓規則的效果看得見`)
沒有這群,「擋對 100 次」與「擋錯 100 次」在資料上長得一模一樣;
而 leo 開場看不到全局,每天要親口提醒「這個有票」「wiki 記過」——正是要拔掉的瓶頸。
| 條目 | 來源票 | 現況 |
|---|---|---|
| 閘的動作要留痕(擋下/放行/逃生口都查得到) | `InkStoneCo#48` | 未動(43 支只有 2 支會記錄);**是本群其餘條目的前提** |
| 票總圖:session 開場注入一份 md | `InkStoneCo#17` | 進行中 |
| 同一份圖涵蓋「哪個 repo 的 wiki 記過」 | `InkStoneCo#20``Arcrun#86` | 進行中(`PANORAMA.md` 已產出,hook patch 未套) |
| AI 開場看不到庫裡有什麼 | `Arcrun#142``Arcrun#81` | 未動 |
| 票 Kanban 視覺化 | `InkStoneCo#18` | pending |
### 13.3 群 2 ─ 同一件事有兩份(里程碑:`同一件事只留一份`)
兩份必然漂移,而漂了之後**看起來還是綠的**——比壞掉更危險。
| 條目 | 來源票 | 現況 |
|---|---|---|
| 【環境】雲端 guard 一支都沒生效 | `InkStoneCo#14` | 機制已交;**等 leo 填 Cloud environment 兩欄** |
| 【環境】薄殼的閘安靜落後真身 | `InkStoneCo#57` | 成因已消除(同一 plugin);舊 `.claude/` 未拆 |
| 【環境】D20 保險入 template | `system-dev-template#2` | 未動 |
| 【環境】安裝 URL 指死帳號 GitHub → 改指 Gitea | `system-dev-template#3` | 未動 |
| 【repo】同一專案兩份 repo、票號撞號 | `InkStoneCo#37` | **等 leo 裁以哪份為準**(建議 `inkstone/*` |
| 【文件】「D29」同號兩決策且無本文 | `InkStoneCo#11` | backlog |
| 【文件】changelog 兩份 | `arcrun-rag#116` | 進行中 |
| 【文件】錯誤分類兩份會漂 | `arcrun-rag#123` | triage |
| 【文件】更新說明沒有一頁看得完 | `arcrun-rag#122` | triage |
| 【版本】內外兩條號+出貨前建版本發佈 | `arcrun-rag#88` | 進行中 |
| 【版本】每人的 `acr` 跟 main 沒有保證關係 | `Arcrun#109` | 未動 |
### 13.4 群 3 ─ 人閘卡住 leo(里程碑:`不要卡在 leo 身上`)
北極星 §1:任何讓 leo 更忙的設計都是錯的。
| 條目 | 來源票 | 現況 |
|---|---|---|
| 不在電腦前就沒辦法同意(通用遠端同意,首例接 arm) | `InkStoneCo#15` | 未動 |
| ARM 碼有時效反而綁住 leo → 用掉才失效+Telegram | `InkStoneCo#38` | 未動 |
| Arm 頻道(手機回一句話=解閘) | `InkStoneCo#34` | 常駐頻道,不關 |
| 票上的同意不能當人閘證據 | `InkStoneCo#31` | 已標 duplicate |
| 催辦要自己發生 | `InkStoneCo#52` | triage |
### 13.5 群 4 ─ 派工與交付紀律(里程碑:`派工與交付紀律`)
| 條目 | 來源票 | 現況 |
|---|---|---|
| 派工全靠人記得(拿任務/改狀態/回報要機械必然) | `InkStoneCo#12` | 未動 |
| 共用工作區被 subagent 切走分支 | `InkStoneCo#28` | 未動|08-20 用 worktree 人工避開一次 |
| 出貨完了版控裡沒有這次出的東西 | `arcrun-rag#47` | 未動 |
| 修好的沒進出貨執行檔且沒有閘會講 | `Arcrun#93` | 未動 |
| main 上的測試要全綠 | `Arcrun#143``Arcrun#131` | 未動 |
| daemon 沒有 stage 通道 | `arcrun-rag#124` | 未動 |
| 出貨機制模組化 | `system-dev-template#7` | backlog |
### 13.6 群 5 ─ 票與文件歸位(里程碑:`票與文件歸位`)
| 條目 | 來源票 | 現況 |
|---|---|---|
| Gitea 管理機制:標籤+project | `InkStoneCo#9` | 標籤半已完成(labels.yaml14 repo 對齊);**project 半未動** |
| 378 條沒人維護的 checkbox 分診 | `InkStoneCo#49` | 未動 |
| issue 落地留底 | `system-dev-template#1` | 未動 |
| md → Gitea Project 單向投影 | `system-dev-template#4` | 未動 |
| 內部管理太混亂(總綱) | `InkStoneCo#10` | 總綱票,不關 |
| JDD 導入規格(方法論母題) | `InkStoneCo#8` | backlog;建議轉 hub 或作廢,**待 leo 裁** |
| 閉環機(哲學母題) | `InkStoneCo#5` | backlog;同上 |
### 13.7 憲法 `InkStoneCo#40` 的七項對帳(08-20
| 要求 | 現況 |
|---|---|
| 三層架構(skillhookify 規則/最小手寫 hook) | ❌ 未開始;`hookify` 已查證存在可用(官方 marketplace |
| 盤點表,leo 看過分類才准遷移 | ✅ 已交(`docs/hooks-inventory.md`**等 leo 看** |
| 每支三行中文檔頭 | ❌ 43 支全不合格(已量測:0 支三行齊全) |
| 新規則一律先 warn | ❌ 總管已違反(08-20 新增兩支直接 block);warn 可行性已查證,見 §13.9 |
| 關閉 CC 內建 git 指示 | ❌ 未動 |
| README 稽核總表 | ❌ 未動 |
| 手寫 hook 只減不增 | ❌ 總管已違反(41 → 43) |
### 13.8 不在本節的(判為非管理,列出供反對)
`arcrun-rag` 登入/額度/安裝/知識庫類約 40 張;`Arcrun` App 系統/KBDB 資料層/搜尋類約 35 張;
`mira` 全部 6 張;`InkStoneCo` `#2 #3 #4 #6 #7 #19 #42 #43 #44 #50 #51 #53`
`content-pipeline` 2 張;`kbdb-graph-plugin` 1 張。
`InkStoneCo#41` 是交接快照(歷史);`#25` 是 ops 排程。
### 13.9 warn 的可行性(查證結果,補 §8.3/§13.7 那一格)
- hookify 的 `warn``systemMessage`**只給人看,不進 AI** ⇒ 對 AI 行為無效
- `hookSpecificOutput.additionalContext` **會進 AI**08-20 本 session 實收多則)
- ⇒ 手寫閘做得出「AI 真的看得到的 warn」;hookify 的 warn 定位是給 leo 的提醒
-`#40` §3 照舊有效;已 block 的兩支新閘要補 warn 期或說明理由
---
## 14. Mapping:新票有沒有滿足舊票(2026-08-20 對帳)
> leo:「mapping 新票是否滿足舊票要求,滿足則舊票指向新票⋯⋯不滿足則新增票」。
> 對帳結果:**不需要新增任何票**——缺口都有既有票承接。
總管 08-20 開的 17 張新票逐張對舊票:
| 新票 | 對應舊票 | 滿足? | 處置 |
|---|---|---|---|
| `ISEP#4` 標籤一致 | `InkStoneCo#9` | **半**(標籤 ✅/project ❌) | 已關;結論貼回 `#9``#9` 續開 |
| `ISEP#2` 規範進 docs | `InkStoneCo#40` | 否 | 已關 duplicate 指回 |
| `ISEP#18` 本機 dogfooding | `InkStoneCo#57` | 否(裝上了,舊的沒拆) | 已關 duplicate 指回 |
| `ISEP#5``#21` 雲端 | `InkStoneCo#14` | 否(機制在,雲端仍沒閘) | 已關 duplicate 指回 |
| `ISEP#19` 舊閘退場 | `InkStoneCo#57` | 否 | 已關 duplicate 指回 |
| `ISEP#11``#17` 封路七張 | `InkStoneCo#40` | 否(把 §8 抄成票) | 已關 duplicate 指回 |
| `ISEP#24` 降 scope 留痕 | `InkStoneCo#10` | 否 | 已關 duplicate 指回 |
| `ISEP#3` wiki`ISEP#6` release | —— | **對不到任何舊票** | 是總管編的;已關 |
🔴 **17 張裡只有 1 張真的推進了舊問題,且只推進一半。** 這就是公理 8 的來由。
---
## 15. 三源整合定案(leo 2026-08-20 核准)
三源=claude.ai 兩份規劃(v0.5.0 draft`InkStoneCo#40` forge-discipline)× 45 張舊票 × 既有機制。
### 15.1 方向(四句,其餘全是它們的展開)
1. **機制只有一份。** 環境、標籤、規範、版本號都是單一真相源;本機與雲端裝同一個 plugin,沒有子集。
2. **閘封動作,不封措辭。** 伺服器端擋不可逆;手寫 hook 擋高代價動作(block);
hookifyadditionalContext 只提醒(永遠 warn);skill 管 regex 表達不了的判斷。
3. **一切要留痕、可量測。** 閘的動作、開場全局、里程碑百分比——leo 看到的畫面就是實況。
4. **進度=舊票關掉幾張。** 版本只是讓閘生效的載具,release note 寫明關了哪張票。
### 15.2 工作順序(六個里程碑,各 repo 同名,內容一經確定不增不減)
| 順 | 里程碑 | 來源票 |
|---|---|---|
| 0 | 讓閘擋對東西 | `InkStoneCo#56 #23 #22 #36 #55 #1` |
| 1 | 讓規則的效果看得見 | `InkStoneCo#48 #17 #20 #18``Arcrun#86 #142 #81` |
| 2 | 同一件事只留一份 | `InkStoneCo#14 #57 #37 #11``arcrun-rag#116 #123 #122 #88``Arcrun#109``system-dev-template#2 #3` |
| 3 | 不要卡在 leo 身上 | `InkStoneCo#15 #38 #34 #31 #52` |
| 4 | 派工與交付紀律 | `InkStoneCo#12 #28``arcrun-rag#47 #124``Arcrun#93 #143 #131``system-dev-template#7` |
| 5 | 票與文件歸位 | `InkStoneCo#9 #49 #10 #8 #5``system-dev-template#1 #4` |
排序判準=「什麼擋住什麼」:閘不修好,其他群的成果會被誤攔咬到;沒有留痕,修了也量不出變好。
`#40` 是憲法,貫穿全部;`#48``#40` warn 校準的資料前提,所以排群 1 之首。
### 15.3 三處矛盾的定案
1. `#40`「hook 只減不增」vs E 清單要 ~11 支新閘 ⇒ 新封路優先做在**伺服器端**或 **warn 層**
要新增 `.sh` 必須在 PR 說明為何前兩層做不到。
2. warn-first vs hookify 的 warn 不進 AI ⇒ warn 一律用 `additionalContext`
新規則從 warn 出生,憑 `#48` 的留痕數據才升 block。
3. milestone 到期自動關+打 tag ⇒ 否決(M4.3)。
### 15.4 待 leo 裁(不擋群 0 開工)
`#37` 兩份 repo 哪份為準(建議 `inkstone/*`)/`#5` `#8` 轉 hub 或作廢/
08-20 兩支未經 warn 期的 block 閘,隨盤點表(`docs/hooks-inventory.md`)一起審。
---
## 附:Label 全集(快照;唯一真相為 `labels.yaml`
```