@execuro-sw-ecosystem/sw-ecosystem-agentic-harness 0.1.11 → 0.1.13

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-setup/SKILL.md

@@ -50,10 +50,9 @@ npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest status --json
 
 `--json` is mandatory for every call this skill makes: without it the CLI
 prints a human summary, not the object below. It prints one JSON object
-(`ok`, `next_step`, `help`, and its own `agents[]`/`drift[]` configuration
-state). Alongside it, run every
-environment row's check from `reference/rows.md` in this skill's directory —
-read-only, seconds each: file/directory existence, one version command, one
+(`ok`, `next_step`, `help`, `targets`, `agents[]`, `drift[]`). First settle
+the target agents (`reference/rows.md`, Target agents); alongside, run every
+environment row's check from `reference/rows.md` — read-only, seconds each: file/directory existence, one version command, one
 `kb_status` call, one `npm view` registry lookup (Package updates row) — the
 one part of step 1 that touches the network, so it is the slow part.
 Never write, never install, never ask a question in this step.
@@ -74,7 +73,8 @@ one line per configuration item the CLI's `agents[]`/`drift[]` reports:
 - [x] Plugin tests — AhCheckout: phpunit + jest ok
 - [ ] Project wiki — docs/project-wiki/ missing
 - [ ] Package updates — harness 0.1.0 → 0.1.3
-- [ ] Installer config — .mcp.json entry: drift (from CLI status)
+- [x] Target agents — claude-code (anchored)
+- [ ] Installer config — .mcp.json entry: drift
 ```
 
 Per-plugin rows print one line per directory under `custom/plugins/`, e.g.
@@ -87,8 +87,7 @@ Print one closing line: `Environment ready.` Stop. No question.
 ### 3. Missing rows
 
 For a missing environment row, research only what it needs: the guideline
-sections `reference/rows.md` cites for that row
-(`shopware-project-qa-guidelines.md` §3.3–§3.7, §6.1), `compose.yaml` for the
+sections `reference/rows.md` cites for that row, `compose.yaml` for the
 service name, `custom/plugins/*` names for per-plugin rows.
 
 For a missing/drifted configuration row, do not research or plan the fix

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

@@ -11,16 +11,25 @@ Every installer-CLI call this skill makes passes `--json`. Without it the CLI
 prints a short human summary instead of the object these rows read — that
 summary is for the person typing the command, never for a skill parsing it.
 
-When that `status --json` call reports no install at all (no lock file, so no
-recorded agents), the installer CLI's `apply --yes`/`install` has no `--agent`
-to reuse and, run from this skill, no terminal to ask on — it would exit 2.
-Do not pass a guessed `--agent`. Report this to the user instead: the first
-install must be run by them directly in a terminal, e.g.
-`npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest install`,
-which then either takes their `--agent` or prompts them interactively. Re-run
-this skill's `status` check afterwards — every later `apply --yes --json`
-reuses the agents that first run recorded, and this skill can call it
-directly again. Expect `agents[]` in every output this skill reads.
+## Target agents
+
+Every row below is judged against the **anchored target agents** only, never
+against marker directories: a stray `.vscode/` makes Copilot a candidate, not a
+target. Read `targets` and `candidates` from the step-1 `status --json`.
+
+- `targets.source` is `settings`: use `targets.agents`. Ask nothing.
+- `none` and exactly one candidate: anchor it with
+  `npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest agents --agent <id> --json`
+  and say so in one line. This is the one write allowed before the question.
+- `none` and zero or several candidates: ask one multi-select question listing
+  the four agents (`claude-code`, `codex`, `copilot`, `cursor`), detected ones
+  marked, then anchor the answer the same way (one `--agent` per pick). Ask
+  with the structured question tool as in `SKILL.md` step 3.
+- A later change of mind goes through the same `agents --agent …` call.
+
+Re-run `status --json` after anchoring and read `agents[]` from that. An agent
+whose `state` is `not-targeted` is never printed or acted on. Print
+`- [x] Target agents — <ids> (anchored)` as the first configuration line.
 
 ## 1. vendor/
 
@@ -69,7 +78,7 @@ So this row never blocks readiness, and it never probes. It asks.
 
 - **Check:** read `agents[]` from the `status --json` output step 1 already
   ran. Each entry carries `id` and `skills_dir` — the directory that agent
-  actually reads skills from. For each agent whose `state` is not `absent`,
+  actually reads skills from. For each target agent (`targeted` is true),
   list `<skills_dir>/sw-specs-editor/` and
   `<skills_dir>/sw-tender-discovery-tool/`: a `SKILL.md` there means that
   editor is installed for that agent. That directory read is the whole check —
@@ -78,12 +87,12 @@ So this row never blocks readiness, and it never probes. It asks.
   state, not something to go looking for. Also read
   `sw-setup-editors.json` from the installer's own state directory if it
   exists — this skill's note of what the user has already declined
-  (`{"sw-specs-editor": "declined"}`). That directory is whatever `lock_file`
-  in the step-1 `status --json` output names, minus the file name — normally
+  (`{"sw-specs-editor": "declined"}`). That directory is the one
+  `settings_file` in `targets` names, minus the file name — normally
   `var/sw-ai-sdk/`, which a Shopware project already ignores. Read the path;
   never hard-code it.
 - **Ticked:** `[x]` when the editor's `SKILL.md` is present in every
-  non-`absent` agent's `skills_dir`; `[-]` when the note records a decline, or
+  target agent's `skills_dir`; `[-]` when the note records a decline, or
   when it is installed for some agents but not all (say which). `[ ]` only for
   an editor that is neither installed nor declined — and even then it does not
   hold the table open: report it as optional and move on.
@@ -97,7 +106,7 @@ So this row never blocks readiness, and it never probes. It asks.
     `--editor` and the `.xlsx` import on `sw-discover-tender`. Install?"
 
   On yes, for each accepted editor, run its own installer once per
-  non-`absent` agent, passing that agent's `skills_dir` from `status --json`:
+  target agent, passing that agent's `skills_dir` from `status --json`:
 
   ```
   npx -y @execuro-sw-ecosystem/sw-specs-editor@latest install-skill --target <skills_dir>
@@ -130,7 +139,7 @@ So this row never blocks readiness, and it never probes. It asks.
   <skills_dir>` and re-run the removal" — and carry on with the other agents
   and the other editor.
 - **On no:** write the decline to `sw-setup-editors.json` in the directory
-  `lock_file` names (create the file, and that directory, if absent; it is
+  `targets.settings_file` names (create the file, and that directory, if absent; it is
   never tracked) and do not
   offer that editor again on any later run. The user asking for it by name is
   the only thing that re-opens it — then delete its key and install. `--editor`
@@ -305,7 +314,8 @@ This row never blocks readiness. It folds into step 3's single question.
   npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest install
   ```
 
-  That command rewrites the installed `sw-setup` skill itself, so the newer
+  That command reuses the anchored target agents and rewrites the installed
+  `sw-setup` skill itself, so the newer
   skill takes effect on the next run — which step 3 already causes by re-running
   step 1. For the editors, see row 3: re-running their `install-skill` line is
   their update.

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>."