Skip to content

Anthropic built Scion for itself. Carbon Forge is yours →

Carbon Forge
Menu

Anleitung

Landing-Regeln: Code-Owner im Datensatz, mit einem AEGIS-Workflow als Gate

Eine CODEOWNERS-Datei nennt Reviewer, aber die Freigabe lebt auf einer Forge und hängt an einer Änderung, die sich seitdem bewegt haben kann. Carbon Forge hält die Regel und die Freigaben im Datensatz, gebunden an die genaue Änderung, und lässt einen Workflow einer der Freigebenden sein.

Auch auf: English, Español, Português, 日本語, Français, 한국어, 简体中文, Italiano, हिन्दी · Alle Anleitungen auf Deutsch

Offenlegung: Wir entwickeln Carbon Forge und daneben AEGIS bei 100monkeys.ai, lesen Sie dies also als Bericht des Herstellers. Einer unserer KI-Agenten hat diese Anleitung aus der öffentlichen Dokumentation (auf Englisch) entworfen, vor allem Schritt 8 von Working in lanes, Source control settings, MCP tools catalog: Lanes, continued und Source control: how it is built and why, das Unternehmen hat sie geprüft; diese deutsche Fassung ist eine Übersetzung der englischen Originalanleitung. Die Tabelle, die Aufrufe und die Ablehnung sind die der Dokumentation. Wo die Dokumentation eine Frage offenlässt, sagt es der letzte Abschnitt.

Warum die Regel in den Datensatz gehört

Die Dokumentation begründet es in zwei Sätzen: "Landing rules are the code-owners rule kept in the record. The approvers a path needs are named on a page of the workspace, and each approval binds to the lane's composition hash, so review is the record's and not a forge's." (Landing-Regeln sind die Code-Owner-Regel, im Datensatz gehalten. Die Freigebenden, die ein Pfad braucht, stehen auf einer Seite des Workspace, und jede Freigabe bindet sich an den Composition-Hash der Lane, sodass das Review dem Datensatz gehört und nicht einer Forge.) Ohne das kann "a landing can carry code no approver saw." (ein Landen Code mitbringen, den kein Freigebender gesehen hat.) Eine Grenze vorab: "Carbon runs no review itself." (Carbon führt selbst kein Review durch.) Es hält fest, wer was freigegeben hat; das Prüfen machen Menschen und die Workflows, die Sie benennen.

Schritt 1. Den Trunk schützen

Regeln werden nur auf einem geschützten Trunk gelesen. Eine Workspace-Administratorin setzt Protect the trunk unter Settings, Workspace, Source control, und optional Protect pages and atoms too. Ein Agent prüft die Einstellung mit:

workspaces.get_settings {}
→ { "workspaceId": "…", "trunkProtected": true, "trunkProtectedEntities": false }

Von da an "the trunk moves only by a lane's landing" (bewegt sich der Trunk nur durch das Landen einer Lane), und ein direkter Schreibzugriff wird abgelehnt mit workspace <slug> protects its trunk: the trunk lands by lanes.land only; write on a lane.

Schritt 2. Die Seite .landing-rules schreiben

Legen Sie eine Seite unter dem reservierten Pfad .landing-rules an, deren erste Markdown-Tabelle die Kopfzeile glob | approvers | gate hat. Das Beispiel der Dokumentation:

| glob | approvers | gate |
| --- | --- | --- |
| app/src/billing/** | <user id>, <user id> | |
| docs/** | <user id> | docs-review |

Nur eine Workspace-Administratorin schreibt diese Seite, auf dem Trunk oder auf einer Lane; alle anderen werden abgelehnt mit The landing rules page .landing-rules is reserved: only a workspace admin writes it.

Schritt 3. Prüfen, dass der Server sie als gültig liest

Der Abschnitt Landing rules im Einstellungsdialog meldet <n> rules, valid. oder nennt eine fehlerhafte Zeile mit Every landing is refused until it is fixed. Eine Zeile, die ein Nichtmitglied nennt oder weder einen Freigebenden noch ein Gate, ist fehlerhaft. Eine kaputte Seite stoppt jedes Landen, prüfen Sie das also, bevor Sie sich darauf verlassen.

Schritt 4. Die Arbeit auf einer Lane erledigen

Öffnen Sie eine Lane und schreiben Sie darauf, wie Working in lanes es zeigt. Beim Landen wird jeder Pfad, den die Lane berührt, gegen jede Zeile geprüft: eine Seite über ihren Pfad, eine verschobene Seite über beide Pfade, eine Tree-Datei als <tree path>/<entry path>.

Schritt 5. Lesen, was der Lane noch fehlt

lanes.create { "label": "agent/7/fix-login" }
lanes.get { "label": "agent/7/fix-login" }
lanes.export { "lane": "agent/7/fix-login" }   // header line: # composition: <hash>
lanes.approve { "lane": "agent/7/fix-login" }

lanes.get listet, wer freigegeben hat, wer fehlt und ob jedes Gate pending oder satisfied ist. In der App zeigt die Übersicht einer Lane dasselbe: die Regeln, auf die sie passt, freigegeben n von m, und eine Freigabe durch ein Gate mit dem Vermerk "via gate <workflow>".

Schritt 6. Die genaue Änderung freigeben

Eine Reviewerin liest lanes.export, einen einzigen Unified Diff mit der Kopfzeile # composition: <hash>, und ruft dann lanes.approve auf. Die Freigabe bindet sich an diesen Hash, also hat "a reviewer who reads the export and approves at its # composition: value has approved exactly that change." (wer den Export liest und bei seinem # composition:-Wert freigibt, genau diese Änderung freigegeben.) Jeder spätere Patch, jede Konfliktlösung oder Trunk-Bewegung, die ändert, was landen würde, ändert den Hash, und frühere Freigaben zählen dann nichts mehr. Geben Sie nach der letzten Änderung frei, nicht davor.

Schritt 7. Den AEGIS-Workflow als Gate freigeben lassen

Ein Gate wird nur vom Workflow selbst erfüllt. Das Token des Laufs wird mit tokens.mint_execution erzeugt, wobei das optionale Argument workflow auf den Namen des Gates gesetzt ist, 1 bis 128 Zeichen; der Lauf ruft dann lanes.approve über dieses Token auf. Der Abgleich ist exakt, "case included" (einschließlich Groß- und Kleinschreibung). "A person's approval, and one given through a token minted without workflow, satisfies no gate." (Die Freigabe einer Person und eine, die über ein ohne workflow erzeugtes Token gegeben wird, erfüllt kein Gate.) Das Ausführungstoken ist ein Kind des Tokens des Aufrufers, beschränkt auf einen Workspace, einen Tree-Pfad, eine Lane, eine Werkzeugliste und höchstens einen Tag. Mit AEGIS by 100monkeys.ai, in beta, ist das Gate ein Workflow, den Sie selbst schreiben: Die Zeile nennt ihn, und Carbon Forge prüft nur, dass ein Lauf davon freigegeben hat.

Schritt 8. Landen

lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links", "dry_run": true }
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links" }

Ein Landen, dem Freigaben fehlen, wird als Ganzes abgelehnt und nennt, was fehlt:

Lane <label> touches <path> under landing rule <glob> (line <n>), which needs approval from <user ids> and gate <name> at the lane's current composition. Approve with lanes.approve; nothing was written.

Wenn es landet, "follow its intent as Approved-by: lines" (folgen die verbrauchten Freigaben, die des Gates eingeschlossen, seiner Absicht als Approved-by:-Zeilen), und das Changeset wird wie jedes andere versiegelt. Beachten Sie, dass ein Landen mit dry_run die Regeln nicht prüft; lesen Sie dafür lanes.get.

Was die Dokumentation offenlässt

Verwandte Anleitungen

Halten Sie das Review im Datensatz.