AI-DLC 2.11.0 kann einen Codex-CLI-Ablauf vor der Codeerzeugung anhalten, damit ein Entwickler den vorgeschlagenen Plan lesen und freigeben kann. Diese Anleitung folgt dem Release v2.11.0 vom 8. Oktober 2026 und dessen versionierten Anleitungen für Codex CLI, Workflowprofile und Plan Approval. BIG CHANGE hat diese Dokumente und die Befehlsreferenz des Release-Tags geprüft. Wir haben AI-DLC weder installiert noch ausgeführt; sämtliche folgenden Schritte beruhen ausschließlich auf der Dokumentation.

Die Anleitung richtet sich an Entwickler mit einem Git-Projekt, die einen Codeplan prüfen möchten, bevor ein KI-Programmierassistent Dateien erzeugt. Das erwartete Ergebnis ist eine Plan-Approval-Frage, die den Plan benennt, Änderungswünsche erlaubt und den Build bis zur Antwort warten lässt. AI-DLC hat weitere spätere Prüfungen; diese Schranke betrifft ausdrücklich den Codeplan.

Vor dem Start

Die zum Tag gehörende Codex-Anleitung verlangt Codex CLI 0.145.0 oder neuer, ein Git-Repository für Projekthooks und einen konfigurierten Modellanbieter. Die native AI-DLC-Version benötigt weder Bun noch Node.js. Verwenden Sie ein Projekt, dessen Code und Plan Sie an den eingestellten Modellanbieter senden dürfen. Prüfen Sie dessen Datenverarbeitungs- und Abrechnungsbedingungen gesondert; das AI-DLC-Repository nennt keinen einheitlichen Anbieterpreis für diesen Ablauf.

Halten Sie eine konkrete Entwicklungsaufgabe als Eingabe bereit. Diese Anleitung wählt das Profil Feature, weil v2.11.0 Plan Approval für Feature als eingeschaltet dokumentiert. Express und Proof of concept beginnen mit ausgeschaltetem Plan Approval; eine Person kann aber die Prüfung eines bestimmten Plans verlangen. Das Profil ist wichtiger als die pauschale Erwartung, jeder AI-DLC-Lauf werde anhalten.

1. Das festgelegte Release installieren und prüfen

Für macOS, Linux oder WSL nennt das Release v2.11.0 diesen versionsspezifischen Installationsbefehl:

Terminal
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/download/v2.11.0/install.sh | sh -s -- --version 2.11.0

Das Release bietet auch einen versionsspezifischen Windows-Installer für PowerShell. Prüfen Sie den Installer und wählen Sie vor der Ausführung den für Ihren Rechner passenden Weg. Prüfen Sie danach aus Ihrem Projekt die installierte Version und die Umgebung:

Terminal
aidlc --version
aidlc doctor
codex --version

Erwarten Sie, dass aidlc --version die Version 2.11.0 meldet. aidlc doctor meldet Konfigurations- und Laufzeitprobleme, während codex --version die Prüfung der Mindestversion von Codex CLI ermöglicht. Ist eine andere Version installiert, stoppen Sie hier und nutzen Sie die Installations- oder Aktualisierungsanleitung des Releases v2.11.0; die folgenden Schritte sind auf dieses Release festgelegt.

2. Codex einrichten und Projekthooks vertrauen

Nutzen Sie aus dem Stammverzeichnis des Git-Projekts den Codex-Einrichtungsweg des Release-Tags:

Terminal
aidlc config --harness codex
aidlc doctor
codex

Codex fragt, ob Sie den Projekthooks vertrauen. Prüfen Sie Projekt und erzeugte Hooks, bevor Sie Trust all and continue (Allen vertrauen und fortfahren) wählen. Laut der Anleitung des Tags lässt sich ein bereits geschlossener Dialog mit /hooks, dann t und Esc wieder öffnen. Führen Sie nach der Vertrauensfreigabe $aidlc --doctor in Codex aus. Laufen die Hooks nicht, folgen Sie der Vertrauenswiederherstellung in der Integrationsumgebungs-Anleitung. Ein erfolgreicher Installer allein belegt nicht, dass die Projekthooks aktiv sind. Modellanbieter und Zugangsdaten werden in den Benutzereinstellungen von Codex konfiguriert und nicht von AI-DLC geliefert.

3. Einen Feature-Workflow starten und Einstellungen prüfen

Führen Sie zuerst $aidlc --status in Codex aus und prüfen Sie, dass kein Workflow aktiv ist. Die Befehlsreferenz des Tags erklärt, dass ein bloßer Scope-Befehl bei aktivem Workflow die bestehende Arbeit fortsetzt. Verwenden Sie für diese Anleitung ein Projekt ohne aktiven Workflow.

Geben Sie in diesem eingerichteten Codex-Projekt $aidlc feature ein und beantworten Sie die Frage nach der gewünschten Entwicklungsaufgabe. Die Eingabe sollte Funktion und Einschränkungen beschreiben; daraus entsteht der spätere Plan. Prüfen Sie vor Erstellung des Codeplans die tatsächlich geltenden Kontrollen anhand der Befehlsreferenz von v2.11.0:

Text
$aidlc --status
$aidlc config get plan-approval
$aidlc config get guard-policy

Suchen Sie nach Plan Approval on (eingeschaltet) und der angegebenen Herkunft des Werts. Ist es für dieses Vorhaben ausgeschaltet, aktiviert $aidlc --plan-approval on die Frage für den nächsten Plan. Ein Schalter auf Rechnerebene kann es zwangsweise ausschalten; eine Team-Gedächtnisregel kann es vorschreiben. Die Statuszeile zeigt den tatsächlich geltenden Wert. Stellen Sie für diese Anleitung Guard Policy mit $aidlc --guard-policy strict auf streng, wenn auch ein geänderter, bereits freigegebener Plan oder dessen Testanweisungen eine neue Freigabe verlangen soll. Eingeschaltetes Plan Approval steuert die erste Frage; Guard Policy steuert das Verhalten nach einer Änderung des genehmigten Plans.

4. Den Codeplan an der Freigabeschranke prüfen

Setzen Sie den Workflow fort, bis Code Generation einen Plan bereitgestellt hat. Bei eingeschaltetem Plan Approval zeigt die Engine v2.11.0 Zusammenfassung und Pfad des Plans sowie die Optionen Approve Plan (Plan freigeben), Request Changes (Änderungen anfordern) oder I'll edit the files (Ich bearbeite die Dateien) an. Öffnen Sie die benannte Datei code-generation-plan.md und lesen Sie die vorgeschlagenen Dateien, die Reihenfolge und die Testanweisungen. Prüfen Sie vor der Freigabe Befehle, Zugriffe auf Projektdaten und Aktionen, die das Repository verändern könnten.

Wählen Sie Request Changes (Änderungen anfordern), wenn der Plan eine andere Umsetzung oder einen anderen Test benötigt. Bearbeiten Sie die Dateien selbst, nutzen Sie den Engine-Pfad I'll edit the files (Ich bearbeite die Dateien), statt eine Bearbeitung als Freigabe zu behandeln. Nur Ihre Antwort autorisiert den Plan; ein Modell kann ihn nicht für Sie genehmigen. Bei aktiver Schranke wartet die Codeerzeugung auf diese Antwort. Laut Release Notes können eine Prüfung, Einstellung, ein Commit oder eine andere zulässige Anfrage weiterlaufen, während der Build wartet.

5. Freigeben, Protokoll prüfen und einen geänderten Plan behandeln

Ist der Plan akzeptabel, antworten Sie in der offenen Frage mit Approve Plan (Plan freigeben). Die Engine protokolliert die Freigabe für diesen Plan und setzt den Build über den normalen next-Ablauf fort. Ein unveränderter freigegebener Plan wird laut Release Notes auch bei Chatkomprimierung oder Parken behalten. Die Befehlsreferenz des Tags dokumentiert den nur lesenden Befehl aidlc engine audit history zur Prüfung des aufgezeichneten Zeitverlaufs, und $aidlc --status zeigt die Workflowposition. Diese Aufzeichnungen dienen zusammen mit der sichtbar vor der Codeerzeugung erscheinenden Schranke als Erfolgskontrolle.

Ändern sich Plan oder Testanweisungen vor dem Build, fragt eine strenge Guard Policy erneut nach Freigabe. Bei lockerer oder ausgeschalteter Richtlinie wird die Änderung gemeldet und protokolliert, der Ablauf kann aber ohne zwingende neue Freigabe weitergehen. Die Dokumentation des Tags unterscheidet zudem Änderungen an unbeteiligten Quelldateien nach der Freigabe: Diese werden gemeldet, während sich die Planfreigabe weiter auf Plan und Testanweisungen bezieht. Die Person kann „zum freigegebenen Plan zurückkehren“ sagen, um vor dem Build den früheren Plan wiederherzustellen. Ein unveränderter Plan sollte nicht allein wegen Chatkomprimierung erneut fragen.

Wenn die Pause nicht erscheint

Lesen Sie zuerst $aidlc --status und $aidlc config get plan-approval. Prüfen Sie den gewählten Scope, die wirksame Einstellung und deren Herkunft. Express und Proof of concept sind standardmäßig ausgeschaltet; aktivieren Sie Plan Approval für dieses Vorhaben oder starten Sie einen Feature-Workflow, falls dessen ganzer Lebenszyklus zur Aufgabe passt. Scheinen Konfiguration oder Hooks defekt, führen Sie aidlc doctor aus und folgen Sie der Wiederherstellung der Codex-Integrationsumgebung. Prüfen Sie Versionsunterschiede, bevor Sie die Laufzeit eines aktiven Projekts ändern. Nehmen Sie nicht an, eine fehlende Frage belege eine protokollierte Freigabe: Bei ausgeschalteter Einstellung schreibt AI-DLC eine Zeile PLAN_APPROVAL_SKIPPED, die die Dokumentation ausdrücklich von der Zustimmung einer Person unterscheidet.

Die große Veränderung

  • AI-DLC 2.11.0 verankert die Planfrage in seiner Engine, die die Entscheidung protokolliert und einen unveränderten freigegebenen Plan über geparkte oder komprimierte Sitzungen hinweg behält.
  • Bei einem Codex-CLI-Feature-Lauf kann der Entwickler den wirksamen Plan-Approval-Wert prüfen, den Plan vor der Codeerzeugung lesen und an der Schranke Änderungen verlangen.
  • Eine erneute Freigabe nach Planbearbeitung hängt von Guard Policy ab. Der Entwickler kann streng wählen, um bei Änderungen am Plan oder den Testanweisungen erneut anzuhalten.

Quellen und weiterführende Informationen