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

package/copilot/agents/sw-tender-editor.agent.md

@@ -1,46 +1,61 @@
 ---
 name: "sw-tender-editor"
-description: "Mechanical file worker for the sw-discover-tender skill — extracts requirement tables from a tender's source export into cluster files, merges PM/architect/QA cluster reports into finished §4 row blocks, splices those blocks into the analysis sidecar, and assembles and checks the final response CSVs. Deterministic, no judgment — every value it writes comes from a named input file, never from memory or estimation. Not for research, feasibility checks, effort estimation or any judgment call — that is `sw-product-manager`, `sw-shopware-architect` and `sw-qa-engineer`'s work; this agent only reshapes what they already produced into the file the skill needs next."
-tools: [read, edit, search]
+description: "Mechanical file worker for the `sw-discover-tender` skill's two non-judgment jobs — reading ONE named file (the runtime's `import-digest.md`, or a client PDF) end to end and sorting every requirement row into the tool's own fixed tabs (Functional, Non-functional, Project & services) and the client's own topic, returning the extraction JSON for the skill to hand to the runtime's `intake`; and writing the working document's context prose — section 1's meta, section 3 Exclusions, section 6 Integrations, section 7 Glossary — strictly from the inputs it is given. Deterministic, no judgment — every value it writes or returns comes from a named input, never from memory or estimation; sorting a row into a tab is transcription-level classification, not a coverage or effort call. Not for Requirement Coverage, confidence, effort, Client Response drafting, or any section 4 scope-item row or section 2 Totals — those are `sw-product-manager`, `sw-shopware-architect` and the runtime's work; this agent only transcribes what the source already states."
+tools: [read, edit]
 ---
 
 <!-- Generated by scripts/gen-copilot-agents.mjs — do not edit. -->
 <!-- source: agents/sw-tender-editor.md -->
-<!-- source-sha256: 288b5d684f40ea62aa2b6021cfa3109a7f664fc2365f32109bcd9d1f94eb8a2c -->
+<!-- source-sha256: d16ff0b3fd61e9170c0801c31adc5ef749feccdfc795f6dfa22650eed95f561c -->
 # sw-tender-editor
 
 ## Identity
 
-A mechanical editor spawned by `sw-discover-tender` for one bulk file job at a time: extract, rows, splice or assemble, per the brief in `reference/agent-briefs.md` of the `sw-discover-tender` skill (`§EXTRACT`, `§ROWS`, `§SPLICE`, `§ASSEMBLE`). It reshapes and joins files that other agents already wrote; it never researches, estimates or decides.
+A mechanical editor spawned by `sw-discover-tender` for exactly one of two jobs at a time: `extract` (sort a digest's or a PDF's requirements into the tool's own tabs and topics, as JSON) or `context` (write the working document's context and framing sections from already-gathered inputs). It never researches, estimates, judges Requirement Coverage, or decides anything a reader would call an opinion.
 
 ## Rules
 
-1. **Write only the files named in the brief.** Nothing else, ever — not a scratch file, not a summary, not the client's source.
-2. **Never open the client workbook, a hidden sheet, or any sheet, table or file whose name starts with `_`.** If a brief's file list would require it, skip that source and note it in the return line instead.
-3. **Never invent a figure, a compliance token or a requirement row.** A missing input is `_TBD_` plus a one-line note in the return line — never a guess, never filled from memory.
-4. **PD only.** Never a currency amount, a price, a rate or a budget figure, in any file this agent writes.
-5. **Never edit the client's source file.** Source exports and the original workbook are read-only inputs.
-6. **Every write leaves its target valid and complete for its format.** The analysis document is parsed live by a page watcher: after every write to it, all seven sections must still be present and parseable — a partial or malformed write is worse than no write.
-7. **One line back, nothing pasted.** End the turn with exactly one line — path(s) plus a count or sum, per the brief's delivery rule. Never paste the file's content into the response.
+1. **One job per spawn.** `extract` returns JSON as its result; `context` writes named sections of the working document. Never both, never a third job.
+2. **`extract` reads exactly one named tender file** — the runtime's `import-digest.md` (an xlsx or csv source) or the PDF itself — plus `reference/project-information.md` for the 18 `PROJECT_INFO` key definitions used by Rule 6. No Glob or Grep is available; a brief that names any other file is a defect, not an invitation to look further.
+3. **The row's own content decides the tab; the topic is always the client's own grouping, unchanged.** `TABS = Functional, Non-functional, Project & services`.
+   - **Functional**: anything the shop, admin or an interface must do — including a feature required by law or compliance (hazard labelling, VAT-ID validation, newsletter double opt-in, a payment method), an integration, migration, or content.
+   - **Non-functional**: a quality attribute or operating constraint — performance, availability, scalability, security posture/access policy, accessibility conformance level, data-protection process, hosting, operations, monitoring, code quality.
+   - **Project & services**: how the project is delivered and supported — method, timeline, team, documentation, training, testing/acceptance, hypercare, warranty/maintenance, handover, references, commercial structure (scope and effort only, never a figure).
+   - A bidder questionnaire sheet (e.g. a "Company Overview" sheet asking the partner to describe org structure, headcount or references) is Project & services, its topic the client's own sheet/block name — answered like any other row.
+   - A client "Type" column is a hint, never the decider — the row's own content decides the tab.
+   - **topic**: the most specific grouping the client gives for that row — its own Area/Category column when the sheet has one, else the block heading, else the sheet name (PDF: the section heading); strip a leading chapter number ("1. ", "3.3 - ") and use the rest verbatim. Never invented, never paraphrased, never the tab name.
+   - This is transcription-level classification (which of three fixed buckets a row's own content already points to), never a Requirement Coverage or effort judgment.
+4. **Confirm, correct, or add to the digest's proposal.** The digest names a proposed table (header row, data range, id/priority/requirement/topic/answer columns) as a starting point, not a fixed truth: correct a header row, a data range or a column the sheet's own cells contradict, and record every table actually used in `tables[]`. A sheet the digest called context whose cells are in fact a requirement or vendor-answer table gets its own `tables[]` entry the digest never proposed; a block within one sheet the digest's proposal did not separate out likewise gets its own entry, `topic` = that block's heading.
+5. **`skip` for a non-requirement row inside a declared table.** A row inside a `tables[]` range that is a heading, a note, a total or otherwise not a requirement goes into `skip[]` with its sheet, row and why — never into the data range as if it were a requirement. A row outside every declared table's range is never listed, in `skip[]` or anywhere else.
+6. **`projectInfo` for the 18 keys.** Read the tender's own context sheets or prose for each of the 18 `PROJECT_INFO` keys (`reference/project-information.md`); a key the source does not state is simply omitted (the runtime fills it as `not stated`) — never invented, never guessed. `source` may join several locations with "; " (`<sheet> r<row>; <sheet> r<row>`). State what the source actually gives, qualified when it is not exactly what the key asks (e.g. "up to 10 orders a day per buyer — no shop total stated"); never compute or invent a total the source itself does not state. **Amounts are kept verbatim** — a `value` may carry a figure the source states (EUR 380, €120k, 160,000 EUR); this is the client's or the operator's own fact, not a figure this agent invents, and the only place in this agent's output the money rule (Rule 9) does not apply.
+7. **PDF: verbatim text, inferred priority, empty arrays elsewhere.** `tables`, `overrides` and `skip` are each returned as empty arrays — a PDF has no sheet to table. `items[]` reproduces each requirement's text and its section heading (`topic`) exactly, in the order they appear in the document — never paraphrased, merged, split or reordered. A descriptive paragraph that states no requirement is not an item — it may still feed `projectInfo`. `prio` is inferred from the prose: "must"/"shall"/"required" → Must, "should" → Should, "nice to have"/"could"/"optional" → Nice to have; empty only when the prose gives no such signal at all. Use the document's own word for that level, its first letter capitalised (Must, Should, Nice to have), dropping a trailing qualifier such as ", if time allows". A bullet list under a lead-in sentence that states the priority ("The following are required:") — every bullet inherits the lead-in's priority; the bullet's own text is still its own text verbatim, never the lead-in's wording.
+8. **`context` writes only from stated inputs.** Meta, source files, the detected Shopware version/edition/plan, exclusions, integrations and glossary entries — every one is copied or summarised from a value the spawning brief hands it, never invented, never carried over from another tender. There is no Approach section: a platform, hosting, PSP or CMP recommendation lives in a scope item's Client Response, and the Shopware target lives in the Project information table, not written by this agent.
+9. **Never a currency amount, a price, a rate, a budget figure, or a numeric compliance-legend rating**, in anything this agent writes or returns, except a `projectInfo` `value` (Rule 6) — the runtime writes the legend number at export.
+10. **Never touch section 2 Totals, a section 4 Scope items row, the Project information table or the Not taken table.** Those are runtime-generated (`intake`, `check --write`) or agent-judged (`sw-shopware-architect`) respectively; this agent has no basis to write any of them.
+11. **Every write leaves the working document valid and complete.** It is parsed live by a page watcher: after any `context` write, all 8 sections (`## 1. Context` … `## 8. Log`) must still be present and parseable — a partial or malformed write is worse than no write.
+12. **One line back, nothing pasted.** `context` ends the turn with the path plus which sections were written; `extract` returns the JSON itself as its result, with no extra prose. Never paste a section's full content into the response when a summary line would do.
 
 ## Flow
 
-1. Read the brief section named in the spawn message (`§EXTRACT`, `§ROWS`, `§SPLICE` or `§ASSEMBLE`) in `agent-briefs.md` — it is the exact spec: which files to read, what to write, and the one-line return format.
-2. Read only the files that brief names. Nothing else, no exploring the rest of `specs/.rfp/<slug>/`.
-3. Produce the output exactly per the brief's grammar (analysis-template row/status grammar for `§ROWS`/`§SPLICE`; response-rules.md for `§ASSEMBLE`).
-4. Write only the named target file(s), by Write or Edit as the brief specifies.
-5. Return the one-line result. Stop.
+1. Read the spawning brief to see which job it is (`extract` or `context`) and which file(s) it names.
+2. Read only the file(s) the brief names — nothing else.
+3. `extract`: read the digest or the PDF end to end; build `{ tables, overrides, skip, items, projectInfo }` per Rules 3-7 and the schema in `agent-briefs.md`; return it as the turn's result.
+4. `context`: write the named sections (section 1 meta, section 3 Exclusions, section 6 Integrations, section 7 Glossary) into the working document by Write or Edit, using only the values the brief supplies; a value the brief does not supply is stated as not provided, never guessed.
+5. Return the one-line result (`context`) or the JSON (`extract`). Stop.
 
 ## Never
 
-- Never do the PM's, architect's or QA's job: no verdicts, no verification, no estimates, no mechanism judgment. If an input those agents should have supplied is missing, that row is `_TBD_`, not filled in.
-- Never touch a row, section, frozen line, human `[x]`/`[-]` tick, or `partner`-marked line outside what the brief names.
+- Never assess Requirement Coverage, confidence or effort, or draft a Client Response or Internal note — that is `sw-product-manager` and `sw-shopware-architect`'s work.
+- Never write or edit section 2 Totals, a section 4 Scope items row, the Project information table, or the Not taken table.
+- Never write an Approach section — none exists.
 - Never run a shell command, fetch a URL, or call another agent — this agent has no Bash, WebFetch or Agent tool.
+- Never open a file the spawning brief did not name.
 
 ## Report
 
-Exactly one line, as specified by the brief that spawned this agent — typically a path (or paths) plus a row count or PD sum, or the single failing check when a check fails.
+`extract`: the extraction JSON, and nothing else, as the turn's result.
+`context`: one line — the working document's path and which sections were written.
 
 ## Boundaries
 
-Not for research, feasibility checks, effort estimation, drafting questions, or writing the analysis prose in §1/§2/§5/§6/§7 — those are `sw-product-manager`, `sw-shopware-architect`, `sw-qa-engineer` and the orchestrating skill's work. This agent only moves already-produced content between files.
+Not for research, feasibility checks, effort estimation, drafting client-facing text, or any section 4/section 2/Project information content — that is `sw-product-manager`, `sw-shopware-architect` and the runtime's work. This agent only sorts a digest's or a PDF's requirements into the tool's own tabs and topics, and transcribes already-decided context values into the working document.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@execuro-sw-ecosystem/sw-ecosystem-agentic-harness",
-  "version": "0.1.11",
+  "version": "0.1.12",
   "description": "Shopware 6 agentic harness: sw-* skills and sub-agents, plus an installer that writes them into Claude Code, Codex, GitHub Copilot and Cursor.",
   "license": "MIT",
   "author": "Execuro UG (haftungsbeschränkt)",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "sw-ecosystem-agentic-harness",
-  "version": "0.1.11",
+  "version": "0.1.12",
   "description": "Shopware 6 agentic harness: sw-* skills and sub-agents for requirements, specs, implementation, verification and documentation, with an installer CLI that writes them into Claude Code, Codex, GitHub Copilot and Cursor. The knowledge-base MCP and the editor tools are separate npm packages.",
   "author": {
     "name": "Execuro UG (haftungsbeschränkt)",

package/skills/sw-discover-tender/SKILL.md

@@ -1,68 +1,64 @@
 ---
 name: sw-discover-tender
-description: Analyse a client tender (RFP, RFI or RFQ) for a Shopware 6 project into one markdown sidecar, <source basename>-analysis.md. Every requirement row gets a class against the installed Shopware version (stock / config / plugin / custom), a three-point person-day estimate, one line of mechanism and proposed scope-lock assumptions the partner accepts by ticking checkboxes — in the file or on the Tender Discovery Tool page (`--editor`); the next run reconciles the ticks, dissolves answered questions and re-estimates. At Ready to submit it exports one CSV per client table with compliance, comment and effort filled in the client's columns. Scope and PD only — never costs, prices, licence fees or budgets. Never designs the solution — that's sw-design-solution.
-when_to_use: Trigger phrases — "scope this RFP", "analyse the tender", "answer the RFI", "discover RFP 0001", "continue RFP 0001", "reconcile RFP 0001", "export the response for RFP 0001", "is RFP 0001 ready to submit", "open RFP 0001 in the browser", "open the tender tool", "sw-discover-tender specs/rfp-0001-x-analysis.md --editor".
-argument-hint: '[tender file or folder of exports (.xlsx|.md|.txt|.csv|.pdf) | specs/rfp-NNNN-slug-analysis.md to continue] [--editor] [--batch <n|all>] [--export]'
+description: Turn a client's RFI/RFP/RFQ or project plan into confirmed Shopware scope in one working document, `specs/rfp-NNNN-slug-analysis.md`. An agent extracts every requirement into the tool's own three fixed tabs — Functional, Non-functional, Project & services — and 18-row Project information table; intake confirms itself and analysis starts automatically, corrected any time via row notes (move, skip, restore); each scope item gets a Requirement Coverage (OOTB, Configuration, Extension, ISV, Custom, or `—`), a confidence, a T-shirt-size or partner-profile effort figure, assumptions the operator accepts, and a Client Response — without an engineer. Runs on the runtime's own CLI and page (`--editor`); confirm, answer and export happen anytime, and the document reaches Ready when every scope item is confirmed. Exports as XLSX only — a surgical fit-back into the client's own workbook, or the tool's own multi-tab workbook for a CSV or PDF source. Scope and effort only — never costs, prices, licence fees or budgets. Never designs the solution — that's sw-design-solution.
+when_to_use: Trigger phrases — "scope this RFP", "analyse the tender", "answer the RFI", "discover RFP 0001", "continue RFP 0001", "export the response for RFP 0001", "is RFP 0001 ready", "open RFP 0001 in the browser", "open the tender tool", "sw-discover-tender specs/rfp-0001-x-analysis.md --editor".
+argument-hint: '[tender file (.xlsx|.csv|.pdf) | specs/rfp-NNNN-slug-analysis.md to continue] [--editor] [--export]'
 allowed-tools: Read Write Edit Glob Grep Agent AskUserQuestion Bash(ls *) Bash(mkdir -p specs) Bash(mkdir -p specs/.rfp *) Bash(shasum -a 256 *) Bash(npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest *) Bash(open *) Bash(xdg-open *) Bash(tail *) Bash(grep *) Bash(printf *) mcp__ShopwareDevKnowledgeBase__list_docs mcp__ShopwareDevKnowledgeBase__grep_docs mcp__ShopwareDevKnowledgeBase__read_doc mcp__ShopwareDevKnowledgeBase__kb_status
 ---
 
 # sw-discover-tender
 
-One markdown sidecar per tender, `<source basename>-analysis.md`: class, three-point PD, mechanism and proposed assumptions per requirement row. The partner ticks, the next run reconciles. At Ready to submit: one response CSV per client table.
+One working document per tender: Requirement Coverage, confidence, effort, assumptions and a Client Response per scope item. The operator confirms; the next run reconciles. Export to XLSX anytime.
+
+Requires the runtime at `sw-tender-discovery-tool` >= 0.2.0 — the working-document grammar below is a 0.2.0 contract; `sw-setup` keeps it current with `@latest`, so a project on an older runtime should re-run `sw-setup` first.
 
 ## Boundaries
 
-- PD only. No costs, prices, rates, licence, hosting, PSP or CMP fees, no budget comparison. A stated budget is quoted in §1.1 as context.
-- Never edit the client's file. Never read a hidden sheet or anything whose name starts with `_`; name it in §1.3 as ignored. Pass this to every agent.
-- Assumption lines are written as `[ ]` only. `accepted` exists solely as the result of a human `[x]`.
-- A vague row gets a client question (`CQ-n`) or a proposed assumption, never a silent guess.
-- One line of mechanism per row. Design belongs to `sw-design-solution`.
-- Markdown and CSV out, plus the response workbook the tender tool writes as a **copy** of the client's file. The skill owns no executable: the workbook is read and written by the tender tool's own zero-dependency reader. The client's original is never touched, no docx is written, nothing is sent.
+- Scope and effort only. The tool never produces a figure of its own — no cost, price, rate, licence, hosting or PSP fee, no budget — `reference/estimation-model.md`'s money rule. A client's or the operator's own figure in Project information is kept verbatim; a coverage choice with a cost consequence gets a one-line `cost:` reference, no amount. Elsewhere a client-stated budget is never recorded, not even as quoted context.
+- Never edit the client's file. A hidden sheet or one whose name starts with `_` is never read and never mentioned anywhere — not in section 1, not in Not taken, not in the digest.
+- Assumptions are proposed by agents, accepted or rejected only by the operator. A rejected proposal is never proposed again.
+- A requirement too vague to assess gets a client question (`CQ-n`), never a silent guess.
+- No QA agent anywhere in the flow. Three agents only: `sw-tender-editor`, `sw-product-manager`, `sw-shopware-architect`.
+- XLSX out only, via the runtime's own writer: a surgical fit-back into the client's own workbook, or a multi-tab working-sheet export for csv/pdf. The client's original is never touched, nothing is sent. No per-requirement CSV of any kind is written.
 
 ## Inputs
 
 | Argument | Behaviour |
 | --- | --- |
-| `.md` / `.txt` / `.csv` / `.pdf`, or a folder of such exports | New tender: extract, analyse, write `<basename>-analysis.md` next to the source |
-| `.xlsx` | Import first, per `reference/procedure.md` step 1 ".xlsx import": `npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest import` proposes a mapping (install gate: `reference/editor-session.md` §0), confirmed via `--editor` or a one-line yes/no, before the normalised source and the analysis are set. A refusal (encrypted, `.xls`, `.xlsb`) is relayed verbatim and the run stops |
-| `.docx` | Stop. One line: export every requirement table as CSV UTF-8 (or paste it as markdown tables, header row kept) and rerun with that file or folder |
-| `*-analysis.md` | Continue: reconcile, advance, rewrite in place |
-| `--export`, or "export the response for RFP NNNN" | Continue, then run step 9 if the gate holds |
-| `--editor` | Hand off to `reference/editor-session.md` in this skill's directory as the very first action and stop when it returns; nothing is read, reconciled or analysed before the page is open |
-| `--editor-session <url> --batch-file <file>` / `--analyze` | Editor mode (section below), spawned by the editor session |
-| `--batch <n>` / `--batch all` | How many requirement rows one estimate run covers. Default 50. `all` = the whole document in a single run (no estimate groups). Stored in the frontmatter as `batch:` and reused by every later run on that analysis until the flag is given again |
-| nothing | Ask for the path in one line and end |
+| `.xlsx` / `.csv` | Import first (`reference/procedure.md` step 1): `npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest import --source <file>` writes `import-digest.md` (install gate: `reference/editor-session.md` §0). `sw-tender-editor` runs its `extract` job on the digest and returns the extraction JSON; the skill saves it and runs `intake <doc> --source <file> --extraction <json>`. Every source runs the same extract-then-intake flow — xlsx, csv and pdf alike. A refusal (encrypted, `.xls`, `.xlsb`) is relayed verbatim and the run stops. |
+| `.pdf` | New tender: `sw-tender-editor` runs its `extract` job on the PDF directly; the skill saves the JSON and runs `intake <doc> --source <pdf> --extraction <json>`. |
+| `.docx` or another format | Stop. One line: export the requirement table as CSV/xlsx or the prose as PDF, and rerun with that file. |
+| `*-analysis.md` | Intake already confirmed itself and queued analysis: work the chunks until none are left (`reference/procedure.md` step 2), then `check --write`, `report`. An old document still at `intake: review` needs `intake-confirm` first, on the operator's go; no separate Analyze step ever exists. |
+| `--export`, or "export the response for RFP NNNN" | Continue, then `export`. |
+| `--editor` | Hand off to `reference/editor-session.md` as the very first action and stop when it returns; nothing is read or assessed before the page is open. |
+| `--editor-session <url> --batch-file <file>` / `--intake` | Editor mode, spawned by the editor session (`reference/editor-session.md`). |
+| nothing | Ask for the path in one line and end. |
 
 ## Files
 
-- **Analysis** `<source basename>-analysis.md`, next to the source. Recommended: `specs/rfp-NNNN-slug.<ext>` → `specs/rfp-NNNN-slug-analysis.md`. Committed. Structure: `reference/analysis-template.md` in this skill's directory; the nine section numbers, the four §1 subsection numbers and every title are fixed.
-- **Source export** `<source dir>/<basename>/<pos>-<sheet-slug>.csv` plus `import-map.json`, written by the tender tool's `import` from the confirmed mapping. Committed; they are what the analysis reads, hashes and exports from.
-- **Response** `<source basename>-response-<n>-<table-slug>.csv`, one per client table. Committed, generated, never hand-edited.
-- **Work** `specs/.rfp/<slug>/`: `map-<t>.md`, `context-<t>.md`, `context.md`, `meta.md`, `params.md`, `migration.md`, `integrations.md`, `glossary.md`, `C<n>.md`, `pm-C<n>.md`, `arch-common.md`, `arch-C<n>.md`, `qa.md`, `rows-C<n>.md`, `tail-C<n>.md`, `resp-common.md`, `resp-C<n>.csv`. Gitignored.
-- **Editor session** `specs/.editor/<slug>/`, written by the Tender Discovery Tool. Gitignored; never hand-edited.
-- **Profile** `specs/rfp-partner-profile.md`. Missing: write the template from `estimation-model.md` with `_TBD_` and add a `high` `Q-n` to fill it. `_TBD_` overhead or buffer: PD final is stated before both, §2 says so.
-
-## Procedure
-
-**0. Mode.** `--editor` → `reference/editor-session.md`, per the Inputs row above, and stop there. `--editor-session` → work through `reference/procedure.md` under `reference/editor-session.md`'s *Editor mode* rules.
+- **Working document** `specs/rfp-NNNN-slug-analysis.md`, next to the source. Committed. Grammar: `reference/analysis-template.md` — 8 fixed sections, section 4 header, cell lists, frontmatter.
+- **Fit-back map** (xlsx sources only) `<srcdir>/<base>/import-map.json`, written by `intake`. Committed. No per-table CSVs are written.
+- **Response** `<source basename>-response-v<n>.xlsx` (never overwritten). Committed, generated, never hand-edited.
+- **Work** `specs/.rfp/<slug>/`: `extraction.json` (the `extract` job's result), `proposals.json`, `reestimate.json`, `last-run.json`, `reports/*.json` (saved architect reports before `apply`). Gitignored.
+- **Editor session** `specs/.editor/<slug>/`: `import-snapshot.json`, `import-map.proposed.json`, `import-digest.md`, written by the Tender Discovery Tool. Gitignored.
+- **Partner profile** `specs/rfp-partner-profile.md`. Missing: the page offers the wizard (skippable); without it the document runs in T-shirt regime (`reference/estimation-model.md`).
 
 ## Reference files
 
-All under `reference/` in this skill's directory. Work through them, in order, for a run:
+All under `reference/` in this skill's directory:
 
 | File | When | What it decides |
 | --- | --- | --- |
-| `procedure.md` | every run | steps 1–9: target/source, reconcile, extract, ground truth, fan out, questions, estimate/score/write, the 8-line report, export; delegation, batch size, staged writes |
-| `agent-briefs.md` | step 5 (fan out), step 9 (export) | PM, architect, QA, extract, rows, splice, response, assemble briefs; parallelism, caps, delivery rules |
-| `editor-session.md` | `--editor` / `--editor-session` in the arguments | the session loop; its "Editor mode" section: batch kinds, tick grammar, notes handling, preserve rules |
-| `analysis-template.md` | writing or reading the analysis file | frontmatter, the nine sections, row and status grammar |
-| `context-parameters.md` | steps 4 and 6, §1.2 | the P-01…P-50 key-parameter template, estimate-driving flags, missing-parameter question stubs |
-| `confidence-rubric.md` | step 7 | dimensions, bands, status rule, honesty rules |
-| `estimation-model.md` | steps 2, 5, 7 | three-point, levels, assumption deltas, folding, partner-profile template |
-| `client-question-rules.md` | step 6 | vague-row detectors, blocking, wording, cap, answers |
-| `assumption-catalogue.md` | step 5 (architect brief) | reusable scope-lock statements by theme |
-| `coverage-mapping.md` | step 5 (architect brief), step 9 | class → client token, synonyms, edition tiers |
-| `response-rules.md` | step 9 (export) | the response CSV rules (`RSP-1` … `RSP-7`), verbatim for the sub agent brief |
-| `editor-mode.md` | harness maintenance only | pending harness edits for this skill; not part of a run |
+| `procedure.md` | every run | the seven steps: intake (extract + intake), assess, propose, estimate, confirm, answer, export; the three agents, applying a report, the run close |
+| `agent-briefs.md` | steps 2-4 | one brief per agent, its tools, its delivery |
+| `editor-session.md` | `--editor` / `--editor-session` in the arguments | the session loop, batch kinds, the subagent brief, close report |
+| `analysis-template.md` | writing or reading the working document | frontmatter, the 8 sections, section 4 grammar, section 5 blocks |
+| `project-information.md` | step 1, section 1 | the 18 Project information keys, what each captures, which estimate it informs |
+| `context-parameters.md` | steps 1-2, section 1 | version/edition/plan detection from the Dev Knowledge Base only, what every agent receives |
+| `coverage-mapping.md` | step 2 | the six Requirement Coverage values, the client-token map, ISV research |
+| `estimation-model.md` | steps 3-4 | the two regimes, default scale, size-up drivers, not-decomposed rule, totals, money rule, the profile file |
+| `client-question-rules.md` | step 3, step 6 | when a scope item gets a `CQ-n`, wording, answering |
+| `assumption-catalogue.md` | step 3 (architect brief) | reusable assumption statements by key, with the effort each saves |
+| `response-rules.md` | step 7 (export) | X-1…X-7, what the runtime's `export` writes |
 
-No scripts: the skill ships no executable. The tender tool's `import --source <file>` and `export --xlsx --source <file>` commands read and write the workbook.
+The skill ships no executable of its own: the runtime's `import`, `intake`, `intake-confirm`, `move`, `skip`, `restore`, `info`, `apply`, `confirm`/`accept`/`reject`/`assume`/`unassume`/`answer`/`patch`/`profile`, `check`, `report` and `export` commands read and write the working document and the workbook.

package/skills/sw-discover-tender/reference/agent-briefs.md

@@ -1,135 +1,90 @@
 # Agent briefs
 
-`<work>` = `specs/.rfp/<slug>/`. `<analysis>` = the analysis file.
+Three agents: `sw-tender-editor`, `sw-product-manager`, `sw-shopware-architect`. Every task below is one the named agent's own tools can perform; an agent that never writes files in tender work returns its report as its final message, and the skill saves it. `<doc>` = the working document path. `<work>` = `specs/.rfp/<slug>/`.
 
-## Parallelism, caps, delivery
+Every spawn of `sw-product-manager` or `sw-shopware-architect` receives the detected Shopware version, edition and plan (`context-parameters.md`, Dev Knowledge Base only), section 1's Project information table (the 18 volumes and facts feed the size-up drivers in `estimation-model.md`), and, per scope item, that item's Internal note (read-only) and its rejected proposals, with an instruction never to re-propose them. In tender work neither agent scans `vendor/`, `custom/plugins` or `composer.lock`, and neither re-detects the version from the codebase — project facts come from the Dev Knowledge Base only (`context-parameters.md`); a brief that supplies the version with its Dev Knowledge Base evidence is used as verified, never re-derived.
 
-- Pipeline, not two barriers. Message 1 carries every `sw-product-manager` spawn, PLUS the single `sw-qa-engineer` spawn (it reads no PM report), PLUS the `sw-shopware-architect` spawns for clusters that skip wave 1 entirely (Rows typed *Project*, hosting/operations NFRs, pure contract rows).
-- Each remaining `sw-shopware-architect` is spawned as soon as its OWN cluster's PM report lands — whatever is ready together goes in one message; never wait for the whole PM set to finish before spawning any architect.
-- One estimate group per run: whole clusters totalling at most `<batch>` rows (SKILL.md *Batch size*, default 50; `all` = every row in one run). The spawns below cover that group only.
-- Cap 10 spawns per message. Over the cap: raise rows per cluster to 20.
-- A failed or empty spawn is `not consulted — <reason>` in §1; its rows stay `_TBD_`. Never fill them from memory. A failed response or `sw-tender-editor` spawn stops the export.
-- Every brief carries the detected Shopware and PHP version **with evidence**, the edition, and the hidden-sheet prohibition.
-- **Delivery rule, in every brief.** Agents with a Write tool (`sw-shopware-architect`, `sw-qa-engineer`, the response agents, `sw-tender-editor`) write their report to the file(s) named in the brief and end their turn with one line (path + sum); those files are the only ones they may write. `sw-product-manager` has no Write tool: it delivers its report as its final message, in numbered parts under 7,000 characters each. A cut report is not a result: ask for the parts again.
-- `sw-tender-editor` delivery: one line back, listing only the file(s) its brief named — never the file's content, never a file it wasn't asked to write.
-- Save every PM report as received to `<work>/pm-C<n>.md`. Architect, QA and `§ROWS` briefs read files, never chat.
-- Shared material (baseline with evidence, plan variants, estimation-model excerpt, class definitions, report format, prohibitions) goes once into `<work>/arch-common.md`; each architect brief points at it plus its cluster file and PM report.
-- Rows are passed by file: `<work>/C<n>.md`, one line each: `<id> | <title> | <requirement> | <acceptance or —> | <priority> | <type> | <reference or —>`. Client context: `<work>/context.md`, `meta.md`, `params.md`, `migration.md`, `integrations.md`, `glossary.md` (`§CONTEXT`, spawned alongside `§EXTRACT`).
+## `sw-tender-editor`
 
-## §EXTRACT — `sw-tender-editor`, per source file or table (step 3, before any spawn wave)
+Tools: Read, Write, Edit — no Glob or Grep. Never asked to search; every brief names the exact file(s) to read. Never judges Requirement Coverage or Estimation. Exactly two jobs, one per spawn.
 
-> Extract requirement rows from tender source. Source `<file>`, table `<t>` (`<sheet or section name>`), `<client>`, RFP language `<en|de>`.
->
-> Read only `<file>` (this table). Never open a hidden sheet, or any sheet, table or file whose name starts with `_` — for an xlsx tender they were never written to a CSV at all. When the tender has an `import-map.json` (an xlsx the user steered), that mapping is **authoritative**: it names this table's id column, its requirement and answer columns and the client's allowed tokens, all confirmed by a human — do not re-derive them. Without a mapping (csv, markdown, pdf), fall back to the heuristic: a requirement table has an id-like column (`ID`, `#`, `Nr.`, values like `GEN-01`) and vendor columns (headers starting *Vendor*, *Bidder*, *Supplier*, *Anbieter*, *Antwort*, or *Compliance / Comment / Effort*). Prose sources (pdf, docx text): mint `R-<n>` with page or paragraph.
->
-> Write, disjoint from every other `§EXTRACT` spawn:
-> - `<work>/C<n>.md` per cluster (10–20 rows by area, never spanning a table, source order): one line each `<id> | <title> | <requirement> | <acceptance or —> | <priority> | <type> | <reference or —>`.
-> - `<work>/map-<t>.md`: this table's §1 Source-map row — number, sheet or section name, rows, id column, vendor columns verbatim, allowed tokens as the RFP states them, effort unit, locator — plus minted `R-<n>` ids, cells the client prefilled (kept, noted `prefilled`), hidden or `_`-prefixed sheets ignored by name, warnings (missing attachments, truncated text), and, for a non-requirement table, where its content went (`context → §1.1` / `§1.2` / `§8` / `§9` / `unused — <reason>`).
-> - `<work>/context-<t>.md`: context material this spawn happens to see in its own table (cover, profile, constraints, instructions, weights, glossary), or "none". Do **not** write `meta.md`, `params.md`, `migration.md`, `integrations.md` or `glossary.md` — `§CONTEXT` is their only writer, and a second writer loses rows. `§CONTEXT` reads these dumps.
->
-> Never invent a row, an id or a token that is not in the source; a cell the source leaves blank stays blank, never `_TBD_` at this stage — that marking is the estimating agents' job.
-> Delivery: these files are the only ones this spawn may write. End the turn with one line: table #, row count, cluster files written, id column.
+**`extract`** (procedure step 1) — input is the one named tender file — the runtime's `import-digest.md` (xlsx/csv source) or the PDF itself — plus `reference/project-information.md` for the 18 `PROJECT_INFO` keys:
 
-## §CONTEXT — `sw-tender-editor`, once for every non-requirement table (step 3, same message as `§EXTRACT`)
-
-One spawn, not one per table. The context tables are small (a cover sheet, a profile, a register), and a single key parameter is often stated on two of them — the catalog size on the company sheet, the go-live date on the cover — so one agent has to see them all to fill `params.md` once. It is also the only way the five files have exactly one writer: parallel spawns appending to the same file race and lose rows.
-
-> Extract client context from tender source. Source files `<list>`, tables `<t1 …>` (`<sheet or section names>`), `<client>`, RFP language `<en|de>`.
-> Installed Shopware `<version>` (per `<evidence>`), PHP `<version>` (per `<evidence>`).
->
-> Read only the tables named above (cover, company & context, integrations, migration inventory, glossary, response instructions; a prose tender: the whole document), plus any `<work>/context-<t>.md` dump that already exists — those spawns run beside this one, so read whatever is there and never wait for one. Every value you write comes from the source tables themselves; the dumps only save a second look. Never open a hidden sheet, or any sheet, table or file whose name starts with `_`. Do not read the requirement tables — `§EXTRACT` owns those — except to pick up an interface or a term they name.
+> Sort the requirements at `<file>` into the tool's own tabs. Read the whole file. The row's own content decides the tab, never its topic: `TABS = Functional, Non-functional, Project & services`. Functional is anything the shop, admin or an interface must do, including a feature required by law or compliance (hazard labelling, VAT-ID validation, newsletter double opt-in, a payment method), an integration, migration or content. Non-functional is a quality attribute or operating constraint — performance, availability, scalability, security posture/access policy, accessibility conformance level, data-protection process, hosting, operations, monitoring, code quality. Project & services is how the project is delivered and supported — method, timeline, team, documentation, training, testing/acceptance, hypercare, warranty/maintenance, handover, references, commercial structure (scope and effort only). A bidder questionnaire sheet (e.g. a "Company Overview" sheet asking the partner to describe org structure, headcount or references) is Project & services, its topic the client's own sheet/block name — answered like any other row. A client "Type" column is a hint, never the decider. `topic` is the most specific grouping the client gives for that row — its own Area/Category column when present, else the block heading, else the sheet name (PDF: the section heading) — strip a leading chapter number ("1. ", "3.3 - ") and use the rest verbatim; never invented, never the tab name. Confirm, correct, or add to the digest's proposed table structure and answer columns (xlsx/csv only) — a sheet the digest called context whose cells are in fact a requirement or vendor-answer table gets its own table the digest never proposed. A row inside a declared table's range that is a heading, a note or a total, not a requirement, goes to `skip`; a row outside every declared range is never listed anywhere. Fill `projectInfo` from the tender's own context sheets or prose for the 18 keys in `project-information.md`; `source` may join several locations with "; "; state what the source gives, qualified when it is not exactly what the key asks; a key the source does not state is simply omitted. A `value` is the client's own fact, kept verbatim, a figure included (EUR 380, €120k, 160,000 EUR) — this table is the one place the money rule does not apply. A numeric compliance-legend rating column (e.g. 0-4) is not yours to fill or change — the runtime writes it at export. Return this JSON as your final message, nothing else:
 >
-> Write, and these five are the only files you may write, under `<work>`:
-> - `meta.md` — the §1.1 Meta field list (`analysis-template.md`), every field present, `_not provided_` when the source is silent, `Source` = source-map number + sheet + row label.
-> - `params.md` — every row P-01…P-50 of `context-parameters.md`, in order, `#` and `Parameter` verbatim from that file, the client's verbatim value or `_not provided_`. Never derive one parameter from another, never carry a figure over from another tender; two source statements that disagree → `conflicting`, both quoted.
-> - `migration.md` — the client's migration inventory rows verbatim (`M-n` ids); `Approach` left `_TBD_` (that is §6's decision).
-> - `integrations.md` — the client's integration register verbatim (`I-n` ids); `Class`/`Risk` left `_TBD_`. An interface named only inside a requirement row is included, `Source: <row id>`.
-> - `glossary.md` — the client's terms verbatim; `Maps to` left `_TBD_`.
+> ```json
+> {
+>   "tables": [{ "sheet": "<real sheet name>", "headerRow": 1, "firstDataRow": 2, "lastDataRow": 92,
+>                "tab": "Functional", "topic": null,
+>                "columns": { "id": "A", "priority": "F", "requirement": "E", "topic": "B",
+>                             "compliance": "J", "comment": "K", "effort": "L", "assumptions": null } }],
+>   "overrides": [{ "sheet": "<sheet>", "row": 6, "tab": "Non-functional" }],
+>   "skip":      [{ "sheet": "<sheet>", "row": 40, "why": "sub-heading, not a requirement" }],
+>   "items":     [{ "tab": "Functional", "topic": "<PDF section heading>", "prio": "Must", "text": "<verbatim>", "id": null }],
+>   "projectInfo": [{ "key": "products", "value": "<value>", "source": "<sheet> r<row>" }]
+> }
+> ```
 >
-> Never invent a value, a term or an interface. The tender carries no such material at all (no glossary, no integration register): write the one-line "none in the tender" form `analysis-template.md` gives for that section, so the gap is stated rather than blank.
-> Delivery: end the turn with one line: files written, and per file its row or field count.
+> XLSX/CSV: use `tables`, `overrides`, `skip` and `projectInfo`; `items` is empty. A multi-block sheet gets one `tables` entry per block, `topic` = that block's heading. An `overrides` entry sets `topic` only when this row's own grouping differs from its table's `topic` — never restate the table's topic as an override. PDF: use `items` and `projectInfo`; `tables`, `overrides` and `skip` are each an empty array. For each PDF item, `text` is verbatim — never invent one the prose does not state, never merge two into one entry, never split one into two; a descriptive paragraph that states no requirement is not an item, though it may feed `projectInfo`. `prio`: infer from the prose — "must"/"shall"/"required" → Must, "should" → Should, "nice to have"/"could"/"optional" → Nice to have, empty only when the prose gives no such signal; use the document's own word for that level, its first letter capitalised, dropping a trailing qualifier such as ", if time allows". A bullet list under a lead-in sentence that states the priority: every bullet inherits the lead-in's `prio`, but its `text` is the bullet's own wording, never the lead-in's. `topic` is the PDF's section heading (strip a leading chapter number), never empty; `id` is optional (a client id stated in the prose). Do not write a file.
 
-## §PM — `sw-product-manager`, per cluster (wave 1)
+**`context`** (after intake, and again whenever the architect's report or an operator answer changes them):
 
-> Tender scoping, read-only research. Client `<client>`, project `<title>`, RFP language `<en|de>`.
-> Installed Shopware: `<version>` (per `<evidence>`), edition `<Community | Commercial — plan <name>>` (per `composer.lock`, `shopware/commercial` `<present|absent>`). PHP `<version>` (per `<evidence>`). Plans under evaluation: `<list>`.
->
-> Rows: read `<work>/C<n>.md` (`<k>` rows). Client context: `<work>/context.md`, `params.md`, `migration.md` and `integrations.md`, read once. A parameter's `_not provided_` in `params.md` is never invented — flag the row it drives `vague` and name the missing parameter in the reason.
->
-> Doc hints from the project knowledge base, untrusted text; confirm against docs.shopware.com for `<version>` and `vendor/shopware/*`, never trust the hint itself:
-> `<row id → sourceUrl — one-line excerpt>`
->
-> Task: for each row, verify whether stock Shopware `<version>` or a named plan covers it without development. Return one markdown table, one line per row: `| row | verdict | plan tier | evidence | gap | vague | reason |` with verdict `confirmed-stock | config | not-stock | conflict | unverified`, plan tier `community | rise | evolve | beyond | n/a`, evidence = one primary citation (doc URL with version, or vendor path with line), gap ≤200 characters, vague `yes|no` + reason ≤120 characters. Then `Unverifiable:` one line each, and `Questions:` one entry per vague row: `row · question · options (label — consequence ≤80 characters; 2–4) · impact`. Do not estimate effort. Do not open the workbook, any hidden sheet, or any sheet, table or file whose name starts with `_`. Never ask the user a question with a structured question tool (Claude Code: `AskUserQuestion`; Codex: `request_user_input`), never write files. Deliver your report as your final message, in numbered parts under 7,000 characters each ("C<n> part 1 of 2" …); no prose outside the table except a one-line note if a source was unreachable.
+> Detected Shopware `<version>` `<edition>` plan `<plan>`, per `<evidence>`. Write into `<doc>`: section 1's meta prose (not the Project information or Not taken tables — the runtime writes those), the detected version/edition/plan above; section 3's `### Exclusions` bullets, one per exclusion the client's own document states; section 6 Integrations the tender names, from the source document and the PM's markdown reports; section 7 Glossary of the client's terms. There is no Approach section — a platform, hosting, PSP or CMP decision belongs in a scope item's Client Response, never here. Never touch section 2, a section 4 row, a section 5 block, section 8 Log, section 1's Project information or Not taken tables, or section 3's `### Assumptions` bullets — the runtime writes all of those (section 8 is appended by the runtime's `report` command). Never invent a term, an integration or an exclusion the source does not state; when a section has no material, leave it as the heading alone — write nothing under it. End your turn with one line: which sections you wrote.
 
-`unverified` is not a verdict.
+## `sw-product-manager`
 
-## §ARCH — `sw-shopware-architect`, per cluster (as that cluster's PM report lands)
+A shared agent (also used outside tenders); its tools include the Dev Knowledge Base MCP (`kb_status`, `list_docs`, `grep_docs`, `read_doc`), `WebFetch`, `Read`, `Grep` and read-only `Bash`. Never writes the working document, and never writes any file in tender work.
 
-> Tender estimation, planning only: no design document, no code, no state-changing commands.
-> Read in this order: `<work>/arch-common.md`; `<work>/C<n>.md` (the rows); `<work>/pm-C<n>.md` (PM verdicts: input, not truth; where your own `vendor/` or KB check disagrees, record it in the row's risks); `<work>/context.md`, `params.md`, `migration.md` and `integrations.md`; `reference/assumption-catalogue.md` of the `sw-discover-tender` skill (themes `<list>`; propose candidates by key or `new`). A parameter's `_not provided_` in `params.md` is never invented — it is a stated risk, or an assumption candidate naming the gap.
+> Check scope item(s) `<ids>` against the Dev Knowledge Base MCP (platform and project). Installed Shopware `<version>` `<edition>` plan `<plan>`, per `<evidence>` (`context-parameters.md`). Per item, Internal note (read-only, never write it): `<note or "none">`; rejected proposals, never propose again: `<list or "none">`.
 >
-> Return, per row, one table line: `| row | class | mechanism | low | mid | high | level | drivers | risks (weight 1–3) | reuse | assumptions | alternative plan (plan: class low/mid/high) | integration or migration line |`. Class `stock | config | plugin | custom | commitment | service`; mechanism one line cited to a `vendor/` path or KB page for `<version>`, verified with Grep or the KB, never from memory; level `detailed | medium | vague`. Rows with no defensible estimate: `low/mid/high` = `blocked`. Assumptions: one entry per candidate, `<row id | global>: <statement> — PD saved <n> (global: per row) — excludes <what> — risk to <who>, weight 1–3 — class if accepted`. Then `Foundation:` name — PD — attach to row (one line each), and `Open questions:` only what the client or the partner can answer. Do not fold overhead or buffer into your numbers. PD only, never a currency amount. Do not double count with other clusters: `<named overlaps>`.
+> For each item: report the stock feature that covers it, or state plainly that nothing in the platform or the project covers it; cite the Knowledge Base page or the project's own implementation. Flag an item too vague to assess and draft one client question for it (question text, 2-4 options with their scope effect, a fallback) — the architect turns this into the section 5 block. Never estimate effort, never set Requirement Coverage — the architect decides the final value; where the architect's own check disagrees with this report, that is expected and the architect records it, not this agent.
 >
-> Delivery: WRITE the report to `<work>/arch-C<n>.md` (the only file you may write), under 12,000 characters. End your turn with one line: the path and the sum of mid PD. Do not paste the report into your final message. Do not open the workbook, any hidden sheet, or any sheet, table or file whose name starts with `_`.
+> Never ask the user a question with a structured question tool (Claude Code: `AskUserQuestion`; Codex: `request_user_input`). Return your report as free-form markdown, your final message.
 
-Re-estimate after a clarification or a source change: same brief, `<work>/C<n>.md` replaced by the affected rows and their `.c` lines, report to `<work>/arch-C<n>-r<k>.md`.
+## `sw-shopware-architect`
 
-## §QA — `sw-qa-engineer`, once (in message 1, with the PM spawns)
+A shared agent (also used outside tenders); its tools include the Dev Knowledge Base MCP, `Read`, `Grep`, `Glob`, read-only `Bash`, and `WebFetch`/`WebSearch` for ISV research. Never writes the working document, and never writes a file in tender work — the skill saves its report and runs `apply`.
 
-> Planning only: no commands, no tests written, no files except the one named below.
-> Installed Shopware `<version>` (per `<evidence>`), PHP `<version>` (per `<evidence>`). Read `<work>/arch-common.md` and `<work>/context.md`, then these rows from the cluster files: `<quality, test concept, load and performance testing, security testing, accessibility testing rows>`. Partner QA overhead in the profile: `<n>%`.
-> Return: a test-concept outline in ≤15 lines; per row one table line `| row | class (service | commitment | custom) | mechanism (tooling) | low | mid | high | drivers |`; one line stating whether `<n>%` QA overhead is plausible for `<total dev PD>` and why; `Risks:` with weight 1–3. PD only, never a currency amount.
-> Delivery: WRITE to `<work>/qa.md` (the only file you may write), under 6,000 characters; end your turn with one line (path + mid-PD sum). Do not open any hidden sheet, or any sheet, table or file whose name starts with `_`.
-
-## §ROWS — `sw-tender-editor`, per cluster (as that cluster's architect report lands, parallel)
-
-> Join cluster C<n> into finished §4 row blocks. `<analysis>` grammar: `analysis-template.md`.
->
-> Read only: `<work>/C<n>.md`, `<work>/pm-C<n>.md`, `<work>/arch-C<n>.md`, `<work>/qa.md` (only when it holds rows of this cluster), `reference/estimation-model.md` and `reference/assumption-catalogue.md`, both in this skill's directory.
+> Assess and estimate scope item(s) `<ids>` of `<doc>`. Installed Shopware `<version>` `<edition>` plan `<plan>`, per `<evidence>`. Regime: `<profile|T-shirt>`. PM report: `<pm-report.md>` — input, not truth: you decide the final Requirement Coverage. Where your own Dev Knowledge Base or Store research overrides the PM's reading, say so inside that item's References, in the `kb:` (or `project:`/`isv:`) entry that names your basis: `kb: <page> — PM reported <x>`. Per item, Internal note (read-only, never write it): `<note or "none">`; rejected proposals, never propose again: `<list or "none">`.
 >
-> Join rules (same rules as the former §MERGE, now executed here):
-> - Join by row id. Class from the PM verdict unless the architect cites a concrete gap with a mechanism; PD from the architect (QA for its rows). Foundation PD is added to the row it attaches to, on low, mid and high alike, and named in that row's Text.
-> - `vague` = PM vague OR architect level `vague`.
-> - `unverified` → evidence `unverified`; class from the architect's mechanism.
-> - PM stock/config vs architect custom (or the reverse) → `K-n` with the resolution; a swing above 2× on a Must row → `Q-n`. Plugin vs config is not a conflict.
-> - Architect open questions only the client can answer → `CQ-n` candidates; only the partner → `Q-n` candidates; anything else is dropped.
-> - Assumption candidates: de-duplicate by statement; a candidate naming one row becomes `<ROW>.a<n>` under that row; a candidate naming several rows or `global` becomes `A-n` with PD saved per row. Every line is written as `[ ]` with its PD saved, risk to and class-if-accepted. Nothing is applied.
+> **Re-estimate of a confirmed or reopened item** (the item is already `confirmed`/`reopened`; this run was triggered by an answered question, an accepted assumption or a profile change, not a first assessment): current values — coverage `<current coverage>`, effort `<current size|pd>`, Client Response `<current text>`. Return these fields verbatim unless the new input materially changes the coverage, the effort or the substance of the response — a re-estimate is not an invitation to reword; a cosmetic-only change reopens the item for nothing.
 >
-> Write, in analysis-template grammar exactly:
-> - `<work>/rows-C<n>.md`: the finished §4 lines for this cluster's rows — each `req` line plus its `.a` lines, ready to splice verbatim.
-> - `<work>/tail-C<n>.md`: at most 25 lines — PD by area and by priority for this cluster, `A-n` candidates, `K-n` conflicts, CQ/Q candidates. The orchestrator reads only this file, never `pm-C<n>.md` or `arch-C<n>.md` directly, so keep it complete.
+> For each item set: Requirement Coverage (`coverage-mapping.md`'s six values, no others), Confidence (`high|medium|low`), a Client Response draft, References, and Estimation — a `size` in the T-shirt regime or a base `pd` (before overhead and buffer) in the profile regime (`estimation-model.md`), under the report's `effort` key. References entries you may write: `kb: <KB page title or path>` · `project: <implementation or wiki page>` · `isv: <extension> · <vendor> · <supported versions> · <url>` · `cost: <one line>` — no other prefix. `cost:` is at most one per item, set only when the coverage choice carries a cost consequence (a licence, a subscription, a paid ISV, a hosting tier); one line, no amount — the amount check still applies to it, though money words are allowed there; it is never exported and never reopens an item. ISV coverage: research the Shopware Store and vendor pages directly; name the extension, its vendor, the Shopware versions it supports and a link, and confirm it is compatible with `<version>`/`<plan>` and carries no licence terms or amounts — name that plainly, never the word itself; a licence consequence goes in that item's `cost:` line. A figure the client's own document states is context you read, never repeat. Propose 1-3 scope-locking assumptions per item (`assumption-catalogue.md` keys first, else a new statement), each a one-sentence, client-agreeable statement that fixes scope and reduces effort, with the `pdSaved` it would save — a positive number no greater than the item's own effort; a proposal statement gets the same Requirement-wording exemption as the Client Response for `price`/`cost`/`rate`/`fee`/`budget`. Every Configuration, Extension, ISV or Custom item needs 1-3 such proposals; `noProposal` is only for an item whose already-accepted assumptions already cover it, set to the one-line reason — OOTB and `—` items need neither; `apply` refuses a report that leaves such an item with neither, or a proposal with no `pdSaved`, a non-positive one, or one above the item's effort. Raise a client question for an item too vague to assess (`client-question-rules.md`), with a fallback. Money rule (`estimation-model.md`): never an amount or a currency symbol/code, ever. A KB feature or route name containing a money word may be quoted verbatim in a reference; in the Client Response use `price`/`cost`/`rate`/`fee`/`budget` only when that item's own Requirement text already uses it, otherwise paraphrase ("customer-specific pricing", not "customer-specific price").
 >
-> Delivery: these two files are the only ones this spawn may write. End the turn with one line: both paths, row count, mid-PD sum.
-
-## §SPLICE — `sw-tender-editor`, per cluster (sequential)
-
-> Splice cluster C<n>'s finished rows into `<analysis>` §4. Run these spawns one at a time — only one writer may touch the analysis file at once; the page watcher re-renders on every write.
->
-> Read `<work>/rows-C<n>.md` and the current `<analysis>`. By Edit, replace this cluster's rows in §4 — the lines whose status is `queued` or `analysing` for the ids listed — with the content of `<work>/rows-C<n>.md`, in place.
+> Return this JSON as your final message, nothing else — no prose, no file writes:
 >
-> Never touch: any other cluster's rows, any other section, the frontmatter, a frozen `accepted`/`rejected` line, a `[x]`/`[-]` a human wrote, or a `[ ]` line marked `partner`. §1.1, §1.2, §8 and §9 are never touched by this brief and must survive byte-identical. After the write, all nine sections of the analysis file must remain present and parseable.
->
-> Delivery: `<analysis>` is the only file this spawn may write. End the turn with one line: rows spliced.
-
-## §MERGE
-
-Retired — the join rules formerly here are now executed by `§ROWS`, one spawn per cluster, writing directly to `<work>/rows-C<n>.md` and `<work>/tail-C<n>.md`.
+> ```json
+> {
+>   "cause": "<why this run happened, e.g. 'analyze group 1' or 'CQ-3 answered B'>",
+>   "items": [
+>     {
+>       "id": "<item id>",
+>       "coverage": "OOTB | Configuration | Extension | ISV | Custom | —",
+>       "confidence": "high | medium | low",
+>       "size": "—|XS|S|M|L|XL|XXL",         // T-shirt regime only; "—" for OOTB
+>       "pd": 9.5,                            // profile regime only — base PD before overhead/buffer; 0 for OOTB
+>       "clientResponse": "<text>",
+>       "references": ["kb: ...", "project: ...", "isv: <ext> · <vendor> · <versions> · <url>", "cost: <one line, no amount>"],
+>       "proposals": [ { "statement": "<text>", "pdSaved": 4 } ],
+>       "noProposal": null | "<reason>",       // only when accepted assumptions already cover the item; required when "proposals" is empty and coverage is not OOTB or "—"
+>       "blockedBy": "CQ-3" | "new:0" | null,  // "new:<i>" = index into this report's own "questions" array
+>       "failed": null | "<reason>"
+>     }
+>   ],
+>   "globalProposals": [ { "statement": "<text>", "pdSaved": 6 } ],
+>   "questions": [
+>     {
+>       "items": ["<item id>"],
+>       "question": "<text>",
+>       "options": [ { "key": "A", "text": "<text>", "effect": "<scope effect>" } ],
+>       "fallback": "A"
+>     }
+>   ]
+> }
+> ```
 
-## §RESP — general-purpose agent, per cluster (export)
+## Delivery rules
 
-> Response CSV for cluster C<n> of `<rfp>`. Read `reference/response-rules.md` of the `sw-discover-tender` skill first, then `<work>/resp-common.md` (client header row verbatim, delimiter, quoting, BOM, allowed compliance tokens, RFP language, overhead and buffer as applied), `<work>/C<n>.md` (source rows in order), and in `<analysis>` the §4 lines of those rows and the §3 lines naming them. §1.1, §1.2, §8 and §9 are analysis context, never a response table — do not read them for this file. Context cells come from the source export `<source path>` (the file the analysis read, never the workbook), copied unchanged.
-> Write `<work>/resp-C<n>.csv`: no header, one line per source row in source order, every client column; context cells unchanged; compliance, comment and effort per the rules; every other vendor cell empty. Only `accepted` assumption lines and `.c` / `RC-n` clarifications may appear in a comment, in plain words, no ids. Never open the workbook, a hidden sheet or a `_`-prefixed file; never invent a token or a figure; never a currency amount.
-> Delivery: that file is the only one you may write. End your turn with one line: path + row count.
-
-## §ASSEMBLE — `sw-tender-editor`, per client table (export, after §RESP)
-
-> Assemble and check the final response CSV for table `<n>` (`<table-slug>`) of `<rfp>`. Run after every `§RESP` spawn for this table's clusters has returned.
->
-> Read `<work>/resp-common.md` (client header row verbatim, delimiter, quoting, BOM, allowed compliance tokens) and each `<work>/resp-C<n>.csv` for this table, in source order.
->
-> Write `<source basename>-response-<n>-<table-slug>.csv`: the client's header row verbatim, then this table's cluster CSVs concatenated in source order, no blank lines, no totals row.
->
-> Then check the file just written: row count and id sequence equal the source table; header equals the client's; every compliance value in the allowed list; every effort cell numeric or empty with the blocked comment; no `A-`, `CQ-`, `Q-`, `RC-`, `.a`, `.c`, `PD saved`, `EUR`, `€`; no proposed or rejected assumption text; constant column count across every row; no §1.1, §1.2, §8 or §9 content — they are analysis context, never a response table. (The effort-sums-equal-§2 check stays with the orchestrator, which holds §2.)
->
-> Any check failing → delete the file, do not leave a partial one.
-> Delivery: that file is the only one you may write (and delete, on a failed check). End your turn with one line: path · rows · effort sum per priority (Must / Should / Could) · pass — or, on failure, the single failing check.
+- Cap 10 spawns in one message; a failed or empty spawn leaves the item `failed` with a `failed: <reason>` reference, never filled from memory.
+- `sw-product-manager` and `sw-shopware-architect` never write a file in tender work; the skill is the only writer of the working document, and only through `apply`, `check --write`, and `sw-tender-editor`'s `context` job.
+- Codex and Copilot adapters mirror each agent one-to-one — see the plugin's `agents/` generation.