AeonDumpManager/CLAUDE.md

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## What this is

AeonDumpManager is a Shopware 6 plugin (`shopware-platform-plugin`) that manages database dumps for
Shopware 6 development environments. It lists, creates, and deletes gzip-compressed `mysqldump`/
`mariadb-dump` SQL dumps, both from a Settings-page admin UI (async creation with a polling progress
bar) and via `aeon:dump:{list,create,remove}` console commands (sync creation). Design decisions and
the full build spec live under `.scratch/admin-dump-manager/` and `.scratch/dump-manager-implementation-spec/`
(Wayfinder maps) — consult those before changing the dump-creation/retention/ACL behavior.

- Plugin bootstrap class: `src/AeonDumpManager.php` (extends `Shopware\Core\Framework\Plugin`) — this
  is the entry point Shopware calls for install/uninstall/activate/deactivate/update lifecycle hooks.
- Plugin class name is wired via `composer.json` → `extra.shopware-plugin-class`.
- Services are registered manually in `src/Resources/config/services.yaml` (Symfony DI, YAML format,
  autowiring is not configured — every new service/command/task must be added here explicitly with
  its tag, e.g. `console.command` or `shopware.scheduled.task`).
- Plugin store-config UI fields (e.g. `maxDumps`, `retantionDays`) are defined in
  `src/Resources/config/config.xml` and read at runtime via Shopware's SystemConfigService.
- `src/Resources/app/administration/` holds the admin UI module (Vue-based Shopware Administration
  extension). The `aeon-dump-manager` module (`src/module/aeon-dump-manager/`) provides the list page
  (`page/aeon-dump-manager-list`), en-GB/de-DE snippets and ACL privilege roles (`acl/`: `viewer`,
  `creator`, `deleter`); `src/service/dump-api.service.ts` is the client for the dump API routes.

## Running the plugin

There is no standalone runtime — this plugin only runs inside a Shopware 6 instance. Local dev uses
`docker-compose.yml`, which mounts the repo into a `dockware/shopware` container at
`custom/plugins/AeonDumpManager`:

```bash
docker compose up -d
```

Shop/Admin/Adminer are all served on port 80/443; SSH into the container on port 22
(`SSH_USER=shopware` / `SSH_PWD=shopware`); admin-watcher and storefront-watcher proxies are exposed
on 8888/9998/9999 for `bin/build-administration.sh --watch` style workflows run inside the container.

Plugin install/activate must be done through Shopware's own tooling inside the container (e.g.
`bin/console plugin:refresh`, `bin/console plugin:install --activate AeonDumpManager`) — there is no
composer script for this in this repo.

The container's internal processes run as uid/gid 33 (`www-data`). The repo directory on the host is
group-owned by that group with setgid bit set (`chgrp -R 33` + `chmod g+s`), so both the container and
host users in group 33 can write without ownership fights.

## Tests

PHPUnit, bootstrapped through Shopware's own `TestBootstrapper` (`tests/TestBootstrap.php`), which
activates this plugin inside a real Shopware kernel for the test run (`KERNEL_CLASS` is set to
`Shopware\Core\Kernel` in `phpunit.xml`). This means tests require a working Shopware installation/DB
to bootstrap against — they are not runnable as an isolated PHP package.

In CI (`phpunit` job) a Shopware 6.6 project is prepared once (`composer create-project` + phpunit,
cached monthly), the plugin is copied into `custom/plugins`, and `system:install` runs once into
`shopware_test` (MariaDB 10.11 service), so the bootstrapper only activates the plugin.

```bash
vendor/bin/phpunit                              # full suite
vendor/bin/phpunit --filter TestClassName        # single test class
vendor/bin/phpunit tests/SomeTest.php            # single file
```

## Dependencies

- PHP `^8.2`, `shopware/core` `~6.6.0` (from `composer.json`); `phpunit/phpunit` `^10.0` as the only
  dev dependency.
- PSR-4 autoload: `AeonDumpManager\` → `src/`, `AeonDumpManager\Tests\` → `tests/`.

## CI / release pipeline

Gitea workflows in `.gitea/`, plugin-agnostic (name/version come from `composer.json`). `shopware-cli`
runs from its official Docker image, intentionally unpinned (`latest`): a red build after a CLI release
means fix the config.

- `workflows/plugin-checks.yml` (PRs into `main`) has three jobs: `version-changelog` (every PR into
  `main` must bump `composer.json` version and add a matching `## [x.y.z]` CHANGELOG heading), `package`
  (shared composite action `actions/package`: `shopware-cli extension package`, `extension validate` on
  the zip, `scripts/ci/assert-built-assets.sh`), and `phpunit`. The package job caches the tested zip
  keyed by the commit's tree hash.
- `workflows/release.yml` (push to `main`, serialized; every step is idempotent so a failed run can simply be re-run): reuses the
  cached zip when the tree hash matches (else packages again, always re-validates), creates the Gitea
  release + tag via API with the zip as asset, publishes a root-level repack of the zip to the Composer registry
  (Gitea requires `composer.json` at the zip root), then links the
  package to the repo. Uses `RELEASE_TOKEN`.
- Required checks on `main` (`plugin-checks / version-changelog|package|phpunit (pull_request)`) are set
  once with `scripts/protect-main.sh` (`tea api`). Build excludes/validation live in
  `.config/shopware-extension.yml`. Background: `docs/spec/shopware-guideline-compliance.md`.

## Adding functionality

- New console commands go in `src/Command/`, new scheduled tasks in `src/ScheduledTask/` — both must
  be registered in `src/Resources/config/services.yaml` with the appropriate tag or Shopware will not
  discover them.
- Scheduled tasks need a matching handler (tagged `messenger.message_handler`) to actually run; a bare
  `ScheduledTask` subclass like `ExampleTask` only defines the schedule, not the behavior.