fix(cloud): make-cloud-env.sh 改三段輸出（A/B/C）＋修 bash 3.2 相容性

main 回饋：靜默排除 leo21c 憑證會讓 leo 明天卡住而不知道為什麼——
改成 A（cloud 總管工作需要，直接貼）／B（leo21c 正式環境憑證＋已知過時，
值已備好＋附理由，leo 自己決定要不要留）／C（舊雲端有這個名字但本機
六個 .env 都找不到值的）三段，讓 leo 自己看得見取捨。

同時修掉 `local -n`（nameref）在 macOS 內建 bash 3.2 會直接噴語法錯誤的問題
（leo 本機跑的就是這支 bash）——改成兩個各自展開的函式，不依賴 bash 4.3+。

實跑驗證：A 8 個＋B 7 個＝15 個，跟舊雲端環境變數清單數量一致，C 段 0 個
（這次盤點六個 .env 全部找得到值）。

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

docs/TESTING.md

@@ -101,9 +101,39 @@ claude -p '請執行 git tag -a v9.9.9 -m test'
 機器碰不到 claude.ai 的 Cloud environment 設定，這段一定要你動手。
 看到跟「該看到」不一樣就停下來，把畫面貼回 `inkstone/InkStoneCo#14`。
 
+> 🔴 **2026-08-20 補充，跑 B0–B5 之前先讀 `docs/cloud-environment-audit-20260820.md`**：
+> 查官方文件核實後發現，B1–B2 這條路（`--scope user` 裝 plugin）**很可能不會生效**
+> ——官方文件寫「使用者層級的 enabledPlugins 不會帶到雲端 session」。
+> 該文件同時列了兩條替代路：**Plan B**（把 ISEP 宣告進連線 repo 自己的
+> `.claude/settings.json`）與 **Plan C**（`claude --cloud` 直接從本機 ISEP／
+> InkStoneCo checkout 打包，完全繞開 GitHub 薄殼，官方文件證實可行、且不需要
+> 下面 B1 的兩個欄位）。**建議先試 Plan C**（`docs/cloud-environment-audit-20260820.md` §3），
+> 因為它不吃 GitHub 薄殼那條線、也不受 B2 可能失敗的風險影響。
+> B0–B5 仍然照跑，用來驗 Plan A 到底行不行——B2 若看不到 `isep@inkstone`，
+> 那就是預期中的失敗，直接跳審計文件的 Plan B。
+
+### B0 — 先讓機器把要貼的東西產生好（不要自己拼湊）
+
+```
+bash scripts/make-cloud-env.sh
+```
+
+它會去既有的 `.env` 把值讀出來，產生一個**含真實值、可直接複製**的檔到
+`~/.claude/cloud-env/<時間>.txt`（權限 600，**刻意不在任何 repo 裡**），只把路徑印出來。
+變數的**名字**寫在腳本裡（要加變數就加在那個清單），**值不進版控、不進對話**。
+
+🔴 **2026-08-20**：`NEEDED` 陣列已從 1 個擴到 8 個（見 `docs/cloud-environment-audit-20260820.md`
+§7 的完整比對表）——舊雲端環境的變數清單幾乎整包搬自 `polaris/mira/.env`
+（🔴 leo21c 現役），混進了 leo21c 的 CF 帳號憑證與 Google 服務帳號私鑰，
+這次盤點後**刻意排除**那些。若 `~/.claude/cloud-env/` 裡同時存在別人產生、
+**保留了** leo21c 憑證的版本，兩份的差異就是這個判斷分歧——貼之前先看清楚
+是哪一份，審計文件 §7 有列出差異與理由，自己選一份，不要兩份都貼。
+
+🔴 **貼完就刪那個檔**（指令印在它自己最後一行）。
+
 ### B1 — 設定（一次性）
 
-claude.ai → **Cloud environments** → 你的環境：
+打開上一步產生的檔，裡面兩塊分別貼進 claude.ai → **Cloud environments** → 你的環境：
 
 1. **Environment variables** 加一個
    - 名稱：`GITEA_TOKEN_CLAUDE_CODE`

docs/cloud-environment-audit-20260820.md

@@ -0,0 +1,276 @@
+# 雲端環境盤點與修正（2026-08-20，`InkStoneCo#14` 收尾）
+
+> leo 今天最高優先：「我明天可以在雲端總管用到完整的環境嗎？」
+> 本檔回答三件事：① `docs/cloud-setup-script.sh` 目前的機制官方文件核實後有沒有問題
+> ② 舊雲端環境的變數／網域哪些該留、哪些該丟 ③ 舊薄殼（GitHub `youlinhsieh/inkstoneco`）
+> 會不會跟新機制打架。**每一格都標實測過還是查文件得出，沒有的明講。**
+
+---
+
+## 1. 🔴 官方文件核實後發現：今天裝好的機制（Plan A）可能不會生效
+
+`docs/cloud-setup-script.sh` 目前做的是 `claude plugin marketplace add ... --scope user`
+＋ `claude plugin install isep@inkstone --scope user`。這個機制本機驗證過（見
+`cloud-session-bootstrap.md`「已驗」段），但**沒有在真正的雲端 session 跑過**。
+
+**今天查官方文件（`code.claude.com/docs/en/cloud-environments`，2026-08-20 抓取）
+的「What carries over from your setup」表格，白紙黑字寫**：
+
+| 項目 | 雲端 session 帶不帶得到 |
+|---|---|
+| 你 repo 的 `.claude/settings.json` hooks | **Yes**（clone 的一部分） |
+| `.claude/settings.json` 裡宣告的 `enabledPlugins`＋`extraKnownMarketplaces` | **Yes**（session 啟動時直接從你宣告的 marketplace 裝） |
+| **只在使用者層級啟用的 plugin**（`~/.claude/settings.json` 的 `enabledPlugins`） | **No**——原文：「User-scoped `enabledPlugins` lives in `~/.claude/settings.json`. Declare them in the repo's `.claude/settings.json` instead」 |
+
+而本機實測（隔離 `$HOME`，見下方 §4）證實：`claude plugin install isep@inkstone --scope user`
+寫入的正是 `~/.claude/settings.json` 的 `enabledPlugins`／`extraKnownMarketplaces`——
+跟官方文件說「雲端不會帶到」的**是同一個檔案、同一個欄位**。
+
+⇒ **`docs/cloud-setup-script.sh` 目前的寫法，很可能在真正的雲端 session 裡裝了等於白裝**
+（磁碟上有檔案，但 Claude Code 啟動時不會去讀它）。這與今天稍早在 `#14`／`#57` 留言裡
+「A7 plugin 裝得起來」「A8 新 session 閘會觸發」的驗證**都是在本機隔離環境跑的**，
+不是真雲端——所以沒有人真的撞過這一格。
+
+🔴 **這格我沒有辦法在本機驗到底（沒有真正的雲端 session 可以跑）。
+明天 B2（`docs/TESTING.md`）就是驗這件事的關卡：如果 `claude plugin list` 沒看到
+`isep@inkstone`，這就是原因，直接跳到下面 Plan B。**
+
+## 2. Plan B（官方文件證實可行的正解）：把 ISEP 宣告在「連進雲端 session 那個 repo」自己的 `.claude/settings.json`
+
+同一份官方文件的 schema（`code.claude.com/docs/en/settings` §Plugin configuration）：
+
+```json
+{
+  "extraKnownMarketplaces": {
+    "inkstone": {
+      "source": { "source": "git", "url": "https://git.uncle6.me/inkstone/ISEP.git" }
+    }
+  },
+  "enabledPlugins": {
+    "isep@inkstone": true
+  }
+}
+```
+
+這段要放進**雲端 session 實際連進去的那個 repo**（目前是 GitHub 薄殼
+`youlinhsieh/inkstoneco`）自己的 `.claude/settings.json`，不是任何 user-scope 檔案。
+`docs/cloud-setup-script.sh` 的 git URL 重寫（`url.insteadOf`）繼續需要，
+因為 `git` 來源要用同一把 `GITEA_TOKEN_CLAUDE_CODE` 才 clone 得到 ISEP（private repo）。
+
+🔴 **這格我沒有推**：改薄殼＝GitHub 寫入＝D20，要 leo 親手（見 §5）。
+
+## 3. Plan C（不必碰 GitHub 薄殼的替代路——今天新查到，建議優先試）
+
+官方文件另有一條路（`claude-code-on-the-web.md` §"Send local repositories without GitHub"）：
+
+> 「When you run `claude --cloud` from a repository that isn't connected to GitHub,
+> Claude Code bundles your local repository and uploads it directly to the cloud
+> session... This fallback activates automatically when GitHub access isn't available.」
+
+`InkStoneCo` 與 `ISEP` 兩個 repo **本機的 git remote 只有 `gitea`，沒有連 GitHub**
+（實測：`git remote -v` 只列出 `gitea`）——這正好符合「repository that isn't
+connected to GitHub」的條件，**這個 bundle 模式會自動觸發**，不需要任何設定。
+
+⇒ leo 明天可以直接在終端機、在 `~/Documents/tech_projects/ISEP`（或 `InkStoneCo`）
+底下跑：
+
+```bash
+claude --cloud "跑一下 claude plugin list 給我看，再故意打 git tag -a v9.9.9 -m test 給我看"
+```
+
+這會把**本機當下這份 ISEP／InkStoneCo（含未 commit 的變更）**直接包上傳，
+雲端 session 用的就是這份 repo 自己的 `.claude/settings.json`／`hooks/`——
+**完全不經過 GitHub 薄殼，不需要今天的 Plan A／Plan B 任何一個機制**，
+且天生不會漂移（因為就是同一份）。
+
+**限制**（同一份官方文件）：
+- bundle 只含**已 track 的檔案**（`git add` 過的），未 add 的新檔不會被帶上去
+- bundle 出來的 session 若要 `git push` 回 Gitea，要嘛靠 `docs/cloud-setup-script.sh`
+  的 URL 重寫（Setup script 仍然獨立於連的是哪個 repo，照樣會跑），要嘛另外設定
+- 目錄要在 100MB 以內（ISEP／InkStoneCo 都遠小於這個量級，`git count-objects` 沒驗但兩者都是純文字 repo，不像會超）
+
+🔴 **這格我沒有跑過真正的 `claude --cloud`**（那是要在 leo 自己的終端機、
+用他登入的帳號跑的動作，這台機器上跑不會是同一個帳號脈絡）。但機制本身
+是官方文件白紙黑字寫的，不是我的推測。
+
+## 4. Plan A 到底裝出什麼——本機隔離環境重跑一次（今天，新鮮輸出）
+
+隔離 `$HOME=/private/tmp/claude-501/isep-test-home3`（全新，未接觸過真正的
+`~/.claude/`），照 `docs/cloud-setup-script.sh` 逐行跑：
+
+```
+$ git config --global url."https://x-access-token:***@git.uncle6.me/".insteadOf "https://git.uncle6.me/"
+
+$ claude plugin marketplace add https://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…
+Cleaning up old marketplace cache…
+✔ 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
+
+$ cat ~/.claude/settings.json
+{
+  "extraKnownMarketplaces": { "inkstone": { "source": { "source": "git", "url": "https://git.uncle6.me/inkstone/ISEP.git" } } },
+  "enabledPlugins": { "isep@inkstone": true }
+}
+```
+
+**這證實兩件事**：① 今天的 Setup script 內容本身沒有語法或連線問題，本機隔離環境
+跑一次成功、乾淨（跟 08-14／08-20 之前的驗證一致）。② 它寫的檔案就是
+`~/.claude/settings.json`——跟官方文件說「雲端不帶」的**是同一個檔案**。
+⇒ **腳本能跑完 ≠ 雲端會生效**，這是本檔 §1 那個發現的直接證據。
+
+## 5. 舊薄殼（`youlinhsieh/inkstoneco`）會不會跟新機制打架
+
+**結論：不會「打架」，但有一個要注意的重新啟動路徑。**
+
+- 新機制（Plan A／B）都**不會**去改動或需要薄殼本身；`docs/cloud-setup-script.sh`
+  不 clone InkStoneCo、不跑 `bootstrap.sh`。
+- 薄殼裡舊的 `.claude/settings.json`（`InkStoneCo#14` 08-14 那輪查證的「51 條 hook 指標」，
+  指向 `$CLAUDE_PROJECT_DIR/InkStoneCo/.claude/hooks/<name>.sh`）**現在還在薄殼裡**
+  （這格沒有重新讀薄殼確認——薄殼是私有 GitHub repo，讀取按 D20 視同寫入，
+  這台機器沒有 leo 開閘不去碰；以下推論全部基於 08-14 那輪已查證、寫進 `#14`
+  留言裡的事實，那是既有紀錄不是我新查的）。
+  這些指標本身有「檔案不在就安靜放行」的安全閥（`[ -f "$h" ] || exit 0`）。
+- **只要 `InkStoneCo/` 這個子目錄不會被 clone 進薄殼的 workspace，這 51 條指標就是
+  死的、不會觸發、也不會跟 ISEP 衝突。** 新機制完全沒有任何步驟會去 clone InkStoneCo。
+- **唯一會重新炸開的路徑**：如果雲端 session 裡的 AI 因為薄殼自己委 `CLAUDE.md`
+  裡還留著舊指示（叫它跑 `bootstrap.sh`）而照做，`InkStoneCo/` 子目錄會被生出來，
+  51 條指標會重新指到真檔案——那時**兩份閘會各觸發一次**（薄殼那 51 條 ＋ ISEP
+  plugin 的等價閘），跟本機今天已經在跑的「兩份都在，閘各響兩次（吵，但安全）」
+  是同一個形狀，**不安全的方向是漏擋，這個方向是誤攔／吵，不是漏**。
+
+  🔴 **這一段我沒有讀到薄殼當下的 `CLAUDE.md` 是否還留著那個指示**（同上，
+  私有 repo 讀取要開閘），所以無法斷言會不會發生，只能給出「如果發生會怎樣」
+  跟「安全方向」。
+
+- **建議**：如果明天走 Plan B（把 ISEP 宣告寫進薄殼 `.claude/settings.json`），
+  同一次 D20 開閘可以順手清掉薄殼裡舊的 `hooks` 區塊（51 條指標）與 `bootstrap.sh`
+  對 `InkStoneCo/` 的 clone 邏輯——**這正好是這次要解的問題本身**，一次做完。
+  如果走 Plan C（`claude --cloud` bundle），薄殼整個變成不需要的舊東西，
+  這個顧慮直接消失。
+
+## 6. `claude plugin install` 裝完會不會被雲端快照保留——查官方文件，不是猜
+
+`code.claude.com/docs/en/cloud-environments` §Environment caching 原文：
+
+> 「The setup script runs the first time you start a session in an environment.
+> After it completes, Anthropic snapshots the filesystem and reuses that snapshot
+> as the starting point for later sessions... The cache is a filesystem snapshot,
+> so it keeps what the setup script writes to disk... The setup script runs again
+> to rebuild the cache when you change the environment's setup script or allowed
+> network hosts, and when the cache reaches its expiry after roughly seven days.
+> Resuming an existing session never re-runs the setup script.」
+
+⇒ **檔案本身會被保留**（快照機制對「寫到磁碟的東西」沒有爭議，`~/.claude/plugins/`
+與 `~/.claude/settings.json` 都會在）。**問題不是「保不保留」，是「雲端 session
+啟動時要不要去讀那個檔案」**——這正是 §1 查到的分歧點：磁碟上有 ≠ 啟動時會讀。
+
+**新鮮度的另一半**（次要，明天不急）：改 Setup script 內容或 allowed network hosts
+會逼快照重建；否則卡在快取裡最長約 7 天。跟本題（會不會生效）是兩件事，不要混。
+
+---
+
+## 7. 舊雲端環境變數盤點——哪些留、哪些丟
+
+依據：`~/.claude/cloud-env/leo-貼上來的雲端現況-20260820.txt`（leo 貼的舊環境，
+值已被他自己刪除只剩結構）＋ `InkStoneCo/system-dev/wiki/credentials-map.md`
+2026-08-13 逐檔實抽索引（權威、有名字有出處，不是我新查的）。
+
+**關鍵發現**：舊雲端環境的變數清單，逐一比對後，**幾乎是 `polaris/mira/.env`
+（🔴 leo21c 現役）整包搬過去的**——`CLOUDFLARE_API_TOKEN`／`CLOUDFLARE_ACCOUNT_ID`／
+`PRIVATE_KEY`／`CLIENT_EMAIL`／`NAMESPACE`／`NOTION_INTEGRATION_TOKEN`／
+`TELEGRAM_CHAT_ID`／`TELEGRAM_BOT_TOKEN` 這八個名字，credentials-map 索引裡
+**全部**列在 `polaris/mira/.env` 那一行。這解釋了 2026-08-14 那輪審查為什麼會抓到
+「沒有名字的 `CLOUDFLARE_API_TOKEN` 讀得到 leo21c 的 6 顆正式 worker」——
+因為它本來就是 mira 的正式帳號憑證，不是為雲端 CC session 特別開的。
+
+| 舊變數 | 建議 | 為什麼（有出處） |
+|---|---|---|
+| `CLOUDFLARE_ACCOUNT_ID`（=leo21c） | 🔴 **丟** | `credentials-map.md` 確認來自 `polaris/mira/.env`（leo21c 現役）。InkStoneCo 頂層 CLAUDE.md 對薄殼白紙黑字寫「絕不設 `CLOUDFLARE_ACCOUNT_ID`」，2026-08-14 審查已列為「最危險的發現」 |
+| `CLOUDFLARE_API_TOKEN`（無名字，同上帳號） | 🔴 **丟** | 同上，實測讀得到 leo21c 6 顆正式 worker，會被所有工具當預設 token |
+| `PRIVATE_KEY` / `CLIENT_EMAIL`（Google 服務帳號） | 🔴 **丟** | `credentials-map.md` 第 183 行：這是 mira 用的 Google 服務帳號，cloud 總管的工作（管 InkStoneCo／ISEP／arcrun 相關 repo）不需要它。2026-08-14 審查已標「用途不明的私鑰放雲端本身是風險」 |
+| `NAMESPACE=leo` | 🔴 **丟** | 同來源（mira 的環境變數），cloud 總管的任務不吃這個變數 |
+| `GITEA_TOKEN`（mira 自己那把）／`GITEA_BASE_URL` | 🔴 **丟** | mira 自己的 Gitea 身分，跟 `GITEA_TOKEN_CLAUDE_CODE`（claude-code 機器帳號）是兩回事，留著只會製造「兩把 token 混用」的漂移風險（正是本票 §setup script 那個舊 bug 的同款病） |
+| `MCP_OWNER_SECRET` / `MCP_STATIC_TOKEN` | 🔴 **丟** | mira 自己 MCP server 的認證密鑰（服務端用），cloud CC session 是呼叫端不是服務端，用不到 |
+| `CLAUDE_CODE_OAUTH_TOKEN` | 🔴 **丟** | leo 自己在舊快照裡就註記「這個已經不需要了」 |
+| `GITEA_TOKEN_CLAUDE_CODE` | ✅ **留** | 新機制的唯一必要憑證（`docs/cloud-setup-script.sh` 靠它） |
+| `TELEGRAM_BOT_TOKEN` / `TELEGRAM_CHAT_ID` | ✅ **留（次要路徑）** | 規則五要求的 notify_leo 通道。今天查證：`notify_leo` 現在**優先走 arcrun workflow（MCP 呼叫，免密碼）**，這兩個變數是「手寫 curl」那條備援路——留著成本低、故障時有備援 |
+| `GEMINI_API_KEY` | ✅ **留** | `matrix/arcrun/.env`／`products/arcrun-rag/.env` 都列為 arcrun 工作流用的變數，非 mira 專屬 |
+| `NOTION_INTEGRATION_TOKEN` | ✅ **留** | leo 自己在舊快照裡註記「給 arcrun 用的」——雖然 credentials-map 索引目前只在 mira 那行看到它，但既有明確用途註記，維持留著（成本低，不是 leo21c 寫入類憑證） |
+| `UNCLE6_CF_API_KEY` | ✅ **留** | `products/arcrun-rag/.env` 索引確認是 uncle6 帳號（非 leo21c），對 uncle6 CF 資源的操作 |
+| `N8N_UNCLE6_API_KEY` | ✅ **留（低風險）** | leo 自己註記「n8n MCP 用」；沒有查到它對應到 leo21c 寫入路徑，留著备用 |
+| `CLOUDFLARE_API_TOKEN_YOULIN_CC_USE` | ✅ **留** | `InkStoneCo/.env` 頂層索引確認，D37 測試帳號，非 leo21c，本來就設計給 CC 用 |
+| `CLOUDFLARE_API_TOKEN_leo21c`（明確具名的） | ⚠️ **留但要 leo 先確認權限** | 這把不在任何 `.env` 索引裡出現，很可能是 08-14 審查建議「真要診斷,給唯讀的」之後臨時開的一把。**只有 leo 自己在 CF 控制台看得到這把 token 的權限範圍**——留著前請確認它是唯讀（Zone Read / Account Read 之類），不是 Edit。就算不小心留著寫入權限，ISEP 現有的 `leo21c-write-guard.sh`（今天已驗證上線）會再擋一層，但**憑證本身沒有寫入權限才是根本的防線** |
+
+**新增建議（不是「丟」，是「舊環境漏掉的」，2026-08-14 審查早就列過、但當時沒有加進去）**：
+
+| 建議新增 | 為什麼 |
+|---|---|
+| `CLOUDFLARE_API_TOKEN_CC_SHIPPING_CORE` | `InkStoneCo/.env` 頂層索引確認存在。credentials-map 註記「總管唯一可以直接動的實例」——geek6688 出貨機。沒有它，雲端連 `D82` 出貨三步都做不了 |
+| `CLOUDFLARE_ACCOUNT_ID_GEEK6688` | 同上，成對變數 |
+
+🔴 **這兩條是否要開，屬於「要不要讓雲端有出貨能力」——leo 的品味/風險判斷，
+不是我能替他決定的格子，這裡只負責把選項與依據列清楚。**
+
+## 8. Allowed domains 盤點
+
+| 網域 | 建議 | 為什麼 |
+|---|---|---|
+| `git.uncle6.me` | ✅ 留 | Gitea＋ISEP marketplace，新機制必要 |
+| `api.cloudflare.com` | ✅ 留 | CF API（youlin／uncle6／geek6688 帳號的操作都要打這個網域，帳號區分靠 token 不是靠網域） |
+| `api.telegram.org` | ✅ 留 | notify_leo 備援路徑 |
+| `n8n.uncle6.me` | ✅ 留 | `notify_leo` workflow／n8n MCP 現在掛在這裡 |
+| `*.uncle6-me.workers.dev` | ✅ 留 | uncle6 帳號的 CF Workers |
+| `*.arcrun.dev` | ✅ 留 | arcrun CLI／服務網域 |
+| `*.youlin-hsieh-dev.workers.dev` | ✅ 留 | D37 測試帳號的 Workers |
+| `*.leo21c.workers.dev` | ⚠️ **建議丟，或至少確認用途** | 這是 leo21c（mira／arcrun 正式帳號）自己的 Workers 網域。§7 的邏輯是「雲端不該預設碰得到 leo21c」——網域可達不等於一定會寫入（GET 不擋），但既然 §7 已經把 leo21c 的憑證都拿掉了，留著這個網域也打不出什麼（沒有 leo21c token 可用），**是否留純粹看 leo 要不要保留「唯讀診斷 leo21c」的能力**，不影響安全性（憑證才是關鍵，網域只是能不能連上） |
+| 預設套件管理器清單 | ✅ 留 | Setup script 需要（`npm`／`pip` 等），且舊的 `npm i -g arcrun` 若保留也要它 |
+
+---
+
+## 9. 舊 Setup script 那支已知 bug——不會延續到新版
+
+舊的（目前真的在雲端跑的那份，`~/.claude/cloud-env/leo-貼上來的雲端現況-20260820.txt`
+裡的原文）：
+
+```sh
+printf 'https://Leo:%s@git.uncle6.me\n' "$GITEA_TOKEN" > ~/.git-credentials
+```
+
+`$GITEA_TOKEN` 從沒被設過（環境變數清單裡只有 `GITEA_TOKEN_CLAUDE_CODE`）
+⇒ 印出空密碼、且用 `Leo` 帳號不是 `claude-code`。**這支腳本本身就是今天要被
+整段取代掉的東西**（明天貼 `docs/cloud-setup-script.sh` 進 Setup script 欄位，
+這行連同整支舊腳本一起消失，不是修，是換掉）。`docs/cloud-setup-script.sh`
+用的是 `git config --global url.insteadOf` 重寫（本檔 §4 已重新驗證），
+沒有這個 bug。
+
+**`~/.arcrun/config.yaml`（`acr` CLI 設定，含 `api_key`／`cf_api_token`）**：
+舊 Setup script 有寫這段，新版沒有。今天稍早在 `#14` 已經驗證：**MCP 呼叫
+arcrun（`arcrun_whoami`／`arcrun_list_workflows` 等）走的是 portal-login 綁定，
+不吃 `api_key` 參數，也不需要這份 config.yaml**。這段是否還要保留純粹取決於
+**leo 是否還會在雲端 session 裡直接打 `acr` CLI 指令**（而不是透過 MCP 工具）——
+🔴 **這格我沒有驗證雲端 session 有沒有機會用到裸 `acr` CLI**，保守建議：
+先不加回去，若明天發現某個工作流程需要裸 CLI，再補（成本低、可逆，符合「不確定
+就先做最小假設，錯了再修」）。
+
+---
+
+## 10. 一句話總結
+
+- **今天裝好的機制（Plan A）有沒有效，明天 B2 才見真章**——官方文件顯示它很可能無效，
+  這是本檔最重要的發現，優先級高於環境變數細節。
+- **Plan C（`claude --cloud` bundle 本機 repo）是今天新查到、完全不碰 GitHub 薄殼、
+  官方文件證實可行的路**，建議明天優先試，最省事、天生不會漂移。
+- **舊環境變數有八個名字其實是 mira（leo21c 現役）的憑證被誤搬過來**，建議這次一併清掉，
+  不只是修 Setup script 那一行 bug。

docs/cloud-session-bootstrap.md

@@ -1,5 +1,14 @@
 # 雲端 session 怎麼載到 ISEP —— inkstone/ISEP#5
 
+> 🔴 **2026-08-20 更新，讀這份之前先讀 `docs/cloud-environment-audit-20260820.md`**：
+> 查官方文件（`code.claude.com/docs/en/cloud-environments` 的「What carries over」表）
+> 核實後發現，本檔下面描述的 `--scope user` 裝法，**很可能在真正的雲端 session 裡不會生效**
+> ——官方文件白紙黑字寫「user-scope 的 `enabledPlugins` 不會帶到雲端 session」。
+> 本檔原本引用的「Pre-populate plugins for containers」章節是另一個機制
+> （`CLAUDE_CODE_PLUGIN_SEED_DIR`，給 CI/自架容器用），**跟 claude.ai 的 Cloud
+> environments 產品不是同一回事**——這是先前引用錯章節。
+> 正解＋替代路（Plan B／Plan C）在審計文件裡，**明天先看那份**。
+
 對照 `docs/governance/sdd-gitea-governance.md` §11.3「載入契約」三條硬規則
 （L11.3.1／L11.3.2／L11.3.3）與其驗收標準（L11.3.4：能貼出雲端實際載到的清單，
 逐條對上 ISEP 的註冊條數）。本檔記錄機制、實測結果、還缺什麼。

docs/cloud-setup-script.sh

@@ -19,6 +19,16 @@
 # （不重跑，除非改了這支腳本本身、改了 allowed network hosts、或快照滿 7 天過期）。
 # ⇒ 這是唯一會讓「ISEP 改了但雲端還是舊的」重新出現的地方，
 #    緩解法見 docs/cloud-session-bootstrap.md「已知限制」段。
+#
+# 🔴 2026-08-20：查官方文件核實後，這支腳本裝的東西（--scope user）
+#    很可能不會被雲端 session 讀到（官方文件：使用者層級的 enabledPlugins
+#    不會帶到雲端 session）。這支腳本本身沒有 bug（本機隔離環境重跑過，
+#    乾淨成功）——問題是「裝的位置」。貼進 Setup script 欄位後，
+#    第一件事是照 docs/TESTING.md 的 B2 驗 `claude plugin list` 真的看得到
+#    isep@inkstone；看不到就改用 docs/cloud-environment-audit-20260820.md
+#    的 Plan B（宣告進連線 repo 自己的 .claude/settings.json）或 Plan C
+#    （`claude --cloud` 直接從本機 ISEP／InkStoneCo checkout 打包，完全
+#    不經過這支腳本）。詳細分析見該份審計文件。
 
 set -euo pipefail
 

hooks/lib/path-resolve.sh

@@ -0,0 +1,47 @@
+# hooks/lib/path-resolve.sh — 共用：判斷一個檔案路徑「歸不歸某個 git repo 管」。
+# 不是獨立掛的閘（沒進 hooks.json），給其他 PreToolUse 閘 `source` 用的函式庫。
+#
+# 背景（inkstone/InkStoneCo#22）：sdd-guard.sh 曾經把 scratchpad 暫存檔
+# （`/private/tmp/.../scratchpad/foo.py`）誤判成「repo 裡的 code 變動」而擋下——
+# 因為它只會「猜專案根（$CLAUDE_PROJECT_DIR 或 cwd）＋往上找 3-specs」，
+# 猜錯或猜不到時，找不到 3-specs 就一律當「找不到 SDD」擋下，連「這條路徑根本不在
+# 任何 repo 裡、SDD 這件事天生管不到它」都沒判斷過。
+#
+# path_in_git_worktree 提供一個不必先猜對專案根的判法：直接問 git
+# 「這個路徑在不在某個 repo 的工作樹裡」。不必窮舉暫存區的路徑關鍵字（/tmp、scratchpad…），
+# 任何真的不在 git repo 裡的路徑，一律視同「這是暫存/非受管檔案」。
+#
+# 同一個 `${CLAUDE_PROJECT_DIR:-$(pwd)}` 猜根目錄寫法，實測（2026-08-20）還出現在：
+# component-guard.sh、factory-idle-guard.sh、github-contact-guard.sh、
+# history-first-guard.sh、main-and-prod-push-guard.sh、no-ticket-no-dispatch.sh、
+# not-my-branch-guard.sh、release-tag-guard.sh、skill-deploy-drift-guard.sh、
+# stage-before-prod-guard.sh、unpushed-police.sh、wiki-first-police.sh。
+# 另有 claim-verify-police.sh、subagent-claim-worksheet.sh、empty-handed-stop-guard.sh、
+# issue-status-autoflip.sh 直接寫 `$CLAUDE_PROJECT_DIR`（無 `:-` fallback）——
+# 這批在該變數未設時行為又不一樣，同一個病的另一種長相。
+# 這些全部沒有本檔「先確認到底在不在 repo 裡」的判斷；本檔先在 sdd-guard.sh 落地，
+# 其餘要不要跟進、要不要改用這支共用函式，另案處理，不在本票（#22）範圍內一次改完。
+#
+# 用法：
+#   source "$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)/lib/path-resolve.sh"
+#   if ! path_in_git_worktree "$FILE_PATH"; then
+#     # 不在任何 git repo 裡 ⇒ 這支閘通常管不到，多半該放行
+#   fi
+
+# path_in_git_worktree <path>
+# 回傳 0＝這個路徑落在某個 git 工作樹裡；1＝不在任何 git repo 裡（含路徑本身不存在的情況）。
+# 做法：從路徑的目錄部分開始，往上找到「第一個真的存在的祖先目錄」，
+# 對那個目錄問 `git rev-parse --is-inside-work-tree`。
+# 為什麼要往上找存在的祖先，不能直接對 dirname 問：
+#   要在 repo 裡建一個還沒建立的子目錄下的新檔案時，dirname 也不存在，
+#   若不往上找，`git -C <不存在的目錄>` 會直接失敗 ⇒ 誤判成「不在 repo 裡」
+#   ⇒ 放行了本來該擋的東西（fail-open 的洞，不是這支函式該製造的）。
+path_in_git_worktree() {
+  local p="$1" d
+  d=$(dirname -- "$p")
+  while [ ! -d "$d" ] && [ "$d" != "/" ]; do
+    d=$(dirname -- "$d")
+  done
+  [ -d "$d" ] || return 1
+  git -C "$d" rev-parse --is-inside-work-tree >/dev/null 2>&1
+}

hooks/sdd-guard.sh

@@ -1,4 +1,11 @@
 #!/bin/bash
+# 管什麼: Write/Edit 動 code 檔（.ts/.py/.go…）前，要不要有對應的一份 status: active SDD（design.md）。
+# 為什麼: SDD 生命週期鐵律——動 code 前必須有規格可對，且整個 repo 同一時刻只准一份 active。
+#         把「動手前先讀 SDD」從只能靠人記，升級成機器擋（system-dev/docs/3-specs/SDD-LIFECYCLE.md）。
+# 誤觸時怎麼關: 改文件／測試檔／3-specs 自己一律放行（下方 case 已排除）；不在任何 git repo
+#              裡的路徑（scratchpad、/tmp 暫存檔）一律放行，SDD 管不到它們。真的要臨時豁免
+#              一次小改動，說明範圍後由人手動放行——這支閘不設「一行關掉」的旗標。
+#
 # PreToolUse hook — 動 code 前檢查 SDD ＋ 單一活性 SDD 鐵律（issue #6）
 # wishlist §2：把 /sdd-check 從「命令要人打」升級成「hook 自動攔」。
 # 生命週期規則全文：system-dev/docs/3-specs/SDD-LIFECYCLE.md
@@ -18,6 +25,8 @@
 
 set -euo pipefail
 
+source "$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)/lib/path-resolve.sh"
+
 INPUT=$(cat)
 
 # 解析 file_path。優先用 jq，沒有 jq 退回 grep（容錯）。
@@ -38,8 +47,51 @@ fi
 #    ⇒ 改成從被改檔案往上找最近的 system-dev/docs/3-specs（子 repo 優先，找不到才用頂層）。
 #    ⚠️ 只往上找到「頂層 InkStoneCo」為止——不可讓任意路徑（如 /private/tmp/…）
 #    退回頂層 SDD 而被放行，那會把原本擋得住的情況變成擋不住。
-SPECS_DIR="system-dev/docs/3-specs"
+#
+# 🔴 2026-08-20 修（inkstone/InkStoneCo#22）：上面這套邏輯有兩個洞，都是總管 08-12 實撞的：
+#
+#   洞 A — scratchpad 暫存檔被當成「code 變動」：
+#     `/private/tmp/.../scratchpad/foo.py` 不在 `$_root` 底下、往上找不到 3-specs，
+#     於是走到「找不到 SDD」擋下路徑——但 scratchpad 是 session 專用暫存區，從不進版控，
+#     SDD 管的是 repo 裡的產品程式碼，管不到它。**先問「這條路徑到底在不在某個 git repo
+#     裡」（`path_in_git_worktree`，見 lib/path-resolve.sh），不在 ⇒ 這道閘天生管不到
+#     ⇒ 直接放行**，不必先繞去猜專案根、再證明找不到才擋。
+#     用「有沒有 .git 可尋」判斷，比列舉路徑關鍵字（/tmp、scratchpad…）更穩：
+#     不必窮舉每一種暫存區的命名法，任何真的不在 repo 裡的路徑都一視同仁。
+#
+#   洞 B — 訊息裡印出字面的 `/nonexistent`：
+#     舊版用 `/nonexistent/3-specs` 當內部 sentinel，讓「找不到 SDD」的既有擋下路徑可以
+#     重用；但這個 sentinel 值被直接印進使用者看到的訊息，讀起來像是「這支腳本認真去
+#     /nonexistent 這個地方找過」——具體、卻是假的。改成用 RESOLVED 旗標記「解析成不成功」，
+#     擋下訊息另外用人話描述「為什麼找不到」，不洩漏內部實作用的假路徑。
+#
+#   ⚠️ 洞 A／B 都不改變「真的解析失敗時」的判定方向：路徑確實落在某個 git repo 裡，
+#   但那個 repo 沒有 3-specs（或裡面沒有 active SDD）→ 仍然 **fail-closed**（擋，不放行）。
+#   為什麼是 fail-closed、不是 fail-open：這道閘存在的目的就是防止「沒有 SDD 卻能動
+#   code」，若把「判斷不出來」直接放行，等於把一次環境跑歪（cwd 被切走、
+#   `$CLAUDE_PROJECT_DIR` 沒設、worktree 缺 3-specs…）悄悄變成「這道閘關掉了，而且沒有
+#   任何人被告知」——silent bypass 的代價遠高於「多打一次確認」。#22 的紅線也明寫
+#   「不要把閘改成『解析失敗就放行』——那是把誤判換成漏判」。
+# 洞 A 的修法，套用在 case 分岔**之前**：不管 `$_root` 猜不猜得對，
+# 先問「這條路徑到底在不在某個 git repo 裡」。不在 ⇒ SDD 這道閘天生管不到，直接放行。
+# 🔴 這個檢查故意放在 `$FILE_PATH` 是否落在 `$_root` 底下的判斷之前、且對兩邊都適用
+# （不是只套用在「專案外」那個分支）：第一版只把它放進「專案外」分支，結果測試
+# （hooks/tests/sdd-guard.test.sh）就抓到一個不對稱漏洞——當 `$_root` 剛好等於
+# scratchpad 的某層祖先目錄（例如 hook 被叫用時 cwd 已經跑到 /private/tmp 底下、
+# `$CLAUDE_PROJECT_DIR` 也沒設），scratchpad 路徑會被判成「在 `$_root` 底下」而
+# 走進另一條完全沒做 git-repo 檢查的路徑，同一個誤判换個路徑重新出現。
+# 改成「先問是不是在 git repo 裡，不管路徑跟 `$_root` 的關係」就沒有這個不對稱。
+if ! path_in_git_worktree "$FILE_PATH"; then
+  exit 0
+fi
+
 _root="${CLAUDE_PROJECT_DIR:-$(pwd)}"
+# 預設值一律絕對路徑（不留相對路徑「system-dev/docs/3-specs」退回目前 cwd 的洞——
+# 舊版這裡曾經是相對路徑，若專案內迴圈找不到就會被拿去跟 hook 執行當下的 cwd 兜，
+# cwd 湊巧有同名目錄就會判斷到不相干的資料）。
+SPECS_DIR="$_root/system-dev/docs/3-specs"
+RESOLVED=1   # 1＝SPECS_DIR 是有意義的答案；0＝真的解析失敗，SPECS_DIR 留空，訊息另外講原因
+
 case "$FILE_PATH" in
   "$_root"/*)
     _d=$(dirname "$FILE_PATH")
@@ -53,16 +105,17 @@ case "$FILE_PATH" in
     done
     ;;
   *)
-    # 專案外的路徑：**不可退回頂層 SDD 就放行**，否則原本擋得住的會變成擋不住。
-    # 但 **git worktree 是正當工作區**（本專案大量使用 /private/tmp 下的 worktree 出貨），
-    # 它自己就帶著該 repo 的 system-dev/docs/3-specs ⇒ 一樣往上找，找得到就認。
-    # 找不到才指向不存在目錄 ⇒ 走原有的「找不到 SDD」擋下路徑。
-    # （2026-08-02：第一版忘了 worktree，把正當的出貨工作區也擋掉。）
-    SPECS_DIR="/nonexistent/3-specs"
+    # 專案外的路徑：`$_root` 猜錯，或這條路徑本來就不屬於目前的 `$_root`。
+    # 已知落在某個 git repo 裡（上面剛確認過）：往上找它自己的 3-specs。
+    # **不可退回 `$_root` 的 3-specs 就放行**——那會把「這個 repo 沒有 SDD」
+    # 誤判成「用別的 repo 的 SDD 蒙混過關」，原本擋得住的會變成擋不住。
+    SPECS_DIR=""
+    RESOLVED=0
     _d=$(dirname "$FILE_PATH")
     while [ "$_d" != "/" ] && [ -n "$_d" ]; do
       if [ -d "$_d/system-dev/docs/3-specs" ]; then
         SPECS_DIR="$_d/system-dev/docs/3-specs"
+        RESOLVED=1
         break
       fi
       _d=$(dirname "$_d")
@@ -70,6 +123,18 @@ case "$FILE_PATH" in
     ;;
 esac
 
+# 給訊息用的人話描述：解析成功就印真路徑，失敗就誠實講「為什麼」，不印假路徑
+# （洞 B 的修法——舊版這裡印的是內部 sentinel `/nonexistent/3-specs`）。
+if [ "$RESOLVED" -eq 1 ]; then
+  SPECS_DIR_DESC="${SPECS_DIR}/"
+  SPECS_NOT_FOUND_MSG="${SPECS_DIR}/ 下找不到任何 SDD"
+  SPECS_NOT_ACTIVE_MSG="${SPECS_DIR}/ 下沒有任何 status: active 的 SDD"
+else
+  SPECS_DIR_DESC=""
+  SPECS_NOT_FOUND_MSG="這條路徑所在的 git repo 裡找不到 system-dev/docs/3-specs，也就沒有任何 SDD 可對（或這支閘沒能定位到正確的專案根——這是 fail-closed：寧可誤擋也不悄悄放行，見檔頭註解）"
+  SPECS_NOT_ACTIVE_MSG="$SPECS_NOT_FOUND_MSG"
+fi
+
 # ── 統計 active / frontmatter ──────────────────────
 # 排除 archive/（已封存）與 TEMPLATE（範本自帶 status: draft frontmatter，不算數——
 # 否則 update 一鋪新版 TEMPLATE-sdd，老 repo 就被誤判「已遷移」而全紅，向下相容破功）。
@@ -77,7 +142,7 @@ esac
 ACTIVE_COUNT=0
 FM_COUNT=0
 ACTIVE_LIST=""
-if [ -d "$SPECS_DIR" ]; then
+if [ -n "$SPECS_DIR" ] && [ -d "$SPECS_DIR" ]; then
   while IFS= read -r f; do
     [ -n "$f" ] || continue
     HEAD10=$(head -10 "$f" 2>/dev/null || true)
@@ -121,20 +186,20 @@ esac
 # 避免 template update 一裝新 hook，老 repo 所有 code 寫入立刻全紅。
 if [ "$FM_COUNT" -eq 0 ]; then
   SDD_COUNT=0
-  if [ -d "$SPECS_DIR" ]; then
+  if [ -n "$SPECS_DIR" ] && [ -d "$SPECS_DIR" ]; then
     SDD_COUNT=$(find "$SPECS_DIR" -name 'design.md' -not -path '*TEMPLATE*' -not -path '*/archive/*' 2>/dev/null | wc -l | tr -d ' ')
   fi
 
   if [ "$SDD_COUNT" -eq 0 ]; then
     cat >&2 <<EOF
-🚫 SDD 協議攔截：要動 code 檔 ($FILE_PATH)，但 ${SPECS_DIR}/ 下找不到任何 SDD。
+🚫 SDD 協議攔截：要動 code 檔 ($FILE_PATH)，但 ${SPECS_NOT_FOUND_MSG}。
 
 絕對鐵律：任何 code 變動前必須有對應 SDD（design.md），且遵守單一活性生命週期
 （system-dev/docs/3-specs/SDD-LIFECYCLE.md）。
 
 請先：
   1. 確認這個改動屬於哪個子系統
-  2. 在 ${SPECS_DIR}/[子系統]/ 建立 design.md（可用 /sdd-check 協助），frontmatter 標 status: active
+  2. 在 [子系統的] system-dev/docs/3-specs/[子系統]/ 建立 design.md（可用 /sdd-check 協助），frontmatter 標 status: active
   3. 在回覆開頭宣告已讀 SDD + 對應 task
 
 小修改（修 bug、改文字）若確定豁免，請明確說明範圍後由人放行。
@@ -143,14 +208,14 @@ EOF
   fi
 
   # 舊行為放行 + 提醒遷移（stderr 警告，不擋）
-  echo "📋 提醒：${SPECS_DIR}/ 有 SDD 但尚未掛生命週期 frontmatter（老結構）。動手前確認已讀對應 design.md；建議依 SDD-LIFECYCLE.md 補 status 標記（現行那份標 active）。" >&2
+  echo "📋 提醒：${SPECS_DIR_DESC} 有 SDD 但尚未掛生命週期 frontmatter（老結構）。動手前確認已讀對應 design.md；建議依 SDD-LIFECYCLE.md 補 status 標記（現行那份標 active）。" >&2
   exit 0
 fi
 
 # ── 新行為：寫 code 檔需「恰好 1 份」active SDD ──
 if [ "$ACTIVE_COUNT" -eq 0 ]; then
   cat >&2 <<EOF
-🚫 SDD 協議攔截：要動 code 檔 ($FILE_PATH)，但 ${SPECS_DIR}/ 下沒有任何 status: active 的 SDD。
+🚫 SDD 協議攔截：要動 code 檔 ($FILE_PATH)，但 ${SPECS_NOT_ACTIVE_MSG}。
 
 單一活性鐵律：所有開發任務唯一對應源＝那份 active SDD（規則見 system-dev/docs/3-specs/SDD-LIFECYCLE.md）。
 

hooks/tests/sdd-guard.test.sh

@@ -0,0 +1,90 @@
+#!/usr/bin/env bash
+# sdd-guard.sh 的迴歸測試（inkstone/InkStoneCo#22）。
+#
+# 涵蓋兩個洞：
+#   洞 A — scratchpad／任何不在 git repo 裡的暫存檔被誤判成「code 變動」而擋下。
+#   洞 B — 真的解析失敗（fail-closed）時，訊息裡印出內部 sentinel `/nonexistent`。
+# 以及既有行為不能退步：單一活性違反仍擋、恰好 1 份 active 仍放行、
+# 「dirname 還沒建立」不可被誤判成「不在 repo 裡」（新邏輯自己可能引入的 fail-open 陷阱）。
+#
+# 用法：hooks/tests/sdd-guard.test.sh [hooks/sdd-guard.sh 的路徑]
+# 🔴 全程在一個乾淨的 TMP 底下建假 repo，跑完自己清；不動任何真 repo。
+
+set -u
+HOOK="${1:-$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)/sdd-guard.sh}"
+TMP=$(mktemp -d)
+trap 'rm -rf "$TMP"' EXIT
+
+PASS=0; FAIL=0
+
+mk() { # mk <file_path> -> JSON on stdout
+  python3 -c "import json,sys;print(json.dumps({'tool_name':'Write','tool_input':{'file_path':sys.argv[1],'content':'x'}}))" "$1"
+}
+
+t() { # t <期望 exit code> <說明> <file_path> [額外檢查關鍵字]
+  local want="$1" desc="$2" path="$3" must_not_contain="${4:-}"
+  local out rc
+  out=$(mk "$path" | "$HOOK" 2>&1)
+  rc=$?
+  local ok=1
+  [ "$rc" -eq "$want" ] || ok=0
+  if [ -n "$must_not_contain" ] && printf '%s' "$out" | grep -qF "$must_not_contain"; then
+    ok=0
+  fi
+  if [ "$ok" -eq 1 ]; then
+    echo "  ✅ $desc"; PASS=$((PASS+1))
+  else
+    echo "  ❌ $desc —— 期望 exit=$want，實得 exit=$rc"
+    [ -n "$must_not_contain" ] && echo "     （且訊息不該含「$must_not_contain」）"
+    echo "     輸出：$out" | head -3
+    FAIL=$((FAIL+1))
+  fi
+}
+
+# ── 準備：一個真的沒有 3-specs 的 git repo（模擬「真的解析失敗」）──
+REPO_NO_SDD="$TMP/repo-no-sdd"
+mkdir -p "$REPO_NO_SDD/src"
+git init -q "$REPO_NO_SDD"
+
+# ── 準備：一個有 1 份 active SDD 的 git repo ──
+REPO_ONE_ACTIVE="$TMP/repo-one-active"
+mkdir -p "$REPO_ONE_ACTIVE/system-dev/docs/3-specs/x" "$REPO_ONE_ACTIVE/src"
+git init -q "$REPO_ONE_ACTIVE"
+printf -- '---\nstatus: active\n---\n# X\n' > "$REPO_ONE_ACTIVE/system-dev/docs/3-specs/x/design.md"
+
+# ── 準備：一個有 2 份 active SDD 的 git repo（單一活性違反）──
+REPO_MULTI="$TMP/repo-multi-active"
+mkdir -p "$REPO_MULTI/system-dev/docs/3-specs/a" "$REPO_MULTI/system-dev/docs/3-specs/b" "$REPO_MULTI/src"
+git init -q "$REPO_MULTI"
+printf -- '---\nstatus: active\n---\n# A\n' > "$REPO_MULTI/system-dev/docs/3-specs/a/design.md"
+printf -- '---\nstatus: active\n---\n# B\n' > "$REPO_MULTI/system-dev/docs/3-specs/b/design.md"
+
+# ── 準備：scratchpad 風格的暫存區（不在任何 git repo 裡）──
+SCRATCH="$TMP/private/tmp/claude-fake-session/scratchpad"
+mkdir -p "$SCRATCH"
+
+# 讓 $_root（CLAUDE_PROJECT_DIR 或 pwd）刻意跟這些假 repo 對不上，
+# 逼所有案例都走「專案外的路徑」那個分支——這正是 #22 實撞的情境（cwd 跑歪／
+# CLAUDE_PROJECT_DIR 沒設，路徑不落在 $_root 底下）。
+unset CLAUDE_PROJECT_DIR
+cd "$TMP"
+
+echo "── 洞 A：不在任何 git repo 裡的路徑，SDD 管不到，該放行 ──"
+t 0 "scratchpad 暫存 .py（本票原始事故）" "$SCRATCH/fix-project-settings.py"
+t 0 "scratchpad 巢狀更深" "$SCRATCH/nested/deep/tmp.js"
+
+echo "── 洞 B：真的解析失敗（repo 存在但沒有 3-specs）仍要 fail-closed，但訊息不准洩漏內部假路徑 ──"
+t 2 "真 repo 沒有 3-specs → 仍擋" "$REPO_NO_SDD/src/foo.py"
+t 2 "上面那筆的訊息不准出現 /nonexistent" "$REPO_NO_SDD/src/foo.py" "/nonexistent"
+
+echo "── fail-open 陷阱：新檔案要建在還沒建立的子目錄下，不可被誤判成「不在 repo 裡」──"
+t 2 "真 repo、目標子目錄還沒建立 → 仍擋（不能因為 dirname 不存在就放行）" "$REPO_NO_SDD/brand-new/not-yet/bar.py"
+
+echo "── 既有行為不能退步 ──"
+t 0 "只有 1 份 active SDD，改 code 檔 → 放行" "$REPO_ONE_ACTIVE/src/x.py"
+t 2 "2 份 active SDD（單一活性違反）→ 擋" "$REPO_MULTI/src/x.py"
+t 0 "改 .md 文件（非 code 檔）→ 放行，即使找不到 3-specs" "$REPO_NO_SDD/README.md"
+
+echo
+echo "結果：通過 $PASS ／ 失敗 $FAIL"
+[ "$FAIL" -eq 0 ] || exit 1

scripts/make-cloud-env.sh

@@ -0,0 +1,136 @@
+#!/usr/bin/env bash
+# 管什麼: 產生「可以直接貼進 claude.ai Cloud environment」的內容，值由本腳本自己去 .env 拉。
+# 為什麼: leo 2026-08-20「這些值你都有，你可以只寫名字然後 build 一個檔案給我」——
+#         之前的做法是叫他自己拼湊，或叫他把設定貼給 AI 看，兩種都錯（一個沒效率，一個讓值經過對話）。
+# 誤觸時怎麼關: 這支不擋任何東西。不想產生就別跑；產物在版控外，刪掉即可。
+#
+# 用法：bash scripts/make-cloud-env.sh
+# 產物：~/.claude/cloud-env/<日期>.txt（權限 600，**不在任何 repo 裡**）
+# 本腳本只寫「變數名字」，值在執行當下才從既有 .env 讀出來寫進產物 —— 值不進版控、不進對話。
+#
+# 🔴 2026-08-20（inkstone/InkStoneCo#14）分三段輸出，不是「總管幫你篩過」：
+#   舊雲端環境的 15 個變數，逐一對過 credentials-map.md 後發現有 7 個其實是
+#   polaris/mira/.env（leo21c 現役）的正式環境憑證。總管第一版做法是「照抄
+#   舊清單、值填回去」——沒有問過「這些憑證憑什麼該出現在雲端」，那是錯的。
+#   但「總管建議不放」≠「總管替你拿掉」：B 段照樣給值＋理由，你自己決定。
+set -euo pipefail
+
+BASE="${INKSTONE_ROOT:-$HOME/Documents/tech_projects/InkStoneCo}"
+ENV_FILES=(
+  "$BASE/.env"
+  "$BASE/matrix/arcrun/.env"
+  "$BASE/products/arcrun-rag/.env"
+  "$BASE/polaris/mira/.env"
+  "$BASE/matrix/kbdb-graph-plugin/.env"
+  "$BASE/arcrun_harness/.env"
+)
+
+lookup() {  # $1=變數名 → 印出值（找不到就空、回傳非 0）
+  local name="$1" f v
+  for f in "${ENV_FILES[@]}"; do
+    [ -f "$f" ] || continue
+    v=$(grep -E "^[[:space:]]*(export[[:space:]]+)?${name}=" "$f" 2>/dev/null | tail -1 \
+        | sed -E "s/^[[:space:]]*(export[[:space:]]+)?${name}=//" \
+        | sed -E 's/^"(.*)"$/\1/; s/^'"'"'(.*)'"'"'$/\1/')
+    [ -n "$v" ] && { printf '%s' "$v"; return 0; }
+  done
+  return 1
+}
+
+# ── A. cloud 總管工作需要的（只有名字＋一句理由。要加就加在這裡）──────
+A_NEEDED=(
+  "GITEA_TOKEN_CLAUDE_CODE|機器帳號 claude-code 的 Gitea token；plugin 安裝與 git push-back 都靠它"
+  "TELEGRAM_BOT_TOKEN|notify_leo 備援路徑（優先路徑是 arcrun MCP workflow，免密碼）"
+  "TELEGRAM_CHAT_ID|同上"
+  "GEMINI_API_KEY|arcrun 工作流用（matrix/arcrun、products/arcrun-rag 兩邊 .env 都列）"
+  "NOTION_INTEGRATION_TOKEN|leo 註記「給 arcrun 用的」"
+  "UNCLE6_CF_API_KEY|uncle6 帳號（非 leo21c）的 CF 操作"
+  "N8N_UNCLE6_API_KEY|n8n MCP 用"
+  "CLOUDFLARE_API_TOKEN_YOULIN_CC_USE|D37 測試帳號，本來就是設計給 CC 用的"
+)
+# 想加 geek6688 出貨機能力（讓雲端能自走完 D82 三步）就在這裡補兩行：
+#   "CLOUDFLARE_API_TOKEN_CC_SHIPPING_CORE|geek6688 出貨機 token——加了雲端就有出貨寫入能力"
+#   "CLOUDFLARE_ACCOUNT_ID_GEEK6688|同上，成對變數"
+# 沒有預設放進來，因為那是「要不要讓雲端有出貨能力」的風險判斷，屬於 leo。
+
+# ── B. 建議不放，但值已備好＋附理由，leo 自己決定要不要留 ────────────
+# 前 5 項全部來自 polaris/mira/.env（leo21c 現役正式環境），不是 cloud 總管
+# 工作需要的東西；credentials-map.md 逐檔核對，2026-08-14 那輪審查已把
+# 「無名字的 CLOUDFLARE_API_TOKEN 讀得到 leo21c 6 顆正式 worker」列為
+# 「本輪最危險的發現」。完整依據見 docs/cloud-environment-audit-20260820.md §7。
+B_LEGACY=(
+  "NAMESPACE|mira（leo21c 現役）自己的環境變數，cloud 總管的工作不吃它；拿掉沒有已知副作用"
+  "PRIVATE_KEY|mira 用的 Google 服務帳號私鑰；拿掉沒有已知副作用（cloud 總管目前的工作不碰 Google API）"
+  "CLIENT_EMAIL|PRIVATE_KEY 的配對變數，同上"
+  "CLOUDFLARE_API_TOKEN|沒有名字，實測讀得到 leo21c 的 6 顆正式 worker，會被所有工具當預設 token；拿掉會失去「不指定帳號也能操作 CF」的能力——但那正是最危險的情境本身，不是值得保留的功能"
+  "CLOUDFLARE_ACCOUNT_ID|＝ leo21c 帳號 id；拿掉會讓 CLI 不再預設打 leo21c——這是拿掉的目的，不是副作用"
+  "CLAUDE_CODE_OAUTH_TOKEN|leo 自己在舊快照裡標記「這個已經不需要了」；拿掉沒有已知副作用"
+  "CLOUDFLARE_API_TOKEN_leo21c|明確具名指向 leo21c；留著的話能對 leo21c 做診斷（GET），但風險是否可接受要看這把 token 在 CF 控制台的實際權限範圍——這台機器沒辦法幫你查，请自己到 CF dashboard 確認是唯讀還是可寫"
+)
+
+OUT_DIR="$HOME/.claude/cloud-env"
+mkdir -p "$OUT_DIR"; chmod 700 "$OUT_DIR"
+OUT="$OUT_DIR/$(date +%Y%m%d-%H%M%S).txt"
+
+SETUP="$(cd "$(dirname "$0")/.." && pwd)/docs/cloud-setup-script.sh"
+[ -f "$SETUP" ] || { echo "🔴 找不到 $SETUP" >&2; exit 1; }
+
+MISSING_NAMES=()   # A／B 兩段裡，本機 .env 完全找不到值的（落進 C 段）
+
+# bash 3.2（macOS 內建）沒有 `local -n`（nameref），這裡故意不用函式傳陣列名，
+# 兩段各自展開迴圈，維持跨平台可跑（leo 本機／雲端 Ubuntu 都要能跑）。
+render_A() {
+  local entry name reason v
+  for entry in "${A_NEEDED[@]}"; do
+    name="${entry%%|*}"; reason="${entry#*|}"
+    if v=$(lookup "$name"); then
+      printf '%s=%s    ← %s\n' "$name" "$v" "$reason"
+    else
+      MISSING_NAMES+=("$name")
+    fi
+  done
+}
+render_B() {
+  local entry name reason v
+  for entry in "${B_LEGACY[@]}"; do
+    name="${entry%%|*}"; reason="${entry#*|}"
+    if v=$(lookup "$name"); then
+      printf '%s=%s    ← %s\n' "$name" "$v" "$reason"
+    else
+      MISSING_NAMES+=("$name")
+    fi
+  done
+}
+
+{
+  echo "claude.ai → Cloud environments → 你的環境。"
+  echo "產生時間：$(date '+%Y-%m-%d %H:%M')"
+  echo "依據：docs/cloud-environment-audit-20260820.md §7（完整比對表與理由）"
+  echo
+  echo "════════ A. Environment variables — cloud 總管工作需要，直接貼 ════════"
+  render_A
+  echo
+  echo "════════ B. leo21c 正式環境憑證／已知過時 — 建議不放，值已備好，你決定 ════════"
+  echo "# 格式：NAME=值    ← 為什麼建議不放"
+  echo "# 要留哪一條，把那一行搬到上面 A 段、拿掉後面的「← 理由」註解即可"
+  render_B
+  echo
+  echo "════════ C. 舊雲端有這個名字、但本機六個 .env 都找不到值 ════════"
+  if [ ${#MISSING_NAMES[@]} -eq 0 ]; then
+    echo "（無——A／B 兩段的變數這台機器上全部找得到值）"
+  else
+    for n in "${MISSING_NAMES[@]}"; do
+      echo "$n=<🔴 這台機器找不到，若還要這個能力，從舊的雲端設定手動搬過來>"
+    done
+  fi
+  echo
+  echo "════════ D. Setup script（整段貼，一字不改）════════"
+  cat "$SETUP"
+} > "$OUT"
+chmod 600 "$OUT"
+
+A_COUNT=${#A_NEEDED[@]}
+B_COUNT=${#B_LEGACY[@]}
+echo "✅ 產生完成：$OUT"
+echo "   A 段 $A_COUNT 個（直接貼）｜B 段 $B_COUNT 個（建議不放，附值與理由）｜C 段找不到值 ${#MISSING_NAMES[@]} 個 ${MISSING_NAMES[*]:-}"
+echo "   🔴 這個檔含金鑰真身：貼完就刪（rm '$OUT'），它刻意不在任何 repo 裡。"

system-dev/docs/2-architecture/decisions/ADR-0001-isep-自建wiki.md

@@ -1,21 +1,40 @@
-# ADR-0001：ISEP 自建 wiki，不繼承 InkStoneCo 的內容
+# ADR-0001：ISEP 這個 repo 自己維護一份 wiki（記 ISEP 自己的事，跟「裝 plugin」無關）
 
-- **狀態**：已採納
+- **狀態**：已採納（決策未變，本次僅修訂標題與內文的誤導處，見文末「常見誤解」）
 - **日期**：2026-08-20
-- **票**：`inkstone/ISEP#3`
+- **票**：`inkstone/ISEP#3`（原案）、`inkstone/InkStoneCo#22`（本次修訂）
+
+## 先講結論，避免讀到一半就會錯意
+
+本 ADR 談的「wiki」，是 **`inkstone/ISEP` 這個 git repo 自己的開發歷史**——
+跟其他任何 repo（`InkStoneCo`、`arcrun`…）在自己 repo 底下放一份
+`system-dev/wiki/` 記自己的事，是同一種、完全獨立的東西。
+
+🔴 **這件事不會發生**：把 ISEP 這個 Claude Code plugin「裝」到別的 repo（本機或雲端的
+Claude Code session 啟用這個 plugin），**不會在那個 repo 裡多寫出任何檔案**，
+更不會在那裡生出一份 `system-dev/wiki/`。「plugin 裝到哪、wiki 就跟著長在哪，
+所以每個 repo 都會有兩份」是誤讀——見文末「常見誤解」段的查證。
 
 ## 背景
 
-ISEP 是獨立 repo，裝的是「環境」（hooks／commands／skills／scripts），本來刻意不放
-「知識」（wiki／docs／`_archive`）——見 `README.md`「裝什麼」段。但接手 ISEP 的 session
-（含雲端）若要查「這裡的決定、踩過的坑、現在什麼狀態」，過去只能回頭 clone InkStoneCo
-頂層知識庫，多一層跳轉、且 ISEP 自己的事並不天然屬於 InkStoneCo 頂層（那裡管的是跨專案決策）。
+ISEP 是獨立 repo，對外扮演的角色是「環境」（hooks／commands／skills／scripts，
+`README.md`「裝什麼」段列了清單，白紙黑字排除 `wiki/`／`docs/`／`_archive/`——
+那些是「知識」不是「環境」）。但 ISEP**自己也是一個在持續開發的 repo**：它有自己的
+決策（例如這份 ADR 本身）、踩過的坑、現在的狀態。過去要查「ISEP 這裡為什麼這樣設計、
+之前討論到哪」，只能回頭 clone InkStoneCo 頂層知識庫，多一層跳轉，而且 ISEP 自己的
+開發細節並不天然屬於 InkStoneCo 頂層（那裡管的是跨專案決策，不是單一 repo 的施工細節）。
 
 ## 決策
 
-ISEP 建立自己的 `system-dev/wiki/`，骨架取自 `inkstone/system-dev-template` 的 wiki
-template（三層 + 標籤橫切：`INDEX.md`／`TAXONOMY.md`／`status.md`／`mistakes.md`／
-`principles.md`／`cards/<bucket>/`），照它的規約裝，不自創格式。
+**`inkstone/ISEP` 這個 repo 自己**建立 `system-dev/wiki/`，骨架取自
+`inkstone/system-dev-template` 的 wiki template（三層 + 標籤橫切：`INDEX.md`／
+`TAXONOMY.md`／`status.md`／`mistakes.md`／`principles.md`／`cards/<bucket>/`），
+照它的規約裝，不自創格式。
+
+這份 wiki 只在 ISEP 這個 repo 的 git 歷史裡，跟著 `git clone inkstone/ISEP` 走；
+它**不是** plugin payload 的一部分（`plugin.json`／`marketplace.json` 只宣告
+`hooks/`／`commands/`／`skills/`，任何 Claude Code session 啟用這個 plugin 時載入的
+也只有這些），所以其他 repo 啟用 ISEP plugin 時，這份 wiki 不會、也無法出現在那裡。
 
 **紅線**：這份 wiki 只記 ISEP 自己的事。不把 InkStoneCo 頂層 wiki 的內容複製過來——
 複製即 fork，fork 即漂移，跟「真身薄殼合一」（見 `cards/isep/真身薄殼合一.md`）要解的病
@@ -23,12 +42,47 @@ template（三層 + 標籤橫切：`INDEX.md`／`TAXONOMY.md`／`status.md`／`m
 
 ## 後果
 
-- 好處：接手 session 在 ISEP 內就能查到 ISEP 自己的歷史，不必先 clone 別的 repo。
-- 代價：多一份骨架要維護（跟 InkStoneCo 頂層、以及其他裝了 template 的子 repo 一樣）。
+- 好處：接手 ISEP 這個 repo 的 session，在它自己的 checkout 裡就查得到它自己的歷史，
+  不必先 clone 別的 repo。
+- 代價：多一份骨架要維護（跟 InkStoneCo 頂層、以及其他裝了 template 的子 repo 一樣，
+  各自一份、各自維護，不互相複製）。
 - 邊界：跨專案的決策、鐵律、部署架構全局，仍然只在 InkStoneCo 頂層記錄，ISEP 不重複。
 
+## 常見誤解，與查證
+
+**誤解**：「ISEP 這個 plugin 裝到哪個 repo，就會在那個 repo 裡自建一份 wiki，
+於是每個裝了 ISEP 的 repo 都會多出兩份（自己的 + ISEP 幫它建的）。」
+
+**這不是實際行為。查證如下（2026-08-20 實查，不是抄口述）**：
+
+1. `.claude-plugin/marketplace.json` 把整個 repo 根目錄（`"source": "./"`）宣告成
+   plugin 來源，Claude Code 依慣例目錄（`hooks/`、`commands/`、`skills/`）載入內容；
+   `README.md`「裝什麼」表列出的也正是這幾個目錄（外加 `scripts/` 供它們呼叫）——
+   **沒有任何一項是 wiki 或 docs**。啟用這個 plugin，載入的是 hook 腳本的路徑
+   （`${CLAUDE_PLUGIN_ROOT}/hooks/*.sh`）、command／skill 的定義；這個載入過程本身
+   不涉及「往目前工作的 repo 寫入任何檔案」——它是讀，不是寫。
+2. `README.md`「裝什麼」段明文把 `wiki/`／`docs/`／`_archive/` 列在「不放」——
+   這條界線本來就是刻意畫的（環境 vs 知識分離），不是本 ADR 才立的。
+3. 全部 hooks 對「自己這支腳本」的路徑一律用 `${CLAUDE_PLUGIN_ROOT}`（不用
+   `$CLAUDE_PROJECT_DIR`，見 `README.md`「路徑規約」段）——這條規約本身就代表
+   hook 的邏輯設計上就是「讀 plugin 自己的檔案」，不是「往目前工作的 repo 寫東西」。
+4. **唯一一支「真的會在某個 repo 裡建出 wiki」的腳本是 `scripts/install.sh`**——
+   但它是 `system-dev-template` 的獨立安裝器（不是 ISEP 的功能），要**人或 AI 手動執行
+   一次**才會動作，且動作對象是**執行當下的 cwd**，不是「ISEP 被啟用的地方」。
+   它會混進這個 repo，是搬家時帶過來的殘留（`docs/governance/DIVERGENCE-v0.5.0-to-v0.6.0.md`
+   A6 節已標記它是待清理項，跟 `.claude-plugin` 宣告的 plugin 功能無關）。
+   **這支腳本的存在，多半就是本誤解真正的來源**——它看起來像「ISEP 會建 wiki」，
+   但觸發方式（手動跑一次）與作用對象（cwd，不是「plugin 裝到的地方」）都跟
+   「裝 plugin 就自動建」完全不同。
+
+⇒ 結論：本 ADR 的「wiki」只指 ISEP 這個 repo 自己 checkout 裡的那一份，
+跟其他任何 repo 有沒有、要不要各自裝一份 wiki（那是它們自己的 `/wiki-init` 決定），
+兩件事互不影響、也不會因為裝了 ISEP plugin 而自動被牽動。
+
 ## 相關
 
 - `cards/isep/真身薄殼合一.md`
 - `cards/isep/repo邊界與紅線.md`
 - `cards/isep/hook路徑規約.md`
+- `inkstone/InkStoneCo#22`（本次修訂的來由：leo 讀完舊版誤解成「plugin 裝到哪、
+  wiki 就跟著建到哪」）