@execuro-sw-ecosystem/sw-ecosystem-agentic-harness 0.1.10 → 0.1.12

package/skills/sw-discover-tender/reference/response-rules.md

@@ -1,13 +1,14 @@
-# Response CSV rules
+# Export rules
 
-The rules for the response CSV the client receives. Goes into every §RESP brief verbatim. Section numbers refer to the analysis file.
+The runtime's `export` command applies these; this file is the reference an agent or the operator checks a result against. No agent writes an export file — export is a runtime command / API call, and there is no per-cluster CSV of any kind.
 
-- **RSP-1 Columns.** The header row is the client's: every context column verbatim in the client's order and wording, then the vendor columns exactly as the client named them. Context cells are copied from the source unchanged. The skill fills only the compliance, comment and effort columns; every other vendor column (one-off cost, recurring cost, further columns) is present and empty. When the source has no vendor columns, `Vendor: Compliance`, `Vendor: Comment`, `Vendor: Effort (PD)` are appended in the RFP's language.
-- **RSP-2 Rows.** Exactly the source rows in source order, one line per requirement. No row added, dropped, merged or reordered. Cells the client had prefilled are kept. Assumption and clarification sub-lines never become rows.
-- **RSP-3 Compliance.** The token from the client's allowed list per `coverage-mapping.md`, derived from the row's class after accepted assumptions. A blocked row carries its likely class. `Not offered` only on a partner decision logged as `C-n`.
-- **RSP-4 Comment.** Client-facing, RFP language, plain words, no internal identifiers. Order: the one-line mechanism; then every accepted assumption that names the row (its own `.a` lines and global lines) as one sentence each, introduced as "Assumption:"; then clarifications (`.c` lines, `RC-n` naming the row) introduced as "As clarified:"; then, for a row whose status names a still open non-blocking client question (`estimated, CQ-n`), "Subject to the open clarification" in plain words. Never present: proposed or rejected assumptions, PD deltas, evidence paths, agent names, low/mid/high figures, money.
-- **RSP-5 Effort.** The row's PD final from section 4 after accepted assumptions, with overhead and buffer as applied in section 2, so the column sums to the Summary totals. Number with a dot decimal, rounded as in the analysis. Blocked rows: empty cell and the comment "Effort stated after clarification of <topic in plain words>". Commitment rows: 0. Service rows: their PD.
-- **RSP-6 Money.** Cost cells stay empty. No currency, rate, price or budget reference anywhere in a file.
-- **RSP-7 Encoding and delimiter.** UTF-8. When the input was the operator's CSV export, delimiter, quoting and BOM mirror that file. Otherwise UTF-8 with BOM, semicolon for a German RFP, comma otherwise. RFC 4180 quoting: fields containing the delimiter, a quote or a line break are quoted, quotes are doubled; line breaks inside a comment are allowed. One header row, no blank lines, no totals row, no timestamps.
+- **X-1** Available anytime. Unconfirmed scope items export with empty answer cells.
+- **X-2** XLSX input: `<source basename>-response-v<n>.xlsx` (X-9), a copy of the client's own workbook. The original is never modified. `export` refuses while any exported table lacks its coverage-to-client-token map, listing the tables (by their `<sheet> r<headerRow>` key) — map them first (`coverage-mapping.md`, `procedure.md` step 7).
+- **X-3** Fit-back by item pointer: export resolves each item via the committed fit-back map (`import-map.json`, `<srcdir>/<base>/import-map.json`) — `items[id].table` names the table, `items[id].row` the row — and writes the mapped compliance token, the Client Response and the effort into the client's own columns at that row. An item with no pointer is reported as `not written: <id> (no source row)`, never silently dropped. The coverage-to-client-token map is decided agentically at export, not at intake (`coverage-mapping.md`), and stored per table key for later exports of the same document. Accepted assumptions go into the mapped assumptions column when a table named one; otherwise they follow the Client Response as bullets in the same cell. No column is added.
+- **X-4** Surgical write: only the written cells change; every other part of the workbook is copied byte-for-byte; Excel recalculates on open. No library that re-serialises the workbook.
+- **X-5** CSV or PDF input: no fit-back map — `<source basename>-response-v<n>.xlsx` (X-9) built as the tool's own workbook mirroring the working sheet's own tabs in page order: `Overview` (regime, totals by priority and by tab, readiness counts), `Project information` (`Parameter · Value · Source`), `Functional`/`Non-functional`/`Project & services` (always present, columns `ID · Topic · Requirement · Requirement Coverage (the six values as-is) · Estimation · Client Response · Assumptions`, answer cells filled for confirmed items only), `Integrations`, `Glossary`; `Log` and References are never exported.
+- **X-6** The page shows each scope item's exact exported text before it is confirmed, for every item, confirmed or not.
+- **X-7** The tool writes no cost, price, rate, licence fee or budget of its own — see `estimation-model.md`'s money rule for the exact word list, the `cost:` exemption and scope. Project information keeps the client's or the operator's own figure verbatim; a `cost:` reference is never exported.
+- **X-9** Numbered exports: every export writes `<base>-response-v<n>.xlsx`, `n` the next free number — an existing file, and an explicit `--out` that already exists, are never overwritten. Each export appends a section 8 Log line: `- <date> · export v<n> · <file> · confirmed <c>/<n> · changed since v<n-1>: <k>`. "Changed since last export" is the set of confirmed items whose exported text differs from the last export's snapshot, or that are newly confirmed since then; it is shown in the CLI export output, in the section 8 line, and as a page filter.
 
-Class notes for the comment, before the mechanism: `commitment` → "No development, commitment." · `service` → "Service effort, no development." · `config` → "Configuration only." · `plugin` → "Store extension, integration effort only; <extension>, <licence source>."
+Unproven in the XLSX writer, per the task 3 POC: conditional formatting, print area, over-wide or x14 validation, tables, pre-filled answer cells, desktop Excel, Google Sheets.

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

@@ -22,9 +22,18 @@ Implement one feature from its technical spec, under TDD, then hand off to full
 
 ### 0. Pre-check
 
-Invoke `sw-setup` once. Rows an AC's tests need — vendor/ (PHPUnit); Acceptance-test project, Playwright browsers, ATS env (e2e); Plugin tests (target plugin) — must be ticked; unticked → stop, tell the user to run `/sw-setup`. Never mark an AC `partly` for a missing environment.
+**Probe what this run is about to use, never the whole environment.** Check only what the ACs in this run actually need, as file existence — never invoke `sw-setup`, which surveys twelve rows behind an `npx` registry call to answer two or three of them:
 
-**Shopware version — detect once, before spawning anything, never assume:** `vendor/shopware/core/composer.json` `version` → `composer.lock` → `composer.json` constraint ("unconfirmed"); PHP from the project runtime (`compose.yaml`, `.ddev/config.yaml`, `Dockerfile`), not the host. State it with evidence in every Agent-tool brief below — implementer spawns, architect escalation, QA e2e runs — so no sub-agent has to re-derive it; a version with no evidence must still be passed on as unconfirmed (e.g. constraint-only), never treated as certain. Unknown → ask the user.
+| This run has… | Probe |
+| --- | --- |
+| any AC | `vendor/shopware/core`, plus `vendor/bin/phpunit` for a PHPUnit AC |
+| an e2e AC | `tests/acceptance/package.json`, `tests/acceptance/playwright.config.ts`, and `tests/acceptance/.env` defining `APP_URL`, `SHOPWARE_ADMIN_USERNAME`, `SHOPWARE_ADMIN_PASSWORD` |
+| an e2e AC | Playwright browsers — the cache directory (`~/.cache/ms-playwright`, or the project-local browsers path). Never `npx playwright install --dry-run`: it reaches the network |
+| a PHPUnit or Jest AC | in the target plugin: `phpunit.xml.dist`, `tests/TestBootstrap.php`, and `jest.admin.config.js` / `jest.storefront.config.js` only for the surface that AC touches |
+
+An API-only feature never probes Playwright. Anything missing → stop, tell the user to run `/sw-setup` — it is the one place the environment is fixed, and this skill neither invokes nor repairs it. Never mark an AC `partly` for a missing environment.
+
+**Shopware version — detect once, before spawning anything, never assume** (the first path is also the vendor/ probe above, so read it once): `vendor/shopware/core/composer.json` `version` → `composer.lock` → `composer.json` constraint ("unconfirmed"); PHP from the project runtime (`compose.yaml`, `.ddev/config.yaml`, `Dockerfile`), not the host. State it with evidence in every Agent-tool brief below — implementer spawns, architect escalation, QA e2e runs — so no sub-agent has to re-derive it; a version with no evidence must still be passed on as unconfirmed (e.g. constraint-only), never treated as certain. Unknown → ask the user.
 
 
 Then work through the three reference files in this skill's directory, in order:

package/skills/sw-setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sw-setup
-description: Print one environment-readiness table for the project's development/test setup — vendor/, Node, the editor CLIs, shopware-cli, the KB MCP, the acceptance-test project, Playwright browsers, its .env, per-plugin test scaffolding, the project wiki, `.gitignore` and whether the SW AH npm packages are current, plus the installer CLI's own configuration/drift status. Stops when every row is ticked. When rows are missing, asks one yes/no question and delegates the fix to the installer CLI. Use when asked to set up the project, check if the environment is ready, or bootstrap the tests. Never designs, implements or verifies a feature itself — that's sw-design-solution, sw-implement-feature and sw-verify-feature, which call this skill first. Never writes a coding agent's configuration file itself — that's the installer CLI.
+description: Print one environment-readiness table for the project's development/test setup — vendor/, Node, the editor CLIs, shopware-cli, the KB MCP, the acceptance-test project, Playwright browsers, its .env, per-plugin test scaffolding, the project wiki, `.gitignore` and whether the SW AH npm packages are current, plus the installer CLI's own configuration/drift status. Stops when every row is ticked. When rows are missing, asks one yes/no question and delegates the fix to the installer CLI. Use when asked to set up the project, check if the environment is ready, or bootstrap the tests. Never designs, implements or verifies a feature itself — that's sw-design-solution, sw-implement-feature and sw-verify-feature; run this one up front, before them. Never writes a coding agent's configuration file itself — that's the installer CLI.
 when_to_use: Trigger phrases — "set up the project", "is the environment ready", "bootstrap the tests", "sw-setup".
 allowed-tools: Read Glob Grep AskUserQuestion Skill Bash mcp__ShopwareDevKnowledgeBase__kb_status Bash(npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest *) Bash(npx -y @execuro-sw-ecosystem/sw-specs-editor@latest *) Bash(npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest *)
 ---
@@ -28,10 +28,15 @@ question; it never restates or re-implements the install protocol.
 
 ## Called from other skills
 
-`sw-design-solution`, `sw-implement-feature` and `sw-verify-feature` invoke
-this skill as their own first step and read its table; they never repeat
-these checks themselves. A caller passes no arguments and reads the printed
-table from this run's output — it does not re-run `sw-setup`'s checks.
+`sw-verify-feature` invokes this skill once, before spawning, and passes the
+table to its verifiers as `args`; one run standalone invokes it itself. A
+caller passes no arguments and reads the printed table, never re-running it.
+
+`sw-design-requirements`, `sw-design-solution` and `sw-implement-feature` do
+**not** invoke it: each probes only what its own run uses and stops naming
+`sw-setup` when one is missing. A full table is the price of surveying an
+environment, not of one run's prerequisites — so this skill stays the one place
+it is surveyed and fixed, run up front.
 
 ## Procedure
 

package/skills/sw-discover-tender/reference/confidence-rubric.md

@@ -1,80 +0,0 @@
-# Confidence rubric
-
-Score each dimension 0–100 against its bands, multiply by weight, sum, round to a whole percent. `points = score × weight / 100`. Score the document as written; a verdict given in chat does not count.
-
-## Coverage evidence — weight 20
-
-| Score | Band |
-| --- | --- |
-| 100 | Every Must `req` line's class rests on a PM verdict or a mechanism cited to `vendor/` or a KB page; ≤5% of rows `unverified` |
-| 70 | ≤15% `unverified`; Should/Could rows partly evidenced |
-| 40 | The PM wave was partly not consulted, or >15% `unverified` |
-| 0 | Classes set from memory |
-
-## Estimate basis — weight 20
-
-| Score | Band |
-| --- | --- |
-| 100 | Every estimated row has low/mid/high, a level and drivers; foundation efforts attached to named rows |
-| 70 | ≤10% of estimated rows lack a three-point |
-| 40 | The architect was not consulted for at least one cluster |
-| 0 | PD figures without agent input |
-
-## Scope lock — weight 20
-
-Counts `accepted` lines only. `[ ]`, an unreconciled `[x]`, `rejected` and `suspect` count as nothing.
-
-| Score | Band |
-| --- | --- |
-| 100 | ≥80% of Must PD sits on rows that are `detailed` or covered by an accepted line; every vague Must row has a `CQ-n` |
-| 70 | 60–80% of Must PD locked; every vague Must row has a `CQ-n` |
-| 40 | <60% locked, or a vague Must row without a `CQ-n` |
-| 0 | No accepted line and no client question |
-
-## Platform decision — weight 15
-
-| Score | Band |
-| --- | --- |
-| 100 | Plan, hosting, PSP and CMP decided in §6, each with a reason naming the rows it serves and a source (profile, PM tier, architect alternative); the plan's PD delta stated |
-| 70 | One §6 platform item `_TBD_` or open in a `Q-n` |
-| 40 | Two or more `_TBD_` or open, or the plan undecided |
-| 0 | Profile missing, or the §6 platform table empty |
-
-## Integration & migration — weight 15
-
-| Score | Band |
-| --- | --- |
-| 100 | Every interface and migration object the RFP names is in §6 with pattern and owner split; §8 and §1.2 are complete for every estimate-driving parameter and migration volume |
-| 70 | Main interfaces covered; secondary ones or the owner split missing; §8/§1.2 mostly complete |
-| 40 | Approach lines missing for named interfaces, or an estimate-driving §1.2 parameter or a §1.2 migration volume is missing without a `CQ-n` |
-| 0 | §6 interface and migration tables `_TBD_` |
-
-## Consistency — weight 10
-
-| Score | Band |
-| --- | --- |
-| 100 | All probes run (plugins, prior analyses, PRDs, partner assets, RFP-internal); every conflict resolved or logged as `K-n` in §7 |
-| 70 | Probes run; a `K-n` unresolved |
-| 40 | Probes run only partially |
-| 0 | A known conflict unrecorded |
-
-## Status
-
-| Confidence | Open `high` `Q-n` | Blocking `CQ-n` on a Must row | `suspect` lines | Unreconciled ticks | Status |
-| --- | --- | --- | --- | --- | --- |
-| > 90 | none | none | none | none | **Ready to submit** |
-| > 90 | any of the four present | | | | **Review** |
-| 80–90 | | | | | **Review** |
-| < 80 | | | | | **Draft** |
-
-The four conditions override the arithmetic. §2 *Weakest dimension* names every blocker by id.
-
-## Honesty rules
-
-- Do not round up to cross 80 or 90.
-- Never raise a score because the deadline is close or the user wants the response finished.
-- A row with an open non-blocking question (`estimated, CQ-n`) caps *Scope lock* at 70 for the share of Must PD it carries, unless the assumption its estimate rests on is `accepted`.
-- `_TBD_` anywhere in §6 caps that dimension at 40.
-- `_TBD_` overhead or buffer in the profile caps *Estimate basis* at 70; §2 states that PD is given before both.
-- `reuse: rfp-NNNN <ID>` is evidence only if the source row carried a verdict, not a guess.
-- If the total moved down since the last run, the report says so and names the cause.

package/skills/sw-discover-tender/reference/editor-mode.md

@@ -1,11 +0,0 @@
-# Pending harness edits for the tender skill
-
-The "Editor mode" section and the eight SKILL.md edits this file used to carry were **applied** (SKILL.md `## Editor mode`, the `--editor` / `--editor-session` input rows, step 0, the `[x] suspect` reconcile bullet, frontmatter, reference list), with the batch kinds redefined for staged writes. What follows is the only part still outstanding.
-
-## `extension` class (ladder OOTB → Plugin → Extension → Custom)
-
-- `coverage-mapping.md` Internal classes: add `| extension | Development on a specific, named, existing base — a stock feature, a store plugin, a partner asset or a project plugin under custom/plugins — materially smaller than building the capability from scratch; the base is named in the row's Text |`. Token rule: `| extension | the development token; comment prefix "Extension of <base>." |`. Synonyms: `| extension | Extension of, Erweiterung von |`. Note under the table: "Not the Shopware plugin/app sense and not 'uses extension points'; test: if the base disappeared, would the estimate roughly double? yes → extension, no → custom."
-- `analysis-template.md` kinds line: class `stock | config | plugin | extension | custom | commitment | service | not-offered | blocked`; the tool shows `stock` and `config` as OOTB.
-- `agent-briefs.md` §ARCH: the class list gains `extension` with the definition and test above; an `assume` candidate may name `extension` as the class the row takes once accepted. §ROWS: plugin vs extension, and extension vs custom, are not conflicts (the architect decides).
-- `estimation-model.md`: one line — an `extension` row states its base in Text; the three-point covers the delta on that base only.
-- `response-rules.md` class note line: `extension` → "Extension of <base>."