Shopware core parity and remaining work

Reference: shopware/core 6.7.14.2, MIT, commit de074a584d77d8abb09ddb21d8799f083a61a3da, installed by reference/composer.lock. Paths below are relative to that original Core package. Native functionality is not automatically a behavioral port. None of these rows certifies full Admin API, Store API, Administration, DAL or plugin interchangeability.

Partial port means original PHP executes independently as an oracle for the specified operation. Native equivalent for the prototype means the feature works end to end within the documented subset, but upstream response/state parity has not been established. Missing means no implementation exists.

Tests and evidence

cargo test --locked protects pure rules, parsers, credentials and sandbox boundaries. scripts/{differential,context_differential,delivery_differential,rule_differential}.py execute original PHP classes. commerce.py proves native product→cart→tax/ shipping/payment→order→delivery/review behavior, including counterexamples. users.py attacks permissions, cross-shop state and existing-session revocation. extensions.py activates three actual guest policies and submits allowed/blocked B2B orders. Existing integration/protocol/studio/intelligence/provider suites protect the former application paths after the module split. apps.py, services.py and payments.py test the new native extension paths.

There is no measured 100% line/branch coverage claim and no blanket claim that all possible inputs or all Shopware behaviors are covered. Important remaining tests include large catalogs, replica failover, long-running load, production identity abuse, real PSP/carrier integration and complete protocol conformance. Executable migration units live in porting/units.json.

Additional bounded ports and native workbench behavior

See workbench.md for the precise supported contract and deployment.md for the prepared self-hosted/Vercel split.

Customer and operational delta (2026-10-02)

Original entity references: Checkout/Customer/CustomerDefinition.php, Aggregate/CustomerAddress/CustomerAddressDefinition.php, Checkout/Order/OrderDefinition.php and its address/customer/transaction aggregates. The reference package remains pinned above; the public upstream definitions were also consulted for field responsibilities. The native identifiers, country model, response envelopes and operation paths differ.

The customer and operational rows above are native end-to-end behaviors, without a new original-PHP entity/state parity proof. The current 7,000 original-PHP comparisons cover the narrowly specified pricing, context, shipping-tax, comparison primitives and 432 condition cases across 74 original rule classes. They do not establish equivalence of whole entities, triggers or flow sequences.

Formal safeguards (additional to upstream behavior comparison)

Twenty selected Rust commerce policies are backed by forty-five Lean theorems and compiled Rust/Lean conformance checks. They preserve native admission/cap rules in checkout, permissions, operational transitions, refunds, receipts and downloads. This is a bounded new safeguard, not proof of full Shopware equivalence or of all surrounding implementation. The original PHP differential suites and real HTTP/PostgreSQL checks remain separate. See formal coverage and the machine-readable inventory in proof/manifest.json.

Connected-app migration update

The rule framework now shares original Shopware numeric, string, string-array and UUID comparison behavior, checked against 1,976 PHP cases. The graphical rule editor edits real AND/OR/NOT condition trees; original supported condition payloads normalize through /api/automation/import-condition. The common native checkout scopes include customer email/authentication/group, country, shipping/payment method, sales channel and cart conditions. cartLineItem handles parent-product matching and original per-line negative operators, and cartLineItemsInCartCount/customerCustomerGroup are accepted source names.

The newer reflected production inventory is 114 concrete original Rule subclasses, of which 108 have an executable native scope. The previous 120-name regex inventory included non-executable/test names and is retained only as historical material. The executable catalog is reference/automation-registry.json; reference/automation-native.json explicitly records each binding. Direct original class comparisons now add 432 cases across 74 scopes to the comparison-primitive suite. Complete behavior remains unproved and each catalog row keeps behavioralParity:false. The six disabled classes, data/validation boundaries and exact native Core action contracts are listed in automation. Original entity UUIDs require explicit identity migration to native IDs. Existing native lineItemId and shippingCountry remain distinct legacy conditions.

App subscriptions and own typed app events now share the durable outbox. Flow app actions use the same HTTP/MCP gateway and recheck current rights before delivery. GA4, Gmail and Slack are new independent integrations, not claimed ports of an original Shopware provider plugin. Their real wire/database fixtures and live-credential boundary are documented in docs/connected-apps.md.

Full-app extension delta (2026-10-03)

Native app contracts now include own Studio modules, product/order panels, storefront pages/slots, namespaced HTTP aliases, selected AI tools/context, managed JSONB data and independently deployed code/storage. The Product Lab example exercises the shared UI/API/MCP gateway and overloaded-service isolation. See the full app contract. This is additional native extension capability, not Shopware PHP plugin ABI, App Script or Administration module parity.

Central product workspace and native categories (2026-10-05)

The native editor is now a searchable/filterable list plus create/detail workflows, not a metadata-only form. Migration 026 and categories/* add real translated category trees, many-to-many assignments, active/visible semantics, nested-listing control and per-channel navigation roots. commerce/product_admin*, product_channels.rs, product_fields.rs and product_edit.rs share atomic writes with MCP, graph synchronization and product outbox events. Ordered media uploads, visual rich documents, native SKU creation and selective staging have real consumers.

This supersedes the older “generic catalog editing UI missing” entry; complete variant generation, global property/manufacturer entities, CMS/product streams, original API/DAL schemas and full SEO URL generation remain missing. Exact source mapping, implemented behaviors and gaps.

International configuration delta (2026-10-05)

Country and tax concepts follow original System/Country, System/Tax and Shopware Administration settings. The native subset lives in commerce/geography.rs, tax_rules.rs, tax_context.rs, settings_validation.rs and the Settings Studio modules. It adds the world catalogue, US subdivisions, tenant overlays, destination/postcode/date/Rule Builder resolution, custom product tax classes and localized shipping/payment availability. international_commerce.py checks actual prices, checkout snapshots, invalid geography and tenant boundaries. This is native prototype equivalence for the documented subset, not an original-PHP tax-detection comparison or full Shopware DAL/API parity.

localization.rs, commerce/content_text.rs, product_languages.rs and product_edit.rs implement configurable main-language and per-field inheritance. translations/ is a native AI extension with durable drafts, bounded jobs and revision-protected apply, covered by the restart/provider/permissions fixture suite. See the full international contract for remaining compound tax/currency, worldwide subdivision, full UI-language and model-quality gaps.

Company identity and sales-channel configuration

The native operations/company_model.rs, master_data.rs, company_logo.rs and company_public.rs replace this prototype's flat issuer settings with structured address/company/legal metadata, revisioned sparse per-channel inheritance, localized brand/legal text, validated tenant logo uploads and Store API identity. staging/company.rs publishes basis/channel units selectively; receipts resolve the order's channel and freeze the effective issuer. This is native functional coverage inspired by Shopware's sales-channel settings, not a claim of identical SystemConfig/DAL wire compatibility. Other commerce settings remain shop-wide, full upstream settings/import formats are not equivalent, and the minimal PDF renderer does not embed a logo. See contracts and tests.

Channel settings and media workspaces (2026-10-05)

See the settings/media guide for the current single-language editor, field-level checkout overrides, dependency-safe method removal, gallery and optional private image jobs. These are native prototype extensions; they do not establish additional full Shopware API/DAL parity, current tax law, paid-provider quality or whole-system formal certification.

CRM usability and native history delta (2026-10-05)

Independent default address card actions, linked customer/order/product editors and configured translated customer groups now run through native API/MCP contracts. Exact group IDs drive rules/flows/tier prices; their explicit price basis drives gross/net presentation. Shared definitions cannot be overridden per channel. This remains a native implementation, not original customer-group DAL/UUID or complete criteria compatibility.

Thirteen entity history types (including inspection-only orders) now record transactional before/after aggregates; twelve editable types delegate rollback to current domain validation. Credentials, immutable identity/login metadata and financial events are not rewound. Historical Shopware versions are not imported or synthesized. The history contract lists all boundaries.

Checkout review and approval return: order_checkout.rs, payments/storage.rs, payments/return_urls.rs and frontend/src/storefront/checkout/* provide native one-page selection, revision/amount confirmation and verified approval capture. Local PostgreSQL/provider fixtures cover stale reviews, replay and forged returns. No full Shopware Payments, accelerated wallet/card or conversion-uplift parity is claimed.

General payment apps

payments/{contract,registry,accounts,app_commands,remote,generic_receipts,sessions,provider_webhooks}.rs implement the versioned provider boundary, tenant/channel inheritance, approved onboarding links, immutable environment/version/account snapshots, isolated checkout sessions and exact receipt claims. App Studio and coding agents use the same declarations; HTTP/MCP/Flow dispatch share durable jobs. scripts/payment_providers.py exercises a second provider through real HTTP/PG. The private connector separately ports source-backed provider behavior. This is not complete Shopware Payments parity, a delivered Stripe adapter or a successful real-money test; details are in payment-provider-api.md.

European-operation additions

Vendune-native legal/privacy settings connect cart/channel consent, built-in tracking gates, document snapshots, public withdrawal/data-rights intake, private review and receipt-email events. These are additions, not a claim of one-to-one Shopware or statutory parity. The requirement matrix explicitly marks missing price-history computation, age verification and subscription cancellation workflows.

Multi-currency native extension

Multi-currency is implemented in src/currencies/ and shared catalog/cart/order, payment, document, MCP/UCP and frontend consumers. It supports shop registry and inherited channel defaults/availability, exact fixed product and variant prices, saved-rate conversion, durable price generation, destination tax adjustment, scaled shipping/absolute discounts, immutable order/ledger currency and separated revenue reporting. It is a native implementation, not a claim of 1:1 Shopware currency UUID/schema compatibility, arbitrary inherited advanced-price records, original custom cash-rounding configurations or every live provider. Existing EUR Shopware differential gates remain unchanged.