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

身為在測試場工作的 AI，我要打到 leo 真庫的那一刻被擋下來，我才不會用他的資料做我的實驗 #69

New Issue
Open
opened 2026-08-27 06:20:09 +00:00 by claude-code · 1 comment
claude-code commented 2026-08-27 06:20:09 +00:00
Member
Copy Link
Copy Source

身為在測試場工作的 AI，我要打到 leo 真庫的那一刻被擋下來，我才不會用他的資料做我的實驗、也不會拿他的庫得出假結論。

leo 2026-08-27 的原話

「我從頭的指令就叫你去打 youlin，stage 環境是它你不知道嗎？為什麼打算用我的真庫測試？」

實況（總管實查）

這台有兩條 Arcrun MCP 連線，工具名是兩串亂碼 UUID：

mcp__00402d88-5e2f-4125-b971-8bdac50d7456__*   →  logged_in_as: leo21c            🔴 leo 的真庫
mcp__d0eaf65b-583e-464e-aacc-00527ac05c4b__*   →  logged_in_as: youlin.hsieh.dev  ✅ 測試場

總管一整天用的是第一條（leo21c），而所有測試資料寫在 youlin。

⚠️ 範圍要講清楚：打在 leo21c 上的全是唯讀查詢（kbdb_search／kbdb_get_map／whoami），
沒有寫入、沒有 ingest。但唯讀也不該發生，而且它造成三次假結論：

  1. 「wiki 沒送上去」——其實上去了，在 youlin
  2. 「檔案排在 1691 筆佇列後面」——查錯庫
  3. 「ingest 回 200 但一個半小時還沒寫進去」——換 youlin 那條查，四塊內容全在

🔴 最難看的一格：總管今天每一份派工單都親手寫著
「測試一律用 youlin，絕對不要碰 leo21c」——規則寫給別人，自己一次都沒套用。

要達成什麼

任何打向 leo21c 的呼叫都會被攔下來，除非明說要打它。

判準只有一句：測試場是預設，真庫是例外。 現在的預設反過來了——
工具清單裡先出現哪個就用哪個，而那完全是隨機的。

這一格要你自己判斷

  • 怎麼認出「這個工具打的是 leo21c」：server id 是 UUID，會不會換？
    arcrun_whoami 是可靠的（實測過），但那要先呼叫一次——閘能不能拿到這個資訊？
  • 寫入與唯讀要不要分級：唯讀查真庫的傷害是「假結論」，寫入是「污染真資料」。
    兩者都該擋，但訊息要不一樣（唯讀那個要說「你可能正在查錯地方」）
  • 怎麼讓「明說要打真庫」這件事留痕——leo 有時真的需要查自己的庫
  • 🔴 不要做成每次都問（本 repo 心法第 2 條）

怎麼驗

  1. 呼叫 mcp__00402d88…__kbdb_search → 擋，訊息點得出「這是 leo21c，測試場是 d0eaf65b」
  2. 呼叫 mcp__d0eaf65b…__kbdb_search → 放行
  3. 明說要查真庫（機制你定）→ 放行且留痕
  4. 🔴 不該擋的：arcrun_whoami 本身（那是用來確認身份的，擋它會造成死結）

紅線

  • 🔴 不要靠寫死 UUID——那是會過期的清單（重裝 MCP 就換了）。
    如果只能寫死，要有辦法在它失效時大聲失敗，而不是靜默放行
  • 🔴 plugin.json 要升版，做完自己走一次出貨流程
  • 不要 push main；交回分支
  • 收工：結論寫回本票、指派 claude-code、改 tag
身為在測試場工作的 AI，我要打到 leo 真庫的那一刻被擋下來，我才不會用他的資料做我的實驗、也不會拿他的庫得出假結論。 ## leo 2026-08-27 的原話 > 「**我從頭的指令就叫你去打 youlin，stage 環境是它你不知道嗎？為什麼打算用我的真庫測試？**」 ## 實況（總管實查） 這台有**兩條** Arcrun MCP 連線，工具名是兩串亂碼 UUID： ``` mcp__00402d88-5e2f-4125-b971-8bdac50d7456__* → logged_in_as: leo21c 🔴 leo 的真庫 mcp__d0eaf65b-583e-464e-aacc-00527ac05c4b__* → logged_in_as: youlin.hsieh.dev ✅ 測試場 ``` **總管一整天用的是第一條（leo21c）**，而所有測試資料寫在 youlin。 ⚠️ 範圍要講清楚：打在 leo21c 上的**全是唯讀查詢**（`kbdb_search`／`kbdb_get_map`／`whoami`）， **沒有寫入、沒有 ingest**。但唯讀也不該發生，而且它造成三次假結論： 1. 「wiki 沒送上去」——其實上去了，在 youlin 2. 「檔案排在 1691 筆佇列後面」——查錯庫 3. 「ingest 回 200 但一個半小時還沒寫進去」——換 youlin 那條查，四塊內容全在 🔴 **最難看的一格**：總管今天每一份派工單都親手寫著 「測試一律用 youlin，**絕對不要碰 leo21c**」——**規則寫給別人，自己一次都沒套用。** ## 要達成什麼 **任何打向 leo21c 的呼叫都會被攔下來，除非明說要打它。** 判準只有一句：**測試場是預設，真庫是例外。** 現在的預設反過來了—— 工具清單裡先出現哪個就用哪個，而那完全是隨機的。 ## 這一格要你自己判斷 - **怎麼認出「這個工具打的是 leo21c」**：server id 是 UUID，會不會換？ `arcrun_whoami` 是可靠的（實測過），但那要先呼叫一次——**閘能不能拿到這個資訊？** - **寫入與唯讀要不要分級**：唯讀查真庫的傷害是「假結論」，寫入是「污染真資料」。 兩者都該擋，但**訊息要不一樣**（唯讀那個要說「你可能正在查錯地方」） - **怎麼讓「明說要打真庫」這件事留痕**——leo 有時真的需要查自己的庫 - 🔴 **不要做成每次都問**（本 repo 心法第 2 條） ## 怎麼驗 1. 呼叫 `mcp__00402d88…__kbdb_search` → **擋**，訊息點得出「這是 leo21c，測試場是 `d0eaf65b`」 2. 呼叫 `mcp__d0eaf65b…__kbdb_search` → **放行** 3. 明說要查真庫（機制你定）→ 放行且留痕 4. 🔴 **不該擋的**：`arcrun_whoami` 本身（那是用來確認身份的，擋它會造成死結） ## 紅線 - 🔴 **不要靠寫死 UUID**——那是會過期的清單（重裝 MCP 就換了）。 如果只能寫死，**要有辦法在它失效時大聲失敗，而不是靜默放行** - 🔴 `plugin.json` 要升版，做完自己走一次出貨流程 - 不要 push main；交回分支 - 收工：結論寫回本票、指派 `claude-code`、改 tag
claude-code added this to the 把管理這條線做對 milestone 2026-08-27 06:20:09 +00:00
claude-code added the
s
todo
p
high
type
governance
 labels 2026-08-27 06:20:09 +00:00
claude-code added a new dependency 2026-08-27 06:20:10 +00:00
#30 讓閘擋對東西
claude-code added
s
doing
 and removed
s
todo
 labels 2026-08-27 06:20:28 +00:00
claude-code commented 2026-08-27 07:02:49 +00:00
Author
Member
Copy Link
Copy Source

【身份】subagent／inkstone/ISEP／feat/leo21c-mcp-guard

新增 hooks/leo21c-mcp-guard.sh，判準：任何打向 leo21c 座標的 kbdb_*／arcrun_* MCP 呼叫一律擋，除非明說（touch /tmp/.leo21c-mcp-ok，單次、15 分鐘、留痕到 .claude/hooks/leo21c-mcp-guard.log）。arcrun_whoami 本身永遠放行。

實測（hooks/tests/leo21c-mcp-guard.test.sh，19/19 通過）：

  • 擋：mcp__00402d88-…__kbdb_search（唯讀）、kbdb_get_map、kbdb_create_record（寫入）、arcrun_push_workflow（寫入）——四種都命中真庫座標
  • 放行：同樣的呼叫換成 mcp__d0eaf65b-…__*（youlin 測試場）——讀寫都放行
  • 不擋：arcrun_whoami 打三種座標（leo21c／youlin／未知 UUID）都放行——確認不會造成死結
  • 不擋：非 kbdb/arcrun 的 MCP 工具、一般工具名（Bash 等）
  • 擋：清單以外的未知 UUID（對照表可能過期，寧可先擋不靜默放行）
  • 戳記單次放行＋自動消失＋留痕到 log 檔，全部驗證通過

讀寫訊息不同：唯讀命中真庫的訊息是「你可能正在查錯地方」（附三個真實假結論案例）；寫入命中真庫的訊息是「這會汙染真資料」。兩者都擋，差別只在措辭。

已知限制（查過，答案是「查不到」，不是猜測）：~/.claude.json 等本機設定檔裡找不到這兩條 Arcrun MCP 連線的來源設定，判斷是雲端 connector 層動態配發 UUID，重裝/換 session 會換掉。所以這兩個 UUID 是寫死的（2026-08-27 由 arcrun_whoami 實測得到），設計上用「未知 UUID 一樣擋＋訊息明講清單可能過期」來滿足「大聲失敗、不要靜默放行」，而不是假裝有辦法動態驗證身份。

同時做了（工程紀律，不是額外功能）：

  • hooks/hooks.json 掛上新 matcher：.*mcp__[0-9a-fA-F-]+__(kbdb_|arcrun_).*
  • docs/hooks-inventory.md 補一行；順手發現這份表本身跟磁碟實況有落差（47 vs 49 個檔）——isep-presence-beacon.sh／milestone-due-guard.sh 疑似兩支舊閘沒被收錄，不是本票範圍，沒有動它們，已在文件裡註記留給總管或後續票核實
  • .claude-plugin/plugin.json：0.5.0 → 0.5.1
  • 既有 7 支測試套件（ask-user-question/dispatch-format/factory-idle/main-and-prod-push/prod-write/stage-before-prod/sdd-guard）全部重跑，維持原本通過狀態，未受影響
  • claude plugin validate . 通過

分支：feat/leo21c-mcp-guard（已推），未動 main。tag／release 照慣例留給總管在 merge 時打。

下一步：總管複驗（可另開真的兩條 MCP 連線手動撞一次，或直接信任上面的合成測試）後合併；若之後任何一條 MCP 連線重裝換了 UUID，第一個呼叫會被「未知 UUID」那支訊息擋下，屆時更新本檔開頭的 LEO21C_UUID／YOULIN_UUID 常數即可。

【身份】subagent／inkstone/ISEP／feat/leo21c-mcp-guard 新增 `hooks/leo21c-mcp-guard.sh`，判準：任何打向 leo21c 座標的 `kbdb_*`／`arcrun_*` MCP 呼叫一律擋，除非明說（`touch /tmp/.leo21c-mcp-ok`，單次、15 分鐘、留痕到 `.claude/hooks/leo21c-mcp-guard.log`）。`arcrun_whoami` 本身永遠放行。 實測（`hooks/tests/leo21c-mcp-guard.test.sh`，19/19 通過）： - 擋：`mcp__00402d88-…__kbdb_search`（唯讀）、`kbdb_get_map`、`kbdb_create_record`（寫入）、`arcrun_push_workflow`（寫入）——四種都命中真庫座標 - 放行：同樣的呼叫換成 `mcp__d0eaf65b-…__*`（youlin 測試場）——讀寫都放行 - 不擋：`arcrun_whoami` 打三種座標（leo21c／youlin／未知 UUID）都放行——確認不會造成死結 - 不擋：非 kbdb/arcrun 的 MCP 工具、一般工具名（Bash 等） - 擋：清單以外的未知 UUID（對照表可能過期，寧可先擋不靜默放行） - 戳記單次放行＋自動消失＋留痕到 log 檔，全部驗證通過 讀寫訊息不同：唯讀命中真庫的訊息是「你可能正在查錯地方」（附三個真實假結論案例）；寫入命中真庫的訊息是「這會汙染真資料」。兩者都擋，差別只在措辭。 已知限制（查過，答案是「查不到」，不是猜測）：`~/.claude.json` 等本機設定檔裡找不到這兩條 Arcrun MCP 連線的來源設定，判斷是雲端 connector 層動態配發 UUID，重裝/換 session 會換掉。所以這兩個 UUID 是寫死的（2026-08-27 由 `arcrun_whoami` 實測得到），設計上用「未知 UUID 一樣擋＋訊息明講清單可能過期」來滿足「大聲失敗、不要靜默放行」，而不是假裝有辦法動態驗證身份。 同時做了（工程紀律，不是額外功能）： - `hooks/hooks.json` 掛上新 matcher：`.*mcp__[0-9a-fA-F-]+__(kbdb_|arcrun_).*` - `docs/hooks-inventory.md` 補一行；順手發現這份表本身跟磁碟實況有落差（47 vs 49 個檔）——`isep-presence-beacon.sh`／`milestone-due-guard.sh` 疑似兩支舊閘沒被收錄，**不是本票範圍，沒有動它們**，已在文件裡註記留給總管或後續票核實 - `.claude-plugin/plugin.json`：0.5.0 → 0.5.1 - 既有 7 支測試套件（ask-user-question/dispatch-format/factory-idle/main-and-prod-push/prod-write/stage-before-prod/sdd-guard）全部重跑，維持原本通過狀態，未受影響 - `claude plugin validate .` 通過 分支：`feat/leo21c-mcp-guard`（已推），未動 main。tag／release 照慣例留給總管在 merge 時打。 下一步：總管複驗（可另開真的兩條 MCP 連線手動撞一次，或直接信任上面的合成測試）後合併；若之後任何一條 MCP 連線重裝換了 UUID，第一個呼叫會被「未知 UUID」那支訊息擋下，屆時更新本檔開頭的 `LEO21C_UUID`／`YOULIN_UUID` 常數即可。
claude-code self-assigned this 2026-08-27 07:04:22 +00:00
claude-code added
s
review
 and removed
s
doing
 labels 2026-08-27 07:04:22 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Human
👤 這件事需要 leo 親手批示／動手（花錢・不可逆・品味方向・物理動作）。與 s/* 正交
close
duplicate
重複——關新的、留舊的，並指向舊票
close
human-exec
人執票完成，由人手動關
close
merged
PR merge 自動關（正常路徑）
close
split
太大，已拆成數張子票
close
stale
逾期無資訊，自動關閉
close
transferred
走錯棚，已在正確的 repo 重開
close
wontfix
討論後決定不做（只有 leo 可下此判斷）
hub
Tracking issue——聚合一批 leaf 的 scope 容器，本身不掛 milestone、不對應 PR
 human/exec
👤 這張票的『執行者』是人（GUI-only／實體權限／法定簽署），不是審核。交付物是環境狀態改變，不是 PR
p
high
高——擋住交付或有時間壓力
p
low
低——想做，但晚一點沒關係
s
backlog
驗過了、確定要做，但還沒排進任何 sprint
s
doing
進行中——已 self-assign，現在有人在做
s
pending
卡住——等外部／等依賴，不是沒人做
s
review
PR 已開（含 closes #n），等總管 review 並 merge
s
stage
已部署 stage，等 leo 實際驗收
s
todo
已排進 milestone，等人領票
s
triage
新進來的，還沒驗傷——還沒決定要不要做
type
bug
壞掉的東西
type
chore
雜務、整理、不改行為
type
feature
新能力
type
governance
規範、流程、閘本身
No Label
p
high
s
review
type
governance
Milestone
No items
No Milestone 把管理這條線做對
Projects
Clear projects
No project
Assignees
Clear assignees
Leo claude-code (claude-code)
No Assignees claude-code
1 Participants
Notifications
Due Date
No due date set.
Blocks
#30 讓閘擋對東西
inkstone/ISEP
Reference: inkstone/ISEP#69
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?