diff --git a/resources/references/adr/2021-11-09-increment-pattern.md b/resources/references/adr/2021-11-09-increment-pattern.md
index eb72a4669..bc86584f7 100644
--- a/resources/references/adr/2021-11-09-increment-pattern.md
+++ b/resources/references/adr/2021-11-09-increment-pattern.md
@@ -1,7 +1,7 @@
 ---
 title: Introduce increment pattern
 date: 2021-11-09
-area: system-settings
+area: services-settings
 tags: [architecture, increment, message-queue-stats]
 ---
 
diff --git a/resources/references/adr/2022-03-25-prevent-mail-updates.md b/resources/references/adr/2022-03-25-prevent-mail-updates.md
index f2fbc8bb3..a7a5effe6 100644
--- a/resources/references/adr/2022-03-25-prevent-mail-updates.md
+++ b/resources/references/adr/2022-03-25-prevent-mail-updates.md
@@ -1,7 +1,7 @@
 ---
 title: Prevent mail updates 
 date: 2022-03-25
-area: system-settings
+area: services-settings
 tags: [mail, flow]
 ---
 
diff --git a/resources/references/adr/2024-04-01-checkout-gateway.md b/resources/references/adr/2024-04-01-checkout-gateway.md
new file mode 100644
index 000000000..d8c237c59
--- /dev/null
+++ b/resources/references/adr/2024-04-01-checkout-gateway.md
@@ -0,0 +1,156 @@
+---
+title: Checkout gateway
+date: 2024-04-01
+area: checkout
+tags: [checkout, app, payment, shipping, cart]
+---
+
+# Checkout gateway
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-04-01-checkout-gateway.md)
+:::
+
+# ADR: Enhanced Checkout Gateway Feature
+## Context
+In response to the evolving landscape of checkout decision-making, we propose the introduction of a centralized and opinionated solution. 
+This solution aims to facilitate informed decisions during the checkout process based on both the cart contents and the current sales channel context. 
+The app-system, in particular, stands to benefit significantly, enabling seamless communication with the app server. 
+Presently, achieving such functionality is constrained to app scripts, limiting the capacity for making nuanced decisions during checkout based on app server logic.
+
+Moreover, payment and shipping providers necessitate specific criteria for determining the availability of their respective methods. 
+These criteria include considerations such as risk assessment related to the current customer and cart, unavailability criteria, 
+merchant connection status validation (e.g., checking for correct credentials), and service availability testing (e.g., detecting provider outages). 
+Additionally, these providers require the ability to block carts during checkout based on risk assessment decisions.
+
+While this ADR focuses on the aforementioned features, the implementation is designed to allow for seamless future extensions.
+
+## Decision
+### CheckoutGatewayInterface
+To address the outlined challenges, we propose the introduction of the CheckoutGatewayInterface.
+This interface will be invoked during the checkout process to determine a response tailored to the current cart and sales channel context.
+
+```php
+<?php declare(strict_types=1);
+
+namespace Shopware\Core\Checkout\Gateway;
+
+use Shopware\Core\Checkout\Gateway\Command\Struct\CheckoutGatewayPayloadStruct;
+use Shopware\Core\Framework\Log\Package;
+
+#[Package('checkout')]
+interface CheckoutGatewayInterface
+{
+    /**
+    * The input struct consists of the cart, sales channel context and currently available payment and shipping methods.
+    */
+    public function process(CheckoutGatewayPayloadStruct): CheckoutGatewayResponse;
+}
+```
+
+Plugin developers are encouraged to create custom implementations of the `CheckoutGatewayInterface` for their specific checkout logic based on decisions from external systems (e.g., ERP, PIM).
+
+The `CheckoutGatewayResponse` will include an `EntityCollection` of payment and shipping methods suitable for the current context, along with a collection of `CartErrors`.
+The input struct and the response is designed for future extension, allowing for more intricate decision-making during checkout.
+
+#### Store-API
+A new store API route, `CheckoutGatewayRoute` '/store-api/checkout/gateway', will be introduced.
+This route will call a `CheckoutGatewayInterface` implementation and respond accordingly,
+and is integral to `CartOrderRoute` requests, ensuring the cart's validity for checkout during the order process.
+
+#### Storefront
+The default invocation of the `CheckoutGatewayRoute` will occur during the checkout-confirm page and edit-order page (so-called "after order").
+Any changes to the context (e.g., language, currency) will trigger a reload of the payment method selection, calling the app server again.
+
+#### Checkout Gateway Commands
+For streamlined response manipulation by plugins and app servers alike, we propose an executable chain of `CheckoutGatewayCommands`.
+The implementation of the app-system will heavily rely on the command structure.
+However, it is encouraged, but not mandatory for a custom implementation plugin-system implementation of the `CheckoutGatewayInterface` to follow the command structure.
+
+These commands, chosen from a predefined set, can be responded with by plugins and app servers.
+The initial release will include the following commands: `add-payment-method`, `remove-payment-method`, `add-shipping-method`, `remove-shipping-method`, and `add-cart-error`.
+Depending on the command, the payload may differ, necessitating updates to the documentation.
+We propose the use of a handler pattern, to facilitate the execution of these commands.
+Commands will be executed in the order provided in the response.
+
+### App-System
+For the initial release, Shopware will support a single implementation of the `CheckoutGatewayInterface`, provided by the app-system.
+The `AppCheckoutGateway` will sequentially call active apps, but only if the app has a defined `checkout-gateway-url` in its manifest.xml file.
+
+#### App Manifest
+To address challenges for apps, a new app endpoint can be defined in the manifest.xml.
+A new key `gateways` will be added to the manifest file, with a sub-key `checkout` to define the endpoint.
+The `gateways` key signalizes possible future similar endpoints for different purposes.
+The checkout gateway endpoint is configured using a new element called `checkout`.
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<manifest>
+    <!-- ... -->
+
+    <gateways>
+        <checkout>https://example.com/checkout/gateway</checkout>
+    </gateways>
+</manifest>
+```
+
+#### Checkout Gateway App Payload
+The app server will receive the current `SalesChannelContext`, `Cart`, and available payment and shipping methods as part of the payload.
+The `AppCheckoutGateway` will call the app server with this payload.
+
+```json
+{
+    "salesChannelContext": SalesChannelContextObject,
+    "cart": CartObject,
+    "paymentMethods": [
+        "payment-method-technical-name-1",
+        "payment-method-technical-name-2",
+        "payment-method-technical-name-3",
+        ...
+    ],
+    "shippingMethods": [
+        "shipping-method-technical-name-1",
+        "shipping-method-technical-name-2",
+        "shipping-method-technical-name-3",
+        ...
+    ]
+}
+```
+
+Note that the paymentMethods and shippingMethods arrays will only contain the technical names of the methods, not the full entities.
+
+#### Checkout Gateway App Response
+
+```json
+[
+  {
+    "command": "remove-payment-method",
+    "payload": {
+      "paymentMethodTechnicalName": "payment-myApp-payment-method"
+    }
+  },
+  {
+    "command": "add-cart-error",
+    "payload": {
+      "reason": "Payment method not available for this cart.",
+      "level": 20,
+      "blockOrder": true
+    }
+  }
+]
+```
+
+#### Event
+A new event `CheckoutGatewayCommandsCollectedEvent` will be introduced.
+This event is dispatched after the `AppCheckoutGateway` has collected all commands from all app servers.
+It allows plugins to manipulate the commands before they are executed, based on the same payload the app servers retrieve.
+
+## Consequences
+### App PHP SDK
+The app-php-sdk will be enhanced to support the new endpoint and data types, ensuring seamless integration with the command structure. 
+The following adaptations will be made:
+
+Checkout gateway requests with payload will be deserialized into a `CheckoutGatewayRequest` object.
+Checkout gateway responses will be deserialized into a `CheckoutGatewayResponse` object.
+Every possible checkout gateway command will have a class representing it, facilitating easy manipulation of its payload.
diff --git a/resources/references/adr/2024-06-12-add-jest-runner-with-disabled-compat-mode.md b/resources/references/adr/2024-06-12-add-jest-runner-with-disabled-compat-mode.md
new file mode 100644
index 000000000..264c05b99
--- /dev/null
+++ b/resources/references/adr/2024-06-12-add-jest-runner-with-disabled-compat-mode.md
@@ -0,0 +1,67 @@
+---
+title: Add jest runner with disabled compat mode
+date: 2024-06-12
+area: administration
+tags: [administration, jest, pipeline, testing, unit]
+---
+
+# Add jest runner with disabled compat mode
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-06-12-add-jest-runner-with-disabled-compat-mode.md)
+:::
+
+## Context
+
+Currently, our component tests in Jest are running with enabled compat mode. To remove the compat mode for each
+component, we need to add a new Jest runner with disabled compat mode to make sure that the tests are running without compat mode.
+
+## Decision
+
+I added a new runner command in the NPM scripts to run the Jest tests without compat mode. The new runner command is
+`unit:disabled-compat` and `unit-watch:disabled-compat`. Also, the composer commands are added to run the tests. These commands are `admin:unit:disabled-compat` and `admin:unit-watch:disabled-compat`. These commands are using the environment variable `DISABLE_JEST_COMPAT_MODE` to disable the compat mode.
+
+For the pipeline, I added a new stage to run the Jest tests without compat mode. The stage is `Jest (Administration with disabled compat mode)`.
+
+To mark a test file working without the compat mode you need to add a comment with the `@group` tag. The tag is `@group disabledCompat`.
+
+Example:
+
+```javascript
+/**
+ * @package admin
+ * @group disabledCompat
+ */
+
+import { mount } from '@vue/test-utils';
+
+async function createWrapper() {
+...
+```
+
+With this tag, the test file is running without compat mode. To make a component working for both modes, you can use the
+compatUtils helper function from Vue compat:
+
+```javascript
+// Example
+import { compatUtils } from '@vue/compat';
+
+...
+
+if (compatUtils.isCompatEnabled('INSTANCE_LISTENERS')) {
+    return this.$listeners;
+}
+
+return {};
+
+...
+```
+
+Important: the test still runs also with compat mode activated in parallel.
+
+## Consequences
+
+- Fixing the components and tests to run also without compat mode. This has to be done by removing the compat mode for each component.
+- Marking fixed tests with `@group disabledCompat` to run without compat mode.
+- When everything is fixed, we can remove the compat mode from the Jest configuration.
diff --git a/resources/references/adr/2024-06-17-error-code-log-level-configuration-in-cloud-and-platform.md b/resources/references/adr/2024-06-17-error-code-log-level-configuration-in-cloud-and-platform.md
new file mode 100644
index 000000000..88c599a23
--- /dev/null
+++ b/resources/references/adr/2024-06-17-error-code-log-level-configuration-in-cloud-and-platform.md
@@ -0,0 +1,42 @@
+---
+title: Error-code log Level configuration in platform or cloud
+date: 2024-06-17
+area: core
+tags: [core, devops, observability]
+---
+
+# Error-code log Level configuration in platform or cloud
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-06-17-error-code-log-level-configuration-in-cloud-and-platform.md)
+:::
+
+## Context
+In the configuration files for platform and cloud, specific error codes can be set to the notice level.
+Some time ago, we decided to configure this in platform ([Exception Log Level configuration](2023-05-25-exception-log-levels)).
+
+As it is still essential for some errors to be logged at the highest level for customers with own servers, we now have to decide which errors we can decrease for all customers and which only for cloud. The key consideration is whether it makes sense for on-premise customers to continue logging these errors at a high level. If it does, the error codes must be added to the cloud configuration file in the SaaS template.
+
+For example, an incorrectly configured flow on the customer side is not an error that needs to be analyzed by us and has to be recorded by our error monitoring, but it is important for the customer to be informed about it at the highest log level.
+
+## Decision
+
+We have to decide for each error code whether it makes sense for on-premise customers to continue logging these errors at a high level. If so, the error codes have to be added to the cloud configuration file in the SaaS template.
+
+### This could be a small guide for the decision:
+* Never decrease critical errors in platform
+
+Errors that shall be configured in cloud:
+* all the unexpected stuff that should not happen and a dev should look at this, even though the fix is not in Shopware itself but probably in some calling code/configuration
+* like API misuses
+* or misconfigurations on the customer side
+
+Errors that shall be configured in platform:
+* all the expected stuff, it is totally normal that those things happen and no dev needs to change something
+* like 404 errors
+* or invalid user credentials at login
+
+## Consequences
+
+By implementing this approach, we ensure that critical errors are properly logged and monitored in both on-premise and cloud environments, aligning with the needs and contexts of different customer bases.
diff --git a/resources/references/adr/2024-06-17-replace-vuex-with-pinia.md b/resources/references/adr/2024-06-17-replace-vuex-with-pinia.md
new file mode 100644
index 000000000..7716e0955
--- /dev/null
+++ b/resources/references/adr/2024-06-17-replace-vuex-with-pinia.md
@@ -0,0 +1,196 @@
+---
+title: Replace Vuex with Pinia
+date: 2024-06-17
+area: admin
+tags: [admin, vuex, pinia]
+---
+
+# Replace Vuex with Pinia
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-06-17-replace-vuex-with-pinia.md)
+:::
+
+# ADR: Replace Vuex with Pinia
+## Context
+It was brought to our attention that the latest version of Vuex `4.1.0` contains a bug that destroys getter reactivity under specific circumstances. The proposed fix was to downgrade to `4.0.2`. However, downgrading was not possible as `4.0.2` contains other bugs that caused modules to fail.
+
+## Decision
+Pinia is the new documented standard with Vue 3; therefore, we will switch to Pinia.
+
+## Consequences
+### Removal of Vuex
+Below you will find an overview of what will be removed on which Shopware Version.
+
+#### 6.7
+For Shopware 6.7 we want to transition all our modules but still leave the possibility for you to use Vuex for your own states.
+
+- All `Shopware.State` functions will cause warnings to appear in the DevTools. For example `Shopware.State.registerModule is deprecated. Use Shopware.Store.register instead!`
+- All Vuex state definitions will be transitioned to Pinia:
+    - src/module/sw-bulk-edit/state/sw-bulk-edit.state.js
+    - src/module/sw-product/page/sw-product-detail/state.js
+    - src/module/sw-category/page/sw-category-detail/state.js
+    - src/module/sw-extension/store/extensions.store.ts
+    - src/module/sw-settings-payment/state/overview-cards.store.ts
+    - src/module/sw-settings-seo/component/sw-seo-url/state.js
+    - src/module/sw-settings-shipping/page/sw-settings-shipping-detail/state.js
+    - src/app/state/notification.store.js
+    - src/app/state/session.store.js
+    - src/app/state/system.store.js
+    - src/app/state/admin-menu.store.js
+    - src/app/state/admin-help-center.store.ts
+    - src/app/state/license-violation.store.js
+    - src/app/state/context.store.ts
+    - src/app/state/error.store.js
+    - src/app/state/settings-item.store.js
+    - src/app/state/shopware-apps.store.ts
+    - src/app/state/extension-entry-routes.js
+    - src/app/state/marketing.store.js
+    - src/app/state/extension-component-sections.store.ts
+    - src/app/state/extensions.store.ts
+    - src/app/state/tabs.store.ts
+    - src/app/state/menu-item.store.ts
+    - src/app/state/extension-sdk-module.store.ts
+    - src/app/state/modals.store.ts
+    - src/app/state/main-module.store.ts
+    - src/app/state/action-button.store.ts
+    - src/app/state/rule-conditions-config.store.js
+    - src/app/state/sdk-location.store.ts
+    - src/app/state/usage-data.store.ts
+    - src/module/sw-flow/state/flow.state.js
+    - src/module/sw-order/state/order.store.ts
+    - src/module/sw-order/state/order-detail.store.js
+    - src/module/sw-profile/state/sw-profile.state.js
+    - src/module/sw-promotion-v2/page/sw-promotion-v2-detail/state.js
+
+#### 6.8
+With Shopware 6.8 we will entirely remove everything Vuex related including the dependency.
+
+- `Shopware.State` - Will be removed. Use `Shopware.Store` instead.
+- `src/app/init-pre/state.init.ts` - Will be removed. Use `src/app/init-pre/store.init.ts` instead.
+- `src/core/factory/state.factory.ts` - Will be removed without replacement.
+- Interface `VuexRootState` will be removed from `global.types.ty`. Use `PiniaRootState` instead.
+- Package `vuex` will be removed.
+
+## Transition to Pinia
+Pinia calls its state-holding entities `stores`. Therefore, we decided to hold everything Pinia-related under `Shopware.Store`.
+The `Shopware.Store` implementation follows the Singleton pattern. The private constructor controls the creation of the Pinia root state.
+This root state must be injected into Vue before the first store can be registered. The `init-pre/store.init.ts` takes care of this.
+
+### Best practices
+1. All Pinia Stores must be written in TypeScript
+2. All Stores will export a type or interface like the `cms-page.state.ts`
+3. The state property of the exported type must be reused for the state definition.
+
+You can always orientate on the `cms-page.state.ts`. It contains all best practices. 
+
+For now, we have decided to limit the public API of `Shopware.Store` to the following:
+
+```typescript
+/**
+ * Returns a list of all registered Pinia store IDs.
+ */
+public list(): string[];
+
+/**
+ * Gets the Pinia store with the given ID.
+ */
+public get(id: keyof PiniaRootState): PiniaStore;
+
+/**
+ * Registers a new Pinia store. Works similarly to Vuex's registerModule.
+ */
+public register(options: DefineStoreOptions): void;
+
+/**
+ * Unregisters a Pinia store. Works similarly to Vuex's unregisterModule.
+ */
+public unregister(id: keyof PiniaRootState): void;
+```
+
+The rest of the previous Vuex (`Shopware.State`) public API is implemented into Pinia itself.
+
+```typescript
+// Setup
+const piniaStore = Shopware.Store.get('...');
+
+// From Vuex subscribe
+Shopware.State.subscribe(...);
+// To Pinia $subscribe
+store.$subscribe(...);
+
+// From Vuex commit
+Shopware.State.commit(...);
+// To Pinia action call
+store.someAction(...);
+
+// From Vuex dispatch
+Shopware.State.dispatch(...);
+// To Pinia action call
+store.someAsyncAction(...);
+```
+
+### Example Implementation
+To prove that Vuex and Pinia can co-exist during the transition period, we picked a private Vuex state and decided to transition it.
+We chose the `cmsPageState`, which is heavily used in many components. The transition went smoothly without any major disturbances.
+
+How to transition a Vuex module into a Pinia store:
+1. In Pinia, there are no `mutations`. Place every mutation under `actions`.
+2. `state` needs to be an arrow function returning an object: `state: () => ({})`.
+3. `actions` no longer need to use the `state` argument. They can access everything with correct type support via `this`.
+4. Point 3 also applies to `getters`.
+5. Use `Shopware.Store.register` instead of `Shopware.State.registerModule`.
+
+Let's look at a simple Vuex module and how to transition it:
+
+```typescript
+// Old Vuex implementation
+Shopware.State.registerModule('example', {
+    state: {
+        id: '',
+    },
+    getters: {
+        idStart(state) {
+            return state.id.substring(0, 4);
+        }
+    },
+    mutations: {
+        setId(state, id) {
+            state.id = id;
+        }
+    },
+    actions: {
+        async asyncFoo({ commit }, id) {
+            // Do some async stuff
+            return Promise.resolve(() => {
+                commit('setId', id);
+                
+                return id;
+            });
+        }
+    }
+});
+
+// New Pinia implementation
+// Notice that the mutation setId was removed! You can directly modify a Pinia store state after retrieving it with Shopware.Store.get.
+Shopware.Store.register({
+    id: 'example',
+    state: () => ({
+        id: '',
+    }),
+    getters: {
+        idStart: () => this.id.substring(0, 4),
+    },
+    actions: {
+        async asyncFoo(id) {
+            // Do some async stuff
+            return Promise.resolve(() => {
+                this.id = id;
+
+                return id;
+            });
+        }
+    }
+});
+```
diff --git a/resources/references/adr/2024-06-18-extended-event-system.md b/resources/references/adr/2024-06-18-extended-event-system.md
new file mode 100644
index 000000000..c6abc0e03
--- /dev/null
+++ b/resources/references/adr/2024-06-18-extended-event-system.md
@@ -0,0 +1,179 @@
+---
+title: Transition to an Event-Based Extension System
+date: 2024-06-18
+area: core
+tags: [core, plugin, event]
+---
+
+# Transition to an Event-Based Extension System
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-06-18-extended-event-system.md)
+:::
+
+## Context
+
+In our current architecture, we rely heavily on PHP decoration, Adapter, and Factory patterns to allow for extensions and customizations by third-party developers. While these patterns are effective, they present significant challenges:
+
+1. **Backward and Forward Compatibility:**
+    - Maintaining backward and forward compatibility with these patterns is complex and labor-intensive. Each change or update can potentially break existing extensions or require extensive rework to ensure compatibility.
+
+2. **Process Extension Limitations:**
+    - These patterns do not inherently allow for the extension of subprocesses unless these subprocesses are extracted into separate classes and interfaces. This extraction often results in a proliferation of interfaces, abstract classes, and their implementations.
+
+3. **Proliferation of Code:**
+    - The need to extract subprocesses into separate entities leads to an overwhelming number of interfaces and abstract classes. This proliferation makes the codebase more difficult to understand and maintain, and increases the cognitive load on developers.
+
+## Decision
+
+To address these challenges, we have decided to transition to an event-based extension system. This new approach will replace the existing decoration, Adapter, and Factory patterns as the primary method for extending and customizing our system.
+
+## Rationale
+
+1. **Simplification of Compatibility:**
+    - An event-based system inherently simplifies backward and forward compatibility. Events can be introduced, deprecated, or modified with minimal impact on existing extensions, as long as the core event structure remains consistent.
+
+2. **Modular Extension Points:**
+    - By leveraging events, we can provide more granular and modular extension points. Developers can hook into specific points of the application flow without needing to manipulate or extend multiple interfaces and classes.
+
+3. **Reduction in Code Proliferation:**
+    - The shift to an event-based system will significantly reduce the need for a large number of interfaces and abstract classes. This will streamline the codebase, making it easier to manage and reducing the cognitive load on developers.
+
+4. **Unified Extension Framework:**
+    - An event-based system provides a more unified and consistent framework for third-party developers. They can use a standardized method to extend and customize the application, leading to better consistency and reliability in extensions.
+
+## Consequences
+
+1. **Initial Refactoring Effort:**
+    - Transitioning to an event-based system will require an initial effort to refactor existing code and extensions. This will involve identifying current extension points and replacing them with event triggers.
+
+2. **Learning Curve:**
+    - Developers accustomed to the current patterns will need to adapt to the new event-based approach. Training and documentation will be necessary to facilitate this transition.
+
+## Implementation
+
+1. **Identify Key Extension Points:**
+    - Conduct an audit of the current system to identify key extension points that will be replaced with events.
+
+2. **Define Event Structure:**
+    - Develop a standard structure for events, including naming conventions, payload formats, and handling mechanisms.
+
+3. **Refactor Existing Extensions:**
+    - Gradually refactor existing extensions to use the new event-based system, ensuring backward compatibility where necessary.
+
+4. **Documentation and Training:**
+    - Create comprehensive documentation and training materials to help developers transition to the new system.
+
+## Conclusion
+
+The transition to an event-based extension system represents a strategic shift aimed at simplifying our extension framework, improving maintainability, and providing a more consistent and flexible platform for third-party developers. While this change requires an initial investment in refactoring and training, the long-term benefits of reduced complexity, improved compatibility, and a unified extension approach make it a worthwhile endeavor.
+
+## Example
+
+The following example demonstrates how an event-based extension can be implemented in the context of resolving product listings:
+
+```php
+<?php declare(strict_types=1);
+
+namespace Shopware\Core\Content\Product\Extension;
+
+use Shopware\Core\Content\Product\ProductCollection;
+use Shopware\Core\Framework\DataAbstractionLayer\Search\Criteria;
+use Shopware\Core\Framework\DataAbstractionLayer\Search\EntitySearchResult;
+use Shopware\Core\Framework\Extensions\Extension;
+use Shopware\Core\Framework\Log\Package;
+use Shopware\Core\System\SalesChannel\SalesChannelContext;
+
+/**
+ * @extends Extension<EntitySearchResult<ProductCollection>>
+ */
+#[Package('inventory')]
+final class ResolveListingExtension extends Extension
+{
+    public const NAME = 'listing-loader.resolve';
+
+    /**
+     * @internal shopware owns the __constructor, but the properties are public API
+     */
+    public function __construct(
+        /**
+         * @public
+         *
+         * @description The criteria which should be used to load the products. Is also containing the selected customer filter
+         */
+        public readonly Criteria $criteria,
+        /**
+         * @public
+         *
+         * @description Allows you to access to the current customer/sales-channel context
+         */
+        public readonly SalesChannelContext $context
+    ) {
+    }
+}
+```
+
+In this example, the `ResolveListingExtension` class represents an event-based extension point for resolving product listings. Developers can subscribe to this event and provide custom logic for loading product data based on specific criteria and context. This approach allows for more modular and flexible extensions compared to traditional patterns like decoration or Adapter.
+
+```php
+<?php declare(strict_types=1);
+
+namespace Shopware\Tests\Examples;
+
+use GuzzleHttp\ClientInterface;
+use Shopware\Core\Content\Product\Extension\ResolveListingExtension;
+use Shopware\Core\Content\Product\ProductCollection;
+use Shopware\Core\Framework\DataAbstractionLayer\EntityRepository;
+use Shopware\Core\Framework\DataAbstractionLayer\Search\Criteria;
+use Symfony\Component\EventDispatcher\EventSubscriberInterface;
+
+readonly class ResolveListingExample implements EventSubscriberInterface
+{
+    public static function getSubscribedEvents(): array
+    {
+        return [
+            'listing-loader.resolve.pre' => 'replace',
+        ];
+    }
+
+    /**
+     * @param EntityRepository<ProductCollection> $repository
+     */
+    public function __construct(
+        // you can inject your own services
+        private ClientInterface $client,
+        private EntityRepository $repository
+    ) {
+    }
+
+    public function replace(ResolveListingExtension $event): void
+    {
+        $criteria = $event->criteria;
+
+        // building a json aware array for the API call
+        $context = [
+            'salesChannelId' => $event->context->getSalesChannelId(),
+            'currencyId' => $event->context->getCurrency(),
+            'languageId' => $event->context->getLanguageId(),
+        ];
+
+        // do an api call against your own server or another storage, or whatever you want
+        $ids = $this->client->request('GET', 'https://your-api.com/listing-ids', [
+            'query' => [
+                'criteria' => json_encode($criteria),
+                'context' => json_encode($context),
+            ],
+        ]);
+
+        $data = json_decode($ids->getBody()->getContents(), true);
+
+        $criteria = new Criteria($data['ids']);
+
+        $event->result = $this->repository->search($criteria, $event->context->getContext());
+
+        // stop the event propagation, so the core function will not be executed
+        $event->stopPropagation();
+    }
+}
+```
diff --git a/resources/references/adr/2024-07-16-deprecating-sdk-public-api.md b/resources/references/adr/2024-07-16-deprecating-sdk-public-api.md
new file mode 100644
index 000000000..2c50c8419
--- /dev/null
+++ b/resources/references/adr/2024-07-16-deprecating-sdk-public-api.md
@@ -0,0 +1,112 @@
+---
+title: Deprecating Meteor Admin SDK public SDK
+date: 2024-07-18
+area: admin
+tags: [admin, meteor admin sdk, component section]
+---
+
+# Deprecating Meteor Admin SDK public SDK
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-07-16-deprecating-sdk-public-api.md)
+:::
+
+## Context
+
+Recently, the need arose to deprecate the `Meteor Admin SDK` public API built into the Shopware Core.
+We need to be able to deprecate the public API, which consists of `component sections` and `data sets`.
+
+### Component sections
+The `sw-extension-component-section` component represents component sections in Shopware.
+This component is added to templates, assigned a `position identifier,` and allows rendering components in place via the SDK.
+
+```vue
+<template>
+    <sw-extension-component-section
+        position-identifier="sw-chart-card__before"
+    />
+</template>
+```
+
+### Data sets
+Data sets can range from whole entities to a subset of such or scalar values. These data sets are published in the component's code like so:
+
+```javascript
+createdComponent() {
+    Shopware.ExtensionAPI.publishData({
+        id: 'sw-dashboard-detail__todayOrderData',
+        path: 'todayOrderData',
+        scope: this,
+    });
+},
+```
+
+No mechanisms were in place to mark `component sections` and `data sets` as deprecated.
+As we promise that the SDK will be our most stable extension tool, we need to ensure that this API is treated as such.
+
+## Decision
+
+### Monitoring
+We decided to monitor the SDK's public API to gain an overview and ensure that it is not diminished by accident.
+This is achieved by the `meta.spec.ts` file. The test uses committed JSON files containing all `data set ID's` and `component section - position identifiers`.
+It then checks the committed file against a run-time computed list to determine if any of these were removed.
+
+### Deprecating
+Both `component sections` and `data sets` must be able to be deprecated.
+For `component sections`, we added two props:
+
+- deprecated: Boolean
+- deprecationMessage: String
+
+```vue
+<template>
+    {# @deprecated tag:v6.7.0 - Will be removed use position XYZ instead #}
+    <sw-extension-component-section
+        position-identifier="sw-chart-card__before"
+        :deprecated="true"
+        deprecation-message="Use position XYZ instead."
+    />
+</template>
+```
+
+For `data sets`, we mimicked the same in the publishing options:
+
+- deprecated: Boolean
+- deprecationMessage: String
+
+```javascript
+createdComponent() {
+    /* @deprecated tag:v6.7.0 - Will be removed, use API instead */ 
+    Shopware.ExtensionAPI.publishData({
+        id: 'sw-dashboard-detail__todayOrderData',
+        path: 'todayOrderData',
+        scope: this,
+        deprecated: true,
+        deprecationMessage: 'No replacement available, use API instead.'
+    });
+},
+```
+
+#### Best practices
+It is considered best practice to add a comment with the usual `@deprecated` annotation, so these parts are not missed in a major version update.
+
+## Consequences
+- Both `component sections` and `data sets` marked as deprecated will throw an error in a dev environment
+- Both `component sections` and `data sets` marked as deprecated will publish a warning in a prod environment
+
+The error or warning message will always state which extension used the deprecated `data set` or `component section` and provide the corresponding ID's:
+
+```shell
+# component section
+[CORE] The extension "TestApp" uses a deprecated position identifier "foo_bar". Use position identifier "XYZ" instead.
+
+# data set
+[CORE] The extension "TestApp" uses a deprecated data set "foo_bar". No replacement available, use API instead.
+```
+
+The first sentence containing the app name and the `data set`/ `component section` ID will always be the same format.
+Any information provided through the `deprecationMessage` will be appended as an addition.
+
+## Conclusion
+With all this, we assured that the public API of the Meteor Admin SDK is treated as such, but we have the possibility to properly deprecate.
diff --git a/resources/references/adr/2024-07-30-add-telemetry-abstraction-layer.md b/resources/references/adr/2024-07-30-add-telemetry-abstraction-layer.md
new file mode 100644
index 000000000..11aeb9c26
--- /dev/null
+++ b/resources/references/adr/2024-07-30-add-telemetry-abstraction-layer.md
@@ -0,0 +1,77 @@
+---
+title: Telemetry abstraction layer
+date: 2024-07-30
+area: core
+tags: [core, profile, performance, datadog, metrics, monitoring]
+---
+
+# Telemetry abstraction layer
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-07-30-add-telemetry-abstraction-layer.md)
+:::
+## Context
+
+Observability is a key aspect of modern software development. It is essential to have the right tools in place to monitor and analyze runtime statistics of the application.
+
+Many tools and backends are available to enable telemetry and monitoring. The context of this ADR is to provide a streamlined and simple way to enable the integration of any observability tool into the Shopware platform.
+
+## Decision
+
+To address the need for a unified way to track metrics and performance data, we will introduce a telemetry abstraction layer. This layer will provide a common interface for integrating different monitoring tools into the Shopware platform.
+
+The telemetry abstraction layer will consist of the following components:
+
+### Shopware's abstraction layer
+
+The abstraction layer will provide a common interface for telemetry integration. It will define the methods and data structures required to send telemetry data to the monitoring backend.
+
+### Events subsystem attachment
+
+The telemetry abstraction layer will be integrated with the existing events subsystem. This integration will allow developers to hook into specific events and capture telemetry data related to those events.
+
+### Transport layer (integrations)
+
+Vendor specific implementation will not be part of the core. Those would be shipped as external libraries that implement the telemetry abstraction layer specification. The core will provide documentation on how to integrate these libraries into the Shopware platform.
+
+Each transport layer should at least be aware of the following metrics objects:
+- `Shopware\Core\Framework\Telemetry\Metrics\Metric\Counter`
+- `Shopware\Core\Framework\Telemetry\Metrics\Metric\Gauge`
+- `Shopware\Core\Framework\Telemetry\Metrics\Metric\Histogram`
+- `Shopware\Core\Framework\Telemetry\Metrics\Metric\UpDownCounter`
+
+Or more generally, should aim to cover all the metric types defined inside the `Shopware\Core\Framework\Telemetry\Metrics\Metric` namespace.
+
+### Implementation and Considerations
+
+Each transport should implement the `MetricTransportInterface`. This interface defines a method `emit` that takes a `MetricInterface` object as an argument. The `MetricInterface` object represents a single metric that needs to be sent to the monitoring backend.
+
+If an instance of an unsupported metric type is passed to the transport, it should throw a `MetricNotSupportedException`. This ensures that the transport layer is decoupled from the core and can be extended to support new metric types in the future.
+
+> `MetricNotSupportedException` is gracefully handled, and the application will skip over the unsupported metric type. 
+
+```php
+interface MetricTransportInterface
+{
+    /**
+     * @throws MetricNotSupportedException
+     */
+    public function emit(MetricInterface $metric): void;}
+```
+
+The `MetricInterface` is a generic empty interface. This approach provides flexibility for different monitoring tools to define their own metric structures alongside the core ones.
+
+```php
+interface MetricInterface
+{
+}
+```
+
+## Consequences
+
+By implementing a telemetry abstraction layer, we provide a unified way to integrate monitoring tools into the Shopware platform. This approach simplifies the process of adding telemetry to the application and ensures consistency across different monitoring tools.
+
+## Usage
+
+See [README.md](../src/Core/Framework/Telemetry/) for the implementation and usage details.
diff --git a/resources/references/adr/2024-07-31-add-more-unit-tests-namespaces-to-featureflag-extension.md b/resources/references/adr/2024-07-31-add-more-unit-tests-namespaces-to-featureflag-extension.md
new file mode 100644
index 000000000..3f760f17d
--- /dev/null
+++ b/resources/references/adr/2024-07-31-add-more-unit-tests-namespaces-to-featureflag-extension.md
@@ -0,0 +1,59 @@
+---
+title: Add more unit tests namespaces to FeatureFlag extension
+date: 2024-07-31
+area: core
+tags: [ core, plugin, test, unit, major ]
+---
+
+# Add more unit tests namespaces to FeatureFlag extension
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-07-31-add-more-unit-tests-namespaces-to-featureflag-extension.md)
+:::
+
+## Context
+
+The `Shopware\Core\Test\PHPUnit\Extension\FeatureFlag\Subscriber\TestPreparationStartedSubscriber` only allows
+the `Shopware\Tests\Unit` namespace to be considered when enabling the major feature in the unit tests suite.
+
+## Decision
+
+To be able to unit test the upcoming major feature in other plugins we will enable the possibility to add other
+namespaces to
+the `Shopware\Core\Test\PHPUnit\Extension\FeatureFlag\Subscriber\TestPreparationStartedSubscriber`.
+
+We'll add a static method called `addNamespace()` method to the
+`Shopware\Core\Test\PHPUnit\Extension\FeatureFlag\FeatureFlagExtension` and by this we are able to add other namespaces
+to the allowlist of the namespaces to be considered when enabling the major flags in the unit test suite.
+
+This can be useful for plugins that wants to enable the major flags in their unit tests suite.
+
+Therefore, add the extension to the extension list in the `phpunit.xml`:
+
+```xml
+
+<extensions>
+    ...
+    <bootstrap class="Shopware\Core\Test\PHPUnit\Extension\FeatureFlag\FeatureFlagExtension"/>
+</extensions>
+```
+
+And register your test namespace in your test bootstrap file:
+
+```php
+FeatureFlagExtension::addTestNamespace('Your\\Unit\\Tests\\Namespace\\');
+```
+
+For example, in the Commercial plugin, we added the following code to the `tests/TestBootstrap.php` file:
+
+```php
+FeatureFlagExtension::addTestNamespace('Shopware\\Commercial\\Tests\\Unit\\');
+```
+
+## Consequences
+
+If your namespace will be added via the `FeatureFlagExtension::addNamespace()` method, the major flags will be enabled
+by default in your unit tests suite, and you have to explicitly disable the feature you don't want to be executed with
+the upcoming major flag turned on. If you want to know the decision why all feature flags are activated by default,
+please read [this ADR](https://github.com/shopware/shopware/blob/trunk/adr/2022-10-20-deprecation-handling-during-phpunit-test-execution.md#L15-L14). 
diff --git a/resources/references/adr/2024-08-02-system-health-check.md b/resources/references/adr/2024-08-02-system-health-check.md
new file mode 100644
index 000000000..6d6188995
--- /dev/null
+++ b/resources/references/adr/2024-08-02-system-health-check.md
@@ -0,0 +1,131 @@
+---
+title: System Health Checks in Shopware
+date: 2024-08-02
+area: core
+tags: [health-check, system, monitoring]
+---
+
+# System Health Checks in Shopware
+
+::: info
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2024-08-02-system-health-check.md)
+:::
+
+## Context
+
+In some instances, a system rollout was completed where an error in certain system functionalities was not detected until the system was live.
+
+A software system is made up of many components that work together to provide a service. The software system can still be healthy even if some of its components are not fully in a healthy state.  System health checks are a way to monitor the health of a system and detect failures early.
+
+## Decision
+
+We will implement system health checks in Shopware to monitor certain parts of the system with the aim to detect failures and issues early.
+This system should be extensible and allow for custom health checks to be added with ease.
+
+### Abstractions and Core concepts
+
+The following abstractions and concepts, are core to the implementation:
+
+1. **Shopware\Core\Framework\SystemCheck\BaseCheck**:
+    - Defines a base class for all system checks.
+
+2. **Shopware\Core\Framework\Health\Check\Category**:
+    - Represents the category of functionality that the check is covering. 
+    - Categories:
+        - `SYSTEM`: System checks makes sure that the backbone of the software is functioning correctly. Example: Database connection.
+        - `FEATURE`: Feature checks make sure that a specific feature of the software is functioning correctly. Example: Payment system.
+        - `EXTERNAL`: External checks make sure that external services are responding correctly. Example: SMTP server is online.
+        - `AUXILIARY`: Auxiliary checks make sure that auxiliary services are functioning correctly. Example: background tasks are running.
+
+3. **Shopware\Core\Framework\SystemCheck\Check\Result**:
+    - Represents the outcome state of a check.
+
+4. **Shopware\Core\Framework\SystemCheck\Check\Status**:
+    - Represents the status of a health check result.
+    - Statuses (in order of severity):
+      - `OK`: The component is functioning correctly.
+      - `SKIPPED`: The component check was skipped.
+      - `UNKNOWN`: The component status is unknown.
+      - `WARNING`: The component is functioning but with some issues that are not errors.
+      - `ERROR`: The component has runtime errors, but some parts of it could still be functioning.
+      - `FAILURE`: The component has failed with irrecoverable errors.
+
+5. **Shopware\Core\Framework\SystemCheck\Check\SystemCheckExecutionContext**:
+    - Represents the context in which a health check is executed.
+    - Contexts:
+        - `WEB`: The check is running in a web environment.
+        - `CLI`: The check is running in a command-line interface environment.
+        - `PRE_ROLLOUT`: The check is running before a system rollout.
+        - `RECURRENT`: The check is running as part of a scheduled task.
+
+#### System Check Guidelines
+
+System checks can differ in complexity, purpose, and computational cost. The types are logical categorizations based on the need and cost for the test and is used to determine the appropriate execution context for a check.
+This distinction is primarily reflected in the `Shopware\Core\Framework\SystemCheck\BaseCheck` class method:
+
+```php
+    protected function allowedSystemCheckExecutionContexts(): array
+    {...}
+```
+
+##### Readiness Checks
+
+Readiness checks are intended to be run by infrastructure teams to determine if a system is ready to be rolled out and accept traffic or run scheduled tasks.
+
+Those checks should typically check critical paths of the system, such as correct configuration and if the storefront indices are correctly opening.  There are no requirements for readiness checks to be fast.
+
+Those system checks would have:
+
+```php
+    protected function allowedSystemCheckExecutionContexts(): array
+    {
+        return \Shopware\Core\Framework\SystemCheck\Check\SystemCheckExecutionContext::readiness();
+    }
+```
+
+##### Health Checks
+
+Health checks are intended to be run by monitoring systems to determine if a system is healthy and functioning correctly. Those checks should typically check the health of the system, such as database connectivity, cache availability, and other critical components.
+
+A requirement to a typical health-check is that it should be fast, inexpensive, and not block the system.
+
+Those system checks would have:
+
+```php
+    protected function allowedSystemCheckExecutionContexts(): array
+    {
+        return \Shopware\Core\Framework\SystemCheck\Check\SystemCheckExecutionContext::cases();
+    }
+```
+
+##### Long Running Checks
+
+This type of check is essentially a health check that can take a long time to run. This type of check should be run sparingly and is only allowed to run when on CLI.
+An example of such test would be a check to verify that there are no issues in log files.
+
+Those system checks would have:
+
+```php
+    protected function allowedSystemCheckExecutionContexts(): array
+    {
+        return \Shopware\Core\Framework\SystemCheck\Check\SystemCheckExecutionContext::longRunning();
+    }
+```
+
+##### Other
+
+This type would be any custom check where it needs to be run in a different context other than the templates given above. This could be anything, based on the requirements of the check.
+
+```php
+    protected function allowedSystemCheckExecutionContexts(): array
+    {
+        # list of contexts
+        return [SystemCheckExecutionContext::CRON, SystemCheckExecutionContext::WEB];
+    }
+```
+
+## Consequences
+
+by implementing system health checks, we ensure that the system is monitored and that issues are detected early. This will help to prevent system failures and improve the overall stability of the system.
+Moreover, it helps detecting issues at the time of deployment and helps to prevent issues from reaching the end-users.
diff --git a/resources/references/adr/2020-08-10-feature-flag-system.md b/resources/references/adr/_superseded/2020-08-10-feature-flag-system.md
similarity index 91%
rename from resources/references/adr/2020-08-10-feature-flag-system.md
rename to resources/references/adr/_superseded/2020-08-10-feature-flag-system.md
index e8a7fc4f5..b0616c575 100644
--- a/resources/references/adr/2020-08-10-feature-flag-system.md
+++ b/resources/references/adr/_superseded/2020-08-10-feature-flag-system.md
@@ -9,10 +9,10 @@ tags: [feature-flag, workflow]
 
 ::: info
 This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
-You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2020-08-10-feature-flag-system.md)
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/_superseded/2020-08-10-feature-flag-system.md)
 :::
 
-## Superseded by [Feature flags for major versions](2022-01-20-feature-flags-for-major-versions)
+## Superseded by [Feature flags for major versions](../2022-01-20-feature-flags-for-major-versions)
 
 ## Context
 To provide a way to toggle code from incomplete features, the feature flag system was implemented.
diff --git a/resources/references/adr/2020-08-19-handling-feature-flags.md b/resources/references/adr/_superseded/2020-08-19-handling-feature-flags.md
similarity index 92%
rename from resources/references/adr/2020-08-19-handling-feature-flags.md
rename to resources/references/adr/_superseded/2020-08-19-handling-feature-flags.md
index cb99460f1..44912a43a 100644
--- a/resources/references/adr/2020-08-19-handling-feature-flags.md
+++ b/resources/references/adr/_superseded/2020-08-19-handling-feature-flags.md
@@ -9,10 +9,10 @@ tags: [feature-flag, workflow, major]
 
 ::: info
 This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
-You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2020-08-19-handling-feature-flags.md)
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/_superseded/2020-08-19-handling-feature-flags.md)
 :::
 
-## Superseded by [Feature flags for major versions](2022-01-20-feature-flags-for-major-versions)
+## Superseded by [Feature flags for major versions](../2022-01-20-feature-flags-for-major-versions)
 
 ## Context
 
diff --git a/resources/references/adr/2021-01-21-deprecation-strategy.md b/resources/references/adr/_superseded/2021-01-21-deprecation-strategy.md
similarity index 99%
rename from resources/references/adr/2021-01-21-deprecation-strategy.md
rename to resources/references/adr/_superseded/2021-01-21-deprecation-strategy.md
index 347a6b255..84078eecf 100644
--- a/resources/references/adr/2021-01-21-deprecation-strategy.md
+++ b/resources/references/adr/_superseded/2021-01-21-deprecation-strategy.md
@@ -9,10 +9,10 @@ tags: [deprecation, feature-flags, workflow]
 
 ::: info
 This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
-You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2021-01-21-deprecation-strategy.md)
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/_superseded/2021-01-21-deprecation-strategy.md)
 :::
 
-## Superseded by [Feature flags for major versions](2022-01-20-feature-flags-for-major-versions)
+## Superseded by [Feature flags for major versions](../2022-01-20-feature-flags-for-major-versions)
 
 ## Context
 
diff --git a/resources/references/adr/2023-09-22-catalog-import-api.md b/resources/references/adr/_superseded/2023-09-22-catalog-import-api.md
similarity index 98%
rename from resources/references/adr/2023-09-22-catalog-import-api.md
rename to resources/references/adr/_superseded/2023-09-22-catalog-import-api.md
index 766ad23d1..2a55fdcb7 100644
--- a/resources/references/adr/2023-09-22-catalog-import-api.md
+++ b/resources/references/adr/_superseded/2023-09-22-catalog-import-api.md
@@ -9,8 +9,9 @@ tags: [catalog, product, category, import, api]
 
 ::: info
 This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
-You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/2023-09-22-catalog-import-api.md)
+You can find the original version [here](https://github.com/shopware/shopware/blob/trunk/adr/_superseded/2023-09-22-catalog-import-api.md)
 :::
+## Superseded as this "project" was aborted as a lot of further issues came up while working on this approach.
 
 ## Context
 
diff --git a/resources/references/adr/_superseded/index.md b/resources/references/adr/_superseded/index.md
new file mode 100644
index 000000000..e69de29bb