Neu im Oktober 2026

Im Oktober ist beim AI Unified Process viel passiert. aiup-core ist von 3.0.0 auf 3.10.0 gewachsen, sieben neue Layer-Plugins sind in den Marketplace gekommen, und das AI Unified Process Studio hat sechs neue Use Cases erhalten. Hier steht, was sich geändert hat und warum.

Die meisten Änderungen kommen aus echten Projekten. Einige stammen daher, dass das Book-Library-Tutorial immer wieder durchgespielt und jede Lücke geschlossen wurde, die der Agent gefunden hat. Andere kommen aus Diskussionen mit Leuten, die die Plugins einsetzen.

Layer-Plugins statt Stack-Plugins #

Bisher hat man ein Stack-Plugin wie aiup-vaadin-jooq oder aiup-angular-jpa gewählt. Das funktioniert, solange das Projekt genau diese Kombination verwendet. Echte Projekte tun das aber nicht. Das eine nutzt Vaadin mit JPA. Das andere hat nur ein REST-API. Ein drittes verwendet Flyway, jOOQ und Angular.

Deshalb sind die Stacks jetzt in Layer-Plugins aufgeteilt, die man pro Projekt kombiniert:

• aiup-flyway für die Migrationsschicht
• aiup-jooq und aiup-jpa für die Persistenzschicht
• aiup-spring-boot für die Service-Schicht, das REST-API und Aufrufe externer Systeme
• aiup-vaadin für Vaadin-Flow- und Hilla-UIs
• aiup-angular für ein Angular-UI
• aiup-playwright für End-to-End-Tests

Der neue Befehl /stack hält in docs/architecture/stack.md fest, welche Schichten ein Projekt hat. Er erkennt den Stack aus pom.xml und package.json, findet die installierten Layer-Skills und fragt nur nach, was er nicht erkennen kann. Er funktioniert neben einer Dokumentation nach arc42, C4 oder 4+1. Er liest sie, ändert sie aber nie.

Danach baut /use-case-implement UC-001 den Use Case von unten nach oben durch die Schichten: Migration, Persistenz, Client, Service, API, UI. /use-case-test UC-001 testet ihn einmal in der Integrationsschicht, und /use-case-coverage UC-001 prüft jeden Schritt, jeden alternativen Ablauf und jede Geschäftsregel gegen Code und Tests.

Die kombinierten Stack-Plugins aiup-vaadin-jooq und aiup-angular-jpa sind deprecated. Layer-Plugins erklärt den neuen Weg im Detail und wie man ein bestehendes Projekt umstellt.

Mockups, API-Verträge und externe Systeme #

Ein Use Case beschreibt Verhalten. Ein Projekt hat aber oft mehr Input: ein Figma-Design, einen vereinbarten OpenAPI-Vertrag oder einen Zahlungsanbieter, den das System aufrufen muss. Drei Ergänzungen verbinden diese Inputs mit dem Use Case:

• Mockup-Zeile. Sie verlinkt einen Figma-Frame, ein Bild oder eine Markdown-Skizze. Die UI-Skills übernehmen das Layout daraus. Welche Felder, Aktionen und Meldungen es gibt, entscheidet weiterhin die Spezifikation. Widerspricht das Mockup der Spezifikation, erfasst der Agent eine offene Frage.
• API-Zeile. Sie verlinkt eine Operation in einem OpenAPI-Vertrag. Anders als ein Mockup ist der Vertrag verbindlich, denn ein Partnersystem hat bereits dagegen gebaut. /spring-rest baut die Operation genau so, wie sie beschrieben ist, und die Tests übernehmen die erwarteten Status und Payloads aus dem Vertrag.
• Externe Systeme. Sie werden in der Stack-Datei festgehalten. Die neue Client-Schicht erzeugt einen Port und einen Adapter aus dem Vertrag des Anbieters. Kein Test erreicht je das echte System; die Tests verwenden stattdessen ein Fake des Ports. Und bevor der Agent ein Retry, ein Timeout oder einen Fallback einbaut, fragt er nach.

Offene Fragen, Entscheidungsrechte und ADRs #

Ein Agent trifft beim Programmieren viele versteckte Entscheidungen. Simon hat darüber in Five Agents, Fifty Decisions geschrieben. Drei Änderungen machen diese Entscheidungen sichtbar.

Offene Fragen. Findet der Agent eine Lücke in der Spezifikation, rät er nicht mehr. Er erfasst die Frage in docs/open_questions.md mit einer OQ-XXX-ID, dem betroffenen Element und der Angabe, ob sie blockiert. Der Skill /open-questions listet, beantwortet und zieht Fragen zurück. /use-case-spec, /requirements und /entity-model übernehmen die Antworten dann in die Spezifikation. Die Implementierung lässt nur weg, was eine blockierende Frage betrifft. Alles andere wird gebaut.

Entscheidungsrechte. /use-case-implement teilt jede Konstruktionsentscheidung in drei Gruppen ein: Der Agent entscheidet allein, der Agent fragt zuerst, oder der Agent tut es nie. Ein Projekt kann die Vorgaben in docs/architecture/decision-rights.md anpassen. Eine neue Abhängigkeit oder eine Abweichung von einem ADR braucht immer eine Rückfrage. Jeder Implementierungsbericht listet die Entscheidungen auf, die der Agent allein getroffen hat, damit man sie prüfen kann.

Architekturentscheidungen. Der neue Skill /architecture-decision entwirft ADRs aus einer Entscheidung, die man in einfachen Worten formuliert. Jeder ADR verweist auf mindestens eine nicht-funktionale Anforderung oder Randbedingung, damit klar ist, warum es ihn gibt. Die Konstruktions-Skills folgen nur akzeptierten ADRs.

Die Transition-Phase #

Der Unified Process hat vier Phasen: Inception, Elaboration, Construction und Transition. Bisher hörten die Plugins nach der Construction auf. Drei neue Skills schliessen diese Lücke. Alle arbeiten mit der Spezifikation, nicht mit dem Code:

• /user-guide schreibt das Benutzerhandbuch aus den Use Cases, die getestet oder fertig sind. Beim zweiten Lauf lässt er unveränderte Abschnitte in Ruhe, schreibt die Abschnitte neu, deren Use Case sich geändert hat, und fragt nach bei Abschnitten, die jemand von Hand bearbeitet hat.
• /acceptance-protocol führt eine Abnahmerunde mit den Benutzern durch. Erst nach Ihrer Bestätigung wechselt ein Use Case auf Done. Nur hier passiert das.
• /release-notes listet die Use Cases, die seit dem letzten Git-Tag Done erreicht haben, in der Sprache des Fachbereichs.

Impact-Analyse und /next #

Zwei Fragen kommen in jedem Projekt: «Was betrifft diese Änderung?» und «Was mache ich als Nächstes?»

/spec-review impact FR-014 beantwortet die erste. Der Befehl listet jeden Use Case, Test Case, Geschäftsprozess und Test, den eine Änderung an einer Anforderung, Geschäftsregel oder einem Use Case betrifft, und zeigt die Spur hinter jedem Treffer. Dank der Traceability-Marker in Code und Tests funktioniert das bis hinunter zur Implementierung.

/next beantwortet die zweite. Der Befehl liest den Zustand des Projekts und nennt den nächsten Befehl mit Begründung: ein fehlendes Dokument, eine blockierende Frage, ein Use Case, der auf ein Review wartet, fehlende Tests oder eine Abnahmerunde. Er führt selbst nie etwas aus. Das hilft besonders, wenn man neu im AI Unified Process ist.

Evals für jeden Skill #

Skills sind Prompts, und Prompts driften. Jeder Core-Skill hat jetzt Eval-Szenarien, darunter eine durchgehende Kette von der Implementierung über die Tests bis zum Coverage-Audit für Vaadin Flow mit jOOQ und für REST mit JPA. Die Szenarien verwenden die echten Layer-Skills, keine gekürzten Kopien, und die CI schlägt fehl, wenn die Fixtures abweichen. Zusätzlich lief das Book-Library-Tutorial mehrmals durch, und jede Lücke, die der Agent dabei gefunden hat, ist behoben.

Neu im Studio #

Das AI Unified Process Studio ist die Webanwendung für alle, die die Spezifikation schreiben und prüfen, aber nicht mit Git oder einer IDE arbeiten wollen. Es wird selbst mit dem AI Unified Process spezifiziert und gebaut. Version 1.18 bringt diese Funktionen:

• Editor für offene Fragen. Eine Tabelle aller offenen Fragen mit Filtern nach Status, Blocking und Element der Spezifikation, dazu ein Detail-Editor, um Fragen zu erfassen, zu bearbeiten, zurückzuziehen, wieder zu öffnen oder als gelöst zu markieren. Ein Business Analyst kann eine Frage beantworten oder eine Annahme des Agenten bestätigen oder korrigieren, ohne je Git zu öffnen. Das ist das Gegenstück zum Skill /open-questions.
• Geschäftsprozesse modellieren. Ein BPMN-2.0-Editor direkt im Studio. Jede Aktivität entspricht einem Use Case, und das Modell wird im Git-Repository neben den anderen Artefakten gespeichert. Das Diagramm lässt sich als PNG exportieren.
• Test Cases aus einem Geschäftsprozess. Das Studio leitet pro Pfad durch den Prozess einen End-to-End-Test-Case ab. Der Test Case verkettet die Use Cases der Aktivitäten in der Reihenfolge des Prozesses.
• PDF-Export. Jedes geöffnete Artefakt lässt sich als PDF herunterladen, um es mit Personen ohne Zugang zum Studio oder zum Repository zu teilen.
• Repository-Zugriff pro Benutzer. Ein Administrator legt fest, an welchen Repositories jeder Benutzer arbeiten darf.

Dazu kommen viele kleinere Verbesserungen: Der Auslöser eines Use Case lässt sich jetzt im strukturierten Editor bearbeiten, im Dateibrowser kann man jeden Dateityp anlegen, und die Traceability-Ansicht zeigt ihre Badges vollständig an.

Upgrade #

Wer die Plugins schon vor Oktober verwendet hat, sollte diese Punkte prüfen:

• Die Layer-Plugins brauchen aiup-core 3.0.0 oder neuer.
• /stack einmal ausführen. Der Befehl übernimmt eine bestehende docs/architecture/development.md, ohne die Fragen zu den Schichten erneut zu stellen.
• docs/open-questions.md in docs/open_questions.md umbenennen, wie entity_model.md und use_cases.puml. Die Skills lesen den alten Namen nicht mehr.
• Wer aiup-vaadin-jooq oder aiup-angular-jpa einsetzt, folgt Bestehendes Projekt umstellen.

Kurz gesagt #

Die meisten Änderungen im Oktober haben eines gemeinsam: Sie machen Lücken sichtbar. Lücken in der Spezifikation werden zu offenen Fragen. Die Entscheidungen des Agenten werden zu einer Liste, die man prüfen kann. Die Auswirkungen einer Änderung werden zu einer Spur, der man folgen kann. Und die Transition-Phase sorgt dafür, dass die Spezifikation nicht beim Code endet, sondern bei einem abgenommenen Release.

Wer die neuen Plugins ausprobiert: Feedback ist sehr willkommen. Eröffnen Sie ein Issue im Marketplace-Repository oder nehmen Sie Kontakt auf.