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

package/skills/sw-discover-tender/reference/assumption-catalogue.md

@@ -1,104 +1,69 @@
-# Scope-lock assumption catalogue
-
-Starting points, not answers. The architect proposes candidates by key (or `new`), each naming its row id or `global`; the statement is rewritten for the tender at hand and lands as a `[ ]` line: `<ROW>.a<n>` under its row, or `A-n` in §3 when no single row owns it. A statement that the RFP already makes is an exclusion `X-n` in §3 (0 PD), not an assumption.
-
-**PD saved** is the typical reduction against the unassumed mid estimate for a mid-size B2B replatforming; the architect states the real figure per RFP. **Risk shifted to** names who carries the consequence if the assumption fails. **Not when** lists the RFP conditions under which the key must not be proposed.
-
-## PLAT — platform and edition
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-PLAT-01 | Target is the current Shopware 6.x minor at kickoff; no core modifications; all customisation in plugins, apps and the theme. | 0 (creep guard) | none | RFP pins an older version |
-| K-PLAT-02 | "Headless-ready" means Store API discipline in all custom code; no SPA or composable frontend is delivered (`<rows>`). | 20–40 | client | RFP names a headless frontend deliverable |
-| K-PLAT-03 | One sales channel per country/language pair the RFP lists, one currency; further channels, languages or currencies are change requests. | 3–8 | client | — |
-| K-PLAT-04 | Commercial plan features are used as shipped; changes to their UI or flows are out of scope (`<rows>`). | 10–30 | client | an acceptance criterion contradicts stock behaviour |
-| K-PLAT-05 | Minor updates within the project; the first major upgrade belongs to maintenance. | 0 (creep guard) | none | — |
-
-## ERP — integration
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-ERP-01 | The ERP partner implements the ERP-side endpoints from an interface specification the bidder writes; the bidder builds the shop side only (`<rows>`). | 10–20 | ERP partner | bidder is asked to deliver both sides |
-| K-ERP-02 | One synchronisation pattern for all objects: queue consumers, idempotent upserts keyed by external id; no middleware or iPaaS. | 5–15 | none | RFP requires an iPaaS |
-| K-ERP-03 | Sync failures: automatic retry, admin notification, admin list with manual retry; no reconciliation or diff UI. | 5–10 | client ops | — |
-| K-ERP-04 | Customer-specific and tier prices are imported asynchronously (full, delta, webhook as the RFP states); no live ERP price call per page view. | 8–15 | client (staleness inside the sync window) | RFP demands per-request live prices |
-| K-ERP-05 | Real-time checks (credit limit, branch stock) use exactly the timeout and fallback the RFP states; no additional fallback logic. | 0–3 | none | — |
-| K-ERP-06 | Field mapping is fixed in one mapping workshop; fields absent from the ERP partner's API list on that date are change requests. | 3–5 | client | — |
-
-## DSGN — design and theme
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-DSGN-01 | The client's agency delivers final, approved designs per page type before the sprint that builds it; one revision round included; later changes are change requests. | 10–15 | client | bidder owns design |
-| K-DSGN-02 | The theme extends the default Storefront theme; stock components are restyled, not rebuilt; breakpoints as the RFP lists, no pixel-perfect commitment beyond them. | 5–10 | client | — |
-| K-DSGN-03 | Printable product sheet = browser print stylesheet; no server-side PDF generation (`<rows>`). | 3–6 | client | RFP requires a downloadable PDF with branding |
-| K-DSGN-04 | The design feasibility review covers implementability in Shopware, not UX advice; at most `<n>` page templates. | 2–4 | client | — |
-
-## MIG — content and data migration
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-MIG-01 | Content, blog and landing pages are rebuilt by client marketing in Shopping Experiences after training; the bidder delivers `<n>` layouts and migrates `<m>` pages as examples (`<rows>`). | 8–15 | client | RFP demands 1:1 migration with acceptance |
-| K-MIG-02 | The SEO redirect map is generated from the URL export the client provides; the bidder imports it and tests the list the RFP names. | 3–5 | client | — |
-| K-MIG-03 | Historical orders are migrated read-only for display; no reorder from migrated lines, no document regeneration. | 5–10 | client | an acceptance criterion requires reorder from migrated orders |
-| K-MIG-04 | Product documents stay in the ERP or document storage and are linked, not migrated as media (`<rows>`). | 5–10 | ERP partner | — |
-| K-MIG-05 | Passwords are re-hashed on first login through a legacy encoder; no forced reset campaign; accounts inactive for more than `<n>` years are not migrated. | 1–3 | client | — |
-| K-MIG-06 | Objects the RFP marks "not migrated" (reviews, vouchers, newsletter recipients) are exclusions. | 0 | none | — |
-| K-MIG-07 | One migration rehearsal on staging and one production cutover; further rehearsals are change requests. | 3–8 | shared | RFP prescribes more rehearsals |
-
-## B2B — accounts, approval, quotes
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-B2B-01 | Employee roles, order approval and budgets use B2B Components as shipped; one threshold type per company (`<rows>`). | 15–30 | client | Community plan chosen |
-| K-B2B-02 | Quotes use stock quote management; one counter-offer cycle, no negotiation thread. | 5–10 | client | Community plan chosen |
-| K-B2B-03 | Quick order = manual multi-row entry plus paste/CSV `sku;qty`; XLSX upload only if stock supports it. | 3–6 | client | RFP acceptance names XLSX |
-| K-B2B-04 | One company hierarchy level (company → employees); cost centres are a list attribute, not organisational units. | 5–15 | client | RFP names multi-level units |
-| K-B2B-05 | Order on behalf uses the stock imitate-customer capability; audit = order flag plus admin log, no separate report. | 2–5 | client | — |
-| K-B2B-06 | Registration approval happens in the shop admin; the ERP writes back the customer number; approval never happens in the ERP. | 3–6 | client process | RFP requires approval in the ERP |
-
-## SRCH — search
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-SRCH-01 | Search = stock OpenSearch/Elasticsearch integration with field boosting on the identifiers the RFP names; no machine-learned ranking, no personalisation (`<rows>`). | 10–20 | client | — |
-| K-SRCH-02 | Synonyms and stop words are maintained by the client in the admin; the bidder migrates the existing list once. | 2–4 | client | — |
-| K-SRCH-03 | "As good as `<competitor>`" is replaced by measurable acceptance: exact-match identifier search opens the product, prefix suggestions, typo tolerance of one edit. | makes the row estimable | client | client rejects the acceptance in `CQ-n` |
-
-## OPS — hosting, operations, security
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-OPS-01 | Managed Shopware hosting from `<profile.hosting>`; availability, backup and restore per the provider's SLA; the bidder is not liable for infrastructure SLAs (`<rows>`). | 5–10 | provider | RFP requires bidder-operated infrastructure |
-| K-OPS-02 | The penetration test is commissioned and paid by the client; findings are fixed within the warranty as the RFP states; one retest cycle. | 0 | client | — |
-| K-OPS-03 | CI/CD on the client's repository with the bidder's standard pipeline (lint, static analysis, tests, build, deploy); further gates are change requests. | 3–5 | none | — |
-| K-OPS-04 | Monitoring and alerting = provider stack plus Shopware admin notifications; no custom dashboards. | 3–6 | client ops | — |
-| K-OPS-05 | One load test before go-live against the RFP's stated profile; tuning limited to configuration (cache, workers, indexes). | 2–5 | shared | — |
-
-## CMPL — compliance and accessibility
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-CMPL-01 | Accessibility conformance covers templates and components the bidder builds; client-authored content, third-party widgets and manufacturer PDFs are excluded (`<rows>`). | 5–10 | client | — |
-| K-CMPL-02 | Consent management = `<profile.cmp>` stock plugin; no custom consent UI; tag configuration by client marketing. | 2–4 | client | — |
-| K-CMPL-03 | Invoices, credit notes and e-invoices are produced by the ERP; the shop displays and links them and never generates fiscal documents (`<rows>`). | 8–15 | ERP partner | RFP wants shop-generated invoices |
-| K-CMPL-04 | Legal texts are supplied by the client in every language; the bidder places them. | 1–2 | client | — |
-| K-CMPL-05 | Data-subject requests use stock export and anonymisation; no custom workflow UI. | 2–4 | client | — |
-
-## PAY / SHP — payment and shipping
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-PAY-01 | Payment on account = stock payment method with rule-based availability from synced ERP flags; payment terms shown from a synced text field. | 2–4 | none | — |
-| K-PAY-02 | Cards and wallets via the official plugin of `<profile.psp>` with a hosted payment page; no custom PSP integration. | 3–8 | PSP | RFP names a PSP without an official plugin |
-| K-SHP-01 | Shipping methods and prices via stock methods and rules from the client's shipping table; no carrier API, no label printing in the shop. | 5–10 | none | RFP requires labels from the shop |
-| K-SHP-02 | Branch pickup = shipping method plus an availability text from a synced branch-stock field; no reservation or transfer logic in the shop. | 3–6 | client | — |
-
-## PROJ — project
-
-| Key | Statement | PD saved | Risk → | Not when |
-| --- | --- | --- | --- | --- |
-| K-PROJ-01 | The client names one product owner with decision authority and a two-working-day answer SLA; decisions past the SLA are scheduled at the bidder's discretion. | 0 (schedule) | client | — |
-| K-PROJ-02 | Acceptance per sprint against the RFP's acceptance criteria; anything outside an RFP row or an accepted assumption is a change request outside the fixed-price scope. | 0 (creep guard) | none | — |
-| K-PROJ-03 | Training, documentation and handover as the RFP lists, delivered once and recorded; repeats are billable. | 0 | client | — |
-| K-PROJ-04 | The environments the RFP names; additional environments via the provider at the client's expense. | 1–2 | client | — |
+# Assumption catalogue
+
+Starting points, not answers. Every Configuration, Extension, ISV or Custom item gets 1-3 proposals in the architect's report, catalogue keys first, each rewritten for the tender at hand as one client-agreeable, scope-locking sentence, in its report JSON's `proposals` (per item) or `globalProposals` (section 3) array — schema in `agent-briefs.md` — each with the `pdSaved` it would save against the item's un-assumed estimate, greater than 0 and no greater than the item's own effort. `noProposal` is for an item only when its already-accepted assumptions already cover it. The runtime's proposal store (`specs/.rfp/<slug>/proposals.json`) is the only place a proposal lives until the operator accepts it (AQ-2); a rejected proposal is never proposed again for the same item (AQ-4), matched by its normalised statement.
+
+Keys below use the `AS-` prefix so they never collide with a scope item id, a `CQ-n`/`Q-n`, a proposal `P-n` or a log entry — none of those families ever starts with `AS-`. `pdSaved` is a typical figure for a mid-size B2B project; the architect states the real figure for the tender at hand. A statement the client's own document already makes is a section 3 Exclusion, not an assumption.
+
+## AS-PLAT — platform and edition
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-PLAT-01 | Target is the current Shopware 6.x minor at kickoff; no core modifications; all customisation in plugins, apps and the theme. | 0 (creep guard) | the client pins an older version |
+| AS-PLAT-02 | One sales channel per country/language pair the client lists, one currency; further channels, languages or currencies are separately scoped. | 5 | — |
+| AS-PLAT-03 | Commercial-plan features are used as shipped; changes to their UI or flows are separately scoped. | 15 | an acceptance criterion contradicts stock behaviour |
+
+## AS-ERP — integration
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-ERP-01 | The counterpart implements the far-side endpoints from an interface specification we write; we build the shop side only. | 15 | the item asks for both sides |
+| AS-ERP-02 | One synchronisation pattern for all objects: queue consumers, idempotent upserts keyed by external id; no middleware or iPaaS. | 8 | the client requires an iPaaS |
+| AS-ERP-03 | Customer-specific and tier pricing is imported asynchronously (full, delta or webhook as stated); no live call per page view. | 10 | the client demands a per-request live lookup |
+
+## AS-DSGN — design and theme
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-DSGN-01 | The client's own designs are delivered per page type before the sprint that builds it; one revision round included. | 10 | we own design |
+| AS-DSGN-02 | The theme extends the default Storefront theme; stock components are restyled, not rebuilt. | 6 | — |
+
+## AS-MIG — content and data migration
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-MIG-01 | Content, blog and landing pages are rebuilt by the client's own team after training; we deliver example layouts only. | 10 | the client requires a full 1:1 migration |
+| AS-MIG-02 | Historical orders are migrated read-only for display; no reorder from migrated lines. | 6 | reorder from migrated orders is a stated requirement |
+
+## AS-B2B — accounts, approval, quotes
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-B2B-01 | Employee roles and order-approval thresholds use B2B Components as shipped; one threshold type per company. | 20 | the plan has no B2B Components |
+| AS-B2B-02 | Quotes use stock quote management; one counter-offer cycle, no negotiation thread. | 6 | the plan has no B2B Components |
+
+## AS-SRCH — search
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-SRCH-01 | Search is the stock OpenSearch/Elasticsearch integration with field boosting on the identifiers named; no machine-learned ranking, no personalisation. | 12 | — |
+
+## AS-OPS — hosting, operations, security
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-OPS-01 | Managed Shopware hosting per the profile's preferred provider; availability, backup and restore per the provider's SLA. | 6 | the client requires self-operated infrastructure |
+| AS-OPS-02 | Monitoring and alerting use the provider's stack plus Shopware admin notifications; no custom dashboards. | 4 | — |
+
+## AS-CMPL — compliance and accessibility
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-CMPL-01 | Accessibility conformance covers templates and components we build; client-authored content and third-party widgets are excluded. | 6 | — |
+| AS-CMPL-02 | Invoices, credit notes and e-invoices are produced by the counterpart system; the shop displays and links them. | 10 | the requirement is shop-generated fiscal documents |
+
+## AS-PAY — payment and shipping
+
+| Key | Statement | pdSaved | Not when |
+| --- | --- | --- | --- |
+| AS-PAY-01 | Cards and wallets via the official ISV plugin of the profile's preferred provider, hosted payment page; no custom PSP integration. | 5 | the client names a provider with no official plugin |
+| AS-PAY-02 | Shipping methods and their pricing via stock methods and rules; no carrier API, no label printing in the shop. | 6 | labels from the shop are a stated requirement |

package/skills/sw-discover-tender/reference/client-question-rules.md

@@ -1,47 +1,28 @@
 # Client question rules
 
-A client question (`CQ-n`) is the written question the partner submits in the tender's Q&A round. It is the only correct answer to a vague row; a silent assumption on a vague row is a defect.
+A client question (`CQ-n`) is the written question the operator takes to the client's Q&A round; the tool writes no question document (AQ-7). It is the correct answer to a requirement too vague to assess — a silent guess is a defect.
 
-## Ask, do not assume, when
+## AQ-5 — when a requirement gets a CQ
 
-1. **Comparative or totality phrasing** — "as good as", "comparable to", "modern", "fast", "everything that works today", "all".
-2. **Undefined reference** — "to be defined", "some", "such as", "etc.", a system named without objects or direction.
-3. **External counterpart without interface or owner** — an integration whose API, format or responsible party is not named.
-4. **Wide estimate** — no acceptance criteria and the architect's high is more than 2× its low.
-5. **Stock contradiction** — the PM reports `conflict` between the row and verified stock behaviour, or between tier documentation and the RFP's plan assumption.
-6. **RFP-internal contradiction** — a row conflicts with the constraints sheet, another row, or a stated out-of-scope item.
-7. **Rejected assumption routed to the client** — an assume line was `[-]` rejected and the partner wants the client to decide (its `C-n` says so).
-8. **Missing or conflicting key parameter** — a §1.2 Key parameters row marked **drv** in `context-parameters.md` reads `_not provided_`, or any row reads `conflicting`. Use that file's question stubs; ask for a figure or a bracket, never for a design. One question may cover a whole group.
-
-## Never ask
-
-- What the RFP already answers, even if buried in another sheet.
-- What the partner can decide (plan preference, own assets, overhead and buffer policy) — that is a `Q-n`.
-- Wording, formatting, or which column to use.
-- Anything technical the client cannot judge ("subscriber or decorator").
-
-Test: *if answered both ways, would a class, a PD figure or a statement on that row differ?* No → no question.
+A requirement too vague to assess gets a `CQ-n` in section 5: options, the scope effect of each, and a fallback. The scope item's Status becomes `blocked CQ-n` and it is estimated on the fallback option (E-4). Vague means: comparative or totality phrasing ("as good as", "everything that works today", "all"); an undefined reference ("to be defined", "some", "etc."); an external counterpart named without an interface or an owner; or a Shopware-stock contradiction the Dev Knowledge Base cannot resolve.
 
 ## Wording
 
-- RFP language. One decision per question. Row ids in the block heading.
-- 2–4 options where the answer space is known, each with its effect on scope in plain words, plus `Other:`. No PD figures to the client unless the partner asks for them.
-- Neutral: never lead with the partner's preferred option, never argue.
-- State the assumption the estimate uses: *"Until answered we assume …"* — and write that same assumption under the row as a suggested `[ ]` line, so the partner can accept it without the client.
-- Quote the RFP's own sentence when the contradiction is internal; quote the PM's evidence (doc URL + version) when it is a stock contradiction, never a claim from memory.
+- Client's own language. One decision per question. Item ids in the block heading (`analysis-template.md` section 5 grammar).
+- At least two options (`A`, `B`, ...), each with its scope effect in plain words after `— effect:`.
+- Neutral: never lead with a preferred option, never argue for one.
+- Name a `Fallback:` key — the option the estimate assumes until the client answers.
+- Quote the client's own sentence when the ambiguity is internal to their document; cite the Knowledge Base page when it is a stock contradiction, never a claim from memory.
 
-## Blocking
+## AQ-6 — answering
 
-A question is **blocking** when no defensible estimate exists even with a written assumption: unbounded parity rows, integrations with undefined objects, a plan-tier conflict on a Must row. Blocking → row status `blocked, CQ-n`, PD empty, heading `blocking: yes`. Everything else → the row keeps its PD, status `estimated, CQ-n`, with the assumption it rests on written under it as a `[ ]` line.
+The operator records the client's chosen option on the page or with `answer <doc> <CQ-n> <key>`. The runtime marks every scope item the question names for re-estimate; a confirmed item among them reopens only when the next `apply` actually changes its Requirement Coverage, Estimation or Client Response (L-3), with the cause in References.
 
-A blocking `CQ-n` on a Must row blocks *Ready to submit* regardless of the confidence total.
-
-## Cap and order
-
-- At most 25 questions per submission; merge questions on the same topic across rows.
-- Order by PD swing (largest first), then by priority (Must before Should).
-- Beyond the cap, the remaining vague rows keep their `[ ]` assumption line and are listed in §5 as `Not sent — cap`.
+## Never ask
 
-## Answers
+- What the client's own document already answers, even if it is on another sheet.
+- What the operator can decide alone (profile inputs, preferred ISVs, phasing) — write a `Q-n` (an operator question, same shape) or resolve it directly.
+- Wording, formatting, or which column to use.
+- Anything the client cannot judge from a technical standpoint (an implementation choice with no client-visible effect).
 
-The partner records the client's answer by ticking an option or filling `Other:` in the §5 block. The next run's reconciliation turns it into a `.c<n>` line under every row the block names (source `client, CQ-n`, status date), or an `RC-n` in §3 when cross-cutting; the block is deleted; affected rows are re-estimated; one `C-n`. The client's wording never lands in the document, the decision does.
+Test: if answered either way, would a Requirement Coverage value, an Estimation figure or the Client Response text differ? No — no question.

package/skills/sw-discover-tender/reference/context-parameters.md

@@ -1,116 +1,23 @@
-# Context parameters — what we expect a tender to state
+# Context parameters — version, edition, plan
 
-The fixed template behind §1.2 *Key parameters*. Every row below is written into the
-analysis on the skeleton write, in this order, with its `#` and `Parameter` verbatim
-from this file — a tender that states nothing still produces the full table. The
-`Value` cell is the client's own words, never rounded, never converted, never inferred
-from another parameter. Where the source is silent the cell reads `_not provided_`.
+Project facts (Shopware version, edition, plan, what the project already built) come from the Dev Knowledge Base MCP only. The tool never researches the project itself outside it — no reading `composer.json`, no scanning `custom/plugins`, no asking the operator to guess.
 
-These are the figures that move an estimate: catalog and price-row counts drive import,
-sync and migration effort; order and traffic figures drive performance, hosting and load
-testing; customer and role counts drive the B2B model; media volume drives the migration
-window. A number the tender never stated and nobody asked for is the most expensive kind
-of gap, because it surfaces after the fixed price is signed.
+## Detection
 
-## Grammar
+Run once per document per session, before any item is assessed, and pass the result to every agent spawned for that run:
 
-| Column | Rule |
-| --- | --- |
-| `#` | `P-01` … `P-50`, fixed by this file. Never renumbered, never reordered, never dropped. |
-| `Parameter` | verbatim from this file. |
-| `Value` | the client's words, with their own unit and qualifier (`~6,000`, `approx. 850`, `38 GB`), or `_not provided_`. Several source statements: join with ` · `. |
-| `Source` | `<source-map #> <sheet or section> <row or cell label>`, e.g. `2 Company & Context · Volumes/Products`. `—` when `_not provided_`. |
-| `Drives` | copied from this file — what the figure changes in the estimate. |
-| `Status` | `stated` · `_not provided_` · `_not provided_ ⚠ CQ-n` · `conflicting` (two source statements disagree — always also a `CQ-n`). |
+1. `mcp__ShopwareDevKnowledgeBase__kb_status` — confirms the Knowledge Base is indexed for this project; refuse to assess coverage without it and say so in section 1.
+2. `mcp__ShopwareDevKnowledgeBase__read_doc` the project's own overview/index page for the installed version, edition (Community or the named Commercial plan) and any plan tier facts it records.
+3. `mcp__ShopwareDevKnowledgeBase__grep_docs` for what the project already built, per requirement area, before asking whether a scope item needs Extension or Custom — a feature the project already delivered is OOTB (D-12), not a separate value.
 
-A parameter marked **drv** below is estimate-driving: when its Status is `_not provided_`
-it MUST raise a `CQ-n` (SKILL.md step 6, `client-question-rules.md`) and the Status cell
-names that question. A non-**drv** gap is recorded and left alone — it is context, not a
-blocker. `conflicting` always raises a `CQ-n` regardless of **drv**.
+A fact the Knowledge Base does not carry: state it as `not provided by the Dev Knowledge Base` in section 1 rather than guessing; a scope item that depends on it becomes a `Q-n` to the operator, never an assumption dressed as a fact.
 
-Never derive one parameter from another (25,000 SKUs in 6,000 parents does not license
-writing `~4 variants per parent` into P-02), and never carry a figure over from a
-different tender.
+## What section 1 states
 
-## The template
+- Detected Shopware version, edition and plan of an existing project, each with the Knowledge Base page it came from — stated here in section 1's meta prose only. The Project information table's `shopware` row (`project-information.md`) instead records the tender's own stated target, Source = the tender location; when the detected version differs from the tender's stated target, raise a `Q-n` to the operator.
+- What the project already built that is relevant to at least one scope item, named by feature, with its Knowledge Base or wiki page.
+- The coverage-to-client-token map is not an intake fact — it is decided at export and stored in the fit-back map (`coverage-mapping.md`).
 
-| # | Parameter | Group | Drives | drv |
-| --- | --- | --- | --- | --- |
-| P-01 | Sellable SKUs / variants | Catalog | import, indexing, migration, search | drv |
-| P-02 | Parent products | Catalog | catalog modelling, PDP work | drv |
-| P-03 | Categories | Catalog | navigation, migration, SEO | drv |
-| P-04 | Technical attributes / properties (and values) | Catalog | property model, filters, ERP mapping | drv |
-| P-05 | Product images (count and storage volume) | Catalog | media migration, CDN, cutover window | drv |
-| P-06 | Product documents (datasheets, certificates) | Catalog | media or ERP-link decision, migration | drv |
-| P-07 | Hazardous / regulated product share | Catalog | compliance fields, shipping rules | |
-| P-08 | Packaging units, MOQ, order increments | Catalog | cart and pricing logic | |
-| P-09 | Languages / translations | Catalog | snippets, content, ERP language feeds | drv |
-| P-10 | Sales channels and domains | Catalog | channel config, theme, caching | drv |
-| P-11 | Customer groups / price lists | Pricing | pricing model, ERP sync | drv |
-| P-12 | Customer-specific price rows | Pricing | price sync volume, performance | drv |
-| P-13 | Tier / scale price coverage | Pricing | pricing rules, import | |
-| P-14 | Net / gross display rule | Pricing | storefront pricing, tax config | |
-| P-15 | Currencies | Pricing | currency config, rounding | |
-| P-16 | Countries / VAT and delivery scope | Pricing | tax, shipping, legal texts | |
-| P-17 | Companies / accounts | Customers | B2B model, migration | drv |
-| P-18 | Contacts / users | Customers | login migration, roles | drv |
-| P-19 | Addresses | Customers | migration, address model | |
-| P-20 | B2B roles, budgets, approval workflows | Customers | B2B Components vs plugin vs custom | drv |
-| P-21 | Punch-out / procurement accounts | Customers | OCI / cXML scope | drv |
-| P-22 | Orders per day (average) | Orders & traffic | sizing, queue and worker design | drv |
-| P-23 | Orders per day (peak) | Orders & traffic | load test target, hosting | drv |
-| P-24 | Average order value | Orders & traffic | context only, never priced | |
-| P-25 | Lines per order | Orders & traffic | cart performance, ERP payload | |
-| P-26 | Order history to migrate (orders and lines) | Orders & traffic | migration volume and window | drv |
-| P-27 | Sessions per month | Orders & traffic | caching, hosting | drv |
-| P-28 | Peak concurrent users | Orders & traffic | load test target, hosting | drv |
-| P-29 | Device split | Orders & traffic | responsive and mobile scope | |
-| P-30 | CMS / shop pages | Content & media | Shopping Experiences rebuild | |
-| P-31 | Blog posts | Content & media | blog scope, migration | |
-| P-32 | Landing pages | Content & media | rebuild effort | |
-| P-33 | Indexed SEO URLs / redirects | Content & media | redirect map, SEO risk | drv |
-| P-34 | Leading system (ERP) and version | Systems | integration pattern, ownership | drv |
-| P-35 | ERP protocol and API surface | Systems | connector effort, real-time feasibility | drv |
-| P-36 | PIM | Systems | catalog ownership | |
-| P-37 | CRM | Systems | interface scope | |
-| P-38 | Marketing / newsletter systems | Systems | interface scope | |
-| P-39 | PSP and payment methods | Systems | payment scope, PCI posture | drv |
-| P-40 | CMP / consent and analytics | Systems | consent scope, tracking | |
-| P-41 | Search / indexing infrastructure | Systems | OpenSearch, relevance work | |
-| P-42 | SSO / identity provider | Systems | admin and customer login scope | |
-| P-43 | Source platform and version | Migration | migration tooling, effort | drv |
-| P-44 | Migration objects and volumes | Migration | see §1.2 Migration inventory | drv |
-| P-45 | Cutover model and freeze window | Migration | go-live plan, risk | drv |
-| P-46 | Hosting model, region and certification | Commercial & timeline | hosting recommendation, operations | |
-| P-47 | Shopware edition / plan expectation | Commercial & timeline | plan decision, class ladder | drv |
-| P-48 | Budget as stated (verbatim, context only) | Commercial & timeline | recorded, never compared, never priced | |
-| P-49 | Questions-until / proposal due dates | Commercial & timeline | question deadline, run planning | |
-| P-50 | Award, kickoff and go-live dates | Commercial & timeline | plan feasibility, phasing | drv |
+## Passed to every agent
 
-Dates in P-49 and P-50 are also written into §1.1 Meta; §1.2 keeps them so the
-parameter table is complete on its own. They are the same values, quoted the same way.
-
-## Question stubs for a missing **drv** parameter
-
-`client-question-rules.md` governs the wording; these are the decisions to offer. Ask
-for the figure, never for a design.
-
-| # | Question | Options to offer |
-| --- | --- | --- |
-| P-01 · P-02 · P-03 · P-04 | catalog size | brackets that change the class, e.g. `< 5,000 SKUs` · `5,000–50,000` · `> 50,000`, plus `Other:` |
-| P-05 · P-06 | media count and storage volume | brackets in files and GB |
-| P-09 | which languages, and who supplies the translations | `client supplies` · `bidder translates UI only` · `bidder translates all` |
-| P-10 | how many sales channels and domains | `one` · `one per country` · `Other:` |
-| P-11 · P-12 · P-13 | how prices are structured and how many customer-specific rows | brackets |
-| P-17 · P-18 · P-20 · P-21 | company/contact counts, and which B2B roles and approval rules apply | the role model options |
-| P-22 · P-23 · P-26 · P-27 · P-28 | order and traffic figures, and how much history must be migrated | brackets; `no history` · `2 years` · `5 years` · `all` |
-| P-33 | indexed URLs and whether a redirect map is required | `redirect map required` · `not required` |
-| P-34 · P-35 | leading system, its version and the API it offers | `documented REST/OData` · `file exchange only` · `to be built by the client's partner` |
-| P-39 | PSP and payment methods in scope | the method list |
-| P-43 · P-44 · P-45 | source platform, migration objects and the cutover model | `big-bang` · `phased` · `Other:` |
-| P-47 | which edition/plan the client expects to licence | `Community` · `Rise` · `Evolve` · `Beyond` · `bidder recommends` |
-| P-50 | the go-live date and whether it is fixed | `fixed` · `target` · `Other:` |
-
-One question may cover a whole group of missing parameters in that table (one `CQ-n`
-for "catalog size", not four); every parameter it covers names it in its Status cell.
-The cap in SKILL.md step 6 applies to these questions like any other.
+Every `sw-product-manager` and `sw-shopware-architect` spawn receives: the detected version/edition/plan from this file, section 1's Project information table, and, per scope item it is given, that item's own Internal note (read-only) and its own rejected proposals (`References` `rejected:` lines plus any `rejected` entries in `proposals.json` for that item or global) with an instruction never to re-propose them (AQ-4).

package/skills/sw-discover-tender/reference/coverage-mapping.md

@@ -1,62 +1,39 @@
-# Coverage mapping
+# Requirement Coverage
 
-## Internal classes
+Six values, exactly, and no others: `OOTB · Configuration · Extension · ISV · Custom · —`. Every method file, the runtime and every agent use these six and these six only.
 
-| Class | Meaning |
-| --- | --- |
-| `stock` | Covered by the installed core or the recommended plan without development |
-| `config` | Covered by configuration (rules, flows, settings, CMS layouts) — configuration effort only |
-| `plugin` | Covered by a named store extension; licence source stated; integration effort only |
-| `custom` | Development required |
-| `commitment` | No development — a process, contract or recommendation the partner commits to |
-| `service` | No development — a service with real effort (training, documentation, test concept, go-live support) |
-| `not-offered` | The partner declines the row — a partner decision, never uncertainty |
-| `blocked` | No defensible estimate until a blocking `CQ-n` is answered |
+| Value | Meaning | Must name | Estimation |
+| --- | --- | --- | --- |
+| OOTB | The base already does it — stock Shopware, or already delivered by the project. | The stock feature and its KB page, or the project's implementation. | `0 PD` |
+| Configuration | The base has it; a consultant sets it up in the Administration — Rule Builder, Flow Builder, Shopping Experiences, settings, import profiles. No code. | The admin surface. | never `0 PD` |
+| Extension | The base has the entity, service, route or UI that does most of the job; we extend it — subscriber, decorator, custom field, Flow action, CMS element, or the project's own extension. | The stock or project feature extended, with its KB page. | the delta |
+| ISV | A Shopware Store extension covers it; we install, configure and integrate it. | Extension, vendor, supported Shopware versions, link. Compatible with the detected version and plan, with no licence terms or amounts attached. | integration and configuration |
+| Custom | A significant part is missing from the base; we build the domain. | Nothing to extend but the DAL or the plugin system. | the whole vertical |
+| `—` | Not about Shopware functionality: training, documentation, go-live support. | — | still carries effort |
+
+Each value's basis is a References line in the Knowledge Base's own feature names: `kb: <page>` for OOTB/Configuration/Extension against the platform docs, `project: <implementation or wiki page>` when the project itself already built it, `isv: <extension> · <vendor> · <supported versions> · <url>` for ISV. A claim the Knowledge Base does not cover becomes an assumption proposal (`assumption-catalogue.md`), never a guess written straight into Requirement Coverage.
 
-## Token rule
+## Client-token map — decided agentically at export
 
-Use the column's allowed list **verbatim** — never translate, never add a token. Applied at export (`RSP-3` in `response-rules.md`); "comment" below means the response comment (`RSP-4`). Map by meaning:
+The six Requirement Coverage values are mapped to the client's own compliance tokens at export, not at intake (`procedure.md` step 7, `editor-session.md` batch kind `export`). Tables are identified by their `<sheet> r<headerRow>` key, unique across the fit-back map. `tokens --suggest` prints the heuristic proposal per table key, the table's client token list, and its numeric legend when it has one; the map is decided from that input and stored with `tokens --file`, keyed the same way, for every later export of the same table.
 
-| Class | Token |
+Every one of the six values is something the partner delivers, so **never map to a negative token** — never "not offered", "not supported", "no", or "roadmap":
+
+| Value | Pick |
 | --- | --- |
-| `stock` | the token the RFP defines as covered without development (`Stock`, `Standard`, `OOTB`, `Yes`) |
-| `config` | the configuration token if the list has one, else the `stock` token; comment states `configuration only` |
-| `plugin` | the plugin/extension token; comment names the extension and its licence source |
-| `custom` | the development token |
-| `commitment` / `service` | the token the RFP defines as "no development"; else a neutral token (`Yes`, `Compliant`, `Erfüllt`); else the configuration token. Comment always `No development — commitment` or `Service effort, no development` |
-| `blocked` | the class the row would most likely be; effort empty; comment `Effort stated after clarification of <topic>` |
-| `not-offered` | the decline token — only on a partner decision logged as `C-n` in §7 (profile exclusion, declined Could row). Never for a Must row without an answered `Q-n`, never for uncertainty |
-
-Three-scale lists (`Yes / Partial / No`, `Fully / Partially / Not compliant`): `stock`, `config`, `plugin` without development → *Yes*; `custom` or `plugin` with development → *Partial*, comment carries the class; `not-offered` → *No*.
-
-**No token list**: use the scale the RFP's instructions define; else the profile's compliance scale; state the scale used in the §1.3 Source map and as an `X-n` line in §3.
-
-## Synonyms
-
-| Class | EN | DE |
-| --- | --- | --- |
-| `stock` | Stock, Standard, OOTB, Out of the box, Core | Standard, Im Standard, Enthalten |
-| `config` | Config, Configuration | Konfiguration |
-| `plugin` | Plugin, Extension, App, Store plugin | Plugin, Erweiterung, App |
-| `custom` | Custom, Development, Customisation | Individualentwicklung, Anpassung, Entwicklung |
-| `not-offered` | Not offered, No, Not available | Nicht angeboten, Nein, Nicht verfügbar |
-
-## Edition tiers — indicative, never evidence
-
-Starting hypothesis, taken from this harness's PRD checklist (`sw-design-requirements/reference/prd-confidence-checklist.md` §I). The PM verifies every cell the response relies on, every run, against `platform/func/commercial-features/*` and docs.shopware.com for the detected version. Conflicting tier documentation exists for some B2B capabilities — when the PM reports `conflict`, the row is a `CQ-n` against the client's contract, not a guess.
-
-| Capability | Community | Rise | Evolve | Beyond | Verify at |
-| --- | --- | --- | --- | --- | --- |
-| B2B Components (employees, roles, quick order, shopping lists) | — | — | ✓ | ✓ | `platform/func/commercial-features/b2b-components*` |
-| B2B order approval, budgets | — | — | verify | ✓ | same |
-| B2B quote management | — | — | verify | ✓ | same |
-| Sales agent / order on behalf (imitate customer is core) | core: imitate only | core | verify | ✓ | same |
-| Custom Products | — | ✓ | ✓ | ✓ | `platform/func/commercial-features/custom-products*` |
-| Advanced Search | — | verify | ✓ | ✓ | `platform/func/commercial-features/advanced-search*` |
-| Multi-Inventory | — | — | ✓ | ✓ | `platform/func/commercial-features/multi-inventory*` |
-| Subscriptions | — | — | — | ✓ | `platform/func/commercial-features/subscriptions*` |
-| Returns Management | — | verify | ✓ | ✓ | `platform/func/commercial-features/returns*` |
-| Admin SSO / 2FA | 2FA via plugin | verify | verify | verify | `platform/func/settings/*`, docs |
-| Flow Builder premium actions (delay, webhooks) | delay: verify | verify | ✓ | ✓ | `platform/func/settings/flow*` |
-
-**Community rule.** With Community as the recommended plan, every row that B2B Components would cover becomes `custom` and typically doubles; the architect returns the alternative and §2 shows both variants until the plan is decided.
+| OOTB | The best "standard / yes / fully" token. |
+| Configuration | The configuration-style token, or the next best after OOTB. |
+| Extension | The customisation- or development-style token. |
+| Custom | The customisation- or development-style token. |
+| ISV | The third-party / partner / add-on-style token when the list has one; otherwise the same customisation-style token as Extension/Custom. |
+| `—` | An N/A-style token when the list has one; otherwise the OOTB token — never a negative token such as "Not offered". |
+
+A numeric legend (key → label): pick the key by what its label means, never by the number's position. No token list in the client's file: use the scale the client's instructions define, or a neutral `Yes / Partially / No`, and record the scale used and the chosen map in the confirmed import map (`tokens --file`), not in section 1.
+
+## ISV research
+
+Coverage is checked only against the Shopware platform documentation and the Shopware Dev Knowledge Base MCP. Exception: for ISV items the architect researches the Shopware Store and vendor pages directly (WebFetch/WebSearch) — there is no marketplace layer in the Knowledge Base yet. An ISV item names the extension, its vendor, the Shopware versions it supports, and a link; it must be compatible with the detected version and plan, and carry no licence terms or amounts — never name a fee, a cost or a rate for it (`estimation-model.md`, money rule).
+
+## Project facts
+
+The detected Shopware version, edition and plan, and what the project already built, come from the Dev Knowledge Base only (`context-parameters.md`). The tool never researches the project itself outside the Knowledge Base.