Gas City (GC) nutzen

GC verwenden

Verwenden Sie Gas City nur, wenn der Aufrufer es explizit auswählt. Behandeln Sie es als austauschbaren Ausführungsadapter, nicht als Korrektheits- oder Abschlussgrenze. Der Adapter kann keine AgentOps-Semantik auswählen, eine verbindliche Entscheidung fällen oder den Factory-Abschluss in einen Liefer- oder Validierungsnachweis verwandeln.

Wählen Sie zuerst die Factory

AgentOps unterstützt sowohl Gas City als auch den Agentic Coding Flywheel als externe Software-Factory-Laufzeiten. Verwenden Sie diese Skill nur für Gas City. Wenn der Aufrufer den Flywheel auswählt, wechseln Sie zu using-flywheel und dessen nativem Workflow, anstatt ihn in Gas City zu verpacken.

AgentOps stellt Skills und Evidence-Verträge für beide Fabriken bereit. Es benötigt keine eigene Gas City-Formel oder Rollenpakete. Installieren oder verknüpfen Sie AgentOps-Skills in der Provider-Laufzeit, bevor Sie Worker starten. Der vorgelagerte Mayor, Koordinator und die Worker können dann plan, implement, test, validate und andere AgentOps-Skills normal erkennen und auswählen.

Gas City 1.4 Betriebsmodell

Gas City 1.4 ist run-zentriert. Der Supervisor bedient das Dashboard und typisierte, paginierte Session/Run-APIs. Jeder Graph-besitzende City- oder Rig-Bereich benötigt einen eigenen core.control-dispatcher; dieser deterministische Worker setzt Formel-Steuerungsperlen fort. Agent-Worker beanspruchen weitergeleitete Arbeit. Der vorgelagerte gc.mayor-Skill ist der geführte Koordinator; gc.run-operator startet und überwacht Formeln.

Der normale AgentOps-Pfad ist:

1. Installieren und pinnen Sie den vorgelagerten gascity-Workflow und die Rig-Rollen-Importe.
2. Fügen Sie das Projekt als Rig hinzu, bereiten Sie seine Standard-Wartungs-Laufzeit vor und machen Sie AgentOps-Skills für seine Provider-Sitzungen sichtbar.
3. Erstellen Sie eine aufrufer-eigene Quell-Intent-Perle und übergeben Sie ihre ID an den Mayor, der die Workflow-Perlen erstellt und die vorgelagerte build-basic-, Fortsetzungs-, Überprüfungs- oder Implementierungsformel versendet, die zu den verfügbaren Artefakten passt.
4. Lesen Sie Run-, Session-, Perlen-, Artefakt- und Entscheidungsstatus. Der Abschluss wird niemals aus Chat- oder Bereichsprosa abgeleitet.

Bereiten Sie ein Rig vor und qualifizieren Sie es vor seinem ersten Build mit der mitgelieferten AgentOps-CLI (kein Repo-Checkout erforderlich):

ao gc prepare --city /path/to/city --rig /path/to/rig
ao gc check --city /path/to/city --rig /path/to/rig

Der Befehl überprüft die exakten offiziellen Workflow- und Rollen-Pins, erstellt einen Schnappschuss der vorgelagerten Validierungsskripte und -schemata unverändert innerhalb des .gc-Laufzeitverzeichnisses des Rigs, installiert nur kleine von AgentOps verwaltete Wrapper an den Formel-Prüfpfaden, wählt ein vorhandenes Python aus, das PyYAML importieren kann, und verknüpft die AgentOps-Skills mit den Codex-Sinks der City und des Rigs. Die Skills stammen aus dem umgebenden AgentOps-Checkout, falls vorhanden, ansonsten aus dem installierten Skills-Stammverzeichnis; übergeben Sie --skills-source, um ein anderes Verzeichnis festzulegen. Es ändert niemals das GC-Binary, den Cache, die Formeln, Rollen oder das vorgelagerte Paket. check gibt nur native Inspektionsbefehle aus, schreibt keine Adapterdateien und schlägt vor dem Modell-Spend fehl, wenn dieser Laufzeitvertrag fehlt oder abgewichen ist.

prepare füttert auch das Codex-Vertrauen für jedes Sitzungsverzeichnis vor, das zum Zeitpunkt der Ausführung existiert – die City- und Rig-Stammverzeichnisse, jedes .gc/agents/**-Sitzungsverzeichnis und jedes Rig-Arbeitsbaumverzeichnis – sodass eine Codex-Sitzung in einem dieser Verzeichnisse nicht durch den interaktiven Vertrauensdialog blockiert wird. Beide persistierten Ebenen werden in $CODEX_HOME/config.toml vorgefüllt: Arbeitsbereichsvertrauen ([projects."<dir>"] trust_level = "trusted"), ohne das Codex stillschweigend meldet, dass dieses Verzeichnis überhaupt keine Hooks hat, und Pro-Hook-Vertrauen ([hooks.state."<hooks.json>:<event>:<m>:<h>"] trusted_hash = "sha256:..."), nach dem das Pakets per-Provider .codex/hooks.json sonst fragen würde. Hook-Digests werden aus Codex' eigenem hooks/list gelesen, niemals neu berechnet.

Vertrauen wird nach Wert beurteilt, nicht nach dem Vorhandensein einer Tabelle. prepare hängt nur fehlende Einträge an und weigert sich, den Eintrag zu benennen, wenn einer existiert, aber kein Vertrauen gewährt – ein explizites trust_level = "untrusted", ein Hook, den Codex als seit seiner Vertrauenswürdigkeit geändert meldet, ein aufgezeichneter Hook, den Codex immer noch ablehnt, oder ein Hook, der als enabled = false aufgezeichnet ist (ein deaktivierter Hook ist kein vertrauenswürdiger funktionierender Hook). Es überschreibt niemals eine Betreiberentscheidung, und eine erneute Ausführung ist ein No-Op. Es schlägt auch fehl, anstatt fortzufahren, wenn Codex eine leere oder nicht erkannte Hook-Liste zurückgibt. Der Vertrauensspeicher selbst wird niemals direkt bearbeitet: Der zusammengeführte Inhalt wird zuerst im Speicher geparst, dann mit dem dauerhaften atomaren Writer der CLI installiert, sodass kein Fehlerpfad eine teilweise geschriebene Codex-Konfiguration hinterlassen kann.

ao gc check überprüft dieselbe Vorbelegung nur aus lokalem Zustand – es führt keinen Codex-Subprozess aus und schreibt nichts, leitet jeden erwarteten Hook-Schlüssel vom eigenen hooks.json des Verzeichnisses ab – und benennt das spezifische defiziente Verzeichnis oder den Hook unter Verwendung derselben Regel, die prepare vorfüllt.

Zwei benannte Einschränkungen.

1. check kann einen veralteten Hash nicht erkennen. Da es Codex niemals fragt, wird ein aufgezeichneter trusted_hash, der nicht mehr mit dem aktuellen Inhalt des Hooks übereinstimmt, als erfüllt gelesen und löst in einer echten Sitzung immer noch den Vertrauensdialog aus. Nur prepare sieht das – Codex meldet den Hook als geändert und prepare weigert sich. Ein grünes check bedeutet daher "Vertrauen ist aufgezeichnet", nicht "Vertrauen ist aktuell".
2. Nach prepare erstellte Homes werden nicht abgedeckt. Die Erkennung erfolgt über Dateisystem-Marker, daher deckt die Garantie Sitzungsverzeichnisse ab, die zum Zeitpunkt von prepare existieren. Ein Sitzungsverzeichnis, das Gas City später materialisiert, hat bei seinem ersten Start immer noch nicht vertrauenswürdige Hooks; prepare benennt die konfigurierten Agenten, die noch kein Home haben.

Die daraus folgende Betriebsregel für beide: Führen Sie prepare aus, starten Sie die City, und führen Sie dann vor dem Versenden erneut prepare aus (es ist idempotent).

Bevorzugtes Paket und Registrierungen

Das integrierte main-Register katalogisiert offizielle Pakete. Das Community-Register ist eine optionale Konfiguration:

gc pack registry list
gc pack registry refresh
gc pack registry search --all
gc pack registry show main:gascity
gc pack registry add community https://registry.gascity.com/registry.toml
gc pack registry search --registry community --all

search liest den lokalen Register-Cache; show meldet Release-Herkunft und genaue Importbefehle. gc import add deklariert eine Quelle/Version, und gc import install löst es in packs.lock auf. Bevorzugen Sie eine exakte akzeptierte Version für reproduzierbare Cities.

AgentOps bevorzugt das offizielle gascity-Build-Paket, die Workflow-Familie, die in der öffentlichen Maintainer City Factory sichtbar ist. Die aktuelle akzeptierte Referenz ist gascity 0.1.6 beim Commit 3b3b89f2011e06d84459aa7bea1552382f13930a:

• Dashboard: https://factory.gascity.com;
• Workflows: build-basic, build-from-*, implement, review, issue und PR Abläufe;
• Standard-Rig-Rollen: gc.run-operator, gc.implementation-worker, Planer, Prüfer und Herausgeber;
• Bereichs-lokale Formelsteuerung: core.control-dispatcher;
• Geführte Koordination: der vorgelagerte gc.mayor-Skill.

Installieren Sie das Workflow-Paket im City-Bereich und sein zugehöriges Rollen-Paket auf jedem Rig, das Arbeit ausführt, und folgen Sie dabei den genauen Befehlen, die von gc pack registry show main:gascity zurückgegeben werden. Behalten Sie den Standard-gc.*-Namespace bei; verschachteln oder benennen Sie die Rollen nicht hinter einem AgentOps-Paket um.

Arbeit gelangt über den Mayor in die City. Der Aufrufer erstellt GENAU EINE Quell-Intent-Perle mit Akzeptanz und übergibt dem Mayor dann ihre ID – der Mayor zerlegt sie, erstellt die Workflow-Perlen und versendet sie. Der Aufrufer führt niemals selbst gc sling aus; ein operator-geschleuderter Run umgeht den Koordinator, der für Wiederholungen, erneutes Versenden und die Pflege dieses Workflows zuständig ist.

gc bd create "Add a --json flag to the export command"
gc mail send mayor -s "Build ago-XXXX" \
  -m "Decompose and launch build-basic for bead ago-XXXX with push=true open_pr=true." --notify

Oder in einer interaktiven Mayor-Sitzung:

Use skill gc.mayor

Direktes gc sling bleibt ein Debugging-Werkzeug für eine City ohne aktiven Mayor; ein so gestarteter Run hat keinen Koordinator und der Operator erbt dessen Pflege.

AgentOps-Skills sind Werkzeuge, die diesen Factory-Agenten zur Verfügung stehen, kein Ersatz-Workflow. Benennen Sie explizit einen Skill in der Perle oder Eingabeaufforderung, wenn sein Verhalten erforderlich ist. Die aktuelle vorgelagerte Zerlegung propagiert nicht automatisch einen freiformatierten Abschnitt "Required Skills" aus der aufrufer-eigenen Quell-Perle in jedes generierte Arbeitselement. Überprüfen Sie die Zerlegung vor der Implementierung; setzen Sie einen erforderlichen Skill-Namen auf das tatsächliche Arbeitselement oder die Worker-Eingabeaufforderung, wenn dessen Verwendung eine Akzeptanzbedingung ist. Skill-Präsenz und Skill-Aufruf sind unterschiedliche Tatsachen.

Upgrade einer bestehenden City auf 1.4

Führen Sie vor dem Start des Orchestrators einmal pro City aus:

gc doctor --fix
gc import install
gc supervisor stop --wait   # macOS, wenn ein älterer direkter Supervisor verbleibt
gc start

Bestätigen Sie dann:

• gc version meldet 1.4.0 vom vorgesehenen Pfad;
• gc doctor hat keine blockierenden Fehler;
• Jeder Graph-besitzende Rig hat einen nicht suspendierten core.control-dispatcher;
• Importe und packs.lock lösen auf;
• ao gc check akzeptiert die enthaltene Wartungs-Laufzeit und AgentOps-Skill-Verknüpfungen;
• Unter macOS löst der Supervisor-LaunchAgent denselben ausführbaren Pfad auf wie das ausgewählte gc-Binary;
• Alte Lesezeichen oder Reverse-Proxys des eigenständigen Dashboards werden entfernt.

Eine veraltete registrierte City kann jeden Start blockieren. Reparieren Sie diese City mit gc doctor --fix, oder deregistrieren Sie sie explizit, wenn sie absichtlich stillgelegt ist.

Stellen Sie eine alte HQ/Canary durch genauen registrierten Namen oder Pfad zurück, ohne den maschinenweiten Supervisor zu stoppen, der für seinen Ersatz benötigt wird:

gc cities --json
gc stop /path/to/old-city --timeout 45s
gc unregister /path/to/old-city
gc cities --json

unregister schlägt fehl, anstatt ein unbekanntes Ziel stillschweigend zu akzeptieren. Bewahren Sie das City-Verzeichnis auf, bis der Beads-Status gesichert oder als entsorgbar bestätigt ist. Erstellen Sie den Ersatz aus der vorgelagerten Gas City-Vorlage, installieren Sie seine gepinnten Importe und verifizieren Sie ihn mit gc cities --json, gc --city <new-city> status und gc --city <new-city> doctor --json.

Orchestrierung durch den Mayor: die Pflegeschleife

Nach der Übergabe der Absicht an den Mayor führt der Orchestrator fünf Verben aus. Jedes Verb hat einen Besitzer; das Überschreiten von Besitzergrenzen ist die wiederkehrende Fehlerklasse, die dieser Abschnitt zu stoppen versucht.

Verb	Besitzer	Oberfläche
Überwachen	Orchestrator	$API/runs/census und $API/runs/<run-id> in einem festen Rhythmus, plus gc mail inbox für Mayor-Antworten. failed > 0 in der Volkszählung, ein Run in failed/canceled oder ungelesene Mayor-Post ist das Handlungssignal; alles andere ist ein Tick.
Beobachten	Orchestrator	Bei einem Handlungssignal die Sichtbarkeitsebenen in der Reihenfolge durchgehen – Volkszählung, Run-Detail, Perlen-Graph, Sitzungs-Roster, Bereichswahrheit – und auf der ersten Ebene anhalten, die erklärt. Beginnen Sie nicht bei der Bereichswahrheit.
Anstoßen	Orchestrator, einmal	Eine ready-Perle: einmal an ihr gc.run_target versenden. Eine weitergeleitete Perle mit einer aktiven Sitzung: gc session wake <run_target> einmal. Ein zweiter Anstoß zum selben Thema bedeutet, dass die Diagnose falsch ist – mailen Sie stattdessen dem Mayor.
Umleiten	Mayor	Prioritäts-, Umfangs-, Stornierungs- oder Modell/Provider-Änderungen werden per Mail mit Perlen-/Run-IDs übermittelt. Der Orchestrator schleudert nie neu, bearbeitet Workflow-Perlen oder patcht einen laufenden Run.
Nacharbeit	GC zuerst, dann Mayor	Fehlgeschlagene Review-Ergebnisse treten über die native Korrekturschleife des Runs wieder ein (review_fix_formula, Standard fix-loop-base); begrenzte gated Wiederholungen sind gc converge-Schleifen. Nur ein TERMINAL failed/canceled-Run – oder ein abgeschlossener Run, dessen Ergebnis die Aufrufer-Akzeptanz verfehlt – geht zurück: Mailen Sie dem Mayor die Run-ID und die Fehlerevidenz für erneute Zerlegung und Neustart.

Nacharbeit, die der Orchestrator von Hand durchführt (Bearbeiten des Arbeitsbaums eines fehlgeschlagenen Runs, erneutes Schleudern seiner Formel, Schließen seiner Perlen), erzeugt einen zweiten unkoordinierten Autor für dieselbe Absicht; der Neustart des Mayors konkurriert dann damit.

Stillstandsprotokoll

Klassifizieren Sie zuerst die Perle.

• Noch ready: einmal an ihr gc.run_target versenden, dann anhalten und inspizieren.

• Bereits weitergeleitet/in Bearbeitung: Erneutes Schleudern ist ein NO-OP. Wecken Sie seinen besitzenden Worker einmal:

  gc session wake <run_target>
  

Erfassen Sie dann den genauen tmux-Bereich, der vom Sitzungsstatus benannt wird, und führen Sie gc doctor aus. Reparieren Sie niemals eine City von innerhalb dieser City.

Erstellen Sie niemals Paket-eigene Sitzungen von Hand. gc session new für einen Singleton oder skalierten Agenten (core.control-dispatcher, Rollen-Worker) erstellt eine falsch skopierte Sitzung, die den kanonischen Namen in start-pending besetzt und den Reconciliatordaran hindert, die echte zu spawnen – und verlängert genau den Stillstand, der repariert wird. Der Sitzungslebenszyklus gehört dem Reconciliatorund der Bedarfsskalierung. Wenn die City selbst Pflege benötigt (ein steckengebliebener Reconciliator, Sitzungen, die nie das Draining verlassen, Modell- oder Provider-Neuverdrahtung), senden Sie die Anfrage an den Mayor:

gc mail send mayor -s "<subject>" -m "<request with bead ids>" --notify

Das vorgelagerte Paket kann einen zukünftigen Affinitäts-gebundenen Schritt einer Sitzung zuweisen, die bereits Drain bestätigt hat. Diagnostizieren Sie dies nur von außerhalb der City:

ao gc recover-affinity --city /path/to/city --rig /path/to/rig

Die Standardeinstellung ist ein Probelauf. Wenn jede aufgeführte Zuweisung korrekt ist, wiederholen Sie mit --apply. Die begrenzte Reparatur löscht nur den Beauftragten auf einer aktuell bereiten Formelperle, deren gc.session_affinity=require-Sitzung nicht mehr aktiv ist. Sie schleudert nicht, wiederholt nicht, schließt nicht, startet nicht neu oder wählt keine Arbeit aus.

Sichtbarkeit: vier Ebenen

1. Supervisor/Run-Status — gc dashboard, Run-Detail, gc status und gc session list --json. Run-Detail vereinheitlicht die Stufenleiter, strukturierte Transkripte, Token-Rate und geschätzte Burn-Rate. Ein Roster kann noch aktiv melden, während ein Provider feststeckt.

   Der programmatische Run-Status kommt von der typisierten Run-API des Supervisors – dieselben Daten, die das Dashboard rendert. gc status gibt die API-Basis aus; weder gc status --json noch ein anderer CLI-Unterbefehl führt Run-Objekte.

   API="http://127.0.0.1:<port>/v0/city/<city-name>"
   curl -s "$API/runs/<run-id>"   # {run_id, title, status, target, scope, started_at, updated_at}
   curl -s "$API/runs/census"     # {status_counts: {pending, active, …}}