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

package/skills/sw-discover-tender/reference/analysis-template.md

@@ -1,224 +1,57 @@
-# Analysis template
+# Working document grammar
 
-Copy verbatim, fill, delete every `<!-- -->` hint. The document is written in stages (SKILL.md *Staged writes*): the first write carries §1 complete — including §1.1 Meta, §1.2 Company & context, §8 Integrations and §9 Glossary, which need no estimate — plus every source row as a `queued` `req` line, with §2/§3/§5/§6/§7 `_TBD_`. Every later write must leave all nine sections and the four §1 subsections in place and parseable — a live page re-renders on each one. Section numbers, subsection numbers and titles are fixed; the rubric, reconciliation, the editor's tabs and the export key off them. Unknown content stays `_TBD_`; a parameter the tender does not state is `_not provided_`; an empty section is a signal, an invented one is a defect. Every assumption line is written as `[ ]`.
+`specs/rfp-NNNN-slug-analysis.md`. The runtime (`lib/parse.mjs`, `lib/check.mjs`, `lib/apply.mjs`) owns this grammar; this file is what an agent or the skill reads to write prose sections and to recognise a well-formed document. Never hand-write section 2 or a section 4 row — `intake` and `check --write` do that.
 
-The nine sections mirror the client's own document where it has one: §1.1 Meta and §1.2 Company & context, §4 grouped by source table, §8 Integrations and §9 Glossary are the tender's material; §2, §3, §5, §6 and §7 are ours.
+## Frontmatter (YAML)
 
----
+`state: In progress | Ready` — `intake: review | confirmed` (absent means `confirmed`; any other value is a parse error) — `regime: profile | T-shirt` — `source-sha256: { <file>: <hex> }` — `slug`, `client`, `tender-type` free text.
 
-```markdown
----
-rfp: RFP-NNNN
-kind: rfp                      # rfp | rfi | rfq
-client: <name>
-source:
-  - {file: <name as given>, size: <bytes>, sha256: <hex>}
-shopware: <version> <edition> (<evidence>); PHP <version> (<evidence>)
-status: Draft                  # Draft | Review | Ready to submit
-batch: 50                      # requirement rows per estimate run; all = one run for the whole document
-confidence: 0
-updated: YYYY-MM-DD
-counts:
-  rows: 0
-  assumptions: {proposed: 0, accepted: 0, rejected: 0, suspect: 0}
-  questions: {client: 0, blocking: 0, partner: 0, high: 0}
-  clarifications: 0
-export: {date: null, files: [], source_sha256: null, stale: false}
----
+## Sections, fixed order
 
-# RFP-NNNN — <Client> — <Project>
+8 sections, headings exactly: `## 1. Context` — `## 2. Totals` — `## 3. Global assumptions and exclusions` — `## 4. Scope items` — `## 5. Questions` — `## 6. Integrations` — `## 7. Glossary` — `## 8. Log`. An empty section stays as the heading alone. Nothing is dropped for being empty. There is no Approach section: a platform, hosting, PSP or CMP recommendation lives in its scope item's Client Response, and the Shopware target lives in section 1's Project information table.
 
-## 1. Context
+- Section 1 holds free prose meta first (source files, hashes, detected Shopware version/edition/plan with its evidence — `context-parameters.md`), then two subsections, always present in this order, each may have no rows:
+  - `### Project information` — table `| Parameter | Value | Source |`, the 18 `PROJECT_INFO` rows in fixed order (`project-information.md`). Written by `intake` and edited by the operator (`info`); `sw-tender-editor` never writes this table.
+  - `### Not taken from the source` — table `| Source | Text | Why |`, one row per skipped or removed row. Written by `intake`/`skip`/`restore`; `sw-tender-editor` never writes this table.
+- Section 2 is runtime-generated between `<!-- totals:begin -->` and `<!-- totals:end -->` (`check --write`): a `Regime:` line, a table `By priority` and a table `By tab` (one row per `TABS` entry in order, rows with 0 items omitted), a total row, and a status line with the confirmed/reopened/failed/open-question/low-confidence/waiting-proposal counts.
+- Section 3 has `### Assumptions` then `- <statement>` bullets, and `### Exclusions` then `- <statement>` bullets the client's document states. `sw-tender-editor` writes exclusions from the source; accepted global proposals land under Assumptions via `accept`/`assume`.
+- Section 4 holds the scope items — see below.
+- Section 5 holds client questions `CQ-n` and operator questions `Q-n` — see below.
+- Section 6 holds the integrations the tender names. Written by `sw-tender-editor`'s `context` job.
+- Section 7 is the Glossary: the client's terms. Written by `sw-tender-editor`'s `context` job.
+- Section 8 is the run log: one line per run (cause, what changed), and any conflict between agent reports the architect resolved. Appended by `report` alone.
 
-### 1.1 Meta
+## Section 4 header, exact
 
-Every field below is present. The tender is silent: `_not provided_`. Values are the client's words, dates as the client wrote them (their time zone kept).
+`| ID | Prio | Requirement | Requirement Coverage | Confidence | Estimation | Client Response | Assumptions | Internal note | References | Status |` — client inputs first (ID, Prio, Requirement), then the working fields. An older document headed `Effort`, or with Requirement after the working fields, is read the same way (columns are matched by header name, not position) and rewritten in this order and heading on its next write.
 
-| Field | Value | Source |
-| --- | --- | --- |
-| RFP reference | <!-- HIB-RFP-2026-03 --> | <!-- 1 Cover · RFP reference --> |
-| Kind | <!-- rfp / rfi / rfq, as the document calls itself --> | |
-| Issuing company | | |
-| Address | | |
-| Contact | <!-- name, role, address as given --> | |
-| Technical contact | | |
-| Date of issue | | |
-| Questions until | <!-- with the answer-distribution rule if stated --> | |
-| Proposal due | | |
-| Vendor presentations | | |
-| Contract award | | |
-| Kickoff | | |
-| Go-live | <!-- and whether it is fixed or a target, if stated --> | |
-| Response instructions | <!-- which columns to fill, which documents to submit, page limits --> | |
-| Compliance tokens | <!-- the client's own token list verbatim, or "none stated; scale: …" --> | |
-| Effort unit | <!-- PD / hours / none stated --> | |
-| Evaluation weights | | |
-| Deliverables | | |
-| Confidentiality | | |
-| Attachments | <!-- listed by name; note which are referenced but not supplied --> | |
-| Out of scope per RFP | <!-- the client's own exclusions; each also an X-n in §3 --> | |
-| Budget as stated | <!-- verbatim, or "none stated". Context only: never compared, never priced --> | |
+One row per scope item, client order. A `|` inside a cell is escaped as `\|`. A cell list (Assumptions, References) is `- ` bullets joined by `<br>`. Every table sits under a `### <Tab> · <Topic>` heading (separator ` · `, U+00B7 with spaces) — one table per topic, same header. `Tab` is one of `TABS = Functional, Non-functional, Project & services`; `Topic` is the client's own grouping verbatim. Canonical render order: tabs in `TABS` order; within a tab, topics in client first-seen order; items in client order. A heading without ` · `, a Tab not in `TABS`, an empty Topic, or a duplicate item id anywhere in section 4 is a parse error.
 
-### 1.2 Company & context
-
-**Profile.** <!-- business, customers, markets, sales organisation — the client's own summary in two or three lines -->
-
-**Current landscape.** <!-- shop platform and version, ERP, other systems, today's integration — one line each -->
-
-**Pain points and goals.** <!-- what the client says is broken, and the goals/KPIs they state -->
-
-**Constraints.** <!-- what the client fixes: leading system, who designs, cutover model, out of scope. Budget stays in §1.1 -->
-
-**Key parameters.** The fixed template is `reference/context-parameters.md` in this skill's directory: every row P-01…P-50 is present, in order, whether or not the tender states it. Never derived from another row, never carried over from another tender.
-
-| # | Parameter | Value | Source | Drives | Status |
-| --- | --- | --- | --- | --- | --- |
-| P-01 | Sellable SKUs / variants | <!-- 25,000 --> | <!-- 2 Company & Context · Volumes/Products --> | import, indexing, migration, search | stated |
-| P-12 | Customer-specific price rows | _not provided_ | — | price sync volume, performance | _not provided_ ⚠ CQ-7 |
-
-**Migration inventory.** The client's own inventory, verbatim; the approach column is ours. Volumes live here and are cited, never restated, by §6.
-
-| # | Object | Source | Volume | Must migrate | Approach | Rows | Notes |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| M-1 | <!-- products and variants --> | <!-- SW5 database + ERP --> | <!-- 25,000 SKUs / 6,000 parents --> | <!-- Yes / No / Partly / Should, client's word --> | <!-- ours, one line; "_TBD_" until §6 decides --> | <!-- MIG-01, INT-01 --> | |
-
-No inventory in the tender: one line `No migration inventory in the tender` and, when the tender asks for a migration at all, a `CQ-n` per P-44.
-
-### 1.3 Source map
-
-| # | Table (sheet / section) | Rows | Id column | Vendor columns (client's words) | Tokens | Effort unit | Locator |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 2 | <!-- 2 Requirements --> | <!-- 91 --> | ID | <!-- every vendor column verbatim; cost columns listed, never filled --> | <!-- Stock, Config, Plugin, Custom, Not offered — or "none stated; scale: …" --> | PD | <!-- rows 2–92 / page 4–9 --> |
-
-Every table in the source appears here exactly once, including the ones that carry no requirement row: its `Rows` count stands, its Id column is `—`, and its Vendor columns cell says where its content went — `context → §1.1`, `context → §1.2`, `context → §8`, `context → §9`, or `unused — <reason>`. A table is never silently dropped.
-
-Minted IDs: <!-- R-1..R-n for prose sources with page or paragraph, or "none" --> · Prefilled vendor cells: <!-- none | rows … (kept) --> · Ignored: <!-- hidden or _-prefixed sheets by name, or "none" --> · Warnings: <!-- missing attachments, truncated text, or "none" -->
-
-### 1.4 Ground truth
-
-Shopware <!-- version, edition, evidence --> · Project plugins <!-- name: covers, or "none" --> · Partner assets <!-- from the profile, or "none" --> · Prior analyses reused <!-- rfp-NNNN <ID> → row, or "none" --> · KB pages <!-- one line --> · Agents <!-- PM clusters …; architect clusters …; QA yes|no; not consulted — <reason> -->
-
-## 2. Summary
-
-| Scope | PD |
+| Column | Grammar |
 | --- | --- |
-| Must (fixed-price scope) | |
-| Should | |
-| Could | |
-| of which Services | |
-| **Total** | |
-
-By area: <!-- area: PD, … — must add up to the priority totals --> · Foundation efforts: <!-- name → row (PD) --> · Overhead / buffer: <!-- n% folded · buffer n% separate · level buffers 0/10/25%, or "_TBD_ — PD stated before overhead and buffer" --> · Plan variants: <!-- Evolve: Must n · Community: Must n, or "single variant" --> · Blocking rows: <!-- ids, or "none" -->
-
-| Dimension | Weight | Score | Points |
-| --- | --- | --- | --- |
-| Coverage evidence | 20 | 0 | 0.0 |
-| Estimate basis | 20 | 0 | 0.0 |
-| Scope lock | 20 | 0 | 0.0 |
-| Platform decision | 15 | 0 | 0.0 |
-| Integration & migration | 15 | 0 | 0.0 |
-| Consistency | 10 | 0 | 0.0 |
-| **Total** | **100** | | **0%** |
-
-Weakest dimension: <!-- name — what raises it; every status blocker by id -->
-
-## 3. Global assumptions
-
-Lines no single row owns. Same status grammar as §4.
-
-| ID | Kind | Rows | Statement | PD saved | Risk to | Status |
-| --- | --- | --- | --- | --- | --- | --- |
-| A-1 | assume | <!-- GEN-06, STF-01..STF-10 --> | <!-- rewritten for this tender --> | <!-- per row: STF-01 −5 · STF-03 −3 --> | client | [ ] |
-| X-1 | exclude | <!-- GEN-04 --> | <!-- what the RFP itself excludes, restated --> | | | rfp |
-| RC-1 | clarify | <!-- rows --> | <!-- decision --> | | client, CQ-5 | YYYY-MM-DD |
-
-## 4. Requirement analysis
-
-| ID | Kind | Prio | Class | L/M/H | Lvl | PD | Text | Evidence / risk | Status |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| STF-03 | req | Must | custom | 12/16/22 | vague | 17.5 | <!-- mechanism, one line; "Includes foundation: <name> (n PD)" --> | <!-- pm: not-stock (…); arch: vendor path / KB page; unverified; reuse: rfp-NNNN ID --> | estimated, CQ-3 |
-| STF-03.a1 | assume | | | | | −5 | <!-- statement --> | risk to client | [ ] |
-| STF-03.a2 | assume | | config | | | −2 | <!-- statement --> | risk to client | accepted YYYY-MM-DD |
-| STF-03.c1 | clarify | | | | | | <!-- decision --> | client, CQ-3 | YYYY-MM-DD |
-
-Kinds: `req` one per source row · `assume` `<ROW>.a<n>` · `clarify` `<ROW>.c<n>`. Req status: `queued` (extracted, not yet estimated — PD and L/M/H empty) · `analysing` (its agents are running) · `estimated` · `estimated, CQ-n` (estimated, with an open question named; the estimate's condition is a `[ ]` assumption line under the row) · `blocked, CQ-n` or `blocked, Q-n` (PD empty; a partner question blocks the same way) · `prefilled`. There is no `provisional` status: a row is either estimated — under stated assumptions and, where needed, an open question — or blocked. A finished run leaves no `queued` or `analysing` row. Assume status: `[ ]` · `[x]` · `[-]` · `accepted YYYY-MM-DD` · `rejected YYYY-MM-DD` · `[ ] suspect`. Class on an assume line = the class the row takes once accepted. Lvl `detailed | medium | vague`.
-
-## 5. Open questions
-
-### CQ-1 · <!-- rows --> · blocking: <!-- yes | no -->
-<!-- question, RFP language, one decision -->
-- [ ] A — <!-- option: effect on scope in plain words -->
-- [ ] B — <!-- option -->
-- [ ] Other:
-Until answered we assume <!-- option, or "no effort stated" -->.
-
-### Q-1 · <!-- high | medium | low --> · <!-- rows or § -->
-<!-- question the partner can answer -->
-- [ ] A — <!-- option (recommended): consequence in PD -->
-- [ ] B — <!-- option -->
-- [ ] Other:
-Until answered we assume <!-- option -->.
-
-Not sent — cap: <!-- row ids, or "none" -->
-
-## 6. Approach
-
-| Item | Decision | Reason (rows served, source) | Alternative · PD delta |
-| --- | --- | --- | --- |
-| Plan | <!-- Community / Rise / Evolve / Beyond --> | | <!-- Community: +n PD --> |
-| Hosting | | | |
-| PSP | | | |
-| CMP | | | |
-
-| Interface | Pattern | Owner split | Risk |
-| --- | --- | --- | --- |
-| <!-- ERP → shop master data --> | <!-- queue consumers, idempotent upserts --> | <!-- bidder: shop side; ERP partner: API pages --> | <!-- one line --> |
-
-| Migration object | Approach | Volume | Tool | Reuse |
-| --- | --- | --- | --- | --- |
-| <!-- products --> | | | | |
-
-## 7. Log
-
-Append-only. Never a transcript.
-
-| ID | Date | Topic | Decision |
-| --- | --- | --- | --- |
-| C-1 | YYYY-MM-DD | <!-- accepted / rejected / answered / suspect / exported / partner decision --> | <!-- one line, ids named --> |
-| K-1 | YYYY-MM-DD | <!-- PM vs architect on B2B-03 --> | <!-- resolved: … / → Q-n --> |
-
-## 8. Integrations
-
-The client's integration register, verbatim; `Class` and `Risk` are ours. One line per interface the tender names, in source order. §6's Interface table decides the pattern and the owner split and cites these numbers instead of repeating them.
-
-| # | System | Direction | Objects | Frequency | Protocol | Counterpart owner | Rows | Class | Risk |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| I-1 | <!-- Microsoft Dynamics 365 Business Central --> | <!-- ERP → shop, client's arrow kept --> | <!-- products, prices, stock --> | <!-- nightly full, 15-min delta --> | <!-- OData v4 REST --> | <!-- client's ERP partner --> | <!-- INT-01, CAT-01..CAT-10 --> | <!-- stock / config / plugin / custom / service, or _TBD_ before the estimate --> | <!-- one line, or "—" --> |
-
-No integration table in the tender: one line `No integration register in the tender`, and every interface named inside a requirement row still gets a line here, `Source: <row id>` in Notes-position of the `#` cell. This section is never exported; it is not a response table.
-
-## 9. Glossary
-
-The client's terms, verbatim, in the client's order. `Maps to` is ours: the Shopware or partner vocabulary the term corresponds to, and the row ids that use it — this is the mapping the Tender Discovery Tool shows on the requirement rows.
-
-| Term | Meaning | Maps to |
-| --- | --- | --- |
-| <!-- PU / Packaging unit --> | <!-- the client's definition, verbatim --> | <!-- purchase unit / `purchaseUnit`, `referenceUnit` · CAT-07, CHK-02 --> |
-
-A term the client defines but nothing in Shopware matches: `Maps to` = `no equivalent — <one line>`. A term we cannot map yet: `_TBD_`. Never invent a definition, never correct the client's. No glossary in the tender: one line `No glossary in the tender`. This section is never exported; it is not a response table.
-```
-
----
-
-Status grammar:
+| ID | Client id verbatim, any format. No id column: `<prefix>-<n>` — `prefix = sheetPrefix(topic)` (initials of the topic's words, ignoring `&`, `and`, `und`, `/`, punctuation; a word with digits contributes its first letter, uppercase, max 4 letters; a single-word topic uses its first 3 letters uppercase; a prefix collision elsewhere in the document appends `2`, `3`...). `n` counts from 1 in source order within that topic over every source row of the declared tables, skipped rows included, so a skip, a restore or a re-intake never renumbers; a restored item gets its old id back and its client-order position. Moving an item to another tab or topic never changes its id; the id is stable across intakes of the same file, never written into the client's file. |
+| Requirement | The client's text, verbatim, never overwritten. |
+| Requirement Coverage | One of `OOTB · Configuration · Extension · ISV · Custom · —`, or empty when not yet assessed. |
+| Confidence | `high \| medium \| low`, or empty. |
+| Estimation | T-shirt: `<SIZE> (<n> PD)`, `SIZE` in `XS S M L XL XXL`, OOTB is `— (0 PD)`. Profile: `<n> PD` rounded to 0.25, OOTB `0 PD`. Empty when not estimated. The report JSON key stays `effort`. |
+| Client Response | Architect drafts, operator edits. |
+| Assumptions | Accepted assumptions for this item, as bullets. |
+| Internal note | Operator-written only; agents read it, never write it. |
+| References | Agent-written: `kb: <KB page title or path>` — `project: <implementation or wiki page>` — `isv: <extension> · <vendor> · <supported versions> · <url>` — `cost: <one line, no amount>`. Runtime-written: `rejected: <statement>` — `failed: <reason>` — `reopened YYYY-MM-DD: <cause>` — `draft: <text>` (the architect's Client Response draft when it differs from a confirmed/reopened item's kept text). Never exported. |
+| Status | `queued · analysing · estimated · blocked CQ-<n> · failed · confirmed YYYY-MM-DD · reopened`. |
+
+## Section 5 blocks
 
 ```
-[ ]  proposed  --human--> [x] | [-]  --next run--> accepted YYYY-MM-DD (frozen, PD applied, row recomputed, C-n)
-                                                   rejected YYYY-MM-DD (row at full scope, C-n)
-source sha256 changed   --next run-->  affected accepted lines become [ ] suspect (C-n)
-question option ticked  --next run-->  .c line under each row named, or RC-n in §3; the block dissolves (C-n)
+### CQ-<n> · <item id>, <item id>
+<question text>
+- [ ] A — <option text> — effect: <scope effect>
+- [ ] B — <option text> — effect: <scope effect>
+Fallback: A
 ```
 
-Every source row has one `req` line; none is dropped to shorten the file. A `_TBD_` cell is a truthful gap; a guessed one reaches the client as a wrong number. `_not provided_` in §1.2 is the same promise about the tender: it says the client never stated the figure, not that the figure is zero or unknown to us.
+Answered: the chosen box is `[x]` and a line `Answered YYYY-MM-DD: <key>` follows `Fallback:`. Operator questions use `### Q-<n> · <item ids>`, same shape, options optional. A `CQ-n` needs at least two options.
+
+## Side files
 
-Export (SKILL.md step 9) reads §1.3, §2 and §4 only. §1.1, §1.2, §8 and §9 are analysis context and are never written into a response CSV.
+Not part of the working document; written under `specs/.rfp/<slug>/` or `specs/`. Grammar: `context-parameters.md` (version/edition/plan), `project-information.md` (the 18 keys), `assumption-catalogue.md` (proposal starting points), `estimation-model.md` (regimes, scale, profile file), `response-rules.md` (export), `client-question-rules.md` (CQ/Q wording). The runtime's own side files (`proposals.json`, `reestimate.json`, `last-run.json`, `import-map.json`) are documented with the runtime, not here.

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.