Markdown-Ausgabe

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

# AI-DLC 2.11.0 vor der Codeerzeugung zur Planfreigabe anhalten

> Eine auf Version 2.11.0 festgelegte, rein dokumentationsbasierte Anleitung: die menschliche Planfreigabe von AI-DLC vor der Codeerzeugung aktivieren und prüfen.

By BIG CHANGE Editorial

Published: 2026-10-15T18:54:16.360Z
Updated: 2026-10-15T18:54:16.360Z
Canonical: https://bigchange.ai/blog/aidlc-2-11-plan-approval-guide

![Conceptual charcoal illustration of one developer reading abstract plan-like lines on an unbranded desktop monitor while the keyboard sits untouched.](https://bigchange.ai/api/media/file/aidlc-human-plan-review-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual AI-DLC interface, user session or observed test result is depicted.

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](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) und dessen versionierten Anleitungen für [Codex CLI](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md), [Workflowprofile](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) und [Plan Approval](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md#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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) 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:

```bash
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](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) 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:

```bash
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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md#install):

```bash
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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) 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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md):

```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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md#read-earlier-questions-and-the-audit-timeline) 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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md#refresh-and-version-skew). 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

- [AI-DLC-Release 2.11.0](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) — datiertes Release, festgelegte Installer und beschriebenes Plan-Approval-Verhalten. Die Release Notes beschreiben die Funktion; sie belegen keine Ausführung dieser Anleitung durch BIG CHANGE.
- [Codex-CLI-Anleitung bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) — Codex-Version, Git- und Anbietervoraussetzungen, Projekteinstellungen, Hook-Vertrauen und Aufruf.
- [Workflowprofile bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) — Profilvorgaben und Unterschied zwischen Feature und Express/Proof of concept.
- [Plan Approval und Guard Policy bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md#plan-approval) — erste Freigabeschranke, Überspringungsprotokolle und Verhalten bei Änderungen am freigegebenen Plan.
- [Befehlsreferenz bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) — Status-, Konfigurations- und Auditverlaufsbefehle.

## Sources

- [AI-DLC-Release 2.11.0](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) — Festgelegte Installer und Projektbeschreibung der Planfreigabe in der Engine; keine Ausführung durch BIG CHANGE.
- [AI-DLC-README bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/README.md) — Integrationsumgebung und Konfiguration im Release-Tag vom 8. Oktober. Der allgemeine Installer der neuesten Version wurde bewusst nicht verwendet.
- [AI-DLC-Codex-CLI-Anleitung bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) — Codex-Voraussetzungen, Projekteinrichtung, Hook-Vertrauen und Wiederherstellung bei Versionsabweichungen im Release-Tag vom 8. Oktober.
- [AI-DLC-Workflowprofile bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) — Scope-Verhalten von Feature, Express und Proof of concept sowie Freigabevorgaben im Release-Tag vom 8. Oktober.
- [AI-DLC Plan Approval und Guard Policy bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md) — Planfrage, Überspringungsprotokoll und erneute Freigabe bei geänderten Plänen oder Testanweisungen im Release-Tag vom 8. Oktober.
- [AI-DLC-CLI-Befehlsreferenz bei v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) — Versions-, Status-, Konfigurations- und Auditverlaufsbefehle im Release-Tag vom 8. Oktober; BIG CHANGE hat keine Befehle ausgeführt.