Markdown-Ausgabe

AI-translated from English; not yet reviewed by a fluent editor.

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

> Ein Leitfaden anhand eines festgelegten Quellstands: Ein Archon-Ticket von Produktauftrag und Laufzeitprüfungen bis zur menschlichen Merge-Entscheidung planen und prüfen. BIG CHANGE hat die Fabrik nicht ausgeführt.

By BIG CHANGE Editorial

Published: 2026-10-19T14:43:34.857Z
Updated: 2026-10-19T14:43:34.857Z
Canonical: https://bigchange.ai/blog/archon-software-factory-reviewed-issue

![Conceptual charcoal illustration of one reviewer studying an unbranded two-column code change printout clipped to a wall rail.](https://bigchange.ai/api/media/file/archon-reviewed-code-change-v2.png)
AI-generated conceptual illustration by BIG CHANGE; no factory installation, issue delivery, code review outcome or product interface is depicted.

Das [Repository AI Software Factory](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/README.md) 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](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/docs/first-hour.md) 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](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/README.md#instructions-for-the-agent) 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:

```bash
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`](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/factory/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](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/README.md#instructions-for-the-agent), 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`](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/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:

```bash
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:

```bash
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:

```bash
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](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/README.md#cost) 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](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/factory/consumer.py) 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](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/README.md): Installation, Befehle, Produkteingaben, Workflow-Auswahl und genannte Grenzen. Maintainerbeschreibung, kein Beleg eines BIG-CHANGE-Laufs.
- [Festgelegtes Pack-Manifest](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/factory/pack.json) und [Steuerprogrammcode](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/factory/consumer.py): Archon-Revision, angebotene Workflows und Unterschiede zwischen status, halt, cancel und pause.
- [Leitfaden für die erste Stunde](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/docs/first-hour.md) und [Laufzeithost-Anleitung](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/factory/RUNTIME_HOST.md): Validierungsvorbehalt und Anforderungen einer an den Kandidaten gebundenen Laufzeitprüfung.
- [Verwandter BIG-CHANGE-Bericht zu Programmieragenten und abgeschlossener Arbeit](https://bigchange.ai/articles/ai-coding-agents-review-output-study): Kontext für die Prüfung fertiger Ergebnisse. Eine andere Studie, keine datierte Fortsetzung dieser Factory-Implementierung.

## Sources

- [README.md](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/README.md) — Einrichtung, Projektdateien, Workflows, Ticket- und PRD-Wege, Merge-Regeln und Betriebsgrenzen des Maintainers.
- [pack.json](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/factory/pack.json) — Exakte Archon-Revision, Workflow-Einträge und Befehlsfähigkeiten; stimmt mit der festgelegten README überein.
- [first-hour.md](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/docs/first-hour.md) — Einrichtungsfolge und ausdrücklicher Hinweis auf ausstehende praktische Ende-zu-Ende-Validierung.
- [consumer.py](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/factory/consumer.py) — Implementierung von doctor/list, Workflow-Aufrufen, status, halt, pause und cancel.
- [RUNTIME_HOST.md](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/factory/RUNTIME_HOST.md) — Kandidatenbindung, Referenz- und Fehlerkalibrierung, unterstützte Anwendungsformen und Grenzen.
- [harness.config.json](https://github.com/coleam00/ai-software-factory/blob/9e2d85298b45497031009597a6ae0811b66fe6d6/template/harness/harness.config.json) — Leere Projektprüfbefehle und erforderliche Prüfungen sowie voreingestellte geschützte Pfade.
- [LICENSE](https://github.com/coleam00/Archon/blob/fad09169ea1b43512bc7ee88470d47f960a3e0f8/LICENSE) — Archon-Lizenzbedingungen; kein Nachweis einer Lizenz für das getrennte Factory-Repository.
- [archon-ship.yaml](https://github.com/coleam00/Archon/blob/fad09169ea1b43512bc7ee88470d47f960a3e0f8/.archon/workflows/sdlc/ship/archon-ship.yaml) — Entdeckungsveröffentlichung steht standardmäßig auf auto; preview legt benachbarte Funde nicht als Tickets an.
- [archon-lifecycle.yaml](https://github.com/coleam00/Archon/blob/fad09169ea1b43512bc7ee88470d47f960a3e0f8/.archon/workflows/sdlc/lifecycle/archon-lifecycle.yaml) — Verlangt ausdrücklich merge, squash oder rebase als Merge-Methode.
- [archon-backlog.yaml](https://github.com/coleam00/Archon/blob/fad09169ea1b43512bc7ee88470d47f960a3e0f8/.archon/workflows/sdlc/backlog/archon-backlog.yaml) — Das PRD wird als Pfad innerhalb der Arbeitskopie angegeben.
- [BIG CHANGE](https://bigchange.ai/articles/ai-coding-agents-review-output-study) — Verwandter, aber eigenständiger Kontext für die Prüfung abgeschlossener Ergebnisse.