Come far leggere a Claude Code i check di GitNest e proporre un nuovo tentativo che approvi tu in osFoundry

Alla fine di questa guida puoi chiedere a Claude Code "il change set di checkout è verde?" e ricevere una risposta letta da osFoundry, non indovinata dai tuoi test locali. Claude Code elenca i check sul commit composto del change set, ti dice quale è fallito e, se sembra instabile (flaky), richiede un nuovo tentativo solo per quel check. Il retry non parte quando lo chiede Claude Code. Arriva in osFoundry come scheda "Retry GitNest check" con la versione del change set e il commit esatto, e viene eseguito solo quando fai clic su Approve retry. Chi fa cosa Claude Code osFoundry Accesso Il suo login sulla tua macchina La connessione che hai approvato una volta per un workspace, con gli scope osfoundry:read e osfoundry:write Quale repository Sceglie tra quelli che il server elenca Solo repository GitNest assegnati a un progetto di cui fa parte la connessione Leggere i check list_gitnest_checks su un change set Restituisce uno stato limitato per il commit composto attuale del change set Eseguire i check Mai Li eseguono le tue macchine runner registrate. osFoundry non esegue il tuo codice Ritentare un check propose_gitnest_check_rerun, marcato come distruttivo, quindi Claude Code ti chiede prima Una scheda sotto "Needs your approval" (in attesa della tua approvazione). Approve retry rimette in coda quel singolo check concluso Cosa viene ricontrollato Niente Al momento dell'approvazione: accesso al repository, versione del change set, commit e stato del check Configurazione 1. Aggiungi osFoundry a Claude Code $ claude mcp add --transport http -s user osfoundry https://api.osfoundry.io/api/v1/external-mcp La CLI di osFoundry stampa la stessa riga con osfoundry agent connect claude --print. In Claude Code esegui /mcp, scegli osfoundry e poi Authenticate. Il browser apre osFoundry e scegli un workspace. Da lì gli strumenti compaiono come mcp__osfoundry__…. 2. Verifica che il repository abbia dei check e un runner Un check mai eseguito non si può né leggere né ritentare. In GitNest apri la pagina delle impostazioni del repository. Qui contano due pannelli: Check runners: "Checks run on your machine, not ours — osFoundry never executes your code on its own infrastructure." (i check girano sulla tua macchina, non su quelle di osFoundry). Register runner ti dà un token una sola volta e il comando per avviarlo, OSF_RUNNER_TOKEN=… osfoundry-runner --api https://api.osfoundry.io. Senza runner, il pannello avvisa "Checks will stay queued until one is." Required checks: nomi presi da .osfoundry/checks.yaml. "A change set cannot merge until every check named here has passed on its commit." 3. Metti il repository in un progetto, e la connessione nello stesso progetto In GitNest, la sezione Project del repository dice "Connected agents in this project can use approved GitNest read tools when their connection owner still has repository access." Solo il proprietario del repository vede il selettore. Scegli un progetto e osFoundry conferma "Repository project updated". Poi apri l'icona della chiave → Connected, seleziona la connessione di Claude Code e, sotto Projects, aggiungila a quel progetto. Esempio: Aggiunta della connessione di Claude Code al progetto che contiene il repository Sotto Tools, nello stesso pannello, "All supported tools are on by default." Quelli usati in questa guida compaiono come list gitnest work, list gitnest checks, list gitnest saved results, read gitnest work e propose gitnest check rerun. Per lasciare a Claude Code la sola lettura dei check, togli la spunta a propose gitnest check rerun e fai clic su Save tools. Un'esecuzione reale I nomi di strumenti e argomenti sono quelli che il server di osFoundry restituisce da tools/list. Repository, change set, ID, nomi dei check e risposte sono contenuti di esempio. 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 chiede conferma prima della chiamata propose perché lo strumento è annotato con destructiveHint: true. È la sua richiesta di permesso, separata dall'approvazione in osFoundry. Prima di approvare, guarda il change set. Nella sua pagina di revisione in GitNest, il pannello dei check sta sopra le schede e riassume il commit composto in una riga, qui "Checks did not pass: e2e", con ogni check e il suo stato sotto. Un change set non ancora composto non mostra alcun pannello, e un commit senza check mostra "No checks have run against this commit" invece di una spunta. La campanella mostra " proposes retrying a GitNest check". In icona della chiave → Connected → la tua connessione → Needs your approval, la scheda riporta: 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 ] Esempio: Una proposta Retry GitNest check sotto Needs your approval "Review change set before approving" apre la stessa pagina di revisione. Se il commit sulla scheda è quello che hai controllato, fai clic su Approve retry. Il check e2e torna in coda per quel commit e il tuo runner lo prende in carico. Poi avvisa Claude Code, che richiama list_gitnest_checks. Dove sta il limite Il retry indica un commit, non un branch. propose_gitnest_check_rerun richiede expected_change_set_version e expected_composition_oid, quindi la scheda dice sempre quale commit composto Claude Code ha visto fallire. Se qualcuno ricompone il change set mentre la scheda è in attesa, il commit che approveresti non è più quello sulla scheda. osFoundry ricontrolla versione, commit e stato del check al clic, e una scheda non aggiornata non viene eseguita. Il pannello mostra allora "Could not decide this proposal. Its access may have changed." Chiedi a Claude Code di rileggere i check e di proporre sul nuovo commit. Si può ritentare solo un check concluso. La descrizione dello strumento dice "retry one finished check", e lo stato del check fa parte del ricontrollo. Un check già di nuovo in coda o in esecuzione, perché qualcun altro l'ha ritentato o il change set è stato ricomposto, non viene messo in coda una seconda volta. Un check per proposta. check_name è una sola stringa di massimo 200 caratteri. Ritentare l'intera suite richiede una scheda per check, ognuna decisa da te. Così il retry di un e2e instabile non rilancia di nascosto una scansione di sicurezza che preferisci lasciare fallita. In questo percorso niente gira sulle macchine di osFoundry né modifica il codice. I check girano sui runner che hai registrato. Approvare un retry rimette in coda un check, e basta. Non ricompone, non fa merge e non pubblica. Il merge aspetta comunque che ogni check obbligatorio passi sul commit. Le letture restano essenziali. list_gitnest_checks restituisce uno stato limitato solo per il commit composto attuale. list_gitnest_saved_results e read_gitnest_work escludono i binding locali e le credenziali, quindi Claude Code può dirti che un test è fallito, ma non vede mai il token del runner né il percorso del tuo checkout locale. Per provarlo, registra un runner su una macchina libera, fai push di un change set con un check che sai essere instabile e chiedi a Claude Code se è verde. La pagina di GitNest mostra le schermate di repository, change set e check, e la pagina Connected descrive il pannello di approvazione.