diff --git a/CHANGELOG.md b/CHANGELOG.md
index fbaab56..c662470 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,12 +1,12 @@
-# next version
+# 1.4.0
 
-- Show the UCP tools only to UCP agents instead of on every Store API MCP connection. 1.3.0 put them into the group Shopware reserves for its own discovery tools, so every client connecting to `/store-api/_mcp` saw the thirteen UCP tools next to Shopware's instruction that no tools are listed until a toolset is enabled -- and models followed that instruction, enabling toolsets for tools they already had. The tools now form their own `ucp` toolset, and `/ucp/mcp` selects it at connect time, so a UCP agent still finds them on its first tool listing while a plain `/store-api/_mcp` connection lists only Shopware's discovery tools. On Shopware versions before `6.7.15.0`, which cannot select a toolset at connect time, the tools stay listed on every connection as before.
+- Show the UCP tools only to AI agents that connect through `/ucp/mcp`, instead of to every client of Shopware's own MCP server at `/store-api/_mcp`. 1.3.0 put them into the group Shopware reserves for its own discovery tools, so every client connecting to `/store-api/_mcp` saw the thirteen UCP tools next to Shopware's instruction that no tools are listed until a toolset is enabled -- and models followed that instruction, enabling toolsets for tools they already had. The tools now form their own `ucp` toolset, and `/ucp/mcp` selects it at connect time, so a UCP agent still finds them on its first tool listing while a plain `/store-api/_mcp` connection lists only Shopware's discovery tools. On Shopware versions before `6.7.15.0`, which cannot select a toolset at connect time, the tools stay listed on every connection as before.
 - Link the UCP settings to their documentation. The Exposure sub-tab of the Agentic Commerce tab now carries a link below the capability and transport checkboxes that opens the UCP section of the user documentation in a new tab, in the language of the administration. Until now the tab explained each option only in a one-line tooltip and gave no way to read on.
-- Let an extension register its own UCP OAuth scope. The supported scopes were a private class constant, so a plugin that adds a UCP capability of its own had no way to make its scope grantable: the token request threw `Unsupported OAuth scope`, and a consent flow that swallowed the error burned its one-time handle and told the buyer the authorization link had expired. Tag a scope provider with `swag_agentic_commerce.ucp.oauth_scope_provider` and its scope is advertised in `scopes_supported` on `/.well-known/oauth-authorization-server` and accepted in an authorization request. A request that omits the scope still gets only the three built-in ones; an extension scope has to be asked for by name. An unregistered scope is still rejected -- now with the supported set named in the message, which is what made this hard to diagnose.
+- Keep the settings that other extensions add to the _General_ tab of a sales channel. The extension replaced the tab's content as a whole, so an extension that passes its own data to the tab lost it, and the tab showed the default settings of a storefront sales channel instead.
+- Let an extension register its own UCP OAuth scope. The supported scopes were a private class constant, so a plugin that adds a UCP capability of its own had no way to make its scope grantable: the token request threw `Unsupported OAuth scope`, and a consent flow that swallowed the error had already used up its one-time link and told the buyer the link had expired. Tag a scope provider with `swag_agentic_commerce.ucp.oauth_scope_provider` and its scope is advertised in `scopes_supported` on `/.well-known/oauth-authorization-server` and accepted in an authorization request. A request that omits the scope still gets only the three built-in ones; an extension scope has to be asked for by name. An unregistered scope is still rejected -- now with the supported set named in the message, which is what made this hard to diagnose.
 - Require Shopware `6.5.8` or newer. `6.5.0.0` through `6.5.7.4` were listed as compatible but could never install: those versions ship Symfony 6.3, while both the extension's own routes and the UCP SDK need Symfony 6.4. Installation therefore ended in a Composer error about `symfony/config` that a merchant cannot act on. Such a shop now sees the extension as incompatible; updating to `6.5.8.x` fixes that and stays inside the same minor.
-- Let Shopware install the UCP SDK instead of shipping it inside the archive. 1.3.0 put the SDK in the plugin's own `vendor/` and loaded the autoloader Composer had generated for it, because Shopware does not load a plugin's `vendor/autoload.php` by itself. Every shop that installed it then carried two separate package registries: FroshTools reported `2 autoloaders registered`, and a question as ordinary as which version of a package is installed could be answered from the plugin's copy instead of the shop's. The extension now carries no dependencies at all. It has Shopware run `composer require` on install and update instead, which is what that mechanism is there for on a zip-installed extension: the extension itself resolves from the `custom/plugins/*` path repository every Shopware project declares, and the SDK version it names comes from Packagist into the shop's own `vendor/`. Nothing changes for a shop that installs through Composer. What is new is that installing has to reach Packagist -- without it the install stops with a Composer error, rather than leaving an extension that cannot run.
+- Let Shopware install the UCP SDK instead of shipping it inside the archive. 1.3.0 put the SDK in the plugin's own `vendor/` and loaded the autoloader Composer had generated for it, because Shopware does not load a plugin's `vendor/autoload.php` by itself. Every shop that installed it then carried two separate package registries: FroshTools reported `2 autoloaders registered`, and a question as ordinary as which version of a package is installed could be answered from the plugin's copy instead of the shop's. The extension now carries no dependencies at all. It has Shopware run `composer require` on install and update instead, which is what that mechanism is there for on a zip-installed extension: the extension itself resolves from the `custom/plugins/*` path repository every Shopware project declares, and the SDK version it names comes from Packagist into the shop's own `vendor/`. Nothing changes for a shop that installs through Composer. What is new is that the shop needs to reach Packagist (`packagist.org`) while installing or updating the extension -- without it the install stops with a Composer error, rather than leaving an extension that cannot run.
 - Switch the extension off instead of taking the shop down when the SDK is missing. An update extracts the new files one request before Shopware runs Composer, so an active extension boots at least once without the dependency it needs. On 1.3.0 every page answered `500` from that moment on, the storefront included, until someone installed the SDK by hand. The extension now registers no services, routes or feeds in that state, and writes to `var/log/swag-agentic-commerce.log` what is missing and the command that fixes it. Once the SDK is there it picks up again on its own. The check asks not only whether an SDK is present but whether it is the version this release names, so a shop still holding the previous one waits instead of running new code against an old SDK. The README has a _Troubleshooting_ section covering what that state looks like, how to leave it, and what to expect when updating from 1.3.0 or older. A cluster setup is the exception: Shopware never runs Composer for a plugin there, so nothing would ever install the requirements, and the extension refuses the install rather than reporting success and then doing nothing.
-- Keep the settings that other extensions add to the _General_ tab of a sales channel. The extension replaced the tab's content as a whole, so an extension that passes its own data to the tab lost it, and the tab showed the default settings of a storefront sales channel instead.
 
 # 1.3.0
 
@@ -17,15 +17,16 @@
 - Answer a UCP request for a cart nobody created with `not_found` instead of handing out a fresh empty cart under the guessed id. Cart ids handed out by `cart.create` are remembered in the same context store the checkout session already uses.
 - Name the UCP MCP tools as the specification's OpenRPC document does (`search_catalog`, `create_cart`, `create_checkout`, `complete_checkout`, `get_order` and so on) and advertise them on a fresh MCP session. They were named `shopware-ucp-*` and hidden behind a toolset an agent had to enable first, so a spec-following agent listing tools on `/ucp/mcp` saw only the toolset meta-tools. An MCP client that called the old names has to switch; the arguments are unchanged.
 - Return real product descriptions from catalog search and lookup, with the product title as the fallback for a product that has none.
-- Apply checkout completion payment data through the platform gateway and expose the applied-discount breakdown.
-- Enforce configured profile-fetch allowlists and prevent checkout tokens from leaking through embedded responses.
-- Completing an agentic checkout keeps working on upcoming Shopware versions: the guest customer created during completion rotates the Shopware context token and moves the cart with it, and the order is now placed against the new token instead of the stale one, which newer Shopware versions reject with a "cart not found" error.
+- Hand the payment an agent sends with `checkout.complete` to an extension point that a payment extension can implement. By default nothing changes for the order: it is still charged with the sales channel's default payment method, and the shop log now warns which payment method the agent asked for.
+- List the discounts applied to a cart one by one under `discounts.applied`, with code, name and amount, instead of only a total.
+- Load agent profiles only from the hosts on the configured allowlist, and keep the secret address of the embedded checkout page from reaching other websites when the buyer clicks through from it.
+- Completing an agentic checkout keeps working on upcoming Shopware versions. Creating the guest customer during completion gives the buyer a new Shopware session, and the order is now placed in that new session instead of the old one, which newer Shopware versions reject with a "cart not found" error.
 - Product links in the OpenAI and Google product feeds now resolve correctly for headless sales channels on Shopware 6.7.14 and newer, so agents receive working product URLs; the feeds keep working unchanged on earlier Shopware versions.
 - Restrict UCP to the sales channels that can actually complete a purchase: Storefront and Headless. Product feed channels are no longer offered for UCP and can no longer have it switched on through the API or the console; one that had it switched on before is now treated as switched off, so no shop is advertised that an agent cannot buy from.
-- Serve `/.well-known/api-catalog` (RFC 9727 linkset) on exposed sales channels, so an agent can discover the shop's UCP profile and Store API entry point from one standardised location; unexposed channels return 404.
+- Serve `/.well-known/api-catalog` (RFC 9727 linkset) on sales channels exposed to UCP, so an agent can discover the shop's UCP profile and Store API entry point from one standardised location; other channels return `404`.
 - Add `ucp:setup`, which configures a sales channel for UCP in one step: exposure, security defaults, a signing key when the channel has none, the readiness checks and the first request to run. `--dev` picks local defaults so the shop can act as its own agent; without it the defaults are production ones. The README now walks through the whole setup in four steps.
-- Count which UCP versions agents actually speak: one `info` record per request on the new `ucp_negotiation` log channel with the agent's declared version, the served version, the outcome and the agent profile host, nothing else. This is the measurement the single-version policy is revisited on, and SDK `0.0.7` reports it.
-- Serve UCP `2026-08-25` through SDK `0.0.7`, including version-aware capability negotiation, the standard catalog capability IDs and updated consent, fulfillment and payment shapes.
+- Count which UCP versions agents actually speak: one `info` record per request on the new `ucp_negotiation` log channel with the agent's declared version, the served version, the outcome and the agent profile host, nothing else. These numbers decide whether the plugin should one day serve more than one UCP version at a time; SDK `0.0.7` reports them.
+- Serve version `2026-08-25` of the UCP specification through SDK `0.0.7`, including version-aware capability negotiation, the standard catalog capability IDs and updated consent, fulfillment and payment shapes.
 - Require the exact UCP SDK version the release was tested against (`0.0.7`) and stop configuring `ucp_sdk.version`. The SDK serves one UCP version per release and defaults to it, so an SDK release now arrives together with a plugin release instead of reaching shops on its own, and the plugin can no longer name a version its linked SDK does not serve. Version 1.2.x combined a pinned `2026-04-08` with a `>=0.0.5 <0.1.0` window: `composer update` resolved SDK 0.0.6, which no longer served that version, and the container build failed inside `assets:install` part-way through a Shopware core upgrade. `docs/ucp-version-support.md` explains what the plugin serves and what a spec bump means for a shop.
 - Store the administration translations in country-agnostic files (`de.json`, `en.json`) following the current Shopware core convention; a compatibility loader keeps them working on Shopware versions before 6.7.3.
 - Polish the administration texts: consistent capitalisation of the informal German address and a clearer "Total" label in the English statistics summary.
@@ -37,7 +38,7 @@
 - Read the shipping address from where UCP sends it, so a checkout with separate shipping and billing addresses no longer ships to the billing one.
 - Always send an absolute, openable order link in `order.permalink_url` -- for guests it is the order's deep link, which works without logging in, and it is the same link the confirmation email uses.
 - Refuse a guest order read in the protocol's own vocabulary: an agent asking for someone else's guest order is told the order was not found and that the permalink is how a guest order is read, rather than receiving an internal error.
-- Add a dry-run mode and actionable error messages to the UCP MCP tools, so an agent that gets a request wrong is told which field and why instead of receiving an opaque failure.
+- Let an agent test a request to the UCP MCP tools before carrying it out: with `dryRun` the request is only checked and nothing is saved. A request that fails now says which field is wrong and why, instead of returning an opaque error.
 - Report the code and severity of a failed agent request, and log the underlying exception, so a failure can be diagnosed from the shop's log.
 - Show the Agentic Commerce tab only on sales channels that can actually sell, and fix tab, template-selection and save-button inconsistencies across Shopware 6.5, 6.6 and 6.7.
 - Mark a product that has variants correctly in the OpenAI feed. `listing_has_variations` was set only when the export had variants switched on, and the variant fields were written for the parent listing as well; the flag now follows the product itself and `variant_dict` appears only on an actual variant.
diff --git a/CHANGELOG_de-DE.md b/CHANGELOG_de-DE.md
index bb68bb3..ad90b77 100644
--- a/CHANGELOG_de-DE.md
+++ b/CHANGELOG_de-DE.md
@@ -1,12 +1,12 @@
-# next version
+# 1.4.0
 
-- Die UCP-Tools sind jetzt nur noch für UCP-Agenten sichtbar und nicht mehr bei jeder MCP-Verbindung zur Store API. In 1.3.0 lagen sie in der Gruppe, die Shopware für seine eigenen Discovery-Tools vorsieht. Jeder Client, der sich mit `/store-api/_mcp` verband, bekam deshalb alle dreizehn UCP-Tools angezeigt, obwohl Shopware ihm gleichzeitig mitteilt, dass Tools erst nach dem Aktivieren eines Toolsets erscheinen. Die Modelle haben sich daran gehalten und Toolsets für Tools aktiviert, die sie längst hatten. Jetzt bilden die Tools ein eigenes Toolset `ucp`, das `/ucp/mcp` direkt beim Verbindungsaufbau auswählt: Ein UCP-Agent sieht sie weiterhin sofort, eine normale Verbindung zu `/store-api/_mcp` zeigt nur noch die Discovery-Tools von Shopware. Unter Shopware-Versionen vor `6.7.15.0`, in denen sich beim Verbindungsaufbau kein Toolset auswählen lässt, bleibt alles wie bisher.
+- Die UCP-Tools sind jetzt nur noch für KI-Agenten sichtbar, die sich über `/ucp/mcp` verbinden, und nicht mehr für jeden Client von Shopwares eigenem MCP-Server unter `/store-api/_mcp`. In 1.3.0 lagen sie in der Gruppe, die Shopware für seine eigenen Discovery-Tools vorsieht. Jeder Client, der sich mit `/store-api/_mcp` verband, bekam deshalb alle dreizehn UCP-Tools angezeigt, obwohl Shopware ihm gleichzeitig mitteilt, dass Tools erst nach dem Aktivieren eines Toolsets erscheinen. Die Modelle haben sich daran gehalten und Toolsets für Tools aktiviert, die sie längst hatten. Jetzt bilden die Tools ein eigenes Toolset `ucp`, das `/ucp/mcp` direkt beim Verbindungsaufbau auswählt: Ein UCP-Agent sieht sie weiterhin sofort, eine normale Verbindung zu `/store-api/_mcp` zeigt nur noch die Discovery-Tools von Shopware. Unter Shopware-Versionen vor `6.7.15.0`, in denen sich beim Verbindungsaufbau kein Toolset auswählen lässt, bleibt alles wie bisher.
 - Die UCP-Einstellungen verweisen jetzt auf ihre Dokumentation. Im Unterreiter „Bereitstellung“ des Tabs „Agentic Commerce“ steht unterhalb der Checkboxen für Funktionen und Transportwege ein Link, der den UCP-Abschnitt der Benutzerdokumentation in der Sprache der Administration in einem neuen Tab öffnet. Bisher erklärte der Tab jede Option nur in einem einzeiligen Tooltip und bot keine Möglichkeit, weiterzulesen.
+- Einstellungen, die andere Erweiterungen im Tab „Allgemein“ eines Verkaufskanals ergänzen, bleiben erhalten. Bisher ersetzte die Erweiterung den gesamten Inhalt des Tabs: Eine Erweiterung, die dem Tab eigene Daten übergab, verlor diese, und der Tab zeigte stattdessen die Standardeinstellungen eines Storefront-Verkaufskanals.
 - Erweiterungen können jetzt eigene UCP-OAuth-Scopes registrieren. Bisher war die Liste der zulässigen Scopes fest im Code hinterlegt, sodass ein Plugin mit eigener UCP-Capability seinen Scope nicht freischalten konnte: Die Token-Anfrage schlug mit `Unsupported OAuth scope` fehl. Weil das Plugin diesen Fehler still abfing, der Autorisierungslink aber schon eingelöst war, sah der Käufer nur die Meldung, der Link sei abgelaufen. Jetzt genügt ein Scope-Provider mit dem Service-Tag `swag_agentic_commerce.ucp.oauth_scope_provider`: Sein Scope wird in `scopes_supported` unter `/.well-known/oauth-authorization-server` veröffentlicht und in Autorisierungsanfragen akzeptiert. Ein Client, der keinen Scope angibt, erhält wie bisher nur die drei eingebauten Scopes; den Scope einer Erweiterung muss er ausdrücklich anfordern. Nicht registrierte Scopes werden weiterhin abgelehnt, die Fehlermeldung führt jetzt aber alle unterstützten Scopes auf -- genau diese Angabe fehlte bei der Fehlersuche.
 - Die Erweiterung setzt jetzt Shopware `6.5.8` oder neuer voraus. `6.5.0.0` bis `6.5.7.4` wurden als kompatibel angezeigt, ließen sich aber nie installieren: Diese Versionen enthalten Symfony 6.3, während sowohl die Routen der Erweiterung als auch das UCP-SDK Symfony 6.4 benötigen. Die Installation brach deshalb mit einer Composer-Fehlermeldung zu `symfony/config` ab, mit der ein Händler nichts anfangen kann. In betroffenen Shops wird die Erweiterung jetzt als nicht kompatibel angezeigt; ein Update auf `6.5.8.x` behebt das und bleibt innerhalb derselben Minor-Version.
-- Das UCP SDK wird nicht mehr mitgeliefert, sondern von Shopware installiert. 1.3.0 legte es in das plugin-eigene `vendor/` und lud den Autoloader, den Composer dafür erzeugt hatte -- denn das `vendor/autoload.php` einer Erweiterung lädt Shopware nicht von sich aus. Damit führte jeder Shop zwei getrennte Paketverzeichnisse: FroshTools meldete `2 autoloaders registered`, und die Frage, welche Version eines Pakets installiert ist, konnte aus der Kopie der Erweiterung beantwortet werden statt aus der des Shops. Die Erweiterung bringt jetzt keine Abhängigkeiten mehr mit, sondern lässt Shopware bei Installation und Update `composer require` ausführen -- dafür ist dieser Weg bei Erweiterungen aus einer ZIP-Datei gedacht. Die Erweiterung selbst wird dabei über das Pfad-Repository `custom/plugins/*` aufgelöst, das jedes Shopware-Projekt mitbringt, das festgelegte SDK kommt von Packagist in das `vendor/` des Shops. Für Shops, die über Composer installieren, ändert sich nichts. Neu ist, dass die Installation Packagist erreichen muss: Ohne Internetzugang bricht sie mit einem Composer-Fehler ab, statt eine unvollständige Erweiterung zu hinterlassen.
+- Das UCP SDK wird nicht mehr mitgeliefert, sondern von Shopware installiert. 1.3.0 legte es in das plugin-eigene `vendor/` und lud den Autoloader, den Composer dafür erzeugt hatte -- denn das `vendor/autoload.php` einer Erweiterung lädt Shopware nicht von sich aus. Damit führte jeder Shop zwei getrennte Paketverzeichnisse: FroshTools meldete `2 autoloaders registered`, und die Frage, welche Version eines Pakets installiert ist, konnte aus der Kopie der Erweiterung beantwortet werden statt aus der des Shops. Die Erweiterung bringt jetzt keine Abhängigkeiten mehr mit, sondern lässt Shopware bei Installation und Update `composer require` ausführen -- dafür ist dieser Weg bei Erweiterungen aus einer ZIP-Datei gedacht. Die Erweiterung selbst wird dabei über das Pfad-Repository `custom/plugins/*` aufgelöst, das jedes Shopware-Projekt mitbringt, das festgelegte SDK kommt von Packagist in das `vendor/` des Shops. Für Shops, die über Composer installieren, ändert sich nichts. Neu ist, dass der Shop bei Installation und Update der Erweiterung Packagist (`packagist.org`) erreichen muss: Ohne diesen Zugang bricht die Installation mit einem Composer-Fehler ab, statt eine unvollständige Erweiterung zu hinterlassen.
 - Fehlt das SDK, schaltet sich die Erweiterung ab, statt den Shop lahmzulegen. Ein Update entpackt die neuen Dateien, bevor Shopware Composer ausführt -- eine aktive Erweiterung startet also mindestens einmal ohne die Abhängigkeit, die sie braucht. In 1.3.0 antwortete daraufhin jede Seite mit `500`, die Storefront eingeschlossen, bis jemand das SDK von Hand nachinstallierte. Jetzt registriert die Erweiterung in diesem Zustand weder Services noch Routen oder Feeds und schreibt nach `var/log/swag-agentic-commerce.log`, was fehlt und mit welchem Befehl es sich beheben lässt. Sobald das SDK da ist, arbeitet sie ohne weiteres Zutun normal weiter. Geprüft wird dabei nicht nur, ob überhaupt ein SDK vorhanden ist, sondern ob es die Version ist, die diese Erweiterung vorgibt: Ein Shop, der noch die vorherige Version hat, wartet lieber ab, als neuen Code mit einem alten SDK auszuführen. Die README beschreibt unter _Troubleshooting_, woran man diesen Zustand erkennt, wie man ihn verlässt und was beim Update von 1.3.0 oder älter zu erwarten ist. Cluster-Setups sind die Ausnahme: Dort führt Shopware für ein Plugin grundsätzlich kein Composer aus, die Anforderungen würden also nie installiert. Deshalb verweigert die Erweiterung dort die Installation, statt Erfolg zu melden und dann nichts zu tun.
-- Einstellungen, die andere Erweiterungen im Tab „Allgemein“ eines Verkaufskanals ergänzen, bleiben erhalten. Bisher ersetzte die Erweiterung den gesamten Inhalt des Tabs: Eine Erweiterung, die dem Tab eigene Daten übergab, verlor diese, und der Tab zeigte stattdessen die Standardeinstellungen eines Storefront-Verkaufskanals.
 
 # 1.3.0
 
@@ -17,27 +17,28 @@
 - Die Anfrage nach einem Warenkorb, den niemand angelegt hat, wird mit `not_found` beantwortet, statt einen frischen, leeren Warenkorb unter der geratenen ID auszuliefern. Die von `cart.create` vergebenen Warenkorb-IDs werden im selben Kontextspeicher vermerkt, den die Checkout-Sitzung bereits nutzt.
 - Die UCP-MCP-Tools heißen so, wie das OpenRPC-Dokument der Spezifikation sie nennt (`search_catalog`, `create_cart`, `create_checkout`, `complete_checkout`, `get_order` und so weiter), und werden direkt in einer frischen MCP-Sitzung angeboten. Bisher hießen sie `shopware-ucp-*` und lagen hinter einem Toolset, das ein Agent erst aktivieren musste -- ein spezifikationstreuer Agent, der die Tools unter `/ucp/mcp` auflistete, sah nur die Meta-Tools des Toolsets. Ein MCP-Client, der die alten Namen aufgerufen hat, muss umgestellt werden; die Argumente bleiben unverändert.
 - Katalogsuche und Produktabfrage liefern echte Produktbeschreibungen. Fehlt eine Beschreibung, wird der Produkttitel verwendet.
-- Zahlungsdaten beim Checkout-Abschluss werden an das Plattform-Gateway weitergereicht; angewendete Rabatte werden einzeln ausgewiesen.
-- Konfigurierte Freigabelisten gelten auch für das Laden von Agentenprofilen. Eingebettete Antworten geben keine Checkout-Tokens mehr preis.
-- Der Abschluss eines agentischen Checkouts funktioniert auch auf kommenden Shopware-Versionen: Der beim Abschluss angelegte Gastkunde rotiert das Shopware-Kontext-Token und verschiebt den Warenkorb mit, und die Bestellung wird nun mit dem neuen statt dem veralteten Token aufgegeben, das neuere Shopware-Versionen mit einem „Warenkorb nicht gefunden“-Fehler ablehnen.
+- Die Zahlungsangaben, die ein Agent mit `checkout.complete` sendet, werden an eine Schnittstelle übergeben, die eine Zahlungserweiterung umsetzen kann. Für die Bestellung ändert sich dadurch zunächst nichts: Sie wird weiterhin mit der Standard-Zahlungsart des Verkaufskanals abgerechnet, und das Shop-Log warnt, welche Zahlungsart der Agent angefragt hat.
+- Die auf einen Warenkorb angewendeten Rabatte werden einzeln unter `discounts.applied` aufgeführt, mit Code, Name und Betrag, statt nur als Gesamtsumme.
+- Agentenprofile werden nur noch von den Hosts geladen, die in der konfigurierten Freigabeliste stehen. Außerdem gelangt die geheime Adresse der eingebetteten Checkout-Seite nicht mehr an andere Websites, wenn der Käufer von dort aus weiterklickt.
+- Der Abschluss eines agentischen Checkouts funktioniert auch auf kommenden Shopware-Versionen. Beim Anlegen des Gastkunden während des Abschlusses erhält der Käufer eine neue Shopware-Sitzung, und die Bestellung wird jetzt in dieser neuen Sitzung aufgegeben statt in der alten, die neuere Shopware-Versionen mit dem Fehler „Warenkorb nicht gefunden“ ablehnen.
 - Produktlinks in den OpenAI- und Google-Produktfeeds werden für Headless-Verkaufskanäle ab Shopware 6.7.14 nun korrekt aufgelöst, sodass Agenten funktionierende Produkt-URLs erhalten; auf älteren Shopware-Versionen funktionieren die Feeds unverändert weiter.
 - UCP lässt sich nur noch in Verkaufskanälen aktivieren, die tatsächlich verkaufen können: Storefront und Headless. Produktfeed-Kanäle werden für UCP nicht mehr angeboten und lassen sich weder über die API noch über die Konsole aktivieren. Ein Feed-Kanal, in dem UCP zuvor aktiviert war, gilt jetzt als deaktiviert und bewirbt so keinen Shop, in dem ein Agent nichts kaufen kann.
-- Exponierte Verkaufskanäle liefern `/.well-known/api-catalog` (RFC-9727-Linkset) aus, sodass ein Agent das UCP-Profil und den Store-API-Einstiegspunkt des Shops an einem standardisierten Ort findet; nicht exponierte Kanäle antworten mit 404.
+- Für UCP freigegebene Verkaufskanäle liefern `/.well-known/api-catalog` (RFC-9727-Linkset) aus, sodass ein Agent das UCP-Profil und den Store-API-Einstiegspunkt des Shops an einem standardisierten Ort findet; alle anderen Kanäle antworten mit `404`.
 - Neuer Befehl `ucp:setup`, der einen Verkaufskanal in einem Schritt für UCP einrichtet: Freigabe, Sicherheitsvorgaben, ein Signaturschlüssel, falls noch keiner existiert, die Bereitschaftsprüfung und der erste auszuführende Request. `--dev` wählt lokale Vorgaben, mit denen der Shop als sein eigener Agent auftreten kann; ohne die Option gelten Produktionsvorgaben. Die README beschreibt die gesamte Einrichtung in vier Schritten.
-- Es wird gezählt, welche UCP-Versionen Agenten tatsächlich sprechen: pro Request ein `info`-Eintrag im neuen Log-Kanal `ucp_negotiation` mit der vom Agenten genannten Version, der bedienten Version, dem Ergebnis und dem Host des Agentenprofils, sonst nichts. Auf dieser Messung beruht die Überprüfung der Ein-Versions-Entscheidung; SDK `0.0.7` meldet sie.
-- UCP `2026-08-25` mit SDK `0.0.7`: versionsabhängige Capability-Aushandlung, standardisierte Katalog-IDs sowie aktualisierte Einwilligungs-, Liefer- und Zahlungsdaten.
+- Es wird gezählt, welche UCP-Versionen Agenten tatsächlich sprechen: pro Request ein `info`-Eintrag im neuen Log-Kanal `ucp_negotiation` mit der vom Agenten genannten Version, der bedienten Version, dem Ergebnis und dem Host des Agentenprofils, sonst nichts. Anhand dieser Zahlen wird entschieden, ob das Plugin künftig mehr als eine UCP-Version gleichzeitig bedienen soll; SDK `0.0.7` liefert sie.
+- Version `2026-08-25` der UCP-Spezifikation wird über SDK `0.0.7` bedient, einschließlich versionsabhängiger Capability-Aushandlung, der standardisierten Capability-IDs für den Katalog sowie aktualisierter Einwilligungs-, Liefer- und Zahlungsdaten.
 - Das UCP-SDK wird in genau der getesteten Version (`0.0.7`) vorausgesetzt, und `ucp_sdk.version` wird nicht mehr gesetzt. Das SDK bedient pro Release genau eine UCP-Version und verwendet sie als Standardwert, deshalb erreicht ein SDK-Release Shops jetzt nur noch zusammen mit einem Plugin-Release, und das Plugin kann keine Version mehr benennen, die sein SDK nicht bedient. Version 1.2.x kombinierte ein fest eingetragenes `2026-04-08` mit einem `>=0.0.5 <0.1.0`-Fenster: `composer update` installierte SDK 0.0.6, das diese Version nicht mehr bedient, und der Container-Build schlug mitten in einem Shopware-Core-Update in `assets:install` fehl. `docs/ucp-version-support.md` beschreibt, welche Version das Plugin bedient und was ein Versionswechsel für einen Shop bedeutet.
 - Die Admin-Übersetzungen liegen jetzt in länderagnostischen Dateien (`de.json`, `en.json`) gemäß aktueller Shopware-Core-Konvention; ein Kompatibilitäts-Loader hält sie auf Shopware-Versionen vor 6.7.3 funktionsfähig.
 - Admin-Texte überarbeitet: durchgängige Großschreibung der Du-Anrede und ein eindeutigeres „Total“-Label in der englischen Statistik-Zusammenfassung.
 
 # 1.2.0
 
-- Beim Abschluss eines Checkouts über MCP werden Zahlungsdaten entgegengenommen. UCP verlangt für `checkout.complete` das Feld `payment`, das Tool kannte aber nur `id` und `dryRun` -- jeder Aufruf scheiterte an der Schema-Validierung mit `$.payment is required`, sodass über MCP überhaupt keine UCP-Bestellung aufgegeben werden konnte. Das Tool nimmt jetzt eine Payload entgegen und setzt eine leere Liste von Zahlungsmitteln ein, wenn der Agent keine sendet.
+- Beim Abschluss eines Checkouts über MCP werden Zahlungsdaten entgegengenommen. UCP verlangt für `checkout.complete` das Feld `payment`, das Tool kannte aber nur `id` und `dryRun` -- jeder Aufruf scheiterte an der Schema-Validierung mit `$.payment is required`, sodass über MCP überhaupt keine UCP-Bestellung aufgegeben werden konnte. Das Tool nimmt jetzt Zahlungsdaten entgegen und setzt eine leere Liste von Zahlungsmitteln ein, wenn der Agent keine sendet.
 - Ein angewendeter Rabatt wird als negativer `items_discount`-Betrag ausgewiesen statt als Position. Eine Shopware-Promotion wurde als gewöhnliche Position mit negativem Preis weitergereicht, was die UCP-Schemas ablehnen: Jede Antwort mit einer Promotion -- `discount.apply`, `cart.get`, `cart.update`, `checkout.get` und `checkout.update` -- verstieß gegen ihr eigenes Schema und erreichte den Agenten als Serverfehler, obwohl der Rabatt angewendet worden war.
 - Die Lieferadresse wird dort gelesen, wo UCP sie sendet. Ein Checkout mit getrennter Liefer- und Rechnungsadresse liefert nicht mehr an die Rechnungsadresse.
 - `order.permalink_url` enthält immer einen absoluten, aufrufbaren Bestell-Link -- für Gäste ist das der Deep Link der Bestellung, der ohne Anmeldung funktioniert, derselbe Link wie in der Bestellbestätigung.
-- Der Zugriff auf eine fremde Gastbestellung wird in der Sprache des Protokolls abgelehnt: Der Agent erhält "nicht gefunden" und den Hinweis, dass Gastbestellungen über den Permalink gelesen werden, statt eines internen Fehlers.
-- Die UCP-MCP-Tools unterstützen einen Trockenlauf (Dry Run) und liefern verwertbare Fehlermeldungen: Ein Agent erfährt, welches Feld falsch ist und warum, statt einen undurchsichtigen Fehler zu erhalten.
+- Der Zugriff auf eine fremde Gastbestellung wird in der Sprache des Protokolls abgelehnt: Der Agent erhält „nicht gefunden“ und den Hinweis, dass Gastbestellungen über den Permalink gelesen werden, statt eines internen Fehlers.
+- Ein Agent kann eine Anfrage an die UCP-MCP-Tools vorab testen, bevor er sie ausführt: Mit `dryRun` wird die Anfrage nur geprüft, gespeichert wird nichts. Schlägt eine Anfrage fehl, nennt die Fehlermeldung jetzt das falsche Feld und den Grund, statt nur einen nichtssagenden Fehler zu liefern.
 - Code und Schweregrad einer fehlgeschlagenen Agenten-Anfrage werden gemeldet und die zugrunde liegende Exception geloggt, sodass Fehler über das Shop-Log nachvollziehbar sind.
 - Der Agentic-Commerce-Tab erscheint nur in Verkaufskanälen, die tatsächlich verkaufen können. Inkonsistenzen bei Tabs, Template-Auswahl und Speichern-Button unter Shopware 6.5, 6.6 und 6.7 sind behoben.
 - Ein Produkt mit Varianten wird im OpenAI-Feed korrekt gekennzeichnet. `listing_has_variations` wurde nur gesetzt, wenn der Export Varianten einschloss, und die Variantenfelder wurden auch beim Hauptprodukt geschrieben; das Kennzeichen richtet sich jetzt nach dem Produkt selbst, und `variant_dict` steht nur noch bei einer echten Variante.
@@ -46,7 +47,7 @@
 
 # 1.1.1
 
-- Behebt den Fehler "Element 'subtitle': This element is not expected" auf der Seite Grundeinstellungen unter Shopware 6.7. Der gebündelte System-Config-Schema-Workaround wird nur noch unter Shopware 6.5 angewendet; unter 6.6 und 6.7 wird das aktuelle Core-Schema verwendet.
+- Behebt den Fehler „Element 'subtitle': This element is not expected“ auf der Seite Grundeinstellungen unter Shopware 6.7. Der gebündelte System-Config-Schema-Workaround wird nur noch unter Shopware 6.5 angewendet; unter 6.6 und 6.7 wird das aktuelle Core-Schema verwendet.
 - Der Speichern-Button im Verkaufskanal zeigte unter Shopware 6.7 einen rohen Snippet-Schlüssel an. Behoben durch Wechsel auf das gemeinsame Label `global.default.save`.
 
 # 1.1.0
diff --git a/composer.json b/composer.json
index 481be89..6ff02c0 100644
--- a/composer.json
+++ b/composer.json
@@ -1,7 +1,7 @@
 {
     "name": "shopware/agentic-commerce",
     "description": "Shopware plugin for agentic commerce discovery, product feeds, and Universal Commerce Protocol shopping flows",
-    "version": "1.3.0",
+    "version": "1.4.0",
     "type": "shopware-platform-plugin",
     "license": "MIT",
     "authors": [