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

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.

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

@@ -1,6 +1,6 @@
 # Editor session — `--editor`
 
-The Tender Discovery Tool: a local live page for one analysis document. The skill session that received `--editor` runs this loop and nothing else; every content change is made by the user on the page (ticks, answers, proposed lines, notes) or by this skill in editor mode, spawned as a subagent per batch. Nothing is read, reconciled or analysed before the page is open.
+The Tender Discovery Tool: a local live page for one working document. The skill session that received `--editor` runs this loop and nothing else; nothing is read, intaken or assessed before the page is open.
 
 **The protocol is not in this file.** Run
 
@@ -8,108 +8,67 @@ The Tender Discovery Tool: a local live page for one analysis document. The skil
 npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest guide
 ```
 
-and follow it: it is the single source for the xlsx import, start, the batch kinds, poll, emit, redelivery and close, and every command ends with a `next_step:` line. An installed copy of any of that goes stale against a newer CLI. This file adds only what `guide` cannot know — the install gate, the row-batch setting, which opening batch to post, the subagent brief, the follow-up queueing grammar and the close report.
+and follow it: the xlsx import, start, poll, emit, redelivery and close, and every command's `next_step:` line. This file adds only what `guide` cannot know: the install gate, which batch kinds this skill runs, the subagent brief, and the close report.
 
 ## 0. Install gate
 
-The Tender Discovery Tool is an **optional add-on**: what a host installs is its skill, `sw-tender-discovery-tool`, which ships inside the npm package and is installed by `sw-setup`.
-
-Before anything else, check whether that skill is present in this host's skills directory. Present → continue. Absent → **stop the run**. Do not fall back to non-editor mode, do not write the analysis, do not continue the procedure. Tell the user in one line: the Tender Discovery Tool is not installed; run the `sw-setup` skill to add it, or re-run without `--editor`. The `.xlsx import` step in `reference/procedure.md` uses this same gate and stops the same way.
+The Tender Discovery Tool is an optional add-on: what a host installs is its own skill, `sw-tender-discovery-tool`, shipped inside the npm package and installed by `sw-setup`. Before anything else, check whether that skill is present in this host's skills directory. Present — continue. Absent — stop the run. Do not fall back to non-editor mode. Tell the user in one line: the Tender Discovery Tool is not installed; run the `sw-setup` skill to add it, or re-run without `--editor`.
 
 ## 1. Prepare
 
-- `grep -q "specs/.editor" .gitignore || printf '\n/specs/.editor/\n' >> .gitignore`
-- `<slug>` = file name without `-analysis.md` (or without the source extension); analysis `specs/<slug>-analysis.md`; session folder `specs/.editor/<slug>/` (gitignored).
-- **Row-batch setting:** `--batch <n|all>` from the invocation, else the analysis frontmatter's `batch:`, else 50. Keep it for the whole session and pass it to every subagent. `guide` knows nothing about this.
+`<slug>` = the source file name without its extension. Working document `specs/rfp-<slug>-analysis.md`. Session state under `specs/.editor/<slug>/`, gitignored.
 
 ## 2. Open the session
 
-Follow `guide` steps 0–1: import an `.xlsx` source first when it has no confirmed mapping, then `start`, then open the printed URL in the browser and tell the user in one line.
-
-Keep the printed `TENDER_TOOL_URL=<url>` (with its trailing slash) for the whole session — the subagent brief needs it.
-
-**An xlsx tender's opening batch is the mapping confirmation, not `analyze`.** The page opens on the steering screen, where the user says which tabs are requirement tables, where each header sits and what each column means. Confirming writes the normalised CSVs and arrives here as a batch with `stage: import` (§4). Do not post `analyze` for an xlsx tender.
+Follow `guide` steps 0-1: import an xlsx source first when it has not yet been extracted and intaken, then `start`, then open the printed URL and tell the user in one line. `start` on a source with no working document yet queues the opening `intake` batch itself — extraction plus intake — the moment the page opens; nothing here has to send it. It arrives at the first `poll` in this session, same as any other batch; there is no mapping screen.
 
-## 3. Opening batch (page first, then the agentic flow)
+## 3. Page actions are not batches
 
-Read `status`, then post exactly one of:
+Move an item, skip an item, restore an item, edit a Project information value, answer a client question, edit a profile input, patch a Client Response or an Internal note, and export are all handled by the runtime's own commands directly (`move`/`skip`/`restore`/`info`/`confirm`/`unconfirm`/`assume`/`unassume`/`answer`/`patch`/`profile`/`export`); the page calls them without spawning this skill (`confirm` and `unconfirm` save at once even while this session's run holds the lock, so `apply` sees a confirmed row as confirmed), except when export needs a token map first — see the `export` batch kind below. Accepting or rejecting a proposal instead queues a decision alongside notes; the server applies it through the same `accept`/`reject` commands the moment a `notes` batch is sent — before this skill ever sees the batch (see the `notes` row below) — never re-applied by this session. Move, skip and restore work at any time, through a row note — skipping a confirmed item is refused ("unconfirm first"), and the operator's own `unconfirm` (a second click on the row's confirm tick, no dialog) reopens the item so a skip or another correction can follow. Intake queues the opening `analyze` batch itself once it confirms, and an `accept`/`answer`/`profile` change queues a `reestimate` batch the same way — this session never has to send either. `intake-confirm` stays only for an old document still at `intake: review`, and this session runs it on the operator's go before any of the above. This session only spawns a subagent for the five batch kinds below.
 
-| State | Post | Why |
-| --- | --- | --- |
-| analysis `missing` | `batch --kind analyze` | Steps 1–4 and the skeleton write only, handled by §4. The page renders every requirement row as `queued` within minutes; the estimate batches follow from §4a. |
-| `found`, pending ticks/answers/proposals > 0 | `batch --kind reconcile` | Unreconciled from an earlier session. |
-| `found`, nothing pending | nothing | The page renders the document as it is. |
-| xlsx with no confirmed mapping | nothing | §2: confirming the mapping is the opening batch. |
+## 4. Batch kinds
 
-Then poll per `guide` until `closed`: `event: batch` → §4, then poll again; `event: closed` or unreachable → §5.
+| kind | Work |
+| --- | --- |
+| `intake` | Extraction (`procedure.md` step 1): `sw-tender-editor`'s `extract` job on the digest or the PDF, then `intake`. Writes section 1's Project information and Not taken tables and every new item `queued`, then confirms itself (`intake: confirmed`) and queues the opening `analyze` batch. |
+| `analyze` | Assess exactly the batch's `items` (about 15 ids, in page order — `procedure.md` step 2): split into groups of about 5, spawn PM→architect pairs in parallel per group (cap 10 spawns per message), `apply` each report as it returns. Refused while `intake: review` (an old document not yet confirmed). Intake confirming itself, and any re-estimate work while confirmed, queues this automatically — nothing here sends it. The server chains batches on its own: when this one finishes it queues the next chunk of items still needing work, releasing the lock in between so a page action lands before the next chunk starts; the chain ends when no work is left. |
+| `reestimate` | The items named in `reestimate.json` (or all, on `item: "*"`): re-run steps 2-4 for those items only. |
+| `notes` | Queued annotations and/or chat. A note on a scope row reading "move to <tab>" or "skip: <why>" is applied with `move`/`skip` directly, at any time, not folded into re-assessment — skip on a confirmed item is refused ("unconfirm first"). Any queued accept/reject decision on a suggested assumption has already landed by the time this batch is sent (the server applies it while enqueueing the batch) — treat it as done, never re-apply it from the batch payload. Any other note, while `intake: confirmed`: no item is re-assessed and the run records why an annotation was or was not applied. While `intake: review` (an old document), the remaining notes are folded into a re-run of `extract` and `intake`. |
+| `export` | The page's Export enqueues this when an XLSX table still lacks its coverage-to-client-token map: `tokens --suggest`, decide the map per table key `<sheet> r<headerRow>` (`coverage-mapping.md`), `tokens --file`, then `export` (`procedure.md` step 7). Post the output path and the chosen map (per table, six lines) in chat; on a refused token, adjust and retry once, else post the reason. |
 
-## 4. Handle one batch
+Every batch, of every kind, ends with `check <doc> --write` then `report <doc>`, whose output is posted to the page as the reply (`procedure.md` "Run close").
 
-The batch JSON's `kind` (`analyze` | `reconcile` | `batch` | `export`) decides which case in the brief below applies; its fields are listed in `guide`. `batch_file` is absolute — open it as given, whatever your working directory is.
+## 5. Handle one batch
 
 Spawn ONE subagent (Agent tool, `general-purpose`). Brief, verbatim structure:
 
 ```
 Run the skill sw-discover-tender in editor mode.
-Invoke it with the Skill tool: skill "sw-discover-tender", args "<analysis path> --editor-session <url> --batch-file <batch file>"
-  (kind=analyze: args "<source path> --editor-session <url> --analyze" — first run on the source, writes <analysis path>;
-   kind=reconcile: the same args as a batch — a plain continue run: reconcile the ticks and answers in the file, re-estimate, rescore;
-   kind=export: args "<analysis path> --editor-session <url> --batch-file <batch file> --export").
-Append the session's row-batch setting to the args when it is not the default: <--batch n | --batch all>.
-If the Skill tool is not available to you, read the SKILL.md of the `sw-discover-tender` skill and follow it exactly, including its "Editor mode" section.
-Rules: never ask the user a question with a structured question tool (Claude Code: `AskUserQuestion`; Codex: `request_user_input`); every gap becomes a §5 block with options; emit progress with
+Invoke it with the Skill tool: skill "sw-discover-tender", args "<doc path> --editor-session <url> --batch-file <batch file>"
+  (kind=intake: args "<source path> --editor-session <url> --intake" — first run on the source).
+If the Skill tool is not available to you, read the SKILL.md of the `sw-discover-tender` skill and follow it exactly.
+Rules: never ask the user a question with a structured question tool (Claude Code: `AskUserQuestion`; Codex: `request_user_input`); every gap becomes a section 5 block with options; emit progress with
   npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest emit progress "<step>" --batch <id>
-  before each procedure step and before/after each agent wave; never change a [x] or [-] except by reconciling it; keep every [ ] line whose
-  Evidence / risk or Risk to says "partner"; frozen accepted/rejected lines stay byte-identical; never edit the client's file.
+  before each procedure step and before/after each agent spawn; never write into a confirmed item's Client Response or Internal note except through `patch`; never edit the client's file.
 Context — last chat entries (newest last):
 <last 10 lines of specs/.editor/<slug>/chat.jsonl, use `tail -n 10`>
-The batch file's `stage` field ("estimate C1,C2", "finalize") says which part of the procedure this batch is; the skill's Editor mode section defines them.
-Return, as your final message, the skill's 8-line report with its final `next:` line (plus the 3 export lines for kind=export). Nothing else.
+Return, as your final message, the run report from `report <doc>`. Nothing else.
 ```
 
-When the subagent returns, post its report as the reply, per `guide`. If it fails or returns nothing usable, still post a reply (`Run failed: <one line>`) so the lock is released.
-
-## 4a. Queue the follow-up batches
-
-The report's last line is `next: estimate C1,C2 | C3,C4` or `next: none`. After posting the reply, post one `batch --kind batch --stage "<group>"` per group in order, then `--stage finalize` after the last one, then go back to the poll.
+When the subagent returns, post its report as the reply. If it fails or returns nothing usable, still post a reply (`Run failed: <one line>`) so the lock is released.
 
-Group sizes come from the session's row-batch setting (§1), so the `next:` line already names them — post exactly those groups. Post them all at once: the queue is FIFO and unbounded, so a batch the user sends meanwhile simply takes its turn, and every group releases the lock when it ends, which is when the ticks made during it are applied. Never post a group whose rows are no longer `queued`. `next: none` → nothing to queue.
+## 6. Close
 
-## 5. Close
+The page going quiet (closed tab, reload, laptop sleep) does not end the session right away: `guide` step 7's close grace holds it open for reconnect first, so keep polling through `idle` and only stop on `closed`.
 
-On `closed` (or when the server is unreachable): read `specs/.editor/<slug>/session.json` and report five lines:
-- analysis path (and the source it answers)
+On `closed` (or when the server is unreachable): read `specs/.editor/<slug>/session.json` and report:
+- document path and the source it answers
 - batches processed this session
-- status · confidence · pending ticks (from `status` before the close if reachable, else the frontmatter)
+- state, and confirmed-of-total from the last `report`
 - path of the chat log (`specs/.editor/<slug>/chat.jsonl`)
-- how to resume: re-run the same command with `--editor`; ticks live in the file, chat and unsent notes are restored
+- how to resume: re-run the same command with `--editor`
 
 ## Notes
 
-- Order of operations is fixed: server → xlsx import (when applicable) → browser → opening batch → loop. If you find yourself reconciling or analysing before the page is open, stop and go back to §2.
-- The page writes only what a human would type: `[x]` / `[-]` / `[ ]` in a Status cell, `- [x]` on a question option, `Other: <text>`, new `[ ]` assumption lines marked `partner`, and `X-n` exclusion lines in §3. Everything else in the file is written by this skill in editor mode.
-- A batch may arrive while rows are still `queued`: that is normal. The user works on the rows already estimated while the rest are still being worked out.
-- Everything under `specs/.editor/` is session state and gitignored; the analysis file next to the source is tracked.
-
-## Editor mode — the skill's own run when spawned by this session
-
-Invoked by the editor session (`reference/editor-session.md` in this skill's directory, this file) as a subagent: `<analysis path> --editor-session <url> --batch-file <batch.json>`, `<source path> --editor-session <url> --analyze` (first run), or `… --batch-file <batch.json> --export`. `--batch-file` is the session's batch descriptor; `--batch <n|all>` is the row-count setting and means the same here as anywhere. Same procedure (`reference/procedure.md`), same boundaries, same reconciliation, plus:
-
-- **Batch kinds.** The batch file's `kind` and `stage` decide the work; a batch is short by design, so the lock is released often and the user's ticks land between batches.
-
-| kind · stage | Work |
-| --- | --- |
-| `analyze` | Steps 1–4 and the **skeleton write only**. Do not estimate. End with `next: estimate <groups>` so the session can queue the rest. Under `--batch all` this batch runs steps 1–8 for every row instead and ends with `next: none`. |
-| `batch` · `stage: import` | The user confirmed what is in the client's workbook. Read `import-map.json` (the batch's `importMap` names it): its `tables` are §1.3 Source map — number, sheet name, rows, id column, vendor columns and allowed tokens, all confirmed by a human. Then continue exactly as `analyze`: steps 1–4 and the skeleton write only. |
-| `batch` · `stage: estimate C3,C4` | Step 5 for those clusters only (pipelined per cluster), then `§ROWS` and `§SPLICE`. No totals. `next:` names the groups still left. |
-| `batch` · `stage: finalize` | Step 7 and step 8: §2, score, §3, §5, §6, §7, frontmatter. |
-| `batch` (notes, chat) | A continue run briefed by the notes and chat in the batch file. |
-| `reconcile` | Step 2 first (every `[x]` → `accepted <date>`, `[-]` → `rejected <date>`, ticked options → `.c` lines / `RC-n` and the block dissolved, rows recomputed, §2 rescored, one `C-n` per decision), then steps 4–7 for the rows it touched. |
-| `export` | Reconcile, then step 9. |
-
-- **Tick grammar from the page.** The box is matched at the start of the Status cell: `[x] suspect` and `[-] suspect` are a human decision on a suspect line; the suffix is dropped on reconcile. A `[ ]` line whose Evidence / risk says `risk to <x>; partner` (§4) or whose Risk to says `<x> (partner)` (§3) was written by the partner on the page: keep it, estimate its effect like any candidate, never delete or reword it.
-- **Notes.** `comment` notes carry `block`, `blockKind`, `path` (section breadcrumb), `line`–`endLine`, `md` (the block's source line), `quote`, `hash` and sometimes `selection` (the exact text the user highlighted). Open the file at that range under that path, confirm the text matches `md`, fall back to searching for `quote` when lines shifted. By `blockKind`: `req` → the note questions the class, mechanism or estimate: re-spawn the architect for that row only and rewrite the `req` line; `assume` / `global` → rewrite the statement as a new `[ ]` line (a frozen line is never edited; a proposed line may be replaced in place), or adjust `PD saved` when the note is about the figure; `clarify` → the decision text; `question` → reword or re-option the block (keep its id); `section` / `paragraph` / `row` → that text. `free` notes and `chat` are the briefing for the run. No PD figure ever comes from the page: a note asking for a different number is an architect question, not a hand edit.
-- **A note on a row still `queued` or `analysing`** is not an immediate re-spawn: carry it into that row's own estimate batch and answer it there.
-- **Preserve on every write.** Frozen `accepted <date>` / `rejected <date>` lines byte-identical; every `[x]` / `[-]` untouched except by reconciling it; partner-proposed `[ ]` lines; `X-n` exclusions the page added; §1.1, §1.2, §8, §9 and the nine section headings; the frontmatter block. Rewrite lines in place, never regenerate from the template. Every write must leave the document parseable — the page re-renders on each one.
-- **Progress.** `npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest emit progress "<step>" --batch <id>` before each procedure step and before and after each spawn wave; the page shows it. Row status carries the rest: `queued` → `analysing` → `estimated`.
-- **Report.** The 8-line report of step 8 with its `next:` line (plus the 3 export lines); the editor posts it to the page. Never paste the document into the report.
+- Order of operations is fixed: server -> xlsx import (when applicable) -> browser -> opening batch -> loop.
+- Everything under `specs/.editor/` and `specs/.rfp/<slug>/` is session state and gitignored; the working document next to the source is tracked.

package/skills/sw-discover-tender/reference/estimation-model.md

@@ -1,106 +1,70 @@
 # Estimation model
 
-## Unit
+A working document is in one regime at a time. Regime = `profile` when `specs/rfp-partner-profile.md` exists and parses, else `T-shirt`. The runtime applies this rule on every run; the architect never decides the regime.
 
-**PD** = one person-day (8 h) of one senior Shopware developer, including unit tests and code review. Excludes project management, QA, design, content, training, hosting and the ERP partner's work; those enter through overhead or as *Services* rows. If the RFP defines PD differently, the RFP's definition wins and the difference is stated in §1.
+## Regimes
 
-## Three-point per row
+| Regime | When | Estimation cell |
+| --- | --- | --- |
+| profile | a partner profile exists | The architect's base person-day estimate, one figure, before overhead and buffer. The runtime applies the profile's overhead and buffer and writes `<n> PD` (rounded to 0.25). |
+| T-shirt | no profile | The architect gives a `size`; the runtime looks up the default-scale PD and writes `<SIZE> (<n> PD)` — default scale, before overhead and buffer. |
 
-The architect returns `low / mid / high` per row:
-- **low** — everything goes right, named reuse applies
-- **mid** — most likely, drivers partly materialise
-- **high** — every listed driver materialises
+**E-1** One figure per scope item, no low/high range — the architect returns a single `size` (T-shirt) or a single base `pd` (profile) per item in its report JSON; there is no three-point estimate.
 
-The PM never estimates. The QA agent estimates only quality, test, security-testing and accessibility rows.
+**OOTB effort.** T-shirt regime: the architect gives `size: "—"`; the runtime writes `— (0 PD)`. It also derives `— (0 PD)` when the coverage is OOTB and `size` is omitted, so an architect that forgets the field on an OOTB item is not a validation failure. Profile regime: the architect gives `pd: 0`.
 
-## Level and buffer
+## Default scale (T-shirt)
 
-| Level | Definition | Buffer |
+| Size | PD | What makes it this size |
 | --- | --- | --- |
-| detailed | Acceptance criteria present, or a quantified specification (volumes, limits, formats) | 0% |
-| medium | Clear intent, no acceptance criteria | 10% |
-| vague | Comparative or totality phrasing, undefined reference, missing counterpart or owner | 25%, and only with a `CQ-n` or a proposed assume line; blocked rows stay empty |
+| — | 0 | OOTB. |
+| XS | 0.5 | A setting, a snippet, a flag. |
+| S | 1.5 | One configuration set, or one hook — subscriber, custom field, Flow action, Rule condition. |
+| M | 4 | One feature on one surface with its own UI, or a plain ISV install and configuration. No new entity. |
+| L | 10 | Administration and Storefront, or a new entity with API and UI, or an ISV integration with real mapping. |
+| XL | 25 | A vertical — domain model, admin module, API, storefront, rules — or a two-way interface. |
+| XXL | 50 | Too large for one scope item; flagged *not decomposed*. |
 
-## Assumption lines
+**Size-up drivers**, one size each, applied by the architect when sizing: an external counterpart the partner does not control · data migration · a hard non-functional requirement · no stock feature to stand on. Section 1's Project information table is size-up evidence, not a separate driver — high order/traffic volumes, a heavy migration or many sales channels/markets/currencies are what makes a driver apply; cite the relevant Parameter row when it is why an item is sized up.
 
-Every candidate is a `[ ]` line with a PD saved figure stated against mid: `<ROW>.a<n>` under its row, or `A-n` in §3 with PD saved per row (`STF-01 −5 · STF-03 −3`). A `[ ]`, `rejected` or `suspect` line changes nothing.
+## Not decomposed
 
-An `accepted` line, and only an accepted line:
-1. removes its PD saved from the row's mid; low and high move proportionally
-2. sets the row's class to the line's class when one is stated
-3. resets the row's level to `detailed` (buffer 0%)
+**E-2** A scope item is *not decomposed* when its size is `XXL`, or — in the profile regime — its final Estimation figure (the architect's base `pd`, after the runtime applies overhead and a folded buffer — the only figure the working document stores) is above the profile's big calibration point (the wizard's XL anchor). It is flagged on the page, in section 2 and in the run report, and still exports with its estimate.
 
-A `.c` or `RC-n` clarification replaces the open assumption of its rows; the rows are re-estimated by the architect (re-spawn for those rows only), never adjusted by hand.
+## Totals
 
-## Folding
+**E-3** Section 2 totals by priority (the client's own priority values, verbatim) and by tab (`TABS`, one row per tab with items) always equal the sum of the section 4 Estimation cells; the runtime checks this on every `check` run and refuses to write section 2 otherwise.
 
-```
-mid'     = mid − Σ PD saved (accepted lines naming the row)
-PD final = mid' × (1 + buffer) × (1 + overhead_pct / 100)      → nearest 0.25
-```
+**E-4** A blocked scope item (`blocked CQ-n`) counts at its fallback option's estimate, marked as such in section 2's "Blocked (at fallback)" column. A scope item with no estimate yet (`queued`, `analysing`, `failed`) is counted in "Not estimated", never as `0`.
 
-- **Overhead** (PM + QA %) is folded into every row and stated once in §2. If the RFP asks for PM/QA as separate lines, set overhead 0 and add *Services* rows instead.
-- **Risk buffer** per profile: `folded` multiplies every row by `(1 + buffer_pct/100)` after the fold above; `separate` adds one line in §2 and leaves rows untouched. The fixed-price scope = the Must rows in PD, plus the separate buffer line when that mode is used.
-- **Foundation efforts** (theme base, integration framework, environments, migration tooling) are rows in their own right when the RFP has a row for them; otherwise they attach to the row the architect named and that row's Text says so.
-- **No money.** No cell, line or report figure carries a currency amount; nothing in the profile is a rate or a fee.
+**E-5** Every effort figure names its regime — section 2's `Regime:` line, the page, and the run report all state it; an item's Estimation cell format (T-shirt vs plain PD) already carries it.
 
-## Edition flip
+**E-6** The client's effort column in the export gets the PD number only — no size letter, no unit text.
 
-Rows whose class changes with the plan carry the architect's alternative (plan: class low/mid/high) in the §4 Evidence / risk cell. Until the plan is decided, §2 shows both variants and the plan choice is `Q-1`. On Community, rows that stock B2B Components would cover become `custom` and typically double.
+## Money
 
-## Non-development rows
+No amount, currency symbol or currency code appears in any file the tool writes, ever — that boundary is absolute, except section 1's Project information table, which keeps the client's or the operator's own figure verbatim (`project-information.md`), and a scope item's `cost:` reference, which carries a one-line cost consequence but no amount (`agent-briefs.md`). The words themselves (`price`, `cost`, `rate`, `fee`, `budget`, and their plurals) are narrower:
 
-- **Commitments** (process, contract, hosting recommendation, references): 0 PD, class `commitment`.
-- **Services** (training, documentation, test concept, pen-test coordination, go-live support, migration rehearsal): real PD, class `service`, shown as the *of which Services* line in §2.
+- **Allowed** in a `kb:`/`project:` reference when it is the Shopware feature, route or admin-surface name itself, quoted verbatim (e.g. a KB page literally titled "Customer-specific Prices").
+- **Allowed** in a Client Response when that item's own Requirement text uses the word — mirror the client's own wording back to them; never introduce the word where the client did not use it.
+- **Allowed** in a `cost:` reference — money words there are not the issue, an amount is; the amount check still applies to a `cost:` line.
+- **Otherwise paraphrase**: write "customer-specific pricing", "a configured amount", "the shop's payment methods" — the `-ing`/descriptive form, not the client's word repeated as if it were the tool's own.
+- Never an amount, a currency symbol (`EUR sign`, `dollar sign`, `pound sign`, `yen sign`) or an ISO code (`EUR`, `USD`, `GBP`, `CHF`), under any of the above, `cost:` included.
 
-## Sanity checks
-
-- The Must total is reported in PD and never compared with the client's stated budget. A partner who wants a lower Must total gets a `Q-n` with the routes in PD: further accepted lines, phasing Should/Could, or the full scope. Never lower a number to fit.
-- Sum per area first, then per priority, then the total; write the area subtotals in §2 and re-add once before writing.
-- A row whose high is more than 3× its low at `medium` level is a `CQ-n` candidate even without vague phrasing.
-- Rows estimated from `reuse` keep the source row's three-point unless the requirement text differs; then re-estimate.
+This applies to Client Response, Assumptions, References, proposals, item fields, section 1 prose, section 2 and section 8 Log, the run report, and a working-sheet export. The client's own verbatim Requirement text and cells, section 1's Project information table (its own verbatim-amounts rule above), section 3 Exclusions, section 6 Integrations and section 7 Glossary (client transcriptions, `sw-tender-editor`'s `context` job) are exempt from the whole rule — the client may state a budget figure; the tool never repeats it as a figure of its own. `check`'s money scan covers that tool-authored text for a currency symbol or an ISO currency code, and for a price/cost/rate/fee/budget word, applying the `kb:`/`project:`/`cost:` exemptions above and, for a proposal statement, the same Requirement-wording exemption as a Client Response; the amount check still applies everywhere, `cost:` included; it refuses with a reason on a match.
 
 ## Partner profile
 
-Path: `specs/rfp-partner-profile.md`. Read every run. Missing: write the template below with `_TBD_` everywhere and add a `high` `Q-n` asking for overhead, buffer and the platform preferences. `_TBD_` overhead or buffer means PD final is stated before both, said in §2, and caps *Estimate basis* at 70.
-
-```markdown
-# RFP partner profile
+`specs/rfp-partner-profile.md`, gitignored, YAML frontmatter:
 
-| | |
-| --- | --- |
-| **Partner** | <name> |
-| **Updated** | YYYY-MM-DD |
-
-Effort and platform defaults only. The partner converts PD to an offer outside the skill.
-
-## 1. Overhead
-- **PM + QA overhead:** <n>% <!-- combined, folded into every row -->
+```yaml
+calibration: { small: <PD>, big: <PD> }
+overhead: <percent>
+buffer: { percent: <percent>, mode: folded | separate }
+isv: [ { name: <name>, vendor: <vendor>, versions: <supported versions> } ]
+assets: [ { name: <name>, covers: <what>, pdSaved: <PD> } ]
+```
 
-## 2. Risk buffer
-- **Buffer:** <n>% · mode `folded` | `separate`
+Created and edited in a page wizard, offered when no profile exists, skippable. The wizard shows `calibration.small` with an XS anchor and `calibration.big` with an XL anchor, so both figures mean the same thing across operators. `isv[]` carries no licence field — the money rule is a hard boundary, not a simplification. Creating or changing the profile marks every scope item for re-estimate on the next run.
 
-## 3. Preferred platforms
-| Item | Preference | Note |
-| --- | --- | --- |
-| Shopware plan | <Rise · Evolve · Beyond, or "per RFP"> | |
-| Hosting | <provider> | <!-- region, managed / PaaS --> |
-| PSP | <provider> | |
-| CMP | <product> | |
-| Store plugins commonly used | <names> | |
-
-## 4. Compliance scale when the RFP has none
-`Stock | Config | Plugin | Custom | Not offered`
-
-## 5. Reusable assets
-| Asset | Covers | PD saved | Ownership / licence |
-| --- | --- | --- | --- |
-| <own plugin> | <rows/themes> | <n> | |
-
-## 6. Standard exclusions and delivery defaults
-- Warranty <n> months · maintenance offer <scope summary>
-- Always excluded: <list>
-
-## 7. Response language
-`auto` <!-- follows the RFP --> | en | de
-```
+Estimation formula the runtime applies (profile regime): `round0.25(pd x (1 + overhead/100) x (1 + buffer/100 if folded))`. Buffer mode `separate` states the buffer once in section 2 instead of folding it into each item.