So lässt du einen Claude-Chat GitNest-Codeänderungen vorschlagen, die du in osFoundry freigibst

Am Ende dieser Anleitung kann eine Claude-Unterhaltung, die mit osFoundry verbunden ist, ein GitNest-Repository lesen, seinen Code durchsuchen und Änderungen daran vorbereiten: eine Aufgabe, einen Datei-Commit, ein Change Set, die Wiederholung eines Checks, einen Pull Request. Nichts davon passiert, wenn Claude danach fragt. Alles landet als Vorschlag unter "Needs your approval" (wartet auf deine Freigabe) in osFoundry, mit Dateien, Branch und exaktem Commit auf der Karte, und läuft erst, wenn du auf Approve klickst. Claude hat kein Tool, das selbst ins Repository schreibt.

Wer macht was

	Claudes Seite	osFoundrys Seite
Login	Dein Claude-Konto, unverändert	Dein osFoundry-Konto hat die Verbindung einmal genehmigt
Was sichtbar ist	Was die Lese-Tools zurückgeben	GitNest-Repositories, die einem Projekt zugeordnet sind, in dem die Verbindung ist
Code lesen	search_gitnest_code: begrenzte Zeilenausschnitte	Keine Binärdateien, keine kompletten Dateien, keine Zugangsdaten oder lokalen Bindungen
Code ändern	Sieben propose_gitnest_…-Tools	Ein Vorschlag pro Aufruf, der auf dich wartet
Wer freigibt	Niemand auf Claudes Seite	Du als Eigentümer der Verbindung, solange du die Repository-Rolle noch hast
Wer schreibt	Niemand	osFoundry führt die freigegebene Aktion aus, der Verbindung zugeordnet
Provider-Tokens	Werden nie gesendet	Dein verknüpftes GitHub-/GitLab-Konto wird nur genutzt, wenn du einen Provider-PR freigibst

Einrichtung

1. Den Chat einmal verbinden

Ist der Claude-Chat noch nicht mit osFoundry verbunden, ist dieser Teil der normale Ablauf für einen Custom Connector: Lege unter dem Schlüssel-Symbol → Connected eine Verbindung an, füge ihre Serveradresse in Claude als Custom Connector hinzu und genehmige einen Workspace. Anthropic beschreibt die Claude-Seite in seinem Leitfaden zu Custom Connectors. Der Rest dieser Anleitung geht davon aus, dass bei der Verbindung "Connected." steht.

2. Das Repository in ein Projekt legen

Eine Verbindung sieht ein GitNest-Repository nie von sich aus. Das Repository muss zu einem Projekt gehören, in dem die Verbindung ist.

Öffne das Repository in GitNest und such den Abschnitt Project. Dort steht "Connected agents in this project can use approved GitNest read tools when their connection owner still has repository access." Nur der Eigentümer des Repositorys bekommt die Auswahl, alle anderen sehen den Projektnamen als reinen Text. Wähle das Projekt. osFoundry bestätigt mit "Repository project updated."

3. Die Verbindung zu diesem Projekt hinzufügen

Zurück unter Schlüssel-Symbol → Connected wählst du die Verbindung aus und fügst sie unter Projects demselben Projekt hinzu. Die GitNest-Repositories des Projekts kommen damit mit, zusammen mit seinen Notizen, Wissensdatenbanken und anderen synchronisierten Inhalten.

Öffne Tools. "All supported tools are on by default", und die Liste zeigt jedes Tool mit Leerzeichen statt Unterstrichen. Die für GitNest sind:

read gitnest repository        propose gitnest work
search gitnest code            propose gitnest change set
list gitnest work              propose gitnest server composition
read gitnest work              propose gitnest file import
list gitnest saved results     propose gitnest check rerun
list gitnest checks            propose gitnest native publication
                               propose gitnest provider publication

Beispiel: Die Tools-Checkliste einer Claude-Verbindung, standardmäßig alle aktiv

Wenn Claude bei Commits aufhören und nie einen Pull Request vorbereiten soll, entferne die Haken bei den beiden Publication-Tools und klick auf Save tools. Vorschläge brauchen so oder so deine Freigabe. Ohne Haken kann Claude nur gar nicht erst darum bitten.

4. Im Chat fragen

Aktiviere in der Claude-Unterhaltung den osFoundry-Connector über das Menü + → Connectors und formuliere deine Bitte ganz normal. Hast du denselben Server in Claude Code unter dem Namen osfoundry hinzugefügt, erscheinen die Tools dort als mcp__osfoundry__propose_gitnest_file_import und so weiter.

Ein echter Durchlauf

Die Tool- und Argumentnamen unten sind die, die der osFoundry-Server in tools/list aufführt. Repository, Prompts, IDs und Antworten sind Beispielinhalte.

Beispiel

Du: Füge in osFoundry zu demo-api eine CONTRIBUTING.md hinzu, die erklärt,
    wie man die Tests ausführt (sie nutzen pytest in tests/), und leg eine
    Aufgabe mit niedriger Priorität an, sie aus der README zu verlinken.

Claude → list_granted_resources {}
       ← Projekt "API" · GitNest-Repository "demo-api"
Claude → read_gitnest_repository {"repository_id": "…"}
       ← natives Repository, Standard-Branch main
Claude → search_gitnest_code {"repository_id": "…", "query": "pytest", "branch": "main"}
       ← pyproject.toml: [tool.pytest.ini_options] · tests/test_limits.py: import pytest
Claude → propose_gitnest_file_import {"repository_id": "…", "branch": "main",
           "message": "Add CONTRIBUTING.md with test instructions",
           "files": [{"path": "CONTRIBUTING.md", "content": "# Contributing\n…"}],
           "idempotency_key": "…"}
       ← Vorschlag wartet auf den Eigentümer
Claude → propose_gitnest_work {"repository_id": "…",
           "title": "Link CONTRIBUTING.md from README", "priority": "low",
           "idempotency_key": "…"}
       ← Vorschlag wartet auf den Eigentümer

Claude: Ich habe zwei Vorschläge in osFoundry vorbereitet: einen Commit, der
        CONTRIBUTING.md zu main hinzufügt, und eine Aufgabe, sie aus der README
        zu verlinken. Noch ist nichts committet. Beide warten auf deine Freigabe.

In osFoundry zeigt die Kopfzeile "Claude research proposes GitNest file changes", und das Panel der Verbindung listet beide unter "Needs your approval". Auf der Commit-Karte steht "Commit GitNest files in demo-api", dann "Commit to branch: main", die Commit-Nachricht und ein eingeklapptes "Review all proposed files (1)", das sich zur vollständigen CONTRIBUTING.md aufklappen lässt. Darunter: "Expires …", Approve and create, Decline.

Beispiel: Ein GitNest-Publish-Vorschlag unter Needs your approval

Ein zweiter Prompt, zu einem Change Set, das schon existiert:

Beispiel

Du: Ist das Rate-Limit-Change-Set grün? Wenn integration fehlgeschlagen ist,
    wiederhol den Check, und sobald er durchläuft, bereite es als Pull Request vor.

Claude → list_gitnest_work {"repository_id": "…", "kind": "changes"}
       ← "Rate-limit fix" · Version 3
Claude → list_gitnest_checks {"repository_id": "…", "change_set_id": "…"}
       ← zusammengesetzter Commit 9c1e47a…: unit bestanden · integration fehlgeschlagen (beendet)
Claude → propose_gitnest_check_rerun {"repository_id": "…", "change_set_id": "…",
           "check_name": "integration", "expected_change_set_version": 3,
           "expected_composition_oid": "9c1e47a…", "idempotency_key": "…"}
       ← Vorschlag wartet auf den Eigentümer
  … du gibst die Wiederholung frei, sie läuft durch …
Claude → propose_gitnest_native_publication {"repository_id": "…", "change_set_id": "…",
           "expected_change_set_version": 3,
           "expected_composition_oid": "9c1e47a…", "idempotency_key": "…"}
       ← Vorschlag wartet auf den Eigentümer

Achte darauf, was Claude mitschicken muss. Die Wiederholung und die Publication nennen beide die Version des Change Sets und den zusammengesetzten Commit, den Claude gesehen hat. Setzt jemand das Change Set neu zusammen, bevor du klickst, ist die Version oder der Commit, den du freigeben würdest, nicht mehr der auf der Karte, und osFoundrys erneute Prüfung bei der Freigabe verweigert die Ausführung.

Was jede Karte dich freigeben lässt

Tool	Kartentitel	Button	Was die Freigabe bewirkt
propose_gitnest_work	Create GitNest work	Approve and create	Legt ein Todo und ein GitNest-Work-Item an
propose_gitnest_change_set	Create GitNest draft change set	Approve and create	Erstellt ein Draft-Change-Set aus gespeicherten Run-Ergebnissen. Nichts wird zusammengesetzt oder veröffentlicht
propose_gitnest_server_composition	Compose GitNest change set	Approve and create	Setzt das Change Set auf dem Server zusammen, nachdem seine Version erneut geprüft wurde
propose_gitnest_file_import	Commit GitNest files	Approve and create	Committet bis zu 20 UTF-8-Dateien (insgesamt 200 KB) auf den Branch auf der Karte
propose_gitnest_check_rerun	Retry GitNest check	Approve retry	Stellt einen beendeten Check für diese Version und diesen Commit erneut in die Warteschlange
propose_gitnest_native_publication	Publish GitNest pull request	Approve and publish	Erstellt einen Publication-Branch und öffnet einen Pull Request im nativen Repository
propose_gitnest_provider_publication	Open a draft GitHub or GitLab pull request	Approve and publish	Pusht nur den Branch dieses Change Sets mit deinem verknüpften Provider-Konto und öffnet einen Draft-PR

Karten, die sich auf ein Change Set beziehen, tragen "Change set: … · expected version N", "Reviewed commit: …" und einen Link "Review change set before approving", der es in GitNest öffnet. Die beiden Publication-Karten haben zusätzlich je eine Zeile dazu, was passieren wird, z. B. "Approval creates a publication branch and opens a pull request in this native repository."

Wo die Grenze liegt

Claudes Verbindung kann nicht in GitNest schreiben. GitNests eigene Schreibrouten lehnen Zugriffe mit Agent-Scope ab (denyAgentScope in osFoundrys GitNest-Routen), und die Connected-Tools rufen sie nicht auf. Ein Claude-Chat kann nur einen Vorschlag einreichen, und osFoundry führt die Aktion nach deiner Freigabe selbst aus, protokolliert mit der Verbindung als Quelle. So gibt es für jeden Schreibvorgang eines Agenten nur einen Weg, und den kannst du prüfen.

Die Freigabe wird im Moment des Klicks noch einmal geprüft. osFoundry kontrolliert erneut, dass die Verbindung noch aktiv ist, dass das Repository noch in einem Projekt liegt, zu dem die Verbindung gehört, dass du die Repository-Rolle noch hast und dass der Vorschlag nicht abgelaufen ist. Bei Composition, Wiederholung oder Publication prüft es außerdem Version und Commit des Change Sets, bei der Publication zusätzlich die Risiko-Richtlinie des Repositorys, die Pflicht-Checks und den Ziel-Branch. Ein abgelehnter, abgelaufener oder veralteter Vorschlag läuft nicht. Jedes Propose-Tool nimmt einen idempotency_key, sodass ein Aufruf, den Claude nach einer verlorenen Antwort wiederholt, keine zweite Anfrage ist.

Hier wird nichts deployt. Weiter als bis zu einem Pull Request kommt ein Vorschlag nicht: ein nativer GitNest-PR oder ein Draft-PR auf GitHub oder GitLab. Den Merge, und alles, was ein Merge auslöst, entscheidest du in GitNest oder beim Provider.

Dein Token für den Git-Provider erreicht Claude nie. Ein Provider-PR nutzt zum Zeitpunkt der Freigabe das Konto, das du in osFoundry verknüpft hast, und pusht nur den dedizierten Branch des Change Sets, nie deine anderen Refs.

Lesezugriffe sind bewusst begrenzt. search_gitnest_code liefert gedeckelte Zeilenausschnitte, nie Binärdateien oder ganze Dateien. Beim Lesen von Work, Runs und gespeicherten Ergebnissen fallen lokale Bindungen und Zugangsdaten weg. Um eine bestehende Datei zu ändern, füg ihren aktuellen Inhalt in den Chat ein, damit Claude die komplette neue Version vorschlagen kann. Neue Dateien hinzufügen klappt direkt auf Basis der Ausschnitte.

Als Nächstes

Probier zuerst den kleinsten Schreibvorgang: Lass Claude eine einzige neue Datei vorschlagen, etwa eine CONTRIBUTING.md, öffne dann die Karte und klapp "Review all proposed files" auf, bevor du freigibst. Wie GitNest selbst Clone, Push und Access Tokens handhabt, steht auf der GitNest-Featureseite.