Create not allowed features in the store

[Vlad (SW) (Swvla)]

We need a new separate page that lists which features are allowed and which are not.

[Micha Hobert (Isengo1989)]

Vlad (SW) (@Swvla) the file name and structure does not meet our standard. Please see other files. The structure is always the same. And a question, do we really need a subpage for that or simply add it to an existing page?

[Copilot]

Pull request overview

Adds a new monetization guide page intended to document which extension behaviors are disallowed (and explicitly permitted) for Shopware Store QA, with emphasis on security- and legally-critical constraints.

Changes:

• Introduces a new documentation page describing prohibited extension behaviors (DB/core filesystem manipulation, bypassing APIs, etc.).
• Adds an explicit “permitted” section to clarify acceptable extension mechanisms.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This new guide file doesn’t follow the existing documentation conventions in guides/development/monetization/: other pages use a .md filename (no spaces) and start with YAML front matter (nav: title/position) followed by an H1 heading (see guides/development/monetization/index.md:1-8). As-is, this page is likely not picked up by the docs navigation/build and also violates markdownlint MD041 (first line should be a top-level heading). Consider renaming the file to a kebab-case .md name, adding the front matter block, and starting the content with an # ... H1 heading so it integrates consistently with the rest of the docs.

[Copilot]

List items use multiple spaces after the - marker (e.g. - direct manipulation ...). With markdownlint MD030 enabled (see markdown-style-config.yml:78-80), this formatting can fail linting; use a single space after list markers (and keep indentation consistent for nested lists) throughout this page.

Suggested change

	- direct manipulation of the database (e.g. executing SQL queries from the admin area),
	- changes to the core table structure,
	- writing, overwriting or deleting files within the Shopware core or the existing directory structure,
	- circumventing designated APIs, DAL, events or services.
	**The following are permitted:**
	- extending via the mechanisms provided by Shopware (DAL, migrations, events, decorator pattern, subscribers, services),
	- copying existing structures (e.g. templates, configurations, assets) and adapting the copy without changing the original,
	- creating your own tables, entities, configuration values or directories, provided these are clearly assigned to the extension.
	Additional prohibitions (security & law)
	----------------------------------------
	In addition, extensions are not permitted that:
	- undermine security-related protection mechanisms (e.g. rights and role concepts, CSRF protection, validations),
	- enable uncontrolled system interventions by the shop operator or end customer (e.g. arbitrary SQL execution, file access or shell commands via the admin UI),
	- circumvent or override legal requirements, such as:
	- data protection and consent mechanisms,
	- logging, documentation or verification obligations,
	- mandatory information or legally prescribed processes.
	Explanation for developers (why this is the case)
	-------------------------------------------------
	Shopware is deliberately designed to ensure that extensions remain stable, update-proof and legally compliant. Direct interventions in the database or file system may seem pragmatic, but they pose a real risk:
	- **Security risk:** Free SQL or file access opens the door to data leaks, manipulation or escalation of user rights.
	- **Update failure:** Core structures are not a stable contract. What works today may cripple shops after the next update.
	- **Liability risk:** Extensions that undermine legal protection mechanisms not only cause problems for merchants, but also for the ecosystem.
	- **Quality standard:** The store stands for trust. Extensions must behave like good guests -- they are allowed to use the space, but not tear down the load-bearing walls.
	- direct manipulation of the database (e.g. executing SQL queries from the admin area),
	- changes to the core table structure,
	- writing, overwriting or deleting files within the Shopware core or the existing directory structure,
	- circumventing designated APIs, DAL, events or services.
	**The following are permitted:**
	- extending via the mechanisms provided by Shopware (DAL, migrations, events, decorator pattern, subscribers, services),
	- copying existing structures (e.g. templates, configurations, assets) and adapting the copy without changing the original,
	- creating your own tables, entities, configuration values or directories, provided these are clearly assigned to the extension.
	Additional prohibitions (security & law)
	----------------------------------------
	In addition, extensions are not permitted that:
	- undermine security-related protection mechanisms (e.g. rights and role concepts, CSRF protection, validations),
	- enable uncontrolled system interventions by the shop operator or end customer (e.g. arbitrary SQL execution, file access or shell commands via the admin UI),
	- circumvent or override legal requirements, such as:
	- data protection and consent mechanisms,
	- logging, documentation or verification obligations,
	- mandatory information or legally prescribed processes.
	Explanation for developers (why this is the case)
	-------------------------------------------------
	Shopware is deliberately designed to ensure that extensions remain stable, update-proof and legally compliant. Direct interventions in the database or file system may seem pragmatic, but they pose a real risk:
	- **Security risk:** Free SQL or file access opens the door to data leaks, manipulation or escalation of user rights.
	- **Update failure:** Core structures are not a stable contract. What works today may cripple shops after the next update.
	- **Liability risk:** Extensions that undermine legal protection mechanisms not only cause problems for merchants, but also for the ecosystem.
	- **Quality standard:** The store stands for trust. Extensions must behave like good guests -- they are allowed to use the space, but not tear down the load-bearing walls.

[Copilot]

The nested list under “circumvent or override legal requirements” also uses the - ... spacing pattern and inconsistent indentation, which is likely to violate markdownlint’s list formatting rules (MD005/MD030). Reformat the nested bullets to use one space after - and consistent indentation for the sublist.

Suggested change

	- data protection and consent mechanisms,
	- logging, documentation or verification obligations,
	- mandatory information or legally prescribed processes.
	- data protection and consent mechanisms,
	- logging, documentation or verification obligations,
	- mandatory information or legally prescribed processes.