What's new in October 2026

October was a busy month for the AI Unified Process. aiup-core went from 3.0.0 to 3.10.0, seven new layer plugins joined the marketplace, and the AI Unified Process Studio got six new use cases. Here is what changed and why.

Most of these changes came from real projects. Some came from running the Book Library tutorial again and again and closing every gap the agent found. Others came from discussions with people who use the plugins.

Layer plugins instead of stack plugins #

Until now, you picked one stack plugin like aiup-vaadin-jooq or aiup-angular-jpa. This worked as long as your project used exactly that combination. But real projects don't. One uses Vaadin with JPA. Another has only a REST API. A third uses Flyway, jOOQ, and Angular.

So the stacks are now split into layer plugins that you combine per project:

• aiup-flyway for the migration layer
• aiup-jooq and aiup-jpa for the persistence layer
• aiup-spring-boot for the service layer, the REST API, and calls to external systems
• aiup-vaadin for Vaadin Flow and Hilla UIs
• aiup-angular for an Angular UI
• aiup-playwright for end-to-end tests

The new /stack command records which layers your project has in docs/architecture/stack.md. It detects the stack from pom.xml and package.json, finds the installed layer skills, and asks only what it cannot detect. It works next to arc42, C4, or 4+1 documentation. It reads them, but never changes them.

Then /use-case-implement UC-001 builds the use case bottom-up through the layers: migration, persistence, client, service, API, UI. /use-case-test UC-001 tests it once in the integration layer, and /use-case-coverage UC-001 checks every step, alternative flow, and business rule against the code and the tests.

The combined stack plugins aiup-vaadin-jooq and aiup-angular-jpa are deprecated. Layer plugins explains the new way in detail and how to move an existing project.

Mockups, API contracts, and external systems #

A use case describes behavior. But a project often has more input than that: a Figma design, an agreed OpenAPI contract, or a payment provider the system must call. Three additions connect these inputs to the use case:

• Mockup line. It links a Figma frame, an image, or a Markdown sketch. The UI skills take the layout from it. The specification still decides which fields, actions, and messages exist. If the mockup contradicts the specification, the agent records an open question.
• API line. It links an operation in an OpenAPI contract. Unlike a mockup, the contract is binding, because a partner system has already built against it. /spring-rest builds the operation exactly as written, and the tests take the expected statuses and payloads from the contract.
• External systems. They are recorded in the stack file. The new Client layer creates a port and an adapter from the provider's contract. No test ever reaches the real system; the tests use a fake of the port instead. And before the agent adds a retry, a timeout, or a fallback, it asks.

Open questions, decision rights, and ADRs #

An agent takes many hidden decisions while it writes code. Simon wrote about this in Five Agents, Fifty Decisions. Three changes make these decisions visible.

Open questions. When the agent finds a gap in the specification, it no longer guesses. It records the question in docs/open_questions.md with an OQ-XXX id, the element it is about, and whether it blocks. The /open-questions skill lists, answers, and withdraws questions. /use-case-spec, /requirements, and /entity-model then take the answers into the specification. The implementation leaves out only what a blocking question is about. Everything else gets built.

Decision rights. /use-case-implement sorts every construction decision into three groups: the agent decides alone, the agent asks first, or the agent never does it. A project can change the defaults in docs/architecture/decision-rights.md. Adding a new dependency or deviating from an ADR always needs a question. Every implementation report lists the decisions the agent took alone, so you can review them.

Architecture decisions. The new /architecture-decision skill drafts ADRs from a decision you state in plain words. Each ADR links to at least one non-functional requirement or constraint, so you know why it exists. The construction skills follow only accepted ADRs.

The Transition phase #

The Unified Process has four phases: Inception, Elaboration, Construction, and Transition. Until now, the plugins stopped after Construction. Three new skills close this gap. All of them work from the specification, not from the code:

• /user-guide writes the user guide from the use cases that are tested or done. On a second run, it leaves unchanged sections alone, rewrites the sections whose use case changed, and asks you about sections someone edited by hand.
• /acceptance-protocol runs a user acceptance round. Only after you confirm does a use case move to Done. This is the only place where that happens.
• /release-notes lists the use cases that reached Done since the last Git tag, in business language.

Impact analysis and /next #

Two questions come up in every project: "What does this change affect?" and "What do I do next?"

/spec-review impact FR-014 answers the first one. It lists every use case, test case, business process, and test that a change to a requirement, business rule, or use case affects, and shows the trace behind each hit. Thanks to the traceability markers in code and tests, this works all the way down to the implementation.

/next answers the second one. It reads the state of the project and names the next command with its reason: a missing document, a blocking question, a use case waiting for review, missing tests, or an acceptance round. It never runs anything itself. This is especially helpful when you are new to the AI Unified Process.

Evals for every skill #

Skills are prompts, and prompts drift. Every core skill now has eval scenarios, including an end-to-end chain from implementation to tests to the coverage audit for Vaadin Flow with jOOQ and for REST with JPA. The scenarios run the real layer skills, not trimmed copies, and CI fails when the fixtures drift. On top of that, the Book Library tutorial ran several times, and every gap the agent found along the way is fixed.

What's new in the Studio #

The AI Unified Process Studio is the web application for the people who write and review the specification but don't want to work in Git or an IDE. It is specified and built with the AI Unified Process itself. Version 1.18 brings these features:

• Open questions editor. A table of all open questions with filters by status, blocking, and specification element, and a detail editor to add, edit, withdraw, reopen, or resolve a question. A business analyst can answer a question, or confirm or correct a default the agent assumed, without ever opening Git. This is the counterpart to the /open-questions skill.
• Business process modeling. A BPMN 2.0 editor right in the Studio. Every activity maps to a use case, and the model is saved in the Git repository next to the other artifacts. You can export the diagram as PNG.
• Test cases from a business process. The Studio derives one end-to-end test case per path through the process. The test case chains the use cases of the activities in process order.
• PDF export. Any artifact you open can be downloaded as a PDF to share with people who have no access to the Studio or the repository.
• Repository access per user. An administrator decides which repositories each user can work on.

There are also many smaller improvements: the trigger of a use case is now editable in the structured editor, you can create any file type in the file browser, and the traceability view shows its badges in full.

Upgrading #

If you used the plugins before October, check these points:

• The layer plugins need aiup-core 3.0.0 or later.
• Run /stack once. It takes over an existing docs/architecture/development.md without asking the layer questions again.
• Rename docs/open-questions.md to docs/open_questions.md, like entity_model.md and use_cases.puml. The skills no longer read the old name.
• If you use aiup-vaadin-jooq or aiup-angular-jpa, follow Moving an existing project.

In short #

Most of the changes in October have one thing in common: they make the gaps visible. The gaps in the specification become open questions. The decisions the agent takes become a list you can review. The impact of a change becomes a trace you can follow. And the Transition phase makes sure the specification doesn't end with the code, but with an accepted release.

If you try the new plugins, feedback is very welcome. Open an issue in the marketplace repository or get in touch.