Der AI Unified Process (AIUP) trennt seit jeher die stack-unabhängigen Spezifikationen von ihrer Konstruktion. Im alten Marketplace lag die Konstruktion in einem kombinierten Stack-Plugin: Ein Plugin bündelte alles nach den Spezifikationen für eine feste Technologiekombination.
aiup-core schrieb die Anforderungen, das Entitätsmodell, die Use Cases und die Testfälle. Ein Projekt installierte dann genau ein Stack-Plugin, und dieses Plugin brachte einen Migrations-Skill, /implement, ein oder zwei Test-Skills, /playwright-test und in zwei Fällen /coverage-check mit. Die vier Stacks:
aiup-vaadin-jooq– Vaadin Flow oder Hilla mit jOOQ: /flyway-migration, /implement, /implement-hilla, /browserless-test, /hilla-test, /playwright-test, /coverage-checkaiup-angular-jpa– Angular mit Spring Boot und JPA: /flyway-migration, /implement, /spring-boot-test, /vitest-test, /playwright-test, /coverage-checkaiup-blazor-dotnet– Blazor und EF Core auf .NET 10: /ef-migration, /implement, /dotnet-test, /bunit-test, /playwright-testaiup-nestjs-nextjs– NestJS und Drizzle mit Next.js: /drizzle-migration, /implement, /nest-test, /react-test, /playwright-testEin Projekt kombiniert aiup-core mit einem Plugin pro technischer Schicht. Die Kombination steht in der Stack-Datei des Projekts, und sechs Befehle in aiup-core führen die Layer-Skills der Reihe nach aus. aiup-core selbst weiss nichts über eine Technologie.
| Schicht | Baut | Plugin | Skills |
|---|---|---|---|
| Migration | Versionierte Schemaänderungen aus dem Entitätsmodell | aiup-flyway | /flyway-schema |
| Persistenz | Abfragen, Repositories, Entity-Mapping, Projektionen | aiup-jooq oder aiup-jpa | /jooq-persistence, /jpa-persistence, je mit einem -test-Skill |
| Service | Geschäftslogik, Transaktionen, Geschäftsregeln | aiup-spring-boot | /spring-service, /spring-service-test |
| API | Endpoints, DTOs und Fehlerformat für einen separaten Client | aiup-spring-boot | /spring-rest, /spring-rest-test |
| UI | Views, Formulare, Grids, Navigation | aiup-vaadin oder aiup-angular | /vaadin-flow-ui, /hilla-ui, /angular-ui, je mit einem -test-Skill |
| E2E | Browser-Tests eines Use Case oder einer Testfall-Journey | aiup-vaadin oder aiup-playwright | /vaadin-e2e-test, /playwright-e2e-test |
Die Stack-Datei hält fest, welcher Layer-Skill welche Schicht baut und testet. Sie liegt immer unter docs/architecture/stack.md, einem Pfad, den jeder Skill liest. Die Stack-Datei gehört zum AI Unified Process, nicht zu Ihrer Architekturdokumentation: Ob das Team arc42, C4, Kruchtens 4+1-Sichten, ein einzelnes docs/architecture.md oder gar nichts schreibt, die Stack-Datei liegt daneben und sieht gleich aus. /stack liest diese Dokumente und die Architekturentscheidungen als Eingabe und schreibt, verschiebt oder indexiert sie nie.
/stack erkennt den Stack eines bestehenden Projekts aus pom.xml, package.json und dem Quellbaum, fragt nach, was es nicht erkennen kann, und hält fest, welcher Skill welche Schicht baut und testet. Eine Schicht, die das Projekt nicht hat, erhält einen Strich. Unter der Layers-Tabelle nennt eine Tabelle zur Integrationsschicht für jede Einstiegsschicht die Schicht, in der ein Use Case getestet wird, und mit einer End-to-End-Schicht hält eine Zeile zum E2E-Umfang fest, ob Browsertests jeden über die UI angebotenen Use Case abdecken oder nur die Testfall-Journeys. Die Datei enthält ausserdem das Modul-Layout, den API-Vertrag, die Build- und Testbefehle und die Marker-Tabelle, die die Coverage-Prüfung liest. /stack besitzt nur die Abschnitte Layers und Markers und schreibt die anderen drei nur, wenn ihre Überschrift fehlt oder sie noch den Platzhalter der Vorlage enthalten; was das Team von Hand geschrieben hat, bleibt.
Migration– Flyway: flyway-schemaPersistence– jOOQ: jooq-persistence, jooq-persistence-testService– Spring Boot: spring-service, spring-service-testAPI– Spring REST: spring-rest, spring-rest-testUI–E2E–Das ist die Layers-Tabelle einer REST-API mit Spring Boot und jOOQ: ein Projekt, das der alte Marketplace nicht abbilden konnte. Seine Integrationsschicht ist die API.
Die Orchestrierung ist vom Stack-Plugin nach aiup-core gewandert. Die Befehle heissen use-case-<Schritt> und test-case-<Schritt>, neben /use-case-spec und /test-case, damit sie nie mit dem /implement eines kombinierten Stack-Plugins kollidieren und alte und neue Plugins in einem Agent-Host nebeneinander existieren können. Die Namen sind endgültig: Sie bleiben, wenn die kombinierten Stacks verschwunden sind.
/stack– die Stack-Datei schreiben oder aktualisieren/use-case-implement UC-001– Die Layer-Skills der Spalte Skill von unten nach oben ausführen: Migration, Persistenz, Service, API, UI/use-case-test UC-001– Die Test-Skills von der Integrationsschicht aufwärts ausführen/use-case-coverage UC-001– Code und Tests mit den Markern aus der Stack-Datei gegen die Spezifikation prüfen/test-case-implement TC-001– Eine Testfall-Journey mit dem End-to-End-Test-Skill automatisieren/test-case-coverage TC-001– Einen Journey-Test gegen seinen Testfall prüfen/use-case-implement und /use-case-test nehmen auch Schichtnamen entgegen: "/use-case-implement UC-001 api" baut nur die API-Schicht. Und jeder Layer-Skill läuft weiterhin allein: "/jooq-persistence UC-001" liest dieselben Eingaben und folgt denselben Regeln.
UI, API und, für einen Use Case, den kein Akteur über eine der beiden erreicht, etwa ein geplanter Job, der Service sind die Einstiegsschichten: wo ein Akteur das System erreicht. Ein Use Case kann in einer optionalen Zeile Schichten nennen, über welche Einstiegsschichten er angeboten wird. Ohne die Zeile bietet jede Einstiegsschicht des Projekts ihn an. Damit lässt sich eine Vaadin-Flow-Anwendung mit einer REST-API daneben ausdrücken: Eine Administrationsmaske ohne API sagt "Schichten: UI", eine Partnerschnittstelle ohne Maske sagt "Schichten: API".
/use-case-implement baut nur die genannten Einstiegsschichten, dazu Migration, Persistenz und Service, soweit der Use Case sie braucht. /use-case-test testet in der obersten In-Process-Schicht, die der Use Case nutzt; ein reiner API-Use-Case einer Vaadin-Flow-Anwendung wird also in der API-Schicht getestet. /use-case-coverage meldet keine Lücke für eine Schicht, die die Zeile auslässt. Die Zeile nennt Einstiegspunkte, nie eine Technologie; /use-case-spec schreibt sie, in englischen Spezifikationen heisst sie Layers.
Die Implementierung läuft in der Reihenfolge Migration, Persistenz, Service, API, UI. Die Tests laufen von der Integrationsschicht aufwärts und enden mit End-to-End, soweit der E2E-Umfang in der Stack-Datei das verlangt. Jeder Layer-Skill endet mit einem Handover-Block, der die Tabellen, Record-Typen, Methodensignaturen oder Endpoints nennt, die er erstellt oder geändert hat. Die nächste Schicht baut genau auf diesem Vertrag auf und erfindet kein DTO und keine Methode neu, die die Schicht darunter schon liefert.
Die Stack-Datei nennt auch die Integrationsschicht, mit einer Zeile pro Einstiegsschicht des Projekts (UI, API, Service): die Schicht, deren Test-Skill im Prozess gegen den echten Service und die echte Datenbank läuft. Ein Use Case wird in der ersten Zeile getestet, die seine Schichten-Zeile nennt. In einer Vaadin-Flow-Anwendung ist das die UI, weil ihre Browserless-Tests den Service und das Repository wirklich ausführen. In einem REST-Service oder hinter einem Angular-Client ist es die API. Hinter einer Hilla-UI ist es der Service. /use-case-test führt die Test-Skills von dieser Schicht aufwärts aus und schreibt keine eigenen Tests für die Schichten darunter. Die Tests der Integrationsschicht decken den ganzen Use Case ab: das Hauptszenario, jeden Alternativablauf, jede Geschäftsregel mit ihrem erlaubten und ihrem abgelehnten Fall und die Nachbedingungen, aus dem gespeicherten Zustand zurückgelesen.
Eine tiefere Schicht erhält weiterhin Tests in vier Fällen: wenn sie eine zweite Einstiegsschicht des Use Case ist, etwa eine REST-API neben einer Vaadin-Flow- oder Hilla-UI, die dann ihren eigenen Vertrag testet (das Hauptszenario über ihren Endpoint, die Antwort jedes Alternativablaufs und die Abbildung der Validierung), die Geschäftsregeln aber nicht noch einmal; wenn ein Lauf sie nennt, etwa "/use-case-test UC-001 persistence"; wenn sie bereits Tests des Use Case enthält, die abzugleichen sind; oder wenn der Skill der Integrationsschicht eine Einheit meldet, die er über seinen Einstiegspunkt nicht erreicht. Die Coverage-Prüfung liest dieselbe Tabelle, sodass eine übersprungene Schicht nie als Lücke gemeldet wird. Eine Stack-Datei, die noch eine einzelne Zeile zur Integrationsschicht hat, erhält die Tabelle beim nächsten Lauf von /stack; bis dahin übergibt /use-case-test an /stack.
Was sich für ein Team ändert, das die Plugins installiert, und was der Wechsel bringt.
| Kombiniertes Stack-Plugin, bis 2.x | Layer-Plugins, seit 3.0.0 | |
|---|---|---|
| Was Sie installieren | aiup-core plus genau ein Stack-Plugin | aiup-core plus ein Plugin pro Schicht |
| Kombinationen | Vier feste Stacks | Jede Kombination aus dem Katalog, auch eine REST-API ohne UI oder eine Vaadin-UI mit einer REST-API daneben |
| Wo die Schichten stehen | Fest im Plugin verdrahtet | Die Stack-Datei, docs/architecture/stack.md, geschrieben von /stack |
| Implementierung | /implement des Stack-Plugins baut den ganzen Durchstich | /use-case-implement in aiup-core führt die Layer-Skills von unten nach oben aus, mit Übergabe dazwischen |
| Tests | Ein Test-Skill pro Werkzeug: /browserless-test, /spring-boot-test, /vitest-test, /playwright-test | /use-case-test führt die Test-Skills von der Integrationsschicht aufwärts aus, sodass ein Use Case einmal getestet wird; jeder Test-Skill läuft weiterhin allein |
| Coverage-Prüfung | /coverage-check, nur in aiup-vaadin-jooq und aiup-angular-jpa | /use-case-coverage in aiup-core, für jede Kombination |
| Gemeinsame Regeln | In das /implement jedes Plugins kopiert | Einmal, in /use-case-implement und /use-case-test |
| Marker für die Prüfung | Eine feste Liste im Agenten jedes Plugins | Die Marker-Tabelle in der Stack-Datei, gepflegt von den Layer-Skills |
| Eine Technologie ergänzen | Ein neues Stack-Plugin mit fünf oder mehr Skills | Ein Layer-Plugin mit ein oder zwei Skills; seine references/layer.md lässt /stack es ohne Core-Release finden. Auch ein eigener Skill des Teams zählt, mit oder ohne layer.md |
| Version | Jedes Plugin mit eigener Version | aiup-core und die Layer-Plugins teilen eine Hauptversion; die Layer-Plugins brauchen aiup-core 3.0.0 oder neuer |
Installieren Sie aiup-core in jedem Projekt, dann ein Plugin pro Schicht, die das Projekt hat. Verwenden Sie entweder Layer-Plugins oder ein kombiniertes Stack-Plugin, nie beides: Die kombinierten Plugins lesen die Stack-Datei nicht.
REST-API, Spring Boot, jOOQ– aiup-flyway, aiup-jooq, aiup-spring-boot. Integrationsschicht: APIREST-API, Spring Boot, JPA– aiup-flyway, aiup-jpa, aiup-spring-boot. Integrationsschicht: APIVaadin Flow oder Hilla, jOOQ– aiup-flyway, aiup-jooq, aiup-spring-boot, aiup-vaadin. Integrationsschicht: UI mit Flow, Service mit HillaVaadin Flow und eine REST-API, jOOQ– aiup-flyway, aiup-jooq, aiup-spring-boot, aiup-vaadin. Integrationsschicht: UI, und die API für Use Cases, deren Schichten-Zeile nur die API nennt. Für einen Use Case, der über beide angeboten wird, testet die API ihren eigenen VertragAngular, Spring Boot, JPA– aiup-flyway, aiup-jpa, aiup-spring-boot, aiup-angular, aiup-playwright. Integrationsschicht: APIEine serverseitige UI wie Vaadin Flow ruft die Service-Schicht direkt auf und braucht keine API-Schicht; in einem Projekt ohne Service-Schicht darf sie die Repositories aufrufen, solange Flow die einzige Einstiegsschicht ist; eine API-Schicht daneben bedient andere Clients, etwa eine Mobile-App oder ein Partnersystem. Eine clientseitige UI wie Angular braucht immer eine: Ein Use Case, der über eine Angular-UI angeboten wird, wird auch in der API-Schicht gebaut und dort getestet. Der Hilla-Endpoint gehört zu /hilla-ui, nicht zu einer separaten API-Schicht. Deckt kein Layer-Plugin eine Ihrer Technologien ab, trägt /stack die Technologie mit einem Strich in der Spalte Skill ein, und /use-case-implement baut diese Schicht aus eigenem Wissen und nach den Konventionen des Projekts.
Das Beispiel ist eine REST-API mit Spring Boot und jOOQ. Ergänzen Sie aiup-vaadin für eine Vaadin-UI oder aiup-angular und aiup-playwright für eine Angular-UI.
Tessl installiert die Skills für Codex, Cursor, GitHub Copilot, Gemini CLI und OpenCode und fixiert die Versionen. Siehe andere KI-Coding-Tools.
Sind die Spezifikationen freigegeben, durchläuft ein Use Case vier Befehle. Der erste läuft einmal pro Projekt.
Einmal pro Projekt und erneut, wenn sich eine Schicht ändert. In einem bestehenden Projekt erkennt der Skill den Stack und fragt nur dort nach, wo zwei Technologien passen, etwa JPA und jOOQ beide auf dem Classpath. In einem neuen Projekt fragt er pro Schicht nach einer Technologie, und bietet einen Strich für eine Schicht an, die das Projekt nicht braucht. Er schreibt die Stack-Datei nach docs/architecture/stack.md, prüft danach, ob jeder eingetragene Skill installiert ist, und nennt die fehlenden Plugins.
Liest den Use Case, genau die Anforderungen, die seine Requirements-Zeile verknüpft, das Entitätsmodell, das Glossar und die Stack-Datei. Prüft die Status-Zeile, sammelt die Lücken aller Schichten, damit Sie einmal antworten, nennt dann, was laufen wird und was die Schichten-Zeile des Use Case auslässt, und führt die Layer-Skills von unten nach oben aus, wobei jede Übergabe an die nächste Schicht geht. Schreibt keine Tests und endet mit einer Liste offener Fragen an die Spezifikation.
Führt die Test-Skills von der Integrationsschicht aufwärts aus. Die Tests dieser Schicht prüfen den ganzen Use Case gegen den echten Service und die echte Datenbank: jede Geschäftsregel mit ihrem erlaubten und ihrem abgelehnten Fall, jeden Alternativablauf und die Nachbedingungen, aus dem gespeicherten Zustand zurückgelesen. Eine UI, die ihr Backend simuliert, etwa Hilla oder Angular, testet nur, was die UI entscheidet und dass eine Ablehnung den Akteur erreicht; die End-to-End-Schicht testet die Szenarien, die ein Akteur im Browser sieht. Bestehende Tests werden aktualisiert, nicht dupliziert. Ein Test, der fehlschlägt, weil der Code der Spezifikation widerspricht, bleibt fehlschlagend und wird gemeldet; welche Seite falsch liegt, entscheiden Sie.
Ein nur lesender Sub-Agent bildet jeden Schritt, jeden Alternativablauf, jede Geschäftsregel, jede Vor- und Nachbedingung und jede verknüpfte NFR oder Rahmenbedingung auf den Code und die Tests dahinter ab, mit den Markern aus der Stack-Datei. Er meldet Lücken und Abweichungen und schlägt den nächsten Wert für die Status-Zeile vor. Er ändert nie eine Datei; eine Lücke schliesst erneut /use-case-implement oder /use-case-test.
Ein Projekt auf aiup-vaadin-jooq oder aiup-angular-jpa behält seinen Code, seine Tests und seine Dokumente. Die Plugins, die Befehlsnamen und der Ort der UseCase-Annotation ändern sich. Der Migrationsleitfaden im Marketplace beschreibt den vollständigen Ablauf.
Entfernen Sie das kombinierte Plugin über die Plugin-Verwaltung Ihres Agenten, aktualisieren Sie aiup-core auf 3.0.0 oder neuer und installieren Sie die Layer-Plugins Ihres Stacks.
aiup-vaadin-jooq– wird zu aiup-flyway, aiup-jooq, aiup-spring-boot, aiup-vaadinaiup-angular-jpa– wird zu aiup-flyway, aiup-jpa, aiup-spring-boot, aiup-angular, aiup-playwrightDer Skill erkennt Flyway, jOOQ oder JPA, Spring Boot und das UI-Framework aus den Build-Dateien und dem Quellbaum, hält das Modul-Layout, die Befehle und die Integrationsschicht fest und schreibt die Stack-Datei nach docs/architecture/stack.md. Bestehende Architekturdokumentation, ein docs/architecture.md, arc42 oder C4, wird als Eingabe gelesen und bleibt, wo sie ist. Am Code ändert sich nichts. Die Marker-Tabelle füllt sich beim nächsten Lauf jedes Layer-Skills.
Die kombinierten Plugins haben die Annotation unter src/main/java angelegt. Die Layer-Test-Skills suchen sie in den Testquellen des getesteten Moduls und würden dort eine zweite Kopie anlegen. Verschieben Sie die Datei vor dem ersten /use-case-test nach src/test/java und behalten Sie das Package bei, damit sich kein Import ändert. Fehlt der Annotation das Attribut requirements, das die NFR- und Rahmenbedingungs-IDs nennt, die ein Test prüft, ergänzen die Layer-Test-Skills es. Ein hexagonales Projekt erhält eine Kopie pro Modul mit Use-Case-Tests.
/flyway-migration– /flyway-schema, normalerweise von /use-case-implement ausgeführt/implement– /use-case-implement/implement-hilla– /use-case-implement, mit hilla-ui in der UI-Zeile der Layers-Tabelle/browserless-test– /vaadin-flow-ui-test, die Integrationsschicht einer Vaadin-Flow-Anwendung, von /use-case-test ausgeführt/hilla-test– /hilla-ui-test für die Views, /spring-service-test für den Service dahinter/spring-boot-test– /spring-rest-test als Integrationsschicht hinter Angular; /spring-service-test und /jpa-persistence-test nur, wenn ein Lauf sie nennt oder eine Einheit ausserhalb der Reichweite der API liegt/vitest-test– /angular-ui-test/playwright-test– /vaadin-e2e-test oder /playwright-e2e-test, auch als /test-case-implement TC-001/coverage-check– /use-case-coverage UC-XXX, /test-case-coverage TC-XXX/karibu-test– Nicht übernommen. Browserless Testing löst Karibu ab; bestehende Karibu-Tests laufen weiterÄndert sich das nächste Mal ein Use Case, findet /use-case-implement die bestehenden Views, Services und Repositories über die Namen, die die Spezifikation nahelegt, und über ihre UC-XXX-Verweise und ändert sie an Ort und Stelle. Code, den das kombinierte Plugin geschrieben hat, wird genauso abgeglichen wie Code der Layer-Plugins. Die Service-Schicht, die das alte /implement als Teil des Durchstichs baute, gehört jetzt zu /spring-service und wird von ihm abgeglichen.
Die Layer-Plugins ändern, wie die Konstruktion organisiert ist, nicht, was sie liest oder wie sie rückverfolgt wird. Alles, was der Stack-Leitfaden beschreibt, gilt weiterhin.
Der Use Case, genau die Anforderungen, die er verknüpft, das Entitätsmodell, das Glossar und die Architekturentscheidungen. Die Grenze zwischen aiup-core und der Konstruktion sind weiterhin die Dateien unter docs/.
Ein Kommentar UC-XXX GR-YYY über dem Code, der eine Geschäftsregel durchsetzt, und @UseCase oder ein describe-Block, der in jedem Test Use Case, Szenario und Regeln nennt.
Ein neues Feature, eine Änderung und ein Bug enden alle in einem geänderten Use Case. Die Skills finden den bestehenden Code und ändern ihn an Ort und Stelle; eine zweite View für denselben Use Case bleibt der Fehler, den sie verhindern sollen.
Erwartete Werte stammen aus der Spezifikation, nie aus dem, was der Code zurückgibt. Ein Widerspruch wird gemeldet, nicht durch eine abgeschwächte Zusicherung überdeckt.
Kein Skill ändert die Status-Zeile eines Use Case. Die Coverage-Prüfung schlägt den nächsten Wert vor; ein Mensch setzt ihn.
Anforderung zu Use Case zu Geschäftsregel zu Code und Test, und Geschäftsprozess zu Testfall zu Journey-Test, mit denselben Bezeichnern wie bisher.
Installieren Sie aiup-core 3.0.0 und die Layer-Plugins Ihres Stacks, führen Sie /stack aus, und der nächste Use Case läuft über /use-case-implement. AI Unified Process Studio schreibt die Spezifikationen, die diese Befehle lesen; fordern Sie eine Einladung an, oder nehmen Sie Kontakt auf, wenn Sie Unterstützung bei der Wahl der Kombination für Ihre Architektur möchten.