照著這篇做完，你可以問 Claude Code「checkout 那個 change set 是綠燈嗎？」，拿到從 osFoundry 讀出來的答案，而不是從你本機的測試結果猜的。Claude Code 會列出 change set 的 composed commit 上的 checks，告訴你哪一個失敗，如果看起來是 flaky，就只針對那一個 check 提出重跑。Claude Code 提出要求時，重跑不會馬上開始。它會以「Retry GitNest check」卡片的形式出現在 osFoundry，上面寫著 change set 版本和確切的 commit，只有在你按下 Approve retry 之後才會執行。
誰負責什麼
| Claude Code | osFoundry | |
|---|---|---|
| 登入 | 在你電腦上的自有登入 | 你針對某個 workspace 核准過一次的連線，帶有 osfoundry:read 和 osfoundry:write scope |
| 用哪個 repository | 從伺服器列出的清單中挑選 | 只限已指派到該連線所屬專案的 GitNest repository |
| 讀取 checks | 對單一 change set 呼叫 list_gitnest_checks | 回傳該 change set 目前 composed commit 的有限狀態 |
| 執行 checks | 從不執行 | 由你註冊的 runner 機器執行。osFoundry 不會執行你的程式碼 |
| 重跑 check | propose_gitnest_check_rerun，被標記為 destructive，所以 Claude Code 會先問你 | "Needs your approval"（待你核准）底下的一張卡片。Approve retry 會把那一個已完成的 check 重新排入佇列 |
| 會重新檢查什麼 | 無 | 核准當下：repository 存取權、change set 版本、commit 與 check 狀態 |
設定步驟
1. 把 osFoundry 加進 Claude Code
$ claude mcp add --transport http -s user osfoundry https://api.osfoundry.io/api/v1/external-mcp 用 osfoundry agent connect claude --print，osFoundry CLI 也會印出同一行。在 Claude Code 執行 /mcp，選 osfoundry，再選 Authenticate。瀏覽器會打開 osFoundry，讓你選一個 workspace。之後工具就會以 mcp__osfoundry__… 的名稱出現。
2. 確認 repository 有 checks 和 runner
從沒跑過的 check 既讀不到，也無法重跑。在 GitNest 打開 repository 的設定頁，這裡有兩個面板要注意：
- Check runners：「Checks run on your machine, not ours — osFoundry never executes your code on its own infrastructure.」（checks 在你的機器上跑，不在 osFoundry 的機器上）。Register runner 會給你一次性的 token 和啟動指令
OSF_RUNNER_TOKEN=… osfoundry-runner --api https://api.osfoundry.io。沒有 runner 時，面板會提醒「Checks will stay queued until one is.」 - Required checks：來自
.osfoundry/checks.yaml的名稱。「A change set cannot merge until every check named here has passed on its commit.」
3. 把 repository 放進專案，連線也加進同一個專案
在 GitNest 中，repository 的 Project 區塊寫著「Connected agents in this project can use approved GitNest read tools when their connection owner still has repository access.」只有 repository 擁有者看得到選單。選好專案後，osFoundry 會顯示「Repository project updated」。
接著打開鑰匙圖示 → Connected，選取 Claude Code 連線，在 Projects 底下把它加進同一個專案。
範例：把 Claude Code 連線加進存放 repository 的專案
同一個面板的 Tools 底下寫著「All supported tools are on by default.」本篇用到的工具會顯示為 list gitnest work、list gitnest checks、list gitnest saved results、read gitnest work 和 propose gitnest check rerun。如果只想讓 Claude Code 讀取 checks，就取消勾選 propose gitnest check rerun，再按 Save tools。
實際跑一次
工具和參數名稱都是 osFoundry 伺服器從 tools/list 回傳的。Repository、change set、ID、check 名稱和回覆都是範例內容。
Example You: Is the checkout-retry change set in shop-api green? If a check failed for a reason that isn't the code, ask osFoundry to retry it. Claude Code → mcp__osfoundry__list_granted_resources {} ← project "Payments" · GitNest repository "shop-api" Claude Code → mcp__osfoundry__list_gitnest_work {"repository_id": "…", "kind": "changes"} ← "Fix double charge on checkout retry" (cs_4e81a0) · version 3 Claude Code → mcp__osfoundry__list_gitnest_checks {"repository_id": "…", "change_set_id": "cs_4e81a0"} ← composed commit 9c1e47a…: unit passed · lint passed · e2e failed Claude Code → mcp__osfoundry__list_gitnest_saved_results {"repository_id": "…", "limit": 10} ← 2 saved results behind this change set Claude Code → mcp__osfoundry__read_gitnest_work {"repository_id": "…", "kind": "runs", "item_id": "…"} ← run summary: payment client tests passed locally Claude Code: unit and lint passed on 9c1e47a. e2e failed. The change only touches the payment client, and its tests passed in the saved run, so a retry is reasonable. Shall I propose one? You: Yes. Claude Code → mcp__osfoundry__propose_gitnest_check_rerun {"repository_id": "…", "change_set_id": "cs_4e81a0", "check_name": "e2e", "expected_change_set_version": 3, "expected_composition_oid": "9c1e47a…", "idempotency_key": "rerun-5b0c…"} ← proposal waiting for the owner Claude Code: The retry is waiting under Connected → Needs your approval. Tell me when you've approved it and I'll read the checks again. Claude Code 在呼叫 propose 之前會先問你，因為這個工具帶有 destructiveHint: true 標註。這是 Claude Code 自己的權限提示，跟 osFoundry 的核准是兩回事。
核准之前，先看一下 change set 本身。在 GitNest 的 review 頁面上，checks 面板位於分頁上方，用一行摘要 composed commit 的結果，這裡是「Checks did not pass: e2e」，下面列出每個 check 和它的狀態。還沒 compose 的 change set 完全不會顯示這個面板，而沒有任何 check 的 commit 會顯示「No checks have run against this commit」，不會出現打勾。
通知鈴會顯示「 proposes retrying a GitNest check」。在鑰匙圖示 → Connected → 你的連線 → Needs your approval 底下，卡片內容如下：
Retry GitNest check in shop-api Change set: cs_4e81a0 · expected version 3 Reviewed commit: 9c1e47a… Check to retry: e2e Review change set before approving Expires … [ Approve retry ] [ Decline ] 
範例：Needs your approval 底下的 Retry GitNest check 提案
「Review change set before approving」會打開同一個 review 頁面。如果卡片上的 commit 就是你剛才看過的那個，按下 Approve retry。e2e check 會針對那個 commit 重新排入佇列，由你的 runner 接手。接著告訴 Claude Code，它會再呼叫一次 list_gitnest_checks。
界線在哪裡
重跑指定的是 commit，不是 branch。propose_gitnest_check_rerun 必須帶 expected_change_set_version 和 expected_composition_oid，所以卡片上一定寫著 Claude Code 看到失敗的是哪個 composed commit。如果卡片還在等待時有人重新 compose 了 change set，你要核准的 commit 就不再是卡片上那個。osFoundry 會在你按下時重新檢查版本、commit 和 check 狀態，過期的卡片不會執行。這時面板會顯示「Could not decide this proposal. Its access may have changed.」請 Claude Code 重新讀取 checks，再針對新的 commit 提出。
只有已完成的 check 可以重跑。工具說明寫的是「retry one finished check」，check 狀態也在重新檢查的範圍內。已經重新排入佇列或正在跑的 check，不論是別人重跑了它、還是 change set 被重新 compose，都不會被排入第二次。
一個提案只能有一個 check。check_name 是最多 200 字元的單一字串。要重跑整個 suite，就是每個 check 一張卡片，每張都由你決定。這樣重跑一個 flaky 的 e2e，就不會順手把你寧願讓它維持失敗的安全掃描也悄悄重跑。
這整個流程沒有任何東西跑在 osFoundry 的機器上，也不會改動程式碼。Checks 跑在你註冊的 runner 上。核准重跑只會把一個 check 重新排入佇列，就這樣而已。不會重新 compose、不會 merge、也不會發佈。Merge 仍然要等每個 required check 都在該 commit 上通過。
讀取的內容維持最少。list_gitnest_checks 只回傳目前 composed commit 的有限狀態。list_gitnest_saved_results 和 read_gitnest_work 不包含本機綁定和憑證，所以 Claude Code 可以告訴你某個測試失敗了，但永遠看不到你的 runner token 或本機 checkout 路徑。
想試試看的話，在一台閒置機器上註冊一個 runner，push 一個帶有你知道會 flaky 的 check 的 change set，然後問 Claude Code 它是不是綠燈。GitNest 頁面 有 repository、change set 和 checks 的畫面，Connected 頁面 則介紹核准面板。
