依 D22 翻正舊 ignore 政策：本 repo 自己的 SDD 進版控 ＋ 新增 jdd-dual-profile 卷

🔴 修的病：這個框架 repo 自己的 5 份 SDD 全部被 .gitignore 擋在版控之外，
只活在一台硬碟上——clone 不到、雲端 CC 讀不到、沒備份。SDD 是進度真相源，
「框架 repo 沒吃自己的狗糧」。

依據 D22（已翻案）：Gitea private 除機敏值外全 push，雲端工人靠 clone，docs 缺＝斷糧；
只有 GitHub mirror 才嚴篩，而 docs 整包已在 github-publish-exclude.txt。

.gitignore 改法：整條擋 → 只擋子項（/*）+ 逐個放行真 SDD。
與 template/ 底下逐位元組相同的自裝副本（TEMPLATE-sdd/、SDD-LIFECYCLE.md）續擋。

新增 docs/3-specs/jdd-dual-profile/（status: draft，等 leo confirm 才升 active）：
JDD（PM 軌 root/journeys/角色權限/站號 sprint）與雙 profile 合成一卷，
33 條 task／6 phase，每條掛服務哪條 Gherkin（G1–G7）。
新增 hook 6 支、改既有 hook 1 支。**0 行實作**。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/3-specs/jdd-dual-profile/design.md

@@ -0,0 +1,416 @@
+---
+status: draft         # active | draft | paused | closed（生命週期鐵律見 ../SDD-LIFECYCLE.md）
+superseded_by: ""     # closed 且被取代時填接替的 SDD 資料夾名
+---
+
+# jdd-dual-profile — Design
+
+> 建立：2026-08-05 | 最後更新：2026-08-05
+> 負責人：system-dev-template CC
+> 來源：InkStoneCo 總管交辦 **W2**
+> **狀態：draft — 等 leo confirm 才升 active，未實作任何 code**
+>
+> 為什麼是 `draft` 而非 `active`：D35 ②③ 規定 CC 不得自行讓 SDD 生效；
+> 本 repo 目前 **0 份 active**（見「現況實查」§0.1），本案 confirm 後直接升 active，
+> 不需搬移任何未完成任務（無現任 active 可搬）。
+
+---
+
+## 一句話說明
+
+把 system-dev-template 從「單一 repo 級框架」改造成 **雙 profile 框架（總管級／repo 級）**，
+並在其上裝入 **JDD PM 軌**（root.md／journeys.md／站號 sprint／角色權限封路），
+讓「憲法分流」「角色權限」「實例不改機制」三件事全部由**檔案結構與 hook 機械決定**，
+沒有任何一格靠 agent 自我判斷。
+
+---
+
+## 0. 現況實查（動手前先搞清楚現在長什麼樣）
+
+> 本節是設計的事實基礎，也是「與規格假設不符」的清單來源。每條都是本次實測，不是回憶。
+
+### 0.1 SDD 現況
+
+- `docs/3-specs/` 下 5 個資料夾，**帶 frontmatter 的只有 `TEMPLATE-sdd`（status: draft）**。
+  `cross-repo-signing` / `install-layout` / `wiki-architecture` / `tasks-project-projection`
+  四份都只在正文寫「狀態：已採納／已結案」，**沒有 frontmatter** ⇒ 機器查得到的 `active` 數 = **0**。
+- 本 repo 的 SDD 住 `docs/3-specs/`，但它發給別人的 `sdd-guard.sh` 與 `sdd-active-check.sh`
+  預設路徑是 `system-dev/docs/3-specs` ⇒ **框架 repo 的 D35 閘從來沒對自己開過火**。
+- 現有 SDD 的實際慣例是 **design.md ＋ tasks.md 兩件式**（`TEMPLATE-sdd` 也只有這兩支），
+  `requirements.md` 在本 repo **沒有先例**。本案依交辦要求補齊三件式。
+
+### 0.2 安裝機制現況
+
+| 事實 | 影響本設計的地方 |
+|---|---|
+| `install.sh` 逐檔 `download_if_missing "<dest>" "$REPO_URL/<path>"`，**沒有 manifest**，檔案清單硬編在腳本裡 | 加 profile ⇒ 清單要分四份（common／repo／orchestrator／模組交叉），硬編必然漂移 → **必須先做 manifest** |
+| `update.sh` 另有一份**幾乎重複**的清單（update_file／keep_file／add_if_missing／keep_with_template 四類） | 同上；manifest 的「類別」欄正好就是這四類 |
+| `REPO_URL = $TEMPLATE_SOURCE/template`，所有安裝產物的遠端路徑都掛在 `template/` 底下 | 分離 §三把 `common/`、`profiles/` 畫在 repo 根 ⇒ 會變成第二個 base URL；本設計改掛 `template/` 底下（見決策 D2） |
+| `update.sh` 的**自我更新在腳本尾端**（先跑完所有下載才更新自己） | 若這一版搬動既有檔案路徑，舊實例這一輪會整排 404；1.16.0 已被同型問題咬過（來源改動＝自動更新死掉）⇒ **既有檔一律不搬**（決策 D3） |
+| `CLAUDE.md` 是整份下載 ＋ `emit_raw_source_block` append，**沒有任何區段界標** | 「本地補充區」目前不存在邊界，漂移偵測無從談起 ⇒ 必須先立界標（設計 §2） |
+| `build_hooks_json()` 依模組（wiki/sdd）條件組裝 settings.json | profile 只是加第三個維度，**沿用同一支函式**，不另造 |
+
+### 0.3 hook 現況（template 內共 7 支）
+
+`pre-write-guard.sh`（空殼，`FORBIDDEN_PATTERNS` 為空＝不攔任何東西）、`publish-lag-check.sh`、
+`sdd-guard.sh`、`session-start-recall.sh`、`subagent-wiki-guard.sh`、`wiki-first-search.sh`、
+`wiki-secret-scan.sh`。
+
+- **`AGENT_ROLE` 在整個 repo 與 InkStoneCo 實例中 0 次出現** ⇒ 角色軸完全從零開始。
+- **`guard-cross-project.sh` 不在 template 裡**——它只存在於 InkStoneCo 實例的 `.claude/hooks/`。
+  分離 §六.4 標它 `[修改]`，實際動作是「**從實例上收進框架**」，不是就地改（決策 D6）。
+- 同理，`delivery-police.sh`／`self-drive-police.sh`／`unpushed-police.sh`／`history-first-guard.sh`
+  等 **11 支都是實例自行發明的**，框架不知道它們存在。
+
+### 0.4 漂移基線（機械閘 #3 的今日實測值）
+
+比對 InkStoneCo 實例的 `.claude/hooks/` 與本 repo `template/.claude/hooks/`：
+
+| 狀態 | 數量 | 檔 |
+|---|---|---|
+| 與框架一致 | 2 | `session-start-recall.sh`、`wiki-secret-scan.sh` |
+| **已被手改（漂移）** | **4** | `pre-write-guard.sh`、`sdd-guard.sh`、`subagent-wiki-guard.sh`、`wiki-first-search.sh` |
+| 實例自行發明 | 11 | 見 §0.3 |
+
+⇒ **今天沒有任何機制知道這 4 支已經漂移**。這就是分離 §八 預測②（「漂移數歸零」）的基線值 = 4。
+
+### 0.5 實例專名基線（機械閘 #2 的今日實測值）
+
+`template/` 底下命中 `arcrun|mira|leo21c|inkstone|uncle6|polaris`：**8 檔 20 行**。分三類：
+
+| 類 | 內容 | 處置 |
+|---|---|---|
+| (a) 註解／舉例（6 行） | `sdd-guard.sh`「誠實限制（抄 arcrun）」、`publish-lag-check.sh` 的 jsDelivr 例、`logseq-markers.md` 的 TODO 例句、`issue-handle.md` 的 repo 名清單 | **本波清理**（改寫成通用敘述） |
+| (b) 政策內容混進框架（3 行） | `subagent-wiki-guard.sh`「有 Arcrun RAG MCP 就用它」、`wiki-extract.md`「下游 Arcrun ingest」 | **標逐行豁免，W3 隨 policy pack 搬走** |
+| (c) 整支是 L2 產物（13 行） | `system-dev/workflows/tasks-project-sync.{yaml,local.sh}`（本體就是 arcrun workflow） | **整組標豁免，W3 移入 policy pack** |
+
+⇒ 閘 #2 **不能一上線就全紅**。必須配「逐行豁免標記 ＋ 基線報表」，否則為了讓 CI 綠會出現
+假性清理（把 arcrun 換成「某工作流引擎」＝資訊消失但問題還在）。
+
+---
+
+## 範圍
+
+### 包含（In Scope）
+
+- template 的雙 profile 化（宣告式，非搬檔）：manifest、`--profile`、profile 專屬產物
+- CLAUDE.md 生成、框架區／本地補充區界標、update 漂移偵測
+- JDD 文件範本：`root.md`、`journeys.md`（含站點索引表）、站號 sprint 範本、術語表
+- 兩軸身分（scope × role）的機械判定函式庫
+- JDD §六 8 條封路規則 ＋ 分離 §六 4 條防糾纏閘的實作
+- policy plugin 的**插槽**：載入順序文件化 ＋ profile 憲法 must-read 注入點
+- CHANGELOG ＋ VERSION bump ＋ 乾淨環境雙 profile 安裝實測
+
+### 不包含（Out of Scope）
+
+- **arcrun-policy plugin 本體**（W3）：`plugin.json`、marketplace 發行、白名單 hook 內容、
+  primer／dispatch-checklist 搬遷、`.mcp.json`
+- **實例側落地**（W4）：InkStoneCo 的 root.md／journeys.md 實填、routine 取任務源改站號、
+  實例 11 支自製 hook 的退役與上收
+- **雲端側**（W5）：LLM Wiki 總編輯管線、儀表 job、`arch_baseline`／`arch_iteration` 卡
+- **記憶階梯改序（KBDB-first）**：藍圖 §7，屬另一波
+- **既有 SDD 的 frontmatter 補齊**（§0.1 撿到的斷層）：本波只回報，不順手改——
+  那會動到四份別的 SDD 的生命週期狀態，屬規格層，另走 pending-changes
+
+---
+
+## 1. 架構總覽
+
+```
+system-dev-template/                     ← 框架 repo（本 repo）
+├─ scripts/install.sh   --profile=repo|orchestrator   ← 改造：讀 manifest
+├─ scripts/update.sh                                   ← 改造：讀 manifest ＋ 漂移偵測
+├─ scripts/check-no-instance-names.sh                  ← 新增：機械閘 #2（CI）
+├─ scripts/instance-names.txt                          ← 新增：黑名單設定檔
+└─ template/                             ← 所有安裝產物的遠端根（$REPO_URL）
+   ├─ manifest/
+   │   ├─ common.tsv                     ← 新增：兩 profile 共裝
+   │   ├─ repo.tsv                       ← 新增：repo profile 專屬
+   │   └─ orchestrator.tsv               ← 新增：orchestrator profile 專屬
+   ├─ .claude/hooks/…                    ← 既有 7 支【原地不動】＝ common 的實體
+   │   ├─ lib/role-lib.sh                ← 新增：兩軸判定函式庫（被 source）
+   │   ├─ role-guard.sh                  ← 新增：J1+J2+J3
+   │   ├─ jdd-format-guard.sh            ← 新增：J4+J5+J8
+   │   ├─ station-done-guard.sh          ← 新增：J6
+   │   ├─ regression-scope.sh            ← 新增：J7
+   │   └─ install-artifact-guard.sh      ← 新增：S1
+   ├─ profiles/
+   │   ├─ repo/
+   │   │   ├─ CLAUDE.md                  ← repo 憲法範本（＝現行 template/CLAUDE.md 演進）
+   │   │   └─ （SDD 三件式、repo wiki 規範：沿用 common 既有產物，manifest 宣告即可）
+   │   └─ orchestrator/
+   │       ├─ CLAUDE.md                  ← 總管憲法範本（藍圖 v3 指針＋術語表）
+   │       ├─ docs/root.md.template
+   │       ├─ docs/journeys.md.template
+   │       ├─ docs/sprint.md.template     ← 站號 sprint
+   │       ├─ docs/triage-map.md.template ← 格式範本，內容留實例
+   │       ├─ docs/plugin-load-order.md   ← 載入順序文件（W3 插槽）
+   │       └─ hooks/orchestrator-scope-guard.sh  ← 新增：S4（上收 guard-cross-project）
+   └─ system-dev/…                       ← 既有【原地不動】
+
+實例安裝後：
+  CLAUDE.md                    ← 框架區（profile 範本）＋ 本地補充區（界標分隔）
+  system-dev/.profile          ← 單行：repo | orchestrator（scope 軸唯一來源）
+  system-dev/.template-manifest ← 每個產物的 path / version / sha256（漂移偵測依據）
+```
+
+---
+
+## 2. 設計答案①：雙 profile 的 CLAUDE.md 怎麼生成、本地補充區邊界、漂移怎麼偵測
+
+### 2.1 生成：組裝而非下載
+
+現行是「整份下載 `template/CLAUDE.md` ＋ append raw source 區塊」。改為三段組裝：
+
+```
+<!-- sdt:framework begin profile=<repo|orchestrator> version=1.19.0 sha256=<前12碼> -->
+（profiles/<profile>/CLAUDE.md 的完整內容，一字不改）
+<!-- sdt:framework end -->
+
+<!-- sdt:local begin — 這一區是你的，update 永遠不會動它 -->
+（install 產生的 raw source 宣告；之後由使用者／CC 自由追加）
+<!-- sdt:local end -->
+```
+
+- 界標用 HTML 註解：md 渲染看不見、CC 讀得到、`grep -n` 定位得到。
+- `sha256` 記的是**框架區內容本身**（不含界標行），是漂移偵測的比對基準。
+- 兩區順序固定：框架區在上（agent 先讀到憲法），本地區在下。
+
+### 2.2 兩份 profile 憲法的內容分界（G4 的判準）
+
+| | `profiles/repo/CLAUDE.md` | `profiles/orchestrator/CLAUDE.md` |
+|---|---|---|
+| 效忠文件 | `requirements.md`（SDD 技術軌） | `root.md` ＋ `journeys.md`（PM 軌） |
+| 含 SDD 三件式細節 | ✅ 含（現行內容） | ❌ **不含**（G4 明文：總管版無 SDD 三件式細節） |
+| 上游指針 | ✅ 一行（指向總管 repo 的憲法位置，**不寫死專案名**，由 install 問一次或留空） | ❌ 無（它自己就是上游） |
+| JDD 術語表 | 只放「站號怎麼標在 task 上」一段 | 全表（Journey／Station／通關／點亮／對帳／完備） |
+| sprint 機制 | 「認領 loop」段（engineer 的動作） | 全流程（指定站 → 認領 → 新增必掛站 → 收尾判準） |
+| 角色 | engineer（可寫 code／tasks／requirements／design；禁改考卷） | orchestrator（可寫 root／journeys／sprint；禁寫 code、禁改 tasks） |
+
+> G4 的機械驗法：`grep -c "SDD 三件式\|requirements.md" CLAUDE.md`
+> 在 orchestrator 實例上 = 0；`grep -c "上游" CLAUDE.md` 在 repo 實例上 ≥ 1。
+
+### 2.3 邊界規則（寫進兩份憲法，並由 hook 兌現）
+
+1. **框架區唯讀**：任何內容變更走框架 repo 提案 → bump → update 拉下來。
+2. **本地補充區隨便寫**：update 永不讀、永不寫、永不比對。
+3. 實例要覆寫框架區的某條規則 → 不准就地改，**在本地補充區寫「例外聲明 ＋ 理由 ＋ 日期」**。
+   這樣 diff 永遠乾淨，而例外仍然留痕可審。
+
+### 2.4 漂移偵測：manifest ＋ sha256
+
+`system-dev/.template-manifest`（install 產生，update 維護），TSV 一行一產物：
+
+```
+<dest 路徑>	<class>	<安裝時 version>	<安裝時 sha256>
+```
+
+`class` 沿用 update.sh 既有四類語意：`overwrite`（模板/邏輯檔）／`keep`（使用者資料檔）／
+`add-if-missing`（新資料檔）／`keep-with-template`（使用者會手填的客製檔）。
+
+update 對每個 `overwrite` 類產物跑三態判定：
+
+| 實檔 sha vs manifest sha | 遠端 sha vs manifest sha | 判定 | 動作 |
+|---|---|---|---|
+| 相同 | 相同 | 沒變 | **no-op**（不下載、不列報表）← 兌現 EARS-1.2.2 |
+| 相同 | 不同 | 乾淨、有新版 | 覆蓋，列「已更新」 |
+| **不同** | 任意 | **漂移** | **不覆蓋**；新版另存 `<檔>.new`；列入 ⚠️ 漂移清單 |
+
+漂移清單的輸出格式（白話，leo 讀得懂）：
+
+```
+⚠️  下列 3 個檔被手改過，這一版沒有覆蓋它們：
+   .claude/hooks/sdd-guard.sh          → 新版已放在 sdd-guard.sh.new，請 diff
+       你可以：① 把你的改動寫成框架提案（推薦，一次修全家）
+               ② 放棄本地改動：mv sdd-guard.sh.new sdd-guard.sh
+```
+
+**舊實例遷移（沒有 manifest 的 1.18.x）**：update 偵測到無 manifest → 進「一次性補植」：
+以本版遠端內容為基準建 manifest，**凡當下與遠端不一致者一律先標成漂移**（保守：寧可多報不漏報），
+並把現有 `CLAUDE.md` 整份包進 `sdt:local` 區、框架區從 profile 重鋪，
+輸出「你的舊 CLAUDE.md 已完整保留在本地補充區，請自行搬移重複段落」。整段冪等，重跑不再動。
+
+---
+
+## 3. 設計答案②：AGENT_ROLE 兩軸身分在 hook 裡怎麼機械判定
+
+### 3.1 兩個來源，零自陳
+
+| 軸 | 來源 | 誰寫 | 讀不到時 |
+|---|---|---|---|
+| **scope** | `system-dev/.profile`（單行 `repo`／`orchestrator`） | install.sh（`--profile` 或偵測＋人確認一次） | 視為 `repo`（多數實例；且此時 orchestrator 專屬閘不觸發，仍有 common 閘在） |
+| **role** | 環境變數 `AGENT_ROLE`（`orchestrator`／`engineer`） | ① install 依 profile 寫進 `.claude/settings.json` 的 `env` 當預設<br>② 派工端 spawn subagent 時注入<br>③ 人工 override | **依 scope 推定**：orchestrator profile → `orchestrator`；repo profile → `engineer` |
+
+> 為什麼 scope 不放 `settings.json`：settings.json 是「使用者資料檔」，update 永不覆蓋，
+> 而且 CI／獨立腳本也要讀得到。`system-dev/.profile` 與 `VERSION` 同層，一致且好找。
+
+### 3.2 身分矩陣（含那個不存在的格子）
+
+| | `AGENT_ROLE=orchestrator` | `AGENT_ROLE=engineer` |
+|---|---|---|
+| **orchestrator profile** | PM 本尊 ✅ | 總管 repo 裡的技術 subagent ✅ |
+| **repo profile** | **❌ 不存在** → exit 2，要求修正環境 | 寫 code 的 subagent ✅ |
+
+「repo profile × orchestrator」被攔的訊息要說清楚：成員 repo 沒有 PM——
+要 PM 的動作請回總管 repo 做（分離 §二「空格也是封路」）。
+
+### 3.3 `lib/role-lib.sh`（common，被 source 不獨立掛）
+
+```bash
+sdt_repo_root()    # 由 ${BASH_SOURCE} 往上找，不假設 CLAUDE_PROJECT_DIR（雲端可跑）
+sdt_rel_path "$f"  # 絕對/相對 → repo 相對路徑（抄 guard-cross-project 的 case 寫法）
+sdt_scope()        # 讀 system-dev/.profile，trim；讀不到回 repo
+sdt_role()         # 讀 $AGENT_ROLE；空 → 依 sdt_scope 推定
+sdt_assert_identity()  # 檢查矩陣空格，命中 → 印訊息 exit 2
+sdt_file_path_from_stdin  # 統一的 JSON 解析（jq → python3 → grep 三段 fallback）
+```
+
+**為什麼是函式庫不是 hook**：六支新 hook 都要做同樣四件事（解析 JSON、算相對路徑、判 scope、判 role）。
+各寫一份＝四處維護同一條規則，正是分離 §六.4 要避免的病。
+
+### 3.4 為什麼角色 hook 屬 common，不按規格放進各自 profile
+
+分離 §三把 `engineer 角色 hooks` 畫在 `profiles/repo/`、`orchestrator 角色 hooks` 畫在
+`profiles/orchestrator/`。**照做會漏一格**：總管 repo 裡也會 spawn engineer subagent
+（矩陣右上角），若 engineer 的封路 hook 只裝在 repo profile，那顆 subagent 在總管 repo 裡
+**改得動 journeys.md** ⇒ G2「考生改考卷被攔截」在最該生效的地方失效。
+
+⇒ 本設計改為：**role 軸的 hook 全部屬 common（兩 profile 都裝），scope 軸的 hook 才按 profile 分**。
+唯一 scope 專屬的是 `orchestrator-scope-guard.sh`（總管禁入成員 repo 寫實作）。
+
+---
+
+## 4. 設計答案③：12 條規則落成哪些 hook（改既有 vs 新增）
+
+> **規則數 ≠ 檔案數**。J1/J2/J3 都是「PreToolUse Write|Edit 依 role×path 判定」，
+> 拆三支＝三次解析同一包 JSON、三處維護同一張路徑表。合併為一支、規則編號保留在程式碼註解與訊息裡。
+
+### 4.1 JDD §六 八條
+
+| 規則 | 內容 | 落點 | 既有/新增 |
+|---|---|---|---|
+| J1 | orchestrator 寫 `src/**`、`*.py`、`*.ts`… → 攔 | `role-guard.sh` | **新增**（規格說「既有 hook 已涵蓋則跳過」——已確認 `pre-write-guard.sh` 是空殼且不認 role，**不涵蓋**） |
+| J2 | orchestrator 寫 `tasks.md`／`requirements.md`／`design.md` → 攔 | `role-guard.sh` | 新增（同上） |
+| J3 | engineer 寫 `journeys.md`／`root.md`／`*.feature`／md 內 Gherkin 區塊 → 攔（**命門**） | `role-guard.sh` | 新增 |
+| J4 | `root.md` 🔴 卡缺【要驗證＋對帳日】→ 攔 | `jdd-format-guard.sh` | 新增 |
+| J5 | `tasks.md` **新增**的 task 缺站號 → 攔 | `jdd-format-guard.sh` | 新增 |
+| J6 | sprint 收尾判準：tasks 全關 → **指定站 Gherkin 全過** | `station-done-guard.sh` | **新增**（規格標 `[修改]`，但 template 內**沒有**任何 sprint 收尾 hook——`delivery-police.sh` 只存在於 InkStoneCo 實例 ⇒ 對框架而言是新增，見決策 D6） |
+| J7 | 站相關實作變動 → 查站點索引表 → 列重考清單 | `regression-scope.sh` | 新增（提醒不擋） |
+| J8 | `root.md`／`journeys.md` 出現技術名詞 → 警告/攔 | `jdd-format-guard.sh` | 新增 |
+
+### 4.2 分離 §六 四條
+
+| 閘 | 內容 | 落點 | 既有/新增 |
+|---|---|---|---|
+| S1 | 實例寫入安裝產物區 → 攔；`--framework-dev` 例外 | `install-artifact-guard.sh` | 新增 |
+| S2 | 框架範本混入實例專名 → CI fail | `scripts/check-no-instance-names.sh`（**非 hook**） | 新增 |
+| S3 | update 漂移偵測 | `update.sh` ＋ `.template-manifest` | **改既有腳本** |
+| S4 | guard-cross-project 職責不重疊 | `profiles/orchestrator/hooks/orchestrator-scope-guard.sh` | **新增於框架**（實體改寫自實例那支，見 D6） |
+
+### 4.3 既有檔改動清單
+
+| 檔 | 改什麼 | 為什麼 |
+|---|---|---|
+| `template/.claude/hooks/session-start-recall.sh` | 依 `sdt_scope()` 分流注入：orchestrator → root/journeys 摘要 ＋ 本 sprint **未點亮**站；repo → 現行 principles/status/mistakes | 唯一真正的「改既有 hook」；藍圖 §0「routine 起牀讀站號」的落點 |
+| `scripts/install.sh` | 加 `--profile`、自動偵測＋人確認、改讀 manifest、產 `.profile`／`.template-manifest`、CLAUDE.md 三段組裝、`build_hooks_json()` 加 profile 維度與 `env.AGENT_ROLE` | E1 主體 |
+| `scripts/update.sh` | 改讀 manifest、三態判定、漂移報表、舊實例 marker 補植遷移 | S3 ＋ EARS-1.2.2 |
+| `template/CLAUDE.md` | 演進為 `template/profiles/repo/CLAUDE.md`；**原路徑保留一份轉址說明**，避免舊 update.sh 404 | D3 向下相容 |
+| §0.5 (a) 類 6 行註解 | 改寫成通用敘述 | S2 前置清潔 |
+
+**合計：新增 hook 6 支**（`role-guard`、`jdd-format-guard`、`station-done-guard`、
+`regression-scope`、`install-artifact-guard`、`orchestrator-scope-guard`）
+＋ **共用函式庫 1 支**（`lib/role-lib.sh`，不獨立掛）；
+**改既有 hook 1 支**（`session-start-recall.sh`）；**改既有腳本 2 支**（install/update）；
+**新增非 hook 腳本 1 支**（`check-no-instance-names.sh`）。
+
+### 4.4 settings.json 掛載順序（install 依 profile 組裝）
+
+```
+SessionStart:   session-start-recall.sh（profile 分流）
+                [W3 插槽：policy plugin 的 SessionStart hook 自動排在框架 hook 之後]
+PreToolUse(Write|Edit|MultiEdit):
+                1. install-artifact-guard.sh   ← 先擋「改機制」，最外層
+                2. role-guard.sh               ← 再判角色
+                3. jdd-format-guard.sh         ← 再驗格式
+                4. orchestrator-scope-guard.sh ← 僅 orchestrator profile
+                5. sdd-guard.sh（既有）
+                6. pre-write-guard.sh（既有空殼）
+                7. wiki-secret-scan.sh（既有）
+PreToolUse(Grep|Glob|Read|Bash):  wiki-first-search.sh（既有）
+PreToolUse(Task):                 subagent-wiki-guard.sh（既有）
+Stop / TaskCompleted:             station-done-guard.sh、regression-scope.sh
+```
+
+順序原則：**範圍大的擋在前**（改機制 → 角色 → 格式），讓錯誤訊息指向最根本的那條規則。
+
+---
+
+## 5. W3 插槽（本波只留座位，不做 plugin）
+
+分離 §五 載入順序原樣文件化到 `profiles/*/docs/plugin-load-order.md`：
+
+```
+SessionStart
+ 1. profile 憲法（scope 軸：這個資料夾的 CLAUDE.md）
+ 2. framework hooks 上鏈（common ＋ profile）
+ 3. 已安裝 policy plugin 注入（primer 推到眼前、白名單 hook 排入鏈尾、skill 就緒）
+ 4. session-start-recall（wiki status 快照，現行機制）
+```
+
+框架要做的只有兩件（分離 §四明文）：
+1. 文件化「政策包＝ Claude Code 官方 plugin」的約定與載入順序——**框架不發明平行外掛格式**；
+2. 在兩份 profile 憲法留 must-read 注入點（一段標題 ＋ 一行說明「政策包的必讀會出現在這裡」），
+   讓 plugin 的 SessionStart hook 有地方推內容。
+
+⚠️ **W3 動手前必讀官方文件**（`code.claude.com/docs/en/plugins.md`、`plugins-reference.md`），
+不憑記憶寫 `plugin.json`。本 SDD **不**預先規定 plugin 的 schema。
+
+---
+
+## 關鍵決策
+
+| # | 決策 | 選擇 | 原因 | 放棄的選項 |
+|---|---|---|---|---|
+| D1 | 安裝清單怎麼管 | **manifest TSV**（common/repo/orchestrator 各一份），install 與 update 共讀 | 現行清單硬編在兩支腳本裡已經重複；加 profile 會變四份必然漂移。manifest 讓「加一個產物」＝加一行資料 | 繼續硬編（四份清單手動同步） |
+| D2 | `common/`、`profiles/` 放哪 | 放 **`template/` 底下** | 所有安裝產物的遠端根是 `$TEMPLATE_SOURCE/template`；放 repo 根會開第二個 base URL，publish-exclude 與 mirror 規則也要跟著改。分離 §三的樹是示意（它把 install.sh 也畫在根，實際在 `scripts/`） | 照規格字面放 repo 根 |
+| D3 | 既有檔要不要實體搬進 `common/` | **不搬**。既有檔原地不動，靠 manifest **宣告**它屬 common | `update.sh` 的自我更新在腳本尾端 ⇒ 舊實例跑的是舊腳本、路徑寫死，搬檔＝這一輪整排 404。1.16.0 已經被「來源改動＝自動更新死掉」咬過一次 | 照規格字面實體搬移（斷所有舊實例的更新） |
+| D4 | 「本地補充區」怎麼劃 | **HTML 註解界標** ＋ 框架區 sha256 | md 渲染不可見、grep 定位得到、CC 讀得到；sha 讓漂移可機械判定 | 靠檔尾約定（無邊界＝無法偵測）／另開 `CLAUDE.local.md`（agent 不保證會讀） |
+| D5 | 角色 hook 屬 common 還是各 profile | **屬 common** | 總管 repo 裡也會 spawn engineer；照規格分裝會讓那顆 subagent 改得動 journeys.md，G2 在最該生效處失效（§3.4） | 照規格分裝進各 profile |
+| D6 | `guard-cross-project` 怎麼「修改」 | **上收進框架** `orchestrator-scope-guard.sh`，實例版於 W4 退役 | 它根本不在 template 裡，是實例自己發明的。就地改＝在實例改機制＝違反本案要立的第一條鐵律 | 在實例上就地改（自打嘴巴） |
+| D7 | J1/J2/J3 三條規則的檔案數 | **合成一支 `role-guard.sh`** | 同一個 hook 事件、同一份身分判定、同一張路徑表；拆三支＝三處維護一條規則 | 一條一支（規格字面「逐條實作」） |
+| D8 | 閘 #2（實例專名）怎麼上線 | **腳本 ＋ 逐行豁免標記 ＋ 基線報表**，(a) 類本波清、(b)(c) 類標豁免待 W3 | 現況 8 檔 20 行命中；一上線全紅會逼出假性清理（把 arcrun 換成「某工作流引擎」＝資訊沒了問題還在） | 硬上線（CI 立刻全紅）／先全部改寫（假性清理） |
+| D9 | `--framework-dev` 怎麼實作 | **repo 根的 `.sdt-framework-dev` 檔**（框架 repo 自帶並 commit），輔以 env `SDT_FRAMEWORK_DEV=1` | Claude Code **沒有** `--framework-dev` 這個官方 flag（規格假設不成立）。用檔案＝框架 repo 天生就有，零記憶負擔 | 造一個 CLI flag（做不到）／純靠環境變數（每次要記得設） |
+| D10 | 本 SDD 的 status | **draft**，confirm 後升 active | D35 ②③；本 repo 現有 0 份 active，升活性不需搬移任何任務 | 直接寫 active（搶活性） |
+
+---
+
+## 技術限制
+
+- 相容 macOS bash 3.2（`set -u` 下空陣列展開要先判長度——install.sh 既有踩過）。
+- 不假設有 `jq`：JSON 解析走 `jq → python3 → grep` 三段 fallback（沿既有 hook 慣例）。
+- 不假設 `CLAUDE_PROJECT_DIR` 存在：路徑一律由 `${BASH_SOURCE}` 往上推（雲端可跑）。
+- hook 一律「解析失敗即放行」，寧可漏擋不誤殺；每支頂部寫誠實限制。
+- 遠端檔案路徑（`$REPO_URL/...`）對既有實例是**契約**，本波只增不移。
+
+---
+
+## 驗收標準
+
+以 requirements.md §四 的 **G1–G7** 為唯一驗收線。收工時每題必須附**實測輸出**，
+狀態只有三種：`✅ 通（附證據）` / `◐ 半通（標明缺什麼）` / `❌ 斷`。
+
+- G5 本波上限為 `◐ 半通`（插槽就位、政策包在 W3）——**不得標 ✅**。
+- 另加兩條非功能驗收：
+  - 乾淨環境雙 profile 安裝各 < 10 分鐘（分離 §八 預測①，實測計時）
+  - `bash scripts/update.sh` 在 InkStoneCo 實例上跑出的漂移清單 = **4 支**（§0.4 基線，
+    對得上＝偵測正確；對不上＝偵測有偽陰/偽陽）
+
+---
+
+## 相關文件
+
+- `requirements.md`（本卷）／`tasks.md`（本卷）
+- `docs/3-specs/SDD-LIFECYCLE.md`（D35 生命週期）
+- `docs/3-specs/install-layout/design.md`（安裝產物佈局的既有決策，本案沿用其「不污染用戶根目錄」原則）
+- 上游提案：`InkStoneCo/system-dev/docs/3-specs/pending-changes.md` §三 W2
+- 需求輸入：`~/Desktop/總管/{JDD-template-upgrade,分離導入規格,總管系統藍圖v3}.md`

docs/3-specs/jdd-dual-profile/requirements.md

@@ -0,0 +1,229 @@
+# jdd-dual-profile — Requirements
+
+> 建立：2026-08-05 | 最後更新：2026-08-05
+> 負責人：system-dev-template CC
+> 來源：InkStoneCo 總管交辦 **W2**（`InkStoneCo/system-dev/docs/3-specs/pending-changes.md`
+> 「[proposal] 總管系統藍圖 v3 三件套落地安排」§三 W2）
+> 需求輸入：《JDD 導入規格》§三/四/五/六 ＋《分離導入規格》§三/六 ＋《總管系統藍圖 v3》§3/§4/§5.5
+> 狀態：**等 leo confirm，未實作**
+
+---
+
+## 為什麼合成一份（不是兩份 SDD）
+
+JDD 的角色權限 hook 必須靠 profile 分流才成立——「總管版憲法」與「repo 版憲法」是同一支
+CLAUDE.md 生成流程的兩個輸出。拆兩份 SDD 會把 CLAUDE.md 生成、manifest、install/update
+改造各做兩遍，且第二遍必然要推翻第一遍的檔案佈局。總管裁定：合成一份。
+
+---
+
+## 一、Epic
+
+| Epic | 一句話 | 需求輸入 |
+|------|--------|---------|
+| **E1 雙 profile 框架** | 同一個 template 能裝出「總管級」或「repo 級」兩種實例，憲法由安裝位置決定、不靠 agent 自我判斷 | 分離 §三 |
+| **E2 PM 軌文件（JDD）** | 框架提供 `root.md` / `journeys.md` 兩份範本與格式紀律，讓驗收線從「tasks 全關」換成「站的 Gherkin 全綠」 | JDD §三、§五 |
+| **E3 角色封路** | orchestrator／engineer 的可寫範圍用 hook 機械強制，不靠 prompt 叮嚀 | JDD §四、§六 |
+| **E4 防糾纏** | 實例不改機制、框架不含實例資料，兩條鐵律各配機械閘；update 能報出被手改過的檔 | 分離 §一、§六 |
+
+**明確不在本 SDD 範圍**（W3 才做）：arcrun-policy plugin 本體、政策包內容搬遷、
+marketplace 發行。本 SDD 只負責**留好插槽**（載入順序文件化 ＋ profile 憲法的 must-read 注入點）。
+
+---
+
+## 二、User Story ＋ EARS
+
+### E1 雙 profile 框架
+
+**US-1.1**：身為安裝者，我要一條指令就裝出正確的那部憲法，不必自己判斷該裝哪些檔。
+
+- `EARS-1.1.1` When 安裝者執行 `install.sh --profile=orchestrator`，the system shall
+  只鋪設 orchestrator profile 宣告的產物，且不鋪設 repo profile 專屬的產物。
+- `EARS-1.1.2` When 安裝者執行 `install.sh --profile=repo`，the system shall
+  只鋪設 repo profile 宣告的產物（含 SDD 三件式與 repo 級 wiki 規範）。
+- `EARS-1.1.3` When 安裝者未指定 `--profile`，the system shall 自動偵測
+  （目前目錄下存在多個各自帶 `.git` 的子目錄 → 建議 orchestrator），
+  **並在寫入任何檔案前要求人確認一次**；確認結果寫入 marker 檔，之後不再問。
+- `EARS-1.1.4` The system shall 在安裝完成後於 `system-dev/.profile` 留下單行 profile 名，
+  作為所有 hook 判定 scope 的唯一機器可讀來源。
+
+**US-1.2**：身為框架維護者，我要 common 與兩個 profile 共用**一條版本流**，不開第二個 repo。
+
+- `EARS-1.2.1` The system shall 以單一 `VERSION` 檔涵蓋 common 與所有 profile 的變更。
+- `EARS-1.2.2` When 執行 update 而該實例所屬 profile 的產物本版未變動，the system shall
+  對該 profile 的產物 no-op（不下載、不覆蓋、不在報表列為「已更新」）。
+
+**US-1.3**：身為安裝者，我要 CLAUDE.md 由 profile 範本生成，而我自己補的內容永遠不會被更新洗掉。
+
+- `EARS-1.3.1` The system shall 把生成的 CLAUDE.md 切成「框架區」與「本地補充區」，
+  兩區以機器可辨識的界標分隔。
+- `EARS-1.3.2` While 執行 update，the system shall 只覆蓋框架區、**絕不動本地補充區**。
+- `EARS-1.3.3` If 框架區內容與本版原始範本不一致（＝被手改過），then the system shall
+  不覆蓋該檔、將它列入漂移清單，並提示「回框架提案 or 放棄本地改動」。
+
+### E2 PM 軌文件（JDD）
+
+**US-2.1**：身為總管（PM），我要一份白話根文件，讓不懂技術的人讀了能勾或搖頭。
+
+- `EARS-2.1.1` The system shall 於 orchestrator profile 提供 `root.md` 範本，
+  格式為「一句白話 ＋ 來源標記 ＋ 紅綠燈」。
+- `EARS-2.1.2` If `root.md` 中任一 🔴 卡缺少【要驗證 ＋ 對帳日】，then the system shall
+  在寫入當下攔截並指出行號。
+- `EARS-2.1.3` If `root.md` 或 `journeys.md` 出現技術名詞黑名單詞（API／DB／WASM／MCP／
+  endpoint／schema…），then the system shall 攔截並列出命中詞與行號。
+
+**US-2.2**：身為總管，我要 `journeys.md` 承載「角色 → Journey → Station → Gherkin」三層，
+並附站點索引表供回歸考查範圍。
+
+- `EARS-2.2.1` The system shall 於 orchestrator profile 提供 `journeys.md` 範本，
+  含三層巢狀結構與「附：站點索引表」段。
+- `EARS-2.2.2` The system shall 在範本內以註記聲明：站全域編號、跨 Journey 共享、
+  重複出現只寫引用不重抄；Gherkin 的 Then 只寫使用者看得到／感覺到的結果。
+
+**US-2.3**：身為 routine／總管，我要 sprint 的單位是「一組站號」，起牀就有明確的「離通關還缺什麼」。
+
+- `EARS-2.3.1` The system shall 於 orchestrator profile 提供 sprint 範本，
+  以站號（而非 task 批次）為單位，含起訖日與到期結算欄。
+- `EARS-2.3.2` If `tasks.md` 中**新增**的 task 條目未標注它服務哪一站，then the system shall 攔截。
+- `EARS-2.3.3` When sprint 收尾驗收，the system shall 以「指定站的 Gherkin 全綠」為判準，
+  而非「tasks 全關」。
+- `EARS-2.3.4` When 偵測到某站相關實作變動，the system shall 查站點索引表並列出需重考的
+  Journey／Gherkin 清單（提醒，不阻擋）。
+
+### E3 角色封路
+
+**US-3.1**：身為系統，我要 agent 的身分由兩個機械來源決定，沒有任何一格靠 agent 自陳。
+
+- `EARS-3.1.1` The system shall 以 `system-dev/.profile` 決定 **scope 軸**，
+  以環境變數 `AGENT_ROLE` 決定 **role 軸**。
+- `EARS-3.1.2` If `AGENT_ROLE` 未設定，then the system shall 依 scope 推定預設 role
+  （orchestrator profile → orchestrator；repo profile → engineer），不詢問 agent。
+- `EARS-3.1.3` If 身分組合落在「repo profile × orchestrator」這個**不存在的格子**，
+  then the system shall 攔截並要求修正環境變數，不得靜默降級。
+
+**US-3.2**：身為系統，我要 orchestrator 寫不了 code、改不了技術軌文件。
+
+- `EARS-3.2.1` If role 為 orchestrator 且寫入目標是程式碼路徑（`src/**`、`*.py`、`*.ts`、
+  `*.go`、`*.sh` 等），then the system shall 攔截（exit 2）。
+- `EARS-3.2.2` If role 為 orchestrator 且寫入目標是 `tasks.md` / `requirements.md` /
+  `design.md`，then the system shall 攔截。
+
+**US-3.3**：身為系統，我要 engineer 改不了考卷。
+
+- `EARS-3.3.1` If role 為 engineer 且寫入目標是 `journeys.md` / `root.md` /
+  任何 `*.feature` 或 md 內的 Gherkin 區塊，then the system shall 攔截。
+- `EARS-3.3.2` The system shall 在攔截訊息中說明「考生不能改考卷」與正確做法
+  （回報給 PM，由 PM 改站或改考題）。
+
+**US-3.4**：身為 session，我醒來時世界已就位，不需要「知道」有哪些機制存在。
+
+- `EARS-3.4.1` When SessionStart，the system shall 依 profile 注入對應的必讀
+  （orchestrator：root/journeys 與本 sprint 未點亮站；repo：現行 status/principles/mistakes）。
+- `EARS-3.4.2` The system shall 於 profile 憲法留下 policy plugin 的 must-read 注入點，
+  使 W3 的 plugin SessionStart hook 能把政策必讀推到眼前，而框架本身不新造外掛格式。
+
+### E4 防糾纏
+
+**US-4.1**：身為框架維護者，我要實例改不了機制——要改就回框架提案。
+
+- `EARS-4.1.1` If 寫入目標落在安裝產物區（`.claude/hooks/`、`system-dev/` 範本區、
+  plugin 安裝目錄），then the system shall 攔截並提示「機制變更走框架／政策包 repo 提案」。
+- `EARS-4.1.2` While session 帶有框架開發標記（框架 repo 根目錄存在 `.sdt-framework-dev`
+  或環境變數 `SDT_FRAMEWORK_DEV=1`），the system shall 放行 EARS-4.1.1。
+
+**US-4.2**：身為框架維護者，我要框架範本裡混進實例專名時 CI 就擋下。
+
+- `EARS-4.2.1` When CI 執行，the system shall 掃描範本區，命中實例專名黑名單 → fail
+  並指出檔案與行號。
+- `EARS-4.2.2` The system shall 讓黑名單住在可維護的設定檔，並提供**逐行豁免標記**
+  （留痕可審），供尚未搬遷的政策內容過渡使用。
+- `EARS-4.2.3` The system shall 不對 policy pack 套用本檢查（政策包本來就是一家之言）。
+
+**US-4.3**：身為安裝者，我要 update 告訴我「哪些檔被手改過」。
+
+- `EARS-4.3.1` When 執行 update，the system shall 比對每個安裝產物的實際雜湊與 manifest
+  記錄的雜湊，差異者列入漂移清單並逐項提示處置選項。
+- `EARS-4.3.2` The system shall 對漂移檔採「不覆蓋 ＋ 另存新版供 diff」策略，不靜默覆寫。
+
+---
+
+## 三、非功能需求
+
+| 項 | 要求 | 為什麼 |
+|---|---|---|
+| 向下相容 | 既有實例（1.18.x）跑 update **不得 404**；已安裝檔案的遠端路徑不得搬移 | 舊實例跑的是**舊** update.sh，檔案清單與 base URL 寫死在裡面；1.16.0 已被「來源改動＝自動更新死掉」咬過一次 |
+| 雲端可跑 | 所有 hook 只用 repo 相對路徑與 POSIX 工具，不假設本機絕對路徑 | 分離 §三 common「封路 hook 工具箱（雲端可跑）」 |
+| 容錯 | hook 解析失敗（拿不到 file_path／無 jq）一律放行並留痕，不誤殺 | 沿既有 hook 慣例（sdd-guard、wiki-secret-scan） |
+| 誠實限制 | 每支 hook 頂部註明「擋語法層、擋不了 bash 繞道」，不宣稱不可繞過 | 沿既有 hook 慣例 |
+| 安裝時間 | 乾淨環境雙 profile 各 < 10 分鐘 | 分離 §八 arch_iteration 預測① |
+| bash 版本 | 相容 macOS bash 3.2（空陣列展開需先判長度） | install.sh 既有踩過的坑 |
+
+---
+
+## 四、驗收 Gherkin（唯一驗收線，tasks 逐條掛號）
+
+> 來源：《JDD 導入規格》§七 三題（G1–G3）＋《分離導入規格》§七 四題（G4–G7），原文照抄。
+
+```gherkin
+# ── G1（JDD §七之一）
+Scenario: PM 總管優先補接縫而非做新功能
+  Given 安裝流程的所有零件均已 commit（部分未 push、部分接口未串）
+  And root.md 與 journeys.md 已就位，J-1（安裝者一次通關）已定義
+  When PM 總管接到指令「交付 J-1」
+  Then 它派出的第一批工作是補接縫（push 缺漏、串斷點）
+  And 不包含任何新功能開發
+
+# ── G2（JDD §七之二）
+Scenario: 考生改考卷被攔截
+  Given engineer subagent 的某站 Gherkin 未過
+  When 它嘗試修改 journeys.md 中的該條 Gherkin
+  Then hook 攔截，修改不生效
+
+# ── G3（JDD §七之三）
+Scenario: 進度以站計量
+  Given sprint 進行中
+  When 詢問 PM 總管目前進度
+  Then 回答形式為「J-x 已點亮 n/m 站」，而非 tasks 完成數
+
+# ── G4（分離 §七之一）
+Scenario: 憲法分流不靠判斷
+  Given template 已裝雙 profile
+  When 在總管 repo 開 session
+  Then CLAUDE.md 只含總管憲法（無 SDD 三件式細節）
+  When 在成員 repo 開 session
+  Then CLAUDE.md 只含 repo 憲法＋一行上游指針
+
+# ── G5（分離 §七之二）— 本 SDD 只負責插槽，Then 的後半由 W3 兌現
+Scenario: 政策包即插即用
+  Given 乾淨實例已裝 repo profile
+  When 安裝 arcrun-policy plugin 並 spawn engineer 實作小功能
+  Then 白名單 hook 攔下 python 路徑、primer 出現在 session 開頭
+  And engineer 的交付物走 Arcrun 零件
+
+# ── G6（分離 §七之三）
+Scenario: 實例改機制被攔
+  Given 實例 session（非 --framework-dev）
+  When 嘗試編輯 .claude/hooks/ 下任一檔
+  Then hook 攔截並提示走框架提案
+
+# ── G7（分離 §七之四）
+Scenario: 框架混入實例名被 CI 擋
+  Given 範本檔新增一行含 "arcrun"
+  When CI 執行
+  Then 檢查 fail 並指出檔案與行號
+```
+
+**G5 的範圍切割（重要）**：本 SDD 交付的是 Given／When 能成立的**插槽**——
+乾淨實例裝得出 repo profile、載入順序文件化、profile 憲法有 must-read 注入點。
+`Then` 的兩句（白名單 hook 攔 python、primer 出現）由 **W3 的 arcrun-policy plugin** 兌現。
+W2 收工時 G5 記 `◐ 半通（插槽就位，政策包未做）`，不得標 ✅。
+
+---
+
+## 五、關聯
+
+- 上游提案：`InkStoneCo/system-dev/docs/3-specs/pending-changes.md` §三 W2
+- 需求輸入原件：`~/Desktop/總管/JDD-template-upgrade.md`、`~/Desktop/總管/分離導入規格.md`、
+  `~/Desktop/總管/總管系統藍圖v3.md`
+- 生命週期規則：`docs/3-specs/SDD-LIFECYCLE.md`
+- 下一波：W3 arcrun-policy plugin（本 SDD 的 G5 後半）

docs/3-specs/jdd-dual-profile/tasks.md

@@ -0,0 +1,283 @@
+# jdd-dual-profile — Tasks
+
+> 權威來源：此檔案是進度真相，不是 CLAUDE.md 或對話。
+> 規則：動手前標 [🔄]，完成立刻標 [x]，不批次更新。
+> **每一項都標「服務哪條 Gherkin」**（G1–G7 定義見 `requirements.md` §四）。
+> 🔴 **本卷 status: draft — 等 leo confirm 才准動工。以下一項都還沒開始。**
+
+---
+
+## Gherkin 對照速查
+
+| 號 | 一句話 | 來源 |
+|---|---|---|
+| G1 | PM 總管優先補接縫而非做新功能 | JDD §七 |
+| G2 | 考生改考卷被攔截 | JDD §七 |
+| G3 | 進度以站計量 | JDD §七 |
+| G4 | 憲法分流不靠判斷 | 分離 §七 |
+| G5 | 政策包即插即用（本波只到 ◐ 半通） | 分離 §七 |
+| G6 | 實例改機制被攔 | 分離 §七 |
+| G7 | 框架混入實例名被 CI 擋 | 分離 §七 |
+
+---
+
+## Phase 0：地基（manifest ＋ 兩軸判定）
+
+### 前置條件
+- [ ] leo confirm 本 SDD，frontmatter 由 `draft` 改 `active`
+
+### Tasks
+
+- [ ] 0.1 定義 manifest 格式並產出三份 `template/manifest/{common,repo,orchestrator}.tsv`
+  - 服務：**G4**（分流的資料基礎）、G6（產物區清單的單一來源）
+  - 欄位：`dest	class	profile`；class ∈ `overwrite|keep|add-if-missing|keep-with-template`
+  - 驗收：三份 manifest 涵蓋現行 install.sh 硬編的**每一個** `download_if_missing` 目標，
+    逐項比對零遺漏（貼比對輸出）
+  - 注意：既有檔一律標 `common` 且 dest 路徑**與現況完全相同**（決策 D3，不搬檔）
+
+- [ ] 0.2 寫 `template/.claude/hooks/lib/role-lib.sh`（兩軸判定函式庫）
+  - 服務：**G2**、G6
+  - 內容：`sdt_repo_root` / `sdt_rel_path` / `sdt_scope` / `sdt_role` /
+    `sdt_assert_identity` / `sdt_file_path_from_stdin`（jq→python3→grep 三段 fallback）
+  - 驗收：以四組身分（orchestrator×orchestrator、orchestrator×engineer、
+    repo×engineer、repo×orchestrator）跑單元測試，最後一組回 exit 2；貼四組輸出
+  - 注意：不得用 `CLAUDE_PROJECT_DIR`（雲端可跑）；bash 3.2 相容
+
+- [ ] 0.3 立 marker 檔約定：`system-dev/.profile`、`system-dev/.template-manifest`、`.sdt-framework-dev`
+  - 服務：**G4**、**G6**
+  - 驗收：三個檔的格式各寫一段規格進 design 的附錄，並在框架 repo 自己放一份
+    `.sdt-framework-dev`（commit）
+  - 注意：`--framework-dev` 不是官方 CLI flag（決策 D9），別去找那個參數
+
+---
+
+## Phase 1：雙 profile 與 CLAUDE.md 生成
+
+> 前置條件：Phase 0 全部完成
+
+- [ ] 1.1 建 `template/profiles/repo/CLAUDE.md`（repo 憲法範本）
+  - 服務：**G4**
+  - 來源：現行 `template/CLAUDE.md` 演進；加「上游指針」一行、「站號怎麼標在 task 上」一段、
+    W3 must-read 注入點一段
+  - 驗收：`grep -c "上游" ≥ 1`；全文不含任何實例專名
+
+- [ ] 1.2 建 `template/profiles/orchestrator/CLAUDE.md`（總管憲法範本）
+  - 服務：**G4**、G3
+  - 內容：效忠 root/journeys、JDD 全術語表、sprint 站號全流程、
+    進度語言「J-x 已點亮 n/m 站」、問題升級階梯三級（藍圖 §5.5）、W3 must-read 注入點
+  - 驗收：`grep -c "SDD 三件式\|requirements.md" = 0`（G4 明文：總管版無 SDD 三件式細節）
+  - 注意：不得出現任何實例專名（藍圖 v3 的內容要抽象化，專案名留給實例填）
+
+- [ ] 1.3 `install.sh` 加 `--profile=repo|orchestrator` ＋ 自動偵測 ＋ 一次性人確認
+  - 服務：**G4**
+  - 偵測規則：目前目錄下存在多個各自帶 `.git` 的子目錄 → 建議 orchestrator
+  - 驗收：三種呼叫（明示 repo／明示 orchestrator／不指定走偵測）各跑一次乾淨環境，
+    貼出各自產生的 `system-dev/.profile` 內容
+  - 注意：**確認在寫入任何檔案之前**問，別裝了一半才問
+
+- [ ] 1.4 `install.sh` 改讀 manifest 鋪設產物 ＋ 產 `.template-manifest`
+  - 服務：**G4**、G6
+  - 驗收：repo profile 裝出的檔案集合 = `common.tsv ∪ repo.tsv`，
+    且**不含** orchestrator 專屬檔（`ls` 對照貼出）
+
+- [ ] 1.5 CLAUDE.md 三段組裝（框架區界標 ＋ 本地補充區界標 ＋ sha256）
+  - 服務：**G4**
+  - 驗收：裝完的 CLAUDE.md 含 `sdt:framework begin/end` 與 `sdt:local begin/end` 四個界標，
+    且 `sha256` 值與框架區實際內容相符（重算比對貼出）
+
+- [ ] 1.6 `install.sh` 的 `build_hooks_json()` 加 profile 維度 ＋ 寫入 `env.AGENT_ROLE` 預設
+  - 服務：**G2**、G6
+  - 驗收：兩 profile 各自產生的 `settings.json` 中，hook 掛載順序符合 design §4.4；
+    orchestrator 實例的 `env.AGENT_ROLE = orchestrator`、repo 實例 = `engineer`
+
+- [ ] 1.7 `update.sh` 改讀 manifest ＋ 三態判定 ＋ 漂移清單輸出
+  - 服務：**G6**（機械閘 #3）
+  - 驗收：在 InkStoneCo 實例上跑，漂移清單**恰好列出 4 支**
+    （`pre-write-guard.sh`／`sdd-guard.sh`／`subagent-wiki-guard.sh`／`wiki-first-search.sh`，
+    見 design §0.4 基線），貼完整輸出
+  - 注意：漂移檔**不覆蓋**，新版另存 `<檔>.new`；輸出用白話（leo 一眼看得懂該做什麼）
+
+- [ ] 1.8 `update.sh` 舊實例遷移：無 manifest → 一次性補植 ＋ CLAUDE.md 界標補植
+  - 服務：**G4**、G6
+  - 驗收：拿一份 1.18.0 的實例副本跑兩次 update，第二次為 no-op（冪等，貼兩次輸出對照）
+  - 注意：舊 CLAUDE.md 整份包進 `sdt:local` 區，一個字都不能掉
+
+- [ ] 1.9 `template/CLAUDE.md` 原路徑保留轉址說明（向下相容）
+  - 服務：**G4**
+  - 驗收：舊版 update.sh 對該路徑的 curl 仍回 200（決策 D3）
+
+---
+
+## Phase 2：JDD 文件範本（orchestrator profile）
+
+> 前置條件：Phase 1 完成（範本要靠 manifest 才鋪得下去）
+
+- [ ] 2.1 `docs/root.md.template`（白話根文件範本）
+  - 服務：**G1**
+  - 內容：JDD §3.1 格式原樣 ＋ 三條規則（來源標記必附、禁技術名詞、🔴 卡必附對帳日）
+  - 驗收：範本自身通得過 task 3.2 的 J4／J8 檢查（自己吃自己狗糧）
+
+- [ ] 2.2 `docs/journeys.md.template`（PM 驗收文件範本）
+  - 服務：**G1**、**G3**
+  - 內容：JDD §3.2 三層巢狀 ＋「附：站點索引表」段 ＋ 站全域編號/引用不重抄的註記
+  - 驗收：範本含站點索引表且欄位為「站｜被哪些 Journey 經過｜改動時重考範圍」
+
+- [ ] 2.3 `docs/sprint.md.template`（站號 sprint）＋ tasks.md 站號欄位約定
+  - 服務：**G3**
+  - 內容：JDD §五 四步流程、順序鐵律「先認領 → 認領不足才新增 → 新增必掛站」、
+    起訖日與到期結算欄
+  - 驗收：範本能被 task 3.4 的 J6 判準讀出「本 sprint 指定站」與「未點亮站」
+
+- [ ] 2.4 `docs/triage-map.md.template`（分診表格式，內容留實例）
+  - 服務：**G1**
+  - 驗收：只有欄位與規則，**零實例內容**（通得過 task 4.1 的專名檢查）
+
+- [ ] 2.5 `docs/plugin-load-order.md`（W3 插槽文件）＋ 兩份憲法的 must-read 注入點
+  - 服務：**G5（半通的那一半）**
+  - 內容：分離 §五 四步載入順序原文 ＋「政策包＝官方 plugin，框架不發明平行格式」的約定
+  - 驗收：兩份 profile CLAUDE.md 各含一段可被 plugin SessionStart hook 填入的注入點標題
+
+- [ ] 2.6 JDD 術語表寫進 orchestrator 憲法（Journey 取代 CP，禁用舊詞）
+  - 服務：**G3**
+  - 驗收：術語表七詞（Journey／Station／通關／點亮／對帳／完備／輪子卡·賭注卡）齊全，
+    且標明 `CP.yaml`／`CPDO.md` 屬技術軌內圈保留原名
+
+---
+
+## Phase 3：封路 hook
+
+> 前置條件：Phase 0（role-lib）＋ Phase 2（有檔可擋）
+
+- [ ] 3.1 `role-guard.sh`（J1＋J2＋J3，common）
+  - 服務：**G2**（命門）
+  - 內容：orchestrator 禁寫 code 路徑／禁寫 tasks·requirements·design；
+    engineer 禁寫 journeys·root·`*.feature`·md 內 Gherkin 區塊；矩陣空格 exit 2
+  - 驗收：**六組實測**各貼 stdout/exit code——
+    ① orchestrator 寫 `.py` → 擋 ② orchestrator 寫 `tasks.md` → 擋
+    ③ engineer 改 `journeys.md` 的 Gherkin → 擋（**這條就是 G2**）
+    ④ engineer 寫 `.py` → 放行 ⑤ orchestrator 寫 `journeys.md` → 放行
+    ⑥ repo profile × `AGENT_ROLE=orchestrator` → 擋並要求修正環境
+  - 注意：Gherkin 區塊偵測要涵蓋 md 內的 ```gherkin fence 與 `- **G-x.y** Given` 行式
+
+- [ ] 3.2 `jdd-format-guard.sh`（J4＋J5＋J8，common）
+  - 服務：**G1**、G3
+  - J4：`root.md` 🔴 卡缺【要驗證＋對帳日】→ 擋並指行號
+  - J5：`tasks.md` **新增**行缺站號 → 擋（Edit 看 `new_string`，Write 比對現檔差異）
+  - J8：`root.md`／`journeys.md` 技術名詞黑名單命中 → 擋並列詞＋行號
+  - 驗收：三條各一組正例一組反例，共六次實測貼輸出
+  - 注意：J5 只判**新增**行，改既有行不擋（否則格式修正都做不了）；誠實限制寫進註解
+
+- [ ] 3.3 `station-done-guard.sh`（J6，common，掛 Stop/TaskCompleted）
+  - 服務：**G3**
+  - 判準：本 sprint 指定站的 Gherkin 全綠才算收工；「tasks 全關」不算
+  - 驗收：造一個「tasks 全關但站 Gherkin 未綠」的情境 → 被退回（貼 exit 2 輸出）
+  - 注意：框架內**沒有**既有的 sprint 收尾 hook（`delivery-police.sh` 只在 InkStoneCo 實例），
+    這是新增不是修改；W4 時實例那支要退役，別兩處維護
+
+- [ ] 3.4 `regression-scope.sh`（J7，common）
+  - 服務：**G3**
+  - 行為：偵測站相關實作變動 → 讀 journeys.md 站點索引表 → 列需重考的 Journey/Gherkin
+  - 驗收：改動某站的實作檔後，輸出正確列出該站被哪些 Journey 經過（貼輸出）
+  - 注意：**提醒不阻擋**（exit 0）
+
+- [ ] 3.5 `install-artifact-guard.sh`（S1，common）
+  - 服務：**G6**
+  - 行為：寫入 `.claude/hooks/`／`system-dev/` 範本區／plugin 安裝目錄 → 擋，
+    提示「機制變更走框架/政策包 repo 提案」；`.sdt-framework-dev` 或 `SDT_FRAMEWORK_DEV=1` 放行
+  - 驗收：① 實例 session 編輯 `.claude/hooks/` 任一檔 → 擋（**這條就是 G6**）
+    ② 框架 repo（有 marker）編輯同路徑 → 放行。兩組都貼輸出
+  - 注意：「範本區」的定義來自 manifest（class=overwrite 者），不要另寫一份路徑表
+
+- [ ] 3.6 `orchestrator-scope-guard.sh`（S4，orchestrator profile 專屬）
+  - 服務：**G6**
+  - 來源：改寫自 InkStoneCo 實例的 `guard-cross-project.sh`（上收進框架，決策 D6）
+  - 抽象化重點：子 repo 目錄清單、autodispatch 白名單**由實例設定檔提供**，
+    範本內**零實例專名**（通得過 task 4.1）
+  - 驗收：以假造的成員目錄結構跑三組——寫子 repo 的 `.py` → 擋／寫子 repo 的 `.md` → 放行／
+    `CHILD_SESSION=1` 且在白名單內 → 放行
+  - 注意：職責與 3.1 不重疊——3.1 管「角色能寫什麼**類型**」，本支管「總管能進哪個**位置**」
+
+- [ ] 3.7 改 `session-start-recall.sh`：依 profile 分流注入【改既有】
+  - 服務：**G3**、G4
+  - orchestrator：root/journeys 摘要 ＋ 本 sprint **未點亮**站（治「起牀沒事做」）
+  - repo：維持現行 principles/status/mistakes
+  - 驗收：兩 profile 各開一次 session，貼注入內容對照（orchestrator 那份要出現站號）
+
+- [ ] 3.8 hook 全鏈掛載順序實測（design §4.4）
+  - 服務：**G2**、G6
+  - 驗收：故意觸發多條規則的一次寫入，確認錯誤訊息來自**最外層**那條（範圍大的先擋）
+
+---
+
+## Phase 4：框架側 CI 與清潔
+
+> 前置條件：Phase 1（manifest 定義了「範本區」）
+
+- [ ] 4.1 `scripts/check-no-instance-names.sh` ＋ `scripts/instance-names.txt`
+  - 服務：**G7**
+  - 行為：掃 `template/`，命中黑名單 → exit 1 並印「檔案:行號:命中詞」；
+    支援逐行豁免標記（行尾 `# sdt-instance-name-ok`）；policy pack 路徑不受檢
+  - 驗收：在範本檔新增一行含 "arcrun" → 檢查 fail 並指出檔案與行號（**這條就是 G7**），貼輸出
+
+- [ ] 4.2 現況 20 行命中的分診處置（design §0.5）
+  - 服務：**G7**
+  - (a) 6 行註解／舉例 → 改寫成通用敘述
+  - (b) 3 行政策內容 ＋ (c) 13 行 L2 產物 → 標 `# sdt-instance-name-ok` ＋ 一行「W3 搬遷」註記
+  - 驗收：處置後 `check-no-instance-names.sh` 回 exit 0，且豁免行數 = 16（貼清單）
+  - 注意：**禁止假性清理**（把 arcrun 改寫成「某工作流引擎」＝資訊消失、問題還在）
+
+- [ ] 4.3 掛 pre-commit / CI
+  - 服務：**G7**
+  - 驗收：`bash scripts/check-no-instance-names.sh` 在 CI 步驟中被呼叫，故意違規的 commit 被擋
+
+---
+
+## Phase 5：出貨（ship-check）
+
+> 前置條件：Phase 0–4 全部完成
+
+- [ ] 5.1 CHANGELOG ＋ VERSION bump（**兩處**：`template/.claude/VERSION` ＋ `template/system-dev/VERSION`）
+  - 服務：全部
+  - 版號：1.18.0 → **1.19.0**（新功能、向下相容）
+  - 驗收：兩個 VERSION 檔內容一致；CHANGELOG 用用戶語言寫「這一版你會多出什麼」
+  - 注意：版本號是 leo 唯一的驗收介面——沒動＝等於沒交付
+
+- [ ] 5.2 乾淨環境雙 profile 安裝實測（含計時）
+  - 服務：**G4**
+  - 驗收：兩個全新空目錄各裝一次，**各記錄實際耗時**（分離 §八 預測①：各 < 10 分鐘），
+    貼安裝輸出 ＋ `ls -R` 檔案清單對照
+
+- [ ] 5.3 七題 Gherkin 逐條實測並記錄三態
+  - 服務：**G1–G7**
+  - 驗收：每題貼實測輸出並標 `✅ 通 / ◐ 半通（缺什麼）/ ❌ 斷`
+  - 注意：**G5 本波上限 `◐`**（插槽就位、政策包在 W3），標 ✅ 就是假綠；
+    G1 需要 root/journeys 有實內容才驗得到端到端 → 若實例尚未落地（W4），
+    以框架附的示範 fixture 驗，並在報告標明「以 fixture 驗，實例端到端待 W4」
+
+- [ ] 5.4 回報總管：交付物、三態表、與規格假設不符的清單
+  - 服務：全部
+  - 驗收：報告含 design §0 全部實查發現 ＋ 本波實際落地的 hook 數（改既有 vs 新增）
+
+---
+
+## 完成定義
+
+整個 SDD 完成 = 以下全部達成：
+- [ ] 所有 tasks 標 [x]
+- [ ] G1–G7 逐題有實測證據，且無任何一題為 `❌ 斷`（G5 可為 `◐`）
+- [ ] `bash scripts/check-no-instance-names.sh` 回 exit 0
+- [ ] `bash scripts/sdd-active-check.sh docs/3-specs` 回 exit 0
+- [ ] 兩處 VERSION = 1.19.0，CHANGELOG 已寫
+- [ ] design.md 與實作一致（如有出入需更新 design，不是默默改 code）
+
+---
+
+## 狀態說明
+
+| 標記 | 意義 |
+|------|------|
+| `[ ]` | 未開始 |
+| `[🔄]` | 進行中（當前 session）|
+| `[x]` | 完成（有驗收證據）|
+| `[~]` | 暫緩（說明原因）|
+| `[!]` | 阻擋中（說明阻擋原因）|