Auch auf: English, Español, Português, 日本語, Français · Alle Anleitungen auf Deutsch
Offenlegung: Wir entwickeln Carbon Forge bei 100monkeys.ai, lesen Sie dies also als Bericht des Herstellers. Einer unserer KI-Agenten hat diese Anleitung aus der öffentlichen Dokumentation entworfen, vor allem aus den Abschnitten zu symbols.drift und Governed seams in MCP tools catalog: Semantics und aus „Drift between prose and code“ in The Carbon paradigm; das Unternehmen hat sie geprüft. Diese deutsche Fassung ist eine Übersetzung der englischen Originalanleitung. Tabelle und Aufrufe sind die Beispiele der Dokumentation selbst; Zitate stehen auf Englisch mit der Übersetzung daneben. Wo die Dokumentation eine Frage offenlässt, sagt es der letzte Abschnitt.
Was der Bericht ist
Die Paradigma-Seite in einem Satz: "A workspace's reserved .governed-seams page declares which pages govern which definitions of a code tree" (die reservierte Seite .governed-seams eines Workspace erklärt, welche Seiten welche Definitionen eines Codebaums steuern). symbols.drift "joins every definition a lane adds, removes or re-signs to the seams that govern it and reports each as changed with or without a patch to its governing page on the same lane, from the syntax index alone, so the same lane and the same seams page answer the same report byte for byte." (verknüpft jede Definition, die eine Lane hinzufügt, entfernt oder deren Signatur sie ändert, mit den Seams, die sie steuern, und meldet jede als geändert mit oder ohne Patch an ihrer steuernden Seite auf derselben Lane, allein aus dem Syntaxindex; dieselbe Lane und dieselbe Seams-Seite ergeben Byte für Byte denselben Bericht.) Kein Modell liest irgendetwas. Und eine Grenze, die man festhalten sollte: "The report advises and never refuses a landing." (Der Bericht berät und verweigert nie ein Landen.)
Schritt 1. Die Definitionen wählen, die eine Seite beschreibt
Beginnen Sie mit den Seiten, die Lesende in die Irre führen würden, wenn sich der Code unter ihnen bewegt: eine Architekturseite zur Abrechnung, eine Anleitung zur Anmeldung. Finden Sie die Definitionen, die sie beschreiben, mit dem semantischen Index:
symbols.search { "tree": "app", "query": "charge", "prefix": true } Definitionen stammen aus den Tags-Abfragen von tree-sitter für TypeScript und TSX, JavaScript, Python, Go, Rust, C, C++, C#, Java, Ruby, PHP, Scala und Bash. CSS, HTML, JSON, YAML, TOML und HCL bekommen Syntaxbäume, "but no definitions or references" (aber keine Definitionen oder Referenzen), ein Seam über solchen Dateien meldet also nichts. Namen werden "matched by name, not by type checking" (über den Namen abgeglichen, nicht per Typprüfung).
Schritt 2. Die Seite .governed-seams schreiben
Legen Sie unter dem reservierten Pfad .governed-seams eine Seite an, deren erste Markdown-Tabelle die Kopfzeile tree | glob | symbols | records hat. Das Beispiel der Dokumentation:
| tree | glob | symbols | records |
| --- | --- | --- | --- |
| app | src/billing/** | chargeCard, refund | architecture/billing |
| app | src/auth/*.ts | * | guides/login, architecture/security | tree: der Pfad eines Codebaums.glob: eine Regel in der Ignore-Regel-Syntax des Imports über die Dateipfade des Baums, nicht beginnend mit!.symbols: kommagetrennte Definitionsnamen, oder*allein für jede Definition unter dem Glob.records: kommagetrennte Seitenpfade, die Seiten, die diese Definitionen steuern.
"A seam is declared, never inferred: no link, tag, metadata key or embedding makes one." (Ein Seam wird deklariert, nie erschlossen: Kein Link, Tag, Metadatenschlüssel oder Embedding erzeugt einen.) Die Seite wird vom Trunk gelesen, "so a lane cannot ungovern its own change." (daher kann eine Lane ihre eigene Änderung nicht der Steuerung entziehen.) Landen Sie sie auf dem Trunk, bevor die Arbeit beginnt, die sie überwachen soll. Eine fehlerhafte Seite stoppt jeden Bericht, bis sie korrigiert ist, mit einem Satz, der die Zeile nennt: The governed seams page .governed-seams is malformed at line <n>, ...
Schritt 3. Gesteuerten Code auf einer Lane ändern
Der Bericht liest eine Lane, die Änderung muss also auf einer liegen: lanes.create, dann trees.apply_patch oder trees.put mit lane, wie Working in lanes zeigt. Ändern Sie etwa die Signatur von chargeCard, indem Sie einen Parameter hinzufügen.
Schritt 4. Den Drift-Bericht lesen
symbols.drift { "lane": "agent/7/fix-login" } Fügen Sie tree hinzu, um nur einen Baum zu lesen. Die Antwort:
{ lane, composition_hash, report_sha256, findings, pending, governed_rows } Jeder Befund nennt tree, path, symbol und kind, die from_signature auf dem Trunk und die to_signature auf der Lane (null, wo eine Seite sie nicht enthält), records als { path, updated_on_lane } und callers, die Zahl der Referenzen auf den Namen auf der Lane. Die class ist das Urteil: seam_changed_without_record, wenn die Lane keinen aktiven Patch an einer steuernden Seite hält. Das ist Ihre veraltete Doku, gefunden vor dem Landen.
Lesen Sie pending, bevor Sie einem leeren Bericht trauen: Es listet geänderte Dateien unter dem Glob eines Seams, die der Index "cannot answer yet" (noch nicht beantworten kann), und "the report is complete when pending is empty." (der Bericht ist vollständig, wenn pending leer ist.) Eine Lane mit Konflikt wird abgewiesen, bis der Konflikt gelöst ist.
Schritt 5. Die steuernde Seite auf derselben Lane aktualisieren
Bearbeiten Sie architecture/billing mit pages.apply_patch und derselben lane, damit Seite und Code gemeinsam warten. Die Anleitung Land a code change and its documentation in one changeset (auf Englisch) geht diesen Teil durch.
Schritt 6. Den Bericht erneut lesen, dann landen
Führen Sie symbols.drift erneut aus. Der Befund lautet jetzt seam_changed_with_record, und sein Record zeigt updated_on_lane. Bewahren Sie den Bericht mit dem Review auf: composition_hash ist der Hash der gelesenen Lane-Komposition, und report_sha256 deckt den kanonischen Text des Berichts ab, "so a report is bound to the exact change it read." (so ist ein Bericht an genau die Änderung gebunden, die er gelesen hat.) Ein späterer Patch ändert beide. Landen Sie die Lane dann als ein Changeset.
Weil der Bericht nur berät, liegt die Durchsetzung bei Ihnen. Ein Muster, unseres und nicht das der Dokumentation: Nennen Sie auf einem geschützten Trunk den Glob des gesteuerten Codes in .landing-rules, mit der verantwortlichen Person der steuernden Seite als Freigebende, und lassen Sie sie zuerst den Drift-Bericht lesen.
Was die Dokumentation offenlässt
- Wer
.governed-seamsschreiben darf. Die Dokumentation macht.landing-ruleszur reinen Admin-Sache; zur Seams-Seite sagt sie nur, dass sie vom Trunk gelesen wird, "whoever wrote it" (wer auch immer sie geschrieben hat). - Eine Ansicht in der App. Die Dokumentation beschreibt das Werkzeug und seine Antwort, keine Seite im Browser, die den Bericht zeigt.
- Markdown wird "not parsed yet" (noch nicht geparst), eine Seite kann also selbst nicht die gesteuerte Seite sein.