Werkzeuge bauen

Entwurf und Veröffentlichen

Alles, was ein Werkzeug ändert, geht in den Entwurf. Live schaltet es ein Mensch.

Das Repository der Werkzeuge hat zwei Stände: den veröffentlichten (Zweig main) und den Entwurf (Zweig draft). Der veröffentlichte Stand ändert sich nur durch Veröffentlichen. Alles andere schreibt in den Entwurf: dein git push, der Agent über MCP und ein installiertes Paket.

In den Entwurf schreiben

Mit Git:

git pull --rebase origin draft
# Dateien ändern
git add . && git commit -m "aufgaben: Filter nach Status"
git push origin draft

Über MCP schreibt der Agent mit scaffold_tool und put_tool_files direkt in den Entwurf. put_tool_files ersetzt genau die Dateien, die der Agent schickt. Er liest eine Datei deshalb zuerst mit read_tool_file.

Ein Push nach main weist die Instanz ab, mit jedem Token.

Den Entwurf ansehen

Der Entwurf eines Werkzeugs steht unter /t/<name>@draft/. Im Übungsraum führt die Seite Werkzeuge deine Entwürfe unter Entwürfe auf.

• Du siehst einen Entwurf, den du angemeldet gepusht oder über MCP geschrieben hast, sofort und ohne Grant.
• Andere sehen ihn nur, wenn eine ihrer Rollen einen Grant auf das Werkzeug hat. Das gilt auch für Administratorinnen und Administratoren.

Die Instanz setzt über jede Entwurfsseite ein Banner. Es sagt, dass der Stand nicht veröffentlicht ist und in welchem Raum er arbeitet.

Prüfen, ob der Stand veröffentlichbar ist

check_tool prüft ein Werkzeug gegen dieselben Regeln wie das Veröffentlichen und ändert nichts. Die Antwort nennt Datei, Grund und den Text, der einzutragen ist.

Ein Entwurf darf weniger als ein veröffentlichter Stand: uses in tool.json darf fehlen. Lass den Agenten check_tool aufrufen, bevor du jemanden um das Veröffentlichen bittest.

Was ein Push abweist

Die Instanz prüft jeden Stand, bevor er gilt. Der Grund steht in deinem Terminal, mit Datei.

• etwas, das wie ein Zugriffstoken aussieht, in irgendeiner Datei irgendeines Commits. Es in einem späteren Commit zu löschen genügt nicht: Schreibe die Commits vor dem Push um und widerrufe das Token.
• ein Inline-Skript
• eine Dateiart, die die Instanz nicht ausliefert, oder ein symbolischer Link
• eine Datei über 5 MB, ein Werkzeug über 20 MB oder mit mehr als 200 Dateien
• ein Werkzeugname mit anderen Zeichen als Kleinbuchstaben, Ziffern und Bindestrichen
• ein Push, der den Entwurf umschreibt (git push -f)

Nennt der Code eine Collection, die in uses fehlt, steht im Terminal eine Zeile note:. Der Push geht trotzdem durch.

Zwei Wege, ein Repository

Dein Klon erfährt nicht, wenn der Agent über MCP oder eine Kollegin per Push in den Entwurf schreibt. Ein Push von einem veralteten Stand scheitert dann. Hole deshalb den Entwurf, bevor du Dateien änderst:

git pull --rebase origin draft

Einen echten Konflikt gibt es nur, wenn zwei dasselbe Werkzeug ändern. Du löst ihn in deinem Klon.

Veröffentlichen

Veröffentlichen tut ein Mensch mit Adminrechten, im Adminbereich unter Betrieb, Auslieferung (/admin/tools), mit Entwurf veröffentlichen. Weder ein Token noch der Agent können das.

• Veröffentlichen übernimmt den ganzen Entwurf. Was sonst noch darin steht, geht mit live.
• Live geht genau der Stand, den du ausprobiert hast. Die Instanz kopiert nichts um.
• Jedes geänderte Werkzeug braucht dafür uses in tool.json.
• Warten Schemaänderungen aus dem Übungsraum noch auf die Produktion, weist die Seite darauf hin. Ein Werkzeug, das sie braucht, bricht, bis jemand sie appliziert hat.

Danach steht das Werkzeug unter /t/<name>/. Andere sehen es erst, wenn eine Rolle einen Grant darauf hat (Werkzeuge freigeben). Ein Grant auf das Werkzeug sagt nichts über Daten: Die Rolle braucht auch das Recht auf die Collections.