一個 repo 為什麼能控制其他 repo？答案不是程式碼，是「權限」這條看不見的線

起因：我不懂一個 repo 怎麼控制得了另一個 repo

接續上一篇〈中央 repo 派工給多個子 repo，這架構叫什麼？〉。我已經知道 a 是中樞、a-a/a-b/a-c 是執行單位。但我心裡有個更基本的疑問卡住：

a 憑什麼能在 a-a 開 Issue？它們不是各自獨立的資料夾嗎？是程式碼之間有什麼隱形連線把它們綁在一起嗎？

我的提問：為什麼這個 repo 可以控制其他 repo，甚至讓彼此 repo 關聯？我不懂

我直接跟 Claude 說：填 repos.yml 之前，我想先搞懂——為什麼這個 repo 可以控制其他 repo、甚至讓彼此關聯？我真的不懂。

Claude 的回答：這個 repo 其實「什麼都控制不了」

Claude 的第一句話就打破我的直覺：

repo 本身沒有任何「控制其他 repo」的能力。真正去控制的，是「一個有權限的身分」，拿著 repo 裡的腳本去執行。

repo 只是一疊「指示說明書」（dispatch.sh、repos.yml、工單）。說明書本身不會動。會動的是執行說明書的那個人、那把鑰匙。

Claude 的比喻：派工單、員工、識別證

Claude 用一間公司打比方，我一聽就通了：

現實世界	GitHub 世界
一疊派工單放桌上	`a` repo 的工單 YAML
派工單寫「送到 A 部門」	`target_repo: a-a`
部門對照表（A 部門在 301 室）	`repos.yml`
你的員工識別證（能刷開哪幾個門）	Token（權限憑證）
你拿單子走過去刷門放單	`gh issue create --repo cameocyc/a-a`

關鍵在哪？那疊派工單放在桌上一萬年，A 部門的門也不會自己開。 一定要一個「有識別證的人」拿著單子走過去刷卡，門禁確認「這張證有 A 部門的權限」，才放他進去。

所以真正讓跨部門派工成立的，是識別證的權限，不是那疊單子。

我又追問：那「識別證」在 GitHub 裡到底是什麼？

那這張識別證，在 GitHub 裡具體是什麼東西？

Claude 的回答：就是 Token，而且整條控制鏈是這樣串的

Claude 說識別證就是 Token（憑證）——派工指南裡的 DISPATCH_TOKEN、GH_TOKEN，還有 gh auth login 登入的身分，全都是它。然後它把整條控制鏈攤開給我看：

dispatch.sh 跑起來
   │
   ▼
呼叫 gh issue create --repo cameocyc/a-a
   │
   ▼
gh 把請求送到 GitHub 伺服器（API），附上你的 Token
   │
   ▼
GitHub 問：這個 Token 是誰？它對 a-a 有「開 Issue」的權限嗎？
   │
   ├─ 有 ──► ✅ 在 a-a 開一張 Issue，回傳網址
   └─ 沒有 ─► ❌ 403 Forbidden，拒絕

這裡最翻轉我認知的一點是：真正在「控制」a-a 的不是 a repo，是 GitHub 的伺服器。 a 只是發出請求，GitHub 才是那個握有所有 repo、負責驗證權限、實際動手開 Issue 的人。a 是下單的，GitHub 是執行的。

我想通的延伸：它們為什麼跨 repo 也行得通

Claude 說四個 repo 看起來獨立，但它們全託管在 GitHub、全屬於 cameocyc 帳號。GitHub 像一棟大樓，四個 repo 是四間辦公室——它們不是靠彼此之間有電線連著，而是各自跟大樓管理中心（GitHub API）講話。

這讓我看懂一件有意思的事：

這不是 a 在「指揮」a-a，而是「一個同時對 a 和 a-a 都有權限的身分」，借用 a 的腳本，去操作 a-a。

換句話說——真正把四個 repo 綁在一起的，是「權限」這條看不見的線，不是程式碼。

那「讓彼此關聯」又是怎麼做到的？

Claude 說「控制」和「關聯」是兩回事，關聯有三層，由弱到強：

靠約定：repos.yml 註冊表就是關聯的本體，純粹一份對照清單，讓腳本知道單要派去哪。
靠連結回寫：派工成功後，腳本把 Issue 網址寫回工單；於是中樞工單記得「我派到了哪張 Issue」、執行單 Issue 也記得「我來自哪張工單」——雙向可追溯。
靠 GitHub 原生引用：在任何 Issue 打 cameocyc/a-a#5，GitHub 自動變成可點擊、會雙向掛鉤的連結，不用寫程式。

我學到的

repo 不會控制 repo。 是一個「有權限的身分（Token）」拿著腳本，透過 GitHub API 去操作其他 repo。把它們綁在一起的是權限和註冊表，不是隱形的程式碼連線。
這也解釋了為什麼派工指南一直強調 DISPATCH_TOKEN 要能寫入三個執行單位——那顆 token 是整套系統的命脈，沒有它，腳本再漂亮也只是一疊放在桌上的廢紙。
最大的收穫是換了一個看世界的角度：以前我以為「能力在程式裡」，現在我懂了「能力在身分與權限裡」。這個觀念之後看任何自動化、任何 API、任何 AI agent 接外部工具，應該都通用。

本文是我在 Claude 協助下，把一段「我搞不懂」的對話整理成的學習筆記。所有比喻與技術解釋由我與 Claude 的對話產生；文中 a / a-a / a-b / a-c 是我實際在操作的專案結構。