@execuro-sw-ecosystem/sw-ecosystem-agentic-harness 0.1.0 → 0.1.3

package/skills/sw-setup/reference/rows.md

@@ -6,18 +6,7 @@ unticked. Host configuration files (`.mcp.json` entries, `.gitignore` lines,
 permission grants) are not rows here — the installer CLI owns them and
 reports their state in its own `status`/`plan` output; see `SKILL.md`.
 
-## 1. Containers
-
-- **Check:** `docker compose ps` — service `web` (or the service named in
-  `compose.yaml`) shows `running`/`healthy`.
-- **Ticked:** the `web` service is up.
-- **Fix:** `docker compose up -d` (guideline §6.1). If the shop was never
-  installed: `docker compose exec web php bin/console system:install --basic-setup --force --no-interaction` (guideline §6.1).
-- **Blocks:** every other row's fix that runs `docker compose exec web …`
-  (vendor/, plugin tests). Design/implement/verify skills that need a running
-  shop for live checks.
-
-## 2. vendor/
+## 1. vendor/
 
 - **Check:** `vendor/shopware/core` exists, `composer.lock` exists,
   `vendor/bin/phpunit` exists — file presence only, never a host
@@ -26,13 +15,20 @@ reports their state in its own `status`/`plan` output; see `SKILL.md`.
   (guideline §6.2).
 - **Ticked:** all three present; report the `shopware/core` version from
   `composer.lock`.
+- **Unticked:** the printed line names the specific missing path(s), not just
+  the row — e.g. a tree built `--no-dev` has `vendor/shopware/core` and
+  `composer.lock` but no `vendor/bin/phpunit`, so the line reads
+  `vendor/ — vendor/bin/phpunit missing (tree built --no-dev)`. This is the
+  same row and the same fix below, offered inside step 3's single question
+  like any other row.
 - **Fix:** `docker compose exec web composer install --no-interaction`
   (guideline §6.1 — "a vendor tree built with `--no-dev` has no
-  `vendor/bin/phpunit`"). Needs the Containers row ticked first.
+  `vendor/bin/phpunit`"). Runs inside the `web` container; if it is not
+  running, stop and report that — sw-setup never starts the stack itself.
 - **Blocks:** `sw-design-solution`, `sw-implement-feature`,
   `sw-verify-feature` (and its architecture/code-quality/ac-tests sub-skills).
 
-## 3. Node
+## 2. Node
 
 - **Check:** `node --version`; parse major and minor.
 - **Ticked:** ≥ 20. Warn (do not fail) when < 20.15: the Tender Discovery Tool
@@ -45,37 +41,37 @@ reports their state in its own `status`/`plan` output; see `SKILL.md`.
   (the knowledge-base MCP), the acceptance-test project,
   Playwright.
 
-## 4. Visual editors (optional)
+## 3. Visual editors (optional)
 
 The Specs Editor and the Tender Discovery Tool are **optional add-ons**, not
 part of this plugin. The installer CLI installs them itself, per host — this
-row never runs a companion package's own install command.
+row never runs an extra component's own install command.
 
 So this row never blocks readiness. It asks.
 
-- **Check:** read `companions[]` from the `status` output the skill already
+- **Check:** read `extra_components[]` from the `status` output the skill already
   ran in step 1 — each entry's `available`, `installed_for` (the hosts it is
   placed in), and `install` (the npm command, when missing). Never probe a
-  path and never run a companion package by hand; the CLI owns both.
-- **Ticked:** `[x]` when a companion's `available` is true and
+  path and never run an extra component by hand; the CLI owns both.
+- **Ticked:** `[x]` when an extra component's `available` is true and
   `installed_for` includes this host; `[-]` when the user has declined it.
   Only an unanswered offer shows `[ ]`, and even then it does not hold the
   table open — report it as optional and move on.
-- **Fix:** offer each missing companion inside step 3's single question,
+- **Fix:** offer each missing extra component inside step 3's single question,
   naming what it buys, not how it works: "Specs Editor — review a PRD or
   tech spec on a live page, with notes, question answers and diagrams.
   Install?" — and "Tender Discovery Tool — read a client tender workbook,
   confirm its column mapping and review the analysis on a live page.
   Install?" On yes, for each accepted one: `npm i -D <package>@0.1.0` (the
-  `package` field from `companions[]`), then re-run
+  `package` field from `extra_components[]`), then re-run
 
   ```
-  npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@0.1.0 apply --yes
+  npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest apply --yes
   ```
 
-  which places one `SKILL.md` per companion into each selected host's own
+  which places one `SKILL.md` per extra component into each selected host's own
   skills directory, records it, and removes it again on uninstall. **Never
-  run the companion package's own `install-skill`** — with no `--target` it
+  run the extra component's own `install-skill`** — with no `--target` it
   defaults to Claude Code's own skills directory, wrong for a Codex, Copilot
   or Cursor install. Needs the Node row ticked.
 - **On no:** record the decline and do not re-ask on the next run. `apply`
@@ -87,7 +83,7 @@ So this row never blocks readiness. It asks.
   Discovery Tool missing → `sw-discover-tender --editor` and its `.xlsx`
   import, plus the `sw-tender-discovery-tool` skill.
 
-## 5. shopware-cli
+## 4. shopware-cli
 
 - **Check:** `command -v shopware-cli`.
 - **Ticked:** present on `PATH`.
@@ -98,7 +94,7 @@ So this row never blocks readiness. It asks.
   (static analysis, Twig linters), `sw-implement-feature` (per-AC
   `extension fix`/`extension validate`).
 
-## 6. KB MCP
+## 5. KB MCP
 
 - **Check:** `mcp__ShopwareDevKnowledgeBase__kb_status` reports the `platform`
   layer as `implemented`. (Whether the `ShopwareDevKnowledgeBase` entry
@@ -118,7 +114,7 @@ So this row never blocks readiness. It asks.
   `sw-design-solution` step 0.5/step 3 (KB grep), `sw-product-manager`,
   `sw-shopware-architect`.
 
-## 7. Acceptance-test project
+## 6. Acceptance-test project
 
 - **Check:** `tests/acceptance/package.json` exists and lists
   `@shopware-ag/acceptance-test-suite` as a dependency;
@@ -137,7 +133,7 @@ So this row never blocks readiness. It asks.
 - **Blocks:** `sw-implement-feature` (e2e authoring by `sw-qa-engineer`),
   `sw-verify-feature-ac-tests` (Playwright execution).
 
-## 8. Playwright browsers
+## 7. Playwright browsers
 
 - **Check:** `npx playwright install --dry-run` output (or
   `~/.cache/ms-playwright`/the project-local browsers path) shows Chromium
@@ -148,7 +144,7 @@ So this row never blocks readiness. It asks.
   ticked (the `@playwright/test` version comes from there).
 - **Blocks:** `sw-implement-feature` (e2e execution), `sw-verify-feature-ac-tests`.
 
-## 9. ATS env
+## 8. ATS env
 
 - **Check:** `tests/acceptance/.env` exists.
 - **Ticked:** file exists and defines `APP_URL`, `SHOPWARE_ADMIN_USERNAME`,
@@ -163,7 +159,7 @@ So this row never blocks readiness. It asks.
   entered. Needs the Acceptance-test project row ticked.
 - **Blocks:** `sw-implement-feature` (e2e execution), `sw-verify-feature-ac-tests`.
 
-## 10. Plugin tests, per `custom/plugins/<Name>`
+## 9. Plugin tests, per `custom/plugins/<Name>`
 
 - **Enumerate:** `ls custom/plugins`; one row per directory found.
 - **Check per plugin:**
@@ -181,12 +177,13 @@ So this row never blocks readiness. It asks.
   `phpunit.xml.dist` from §3.3, `tests/TestBootstrap.php` from §3.4 (fill
   `<Name>`/`<Vendor>` from `composer.json`), Jest config(s) from §3.5 (option
   (a), plugin-local preset), `package.json` scripts block from §3.5's closing
-  JSON snippet. Needs the Containers row ticked for the `npm install` steps
-  that run inside the container.
+  JSON snippet. The `npm install` steps run inside the `web` container; if it
+  is not running, stop and report that — sw-setup never starts the stack
+  itself.
 - **Blocks:** `sw-implement-feature` (PHPUnit/Jest execution for that
   plugin's ACs), `sw-verify-feature` (and its sub-skills, for that plugin).
 
-## 11. Project wiki
+## 10. Project wiki
 
 - **Check:** `docs/project-wiki/` exists.
 - **Ticked:** directory present.
@@ -195,7 +192,7 @@ So this row never blocks readiness. It asks.
   logic here.
 - **Blocks:** `sw-document-feature`.
 
-## 12. `.gitignore`
+## 11. `.gitignore`
 
 - **Check:** `.gitignore` contains all six lines:
   ```

package/skills/sw-verify-feature/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-verify-feature
 description: Verify a feature implementation against its technical spec (specs/NNNN-slug-spec.md) by running three independent verifiers in parallel — AC test coverage/health, architecture/guideline compliance, and code quality/static analysis — then cross-checking their verdicts into one final per-AC pass/not pass/partly report. Wired as the final step of sw-implement-feature; can also be run standalone to (re)check a feature. Not to be confused with the existing "verify-implementation" skill, which is a mock and should be ignored.
 when_to_use: Trigger phrases — "verify spec 0007", "check if this feature is done", "run full verification for this feature", "is epic 1 actually passing".
-argument-hint: [specs/NNNN-slug-spec.md]
+argument-hint: '[specs/NNNN-slug-spec.md]'
 allowed-tools: Read Write Glob Grep Agent
 ---
 

package/skills/sw-verify-feature-ac-tests/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-verify-feature-ac-tests
 description: Verify that a feature's acceptance criteria are backed by tests that actually exist, actually pass, and actually test what their name/comment/PHPDoc claims. Classifies tests by type (API/PHPUnit, Admin Panel/Playwright, Storefront/Playwright, CLI/PHPUnit), runs a test-health audit to catch false, mismatched, or unhealthy tests, then reports per-AC Coverage and Execution as pass / partly / not pass. One of three parallel verifiers spawned by sw-verify-feature; can also be run standalone.
 when_to_use: Trigger phrases — "verify AC tests for spec 0007", "audit test health for this feature", "are these tests actually testing what they claim", "check test coverage for epic 1".
-argument-hint: [specs/NNNN-slug-spec.md]
+argument-hint: '[specs/NNNN-slug-spec.md]'
 allowed-tools: Read Glob Grep Bash mcp__playwright__browser_navigate mcp__playwright__browser_click mcp__playwright__browser_type mcp__playwright__browser_fill_form mcp__playwright__browser_snapshot mcp__playwright__browser_take_screenshot mcp__playwright__browser_wait_for mcp__playwright__browser_console_messages mcp__playwright__browser_network_requests mcp__playwright__browser_evaluate mcp__playwright__browser_select_option mcp__playwright__browser_press_key mcp__playwright__browser_hover mcp__playwright__browser_tabs mcp__playwright__browser_close
 ---
 

package/skills/sw-verify-feature-architecture/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-verify-feature-architecture
 description: Verify that a feature's implementation matches the architectural decisions its spec made, and complies with Shopware's own Core conventions plus any written Project guidelines this repo defines. Reports per-AC pass/partly/not pass with the specific guideline or mismatch behind any non-pass. One of three parallel verifiers spawned by sw-verify-feature; can also be run standalone.
 when_to_use: Trigger phrases — "verify architecture for spec 0007", "does this implementation follow the spec's design", "check Core/Project guideline compliance for this feature", "architecture audit for epic 1".
-argument-hint: [specs/NNNN-slug-spec.md]
+argument-hint: '[specs/NNNN-slug-spec.md]'
 allowed-tools: Read Glob Grep Bash mcp__ShopwareDevKnowledgeBase__list_docs mcp__ShopwareDevKnowledgeBase__grep_docs mcp__ShopwareDevKnowledgeBase__read_doc mcp__ShopwareDevKnowledgeBase__kb_status
 ---
 

package/skills/sw-verify-feature-code-quality/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-verify-feature-code-quality
 description: Verify the code-quality gate for a feature — identifies which tool suites actually apply (PHPStan, ESLint, Stylelint, sw-cli structural validation via shopware-cli, PHPUnit regression), executes them, and checks the touched files against written Core and Project guidelines' quality/style clauses (naming, duplication, dead code, unneeded complexity). Reports whole-plugin gate results plus any per-AC quality defect found in that AC's files. One of three parallel verifiers spawned by sw-verify-feature; can also be run standalone.
 when_to_use: Trigger phrases — "verify code quality for spec 0007", "run static analysis for this feature", "does this pass PHPStan/ESLint", "code quality gate for epic 1".
-argument-hint: [specs/NNNN-slug-spec.md]
+argument-hint: '[specs/NNNN-slug-spec.md]'
 allowed-tools: Read Glob Grep Bash mcp__ShopwareDevKnowledgeBase__list_docs mcp__ShopwareDevKnowledgeBase__grep_docs mcp__ShopwareDevKnowledgeBase__read_doc mcp__ShopwareDevKnowledgeBase__kb_status
 ---