1.4.0

• 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.
• 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 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.