Eine Archon-gestützte Softwarefabrik einrichten und ein Ticket prüfen

Das Repository AI Software Factory beschreibt den Weg vom Produktauftrag und Ticket zu einem von Archon erstellten Pull Request. Installation und Workflow-Prüfungen sind erst der Anfang. Laut Leitfaden für die erste Stunde des Maintainers steht die praktische Ende-zu-Ende-Validierung noch aus. Dieser Artikel folgt dem Factory-Commit 9e2d85298b45497031009597a6ae0811b66fe6d6 und der darin festgelegten Archon-Revision fad09169ea1b43512bc7ee88470d47f960a3e0f8. Er beruht auf Dokumentation und Quellcode, nicht auf einer Installation oder Ausführung durch BIG CHANGE.

Der Ablauf richtet sich an ein Team, das ein Anwendungsrepository oder PRD, seine GitHub-Berechtigungen und sein Modellanbieterkonto kontrolliert. Der Maintainer beschreibt ausdrücklich das Klonen und Installieren der Factory im eigenen Repository. Im festgelegten Factory-Quellbaum fehlen Lizenz- und Hinweisdokumente; diese Anleitung begründet keine weitergehenden Wiederverwendungs- oder Weiterverbreitungsrechte. Archons MIT-Lizenz gilt für den getrennten Archon-Quellcode. Anbieterzugangsdaten gehören weder in Tickets und Prompts noch in Protokolle oder Prüfbelege.

Die große Veränderung

• Was sich ändert: Die Implementierung verbindet Produktumfang, Ticketplanung, Programmierung, unabhängige Prüfung und Laufzeitkontrollen durch ein festgelegtes Archon-Workflow-Pack. Die Fabrik liefert Projekteingaben und Starter; das gemeinsame Pack enthält die KI-Schritte.
• Warum es zählt: Ein Team kann eine Änderung vom Ticket zu einem bestimmten Diff, CI-Ergebnis und laufenden Kandidaten verfolgen, bevor es über den Merge entscheidet. Installationsprüfungen allein lassen diese Kette unvollständig; laut Maintainer fehlt noch die praktische Integrationsvalidierung.
• Worauf zu achten ist: Der erste brauchbare Beleg ist ein echtes Ticket, dessen gelieferte Revision aussagekräftige Abläufe und unabhängige zurückgehaltene Prüfungen besteht, mit sichtbaren Kosten und Prüfprotokollen. Zeitplanung und Bereitstellung bleiben danach getrennte Entscheidungen.

1. Repository, Berechtigungen und Quellstand prüfen

Die Installationsanleitung des Maintainers nennt Git, Python ab 3.10, angemeldetes gh mit Berechtigungsumfang workflow, ein GitHub-Remote, einen Programmieragenten, Bun und uv. Git muss auch Workflow-Dateien übertragen dürfen (gh auth setup-git). Prüfen Sie vor dem Agentenlauf die vorhandenen Test-, Start- und CI-Befehle, den Branch-Schutz, GitHub-Zugriff, Anbieteranmeldung und Modellabrechnung. Erteilen Sie nur die benötigten Repository- und Workflow-Rechte.

Klonen Sie die Fabrik außerhalb des Anwendungsrepositorys und wechseln Sie zum angegebenen Commit. Der dokumentierte Installationsbefehl wird vom Stammverzeichnis der Anwendung aus ausgeführt:

git clone https://github.com/coleam00/ai-software-factory ~/ai-software-factory
git -C ~/ai-software-factory checkout 9e2d85298b45497031009597a6ae0811b66fe6d6
python ~/ai-software-factory/bin/factory.py init

Verwenden Sie bei Bedarf python3. Das Installationsprogramm kopiert Factory- und Projektvorlagen und installiert die in pack.json genannte Archon-Quelle. README und Pack dieses Commits nennen beide fad09169ea1b43512bc7ee88470d47f960a3e0f8. Es meldet keinen Anbieter an, wählt keine Modellstufen und startet keinen Zeitplan. Prüfen Sie die Dateiveränderungen, bevor Sie diese in Ihr Repository übernehmen.

Konfigurieren Sie den gewählten Anbieter und unterstützte Modellkennungen anhand der installierten Archon-Anleitung. Tragen Sie die tatsächlichen Befehle für statische Prüfungen und Unit-Tests in harness/harness.config.json ein. Kann GitHub den Branch-Schutz nicht melden, nennen Sie die zum Merge nötigen CI-Jobs in required_checks. Prüfen Sie protected_paths, damit Änderungen an Auftrag, Prüfumgebung und Factory-Regeln menschliche Kontrolle erfordern. Die Vorlage lässt normale Prüfbefehle und required_checks leer; Kopieren allein schafft keine brauchbare Abnahmeschranke.

2. Auftrag und Prüfungen für das vorhandene Produkt festhalten

Beschreiben Sie in MISSION.md Produktzweck, harte Grenzen und plausible Anfragen außerhalb des Auftrags. Dokumentieren Sie in harness/END-TO-END.md zwei bis fünf Abläufe, die die bestehende Anwendung tatsächlich abschließt, einschließlich des sichtbaren Nutzens. Ein Ablauf mit noch fehlenden Funktionen würde die erste Lieferung blockieren. Schreiben Sie in .factory/holdout/HOLDOUT.md getrennte Prüffälle für kombinierte Verhaltensweisen und Randfälle. Der Ordnername verbirgt sie nicht vor einem Entwickler mit Zugriff auf dieselbe Arbeitskopie. Wirklich geheime Fälle gehören außerhalb dieser Kopie und nur in die Verifikation.

Enthält das Repository nur ein PRD, verlangt die README, Auftrag, geplante Abläufe und Prüfbefehle daraus abzuleiten. Das erste vorgeschlagene Ticket muss das Produkt ausführbar machen und Startbefehl, Zustands- und Build-Identitätspfade, Tests und CI nennen. Prüfen Sie den Vorschlag, bevor Sie die Ticketveröffentlichung erlauben.

Überführen Sie die Abläufe in die Szenarioeingaben der Archon-Laufzeitworkflows. Befolgen Sie die installierte factory/RUNTIME_HOST.md: Anwendungsabbild vom gelieferten Commit, frischer Zustand, Zustands- und Build-Identitätsprüfungen sowie zulässige Python- oder Node-Startbefehle. Der dokumentierte Host verwaltet weder entfernte Datenbanken noch Container oder Cloud-Ressourcen als eigene Laufzeitressourcen. Anwendungen damit benötigen eine gesondert begründete Prüfanordnung; eine erfolgreiche lokale Host-Prüfung belegt deren Isolation nicht.

Bevor Sie dem Prüfer vertrauen, erstellen Sie eine erfolgreiche Referenz, die echten Nutzwert ausübt. Zeigen Sie, dass ein passender absichtlicher Fehler scheitert und eine falsche Kandidatenidentität zu einem nicht eindeutigen Urteil führt. Die Host-Anleitung nennt Eingaben und exakte erwartete Felder, darunter expectations_passed: true und baseline_verified: true. Bewahren Sie die tatsächliche native Rückgabe und Kandidatenidentität als Beleg auf. Nur das Laden einer Seite zu prüfen oder den Endzustand direkt für den Test anzulegen reicht nicht.

3. Installation prüfen und eine Aufgabe wählen

Führen Sie im Anwendungsstamm aus:

python factory/consumer.py doctor
python factory/consumer.py list

doctor prüft festgelegte Quelle, Befehlsfähigkeiten und verfügbare Workflows. list zeigt gefundene Workflows. Keiner der Befehle beweist, dass ein Anbieter ein Ticket abschließt, CI besteht oder die Anwendung läuft. Beheben Sie gemeldete Fehler vor der Lieferung; lassen Sie den Zeitplan ausgeschaltet.

Formulieren Sie für vorhandenen Code ein kleines Ticket mit klarem Ergebnis und Abnahmekriterien. Die README dokumentiert folgenden Befehl für Einordnung, Lieferung und Prüfung bis zum Pull Request:

python factory/consumer.py run archon-ship --input target=https://github.com/OWNER/REPO/issues/1 --input discovery_publication=preview --detach --json

Ersetzen Sie die Ticket-URL durch eine unter Ihrer Kontrolle. Das ausdrückliche discovery_publication=preview verhindert das Anlegen zusätzlicher Tickets für benachbarte Prüffunde; ansonsten verwendet der festgelegte Workflow archon-ship hier standardmäßig auto. Nutzen Sie archon-lifecycle erst mit vorbereiteten Laufzeitszenarien und zurückgehaltenen Prüffällen. Übergeben Sie das Ticket als target, die Eingabepfade als scenario und holdout, außerdem merge_mode=approve und discovery_publication=preview. Geben Sie eine projektseitig erlaubte merge_method an: merge, squash oder rebase. merge_method=squash ist beispielsweise nur zulässig, wenn Ihr Repository dies erlaubt. Der Workflow umfasst Laufzeit- und zurückgehaltene Prüfungen, Reparatur und Merge-Schranke. Der Freigabemodus bewahrt die menschliche Entscheidung vor dem Merge; eine Bereit-Meldung ist keine Freigabe. Mit dem Factory-Laufzeithost funktioniert die dokumentierte Option --runtime-host nur im Vordergrund und nicht zusammen mit --detach oder --resume.

Für ein PRD lautet der dokumentierte Backlog-Befehl:

python factory/consumer.py run archon-backlog --input 'prd=docs/PRD.md' --input publication=approve

Ersetzen Sie das in Anführungszeichen stehende docs/PRD.md durch den tatsächlichen, zur Anwendungsarbeitskopie relativen PRD-Pfad. Prüfen Sie die vorgeschlagene Ticketreihenfolge vor Veröffentlichung. Richten Sie den Laufzeithost nach dem im ersten Ticket festgelegten Anwendungsstart und Identitätsvertrag ein. Führen Sie das Ticket dann mit vorbereiteten Abläufen und zurückgehaltenen Fällen durch archon-lifecycle. Prüfen Sie das erste Ticket ebenso sorgfältig wie spätere Aufgaben.

4. Änderungen und laufendes Ergebnis vor der Freigabe beurteilen

Bewahren Sie die zurückgegebene Laufkennung auf. Das Steuerprogramm bietet get <run-id> --json --events und status --all --json für Fortschritt und Belege. Vergleichen Sie Ticket und Plan mit MISSION.md; lesen Sie den tatsächlichen PR-Diff und die unabhängige Prüfung des aktuellen Quellstands. Prüfen Sie erforderliche CI-Ergebnisse und den Bericht zu geschützten Pfaden. Führen Sie die Produktabläufe gegen die gelieferte Revision aus und prüfen Sie native Laufzeit- und zurückgehaltene Ergebnisse samt Kandidatenidentität. Vergleichen Sie das beobachtete Nutzerergebnis mit den Abnahmekriterien. Mangelhafte PRs müssen zur Reparatur zurückgehen; die README nennt archon-deliver --adopt <run id> für einen von der Merge-Warteschlange zurückgehaltenen Lieferlauf.

Erst nach erfolgreichen Prüfungen darf ein Mensch mit Repository-Berechtigung den Merge freigeben. Eine Bereitstellung braucht projektspezifische Bereitstellungs-, Zustands- und Identitätsbefehle und eine anschließende Rücklesung der Revision. Ein zusammengeführter PR beweist keine Bereitstellung. Lassen Sie während dieses ersten Tickets den Zeitplan aus und entscheiden Sie gesondert über wiederkehrende Läufe.

Die Kostenhinweise des Maintainers nennen keinen Festpreis pro Lauf. Sie empfehlen Tokenmessung ab dem ersten Tag und Beobachtung der Modellaufrufe an einem kleinen Ticket vor Aktivierung einer Schleife. Die Gebühren hängen von Anbieter, Modellen und Kontobedingungen ab. BIG CHANGE hat die Ausgaben dieser Fabrik nicht gemessen.

Ein aktiver Lauf benötigt außerdem eine ausdrückliche Stoppentscheidung. Im Steuerprogrammcode blockiert halt neue Starts und Fortsetzungen; cancel <run-id> richtet sich an aktive Arbeit. pause stoppt Zeitgeberstarts, erlaubt jedoch das Aufwecken bereits laufender Arbeit. Keiner dieser Befehle ersetzt die Prüfung des aktuellen Laufzustands und der Änderungen im entfernten Repository.

Quellen und weiterführende Lektüre

• Factory-README am festgelegten Quellstand: Installation, Befehle, Produkteingaben, Workflow-Auswahl und genannte Grenzen. Maintainerbeschreibung, kein Beleg eines BIG-CHANGE-Laufs.
• Festgelegtes Pack-Manifest und Steuerprogrammcode: Archon-Revision, angebotene Workflows und Unterschiede zwischen status, halt, cancel und pause.
• Leitfaden für die erste Stunde und Laufzeithost-Anleitung: Validierungsvorbehalt und Anforderungen einer an den Kandidaten gebundenen Laufzeitprüfung.
• Verwandter BIG-CHANGE-Bericht zu Programmieragenten und abgeschlossener Arbeit: Kontext für die Prüfung fertiger Ergebnisse. Eine andere Studie, keine datierte Fortsetzung dieser Factory-Implementierung.