Wie Claude Code in osFoundry GitNest-Checks liest und einen Retry vorschlägt, den du freigibst

Am Ende dieser Anleitung kannst du Claude Code fragen "Ist das Checkout-Change-Set grün?" und bekommst eine Antwort, die aus osFoundry gelesen ist und nicht aus deinem lokalen Testlauf geraten. Claude Code listet die Checks auf dem Composed Commit des Change Sets, sagt dir, welcher fehlgeschlagen ist, und stellt bei einem offenbar flaky Check einen Retry für genau diesen einen Check. Der Retry startet nicht, wenn Claude Code ihn anfragt. Er landet in osFoundry als Karte "Retry GitNest check" mit der Change-Set-Version und dem exakten Commit darauf und läuft erst, wenn du auf Approve retry klickst.

Wer macht was

Einrichtung

1. osFoundry zu Claude Code hinzufügen

$ claude mcp add --transport http -s user osfoundry https://api.osfoundry.io/api/v1/external-mcp

Die osFoundry-CLI gibt dieselbe Zeile mit osfoundry agent connect claude --print aus. Führ in Claude Code /mcp aus, wähl osfoundry und dann Authenticate. Der Browser öffnet osFoundry, und du wählst einen Workspace. Danach tauchen die Tools als mcp__osfoundry__… auf.

2. Sicherstellen, dass das Repository Checks und einen Runner hat

Ein Check, der nie gelaufen ist, lässt sich weder lesen noch wiederholen. Öffne in GitNest die Einstellungsseite des Repositorys. Zwei Panels sind hier wichtig:

• Check runners: "Checks run on your machine, not ours — osFoundry never executes your code on its own infrastructure." (Checks laufen auf deiner Maschine, nicht bei osFoundry). Register runner gibt dir einmalig ein Token und den Befehl zum Starten, OSF_RUNNER_TOKEN=… osfoundry-runner --api https://api.osfoundry.io. Ohne Runner warnt das Panel "Checks will stay queued until one is."
• Required checks: Namen aus .osfoundry/checks.yaml. "A change set cannot merge until every check named here has passed on its commit."

3. Repository in ein Projekt legen, und die Verbindung ins selbe Projekt

In GitNest steht im Abschnitt Project des Repositorys "Connected agents in this project can use approved GitNest read tools when their connection owner still has repository access." Nur der Owner des Repositorys sieht die Auswahl. Wähl ein Projekt, und osFoundry bestätigt "Repository project updated".

Öffne dann das Schlüssel-Icon → Connected, wähl die Claude-Code-Verbindung aus und füg sie unter Projects zu diesem Projekt hinzu.

Beispiel: Die Claude-Code-Verbindung wird dem Projekt hinzugefügt, das das Repository enthält

Unter Tools im selben Panel gilt "All supported tools are on by default." Die Tools aus dieser Anleitung erscheinen als list gitnest work, list gitnest checks, list gitnest saved results, read gitnest work und propose gitnest check rerun. Soll Claude Code bei Checks nur lesen dürfen, entfern den Haken bei propose gitnest check rerun und klick auf Save tools.

Ein echter Durchlauf

Tool- und Argumentnamen sind die, die der osFoundry-Server über tools/list zurückgibt. Repository, Change Set, IDs, Check-Namen und Antworten sind Beispielinhalte.

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 fragt vor dem Propose-Aufruf nach, weil das Tool mit destructiveHint: true annotiert ist. Das ist sein eigener Berechtigungs-Prompt, getrennt von der Freigabe in osFoundry.

Bevor du freigibst, schau dir das Change Set selbst an. Auf seiner Review-Seite in GitNest sitzt das Checks-Panel über den Tabs und fasst den Composed Commit in einer Zeile zusammen, hier "Checks did not pass: e2e", darunter jeder Check mit seinem Status. Ein Change Set, das noch nicht composed wurde, zeigt gar kein Panel, und ein Commit ohne Checks zeigt "No checks have run against this commit" statt eines Häkchens.

Die Glocke zeigt " proposes retrying a GitNest check". Unter Schlüssel-Icon → Connected → deine Verbindung → Needs your approval steht auf der Karte:

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 ]

Beispiel: Ein Retry-GitNest-check-Vorschlag unter Needs your approval

"Review change set before approving" öffnet dieselbe Review-Seite. Ist der Commit auf der Karte der, den du dir angesehen hast, klick auf Approve retry. Der e2e-Check wird für diesen Commit erneut in die Queue gestellt, und dein Runner übernimmt ihn. Sag dann Claude Code Bescheid, und es ruft list_gitnest_checks noch einmal auf.

Wo die Grenze liegt

Der Retry nennt einen Commit, keinen Branch. propose_gitnest_check_rerun verlangt expected_change_set_version und expected_composition_oid, daher steht auf der Karte immer, welchen Composed Commit Claude Code fehlschlagen sah. Composed jemand das Change Set neu, während die Karte wartet, ist der Commit, den du freigeben würdest, nicht mehr der auf der Karte. osFoundry prüft beim Klick Version, Commit und Check-Status erneut, und eine veraltete Karte läuft nicht. Das Panel zeigt dann "Could not decide this proposal. Its access may have changed." Bitte Claude Code, die Checks noch einmal zu lesen und gegen den neuen Commit vorzuschlagen.

Nur ein abgeschlossener Check kann wiederholt werden. Die Tool-Beschreibung sagt "retry one finished check", und der Check-Status gehört zur erneuten Prüfung. Ein Check, der bereits wieder in der Queue steht oder läuft, weil jemand anderes ihn wiederholt hat oder das Change Set neu composed wurde, wird nicht ein zweites Mal eingereiht.

Ein Check pro Vorschlag. check_name ist ein einzelner String mit bis zu 200 Zeichen. Die ganze Suite zu wiederholen heißt eine Karte pro Check, und jede entscheidest du. So startet ein Retry für einen flaky e2e-Test nicht stillschweigend einen Security-Scan neu, den du lieber rot lassen willst.

Nichts in diesem Ablauf läuft auf Maschinen von osFoundry oder ändert Code. Checks laufen auf den Runnern, die du registriert hast. Einen Retry freizugeben stellt einen Check erneut in die Queue, sonst nichts. Es wird nicht neu composed, gemergt oder veröffentlicht. Der Merge wartet weiterhin, bis jeder Required Check auf dem Commit bestanden hat.

Die Lesezugriffe bleiben schmal. list_gitnest_checks liefert einen begrenzten Status nur für den aktuellen Composed Commit. list_gitnest_saved_results und read_gitnest_work lassen lokale Bindings und Credentials weg. Claude Code kann dir also sagen, dass ein Test fehlgeschlagen ist, sieht aber nie dein Runner-Token oder den Pfad deines lokalen Checkouts.

Zum Ausprobieren registrierst du einen Runner auf einer freien Maschine, pushst ein Change Set mit einem Check, von dem du weißt, dass er flaky ist, und fragst Claude Code, ob es grün ist. Die GitNest-Seite zeigt die Screens für Repository, Change Set und Checks, und die Connected-Seite beschreibt das Freigabe-Panel.