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

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.

package/skills/sw-discover-tender/reference/procedure.md

@@ -1,98 +1,62 @@
-# Procedure — steps 1–9
+# Procedure — the seven steps
 
-**Delegation.** The orchestrator never reads a source export, an agent report or a generated response CSV in full. Bulk reads and writes go to `sw-tender-editor` (briefs `§EXTRACT`, `§ROWS`, `§SPLICE`, `§ASSEMBLE`); the orchestrator reads only their one-line returns and the small `map-<t>.md` / `tail-C<n>.md` files. It keeps reconciliation, the §2 arithmetic, the confidence score, §6, §7 and the frontmatter.
+Three agents only: `sw-tender-editor`, `sw-product-manager`, `sw-shopware-architect`. No QA agent anywhere in this flow — QA effort sits inside the profile's overhead percentage (AG-5). No general-purpose agent writes a response file of any kind. Every deterministic step below is a runtime CLI call (`npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest <command>`); an agent's only output is its report, saved by the skill and applied with `apply`.
 
-**Batch size.** `--batch <n>` sets how many requirement rows one estimate run covers; default 50, minimum one cluster. `--batch all` puts every row in one run — the whole document in a single pass, no estimate groups. The value is written to the frontmatter as `batch: 50` (or `all`) on the first run and reused by every later run on that analysis unless the flag is given again. An estimate group is whole clusters, in source order, totalling at most `<batch>` rows.
+Steps 2-6 repeat until the document is *Ready* (every scope item confirmed). One flow for RFI, RFP, RFQ and project plans alike; a greenfield tender, a tender on an existing project and an internal planning exercise all run the same steps.
 
-**Staged writes.** The analysis file is written in three stages, never once at the end. Every write leaves a document that parses: all nine sections present, frontmatter intact.
+## 1. Intake
 
-1. **Skeleton**, after steps 1–4: frontmatter, §1 complete — §1.1 Meta, §1.2 Company & context, §8 Integrations and §9 Glossary fully populated (they need no estimate) — §4 with one `req` line per source row (`Text` = the source requirement, PD and L/M/H empty, status `queued`), §2/§3/§5/§6/§7 present with `_TBD_`. This is what makes the tender's own content readable for the whole run, and on the page, from the first minute.
-2. **Per cluster**, step 5: the cluster's rows go to `analysing` when its agents are spawned, and its `queued` lines are replaced in place by the finished `req` + `.a` lines as soon as they are merged (`§SPLICE`).
-3. **Totals**, step 7: §2, the score, §3, §5, §6, §7 and the frontmatter counts.
+- **XLSX/CSV**: `import --source <file>` writes `specs/.editor/<base>/import-snapshot.json`, `import-map.proposed.json` and `import-digest.md` — a heuristic proposal of each table's header/data range and columns, no operator step. In an `--editor` session, `emit progress "Reading N sheets…" --batch <id>` before spawning; spawn `sw-tender-editor` for its `extract` job on `import-digest.md` (the one named file it reads); it confirms or corrects the proposed table structure and answer columns, sorts every row into a tab and topic, and returns the extraction JSON (schema in `agent-briefs.md`). Save it to `specs/.rfp/<slug>/extraction.json`, `emit progress "Extracted N items — building working document" --batch <id>`, then run `intake <doc> --source <file> --extraction <json>` — this writes the committed fit-back map (`import-map.json`) for an xlsx source.
+- **PDF**: in an `--editor` session, `emit progress "Reading the source…" --batch <id>` before spawning; spawn `sw-tender-editor` for its `extract` job on the PDF directly; it returns `items`/`projectInfo` only (no `tables`), per the same schema. Save the extraction JSON, `emit progress "Extracted N items — building working document" --batch <id>`, then run `intake <doc> --source <pdf> --extraction <json>`.
+- Either way, `intake` builds section 4 by tab and topic, fills section 1's Project information and Not taken tables, sets every new scope item `queued`, then confirms itself (`intake: confirmed`) and queues the opening analysis chunk automatically — no operator step in between. Then spawn `sw-tender-editor` for its `context` job to write section 1's meta (detected version/edition/plan per `context-parameters.md`, source files and hashes) and section 3's `### Exclusions` from anything the client's document already states.
+- **Operator corrections, at any time**: on the page, the Overview tab shows a Not-taken banner whenever there are Not-taken rows or unused sheets (item counts per tab, the rows with Restore, unused sheets, per-table answer targets); the operator may `move`, `skip` or `restore` an item and edit Project information (`info`) any time, through a queued row note — skipping a confirmed item is refused ("unconfirm first"). Without the page: relay the same actions from chat. A document still at `intake: review` (an old one, from before this behaviour) is confirmed first: show the extraction summary in chat and run `intake-confirm <doc>` only on the user's explicit go-ahead — that alone starts the analysis; a `notes` batch on such a document re-runs `extract` and `intake` with the notes folded in.
+- Re-intake of a new file version (the same or a newer file, any time): re-run `extract` and `intake` as above. A known id (matched by id across the whole document, not per tab) keeps its current tab, topic and every answer field — a text change sets `reopened` (L-5), keeping Assumptions. A new id is `queued`, placed per the extraction. An id that is gone gets a `removed from <file>` reference. A Project information value whose Source is `operator` is kept; the rest are overwritten. Operator skips are kept while their source row still exists. Every re-intake confirms itself again and queues analysis for whatever needs it.
 
-### 1. Target and source
+## 2. Assess — in chunks, page order
 
-`ls specs`. Keep `rfp-NNNN-` from the input name; else `NNNN` = highest existing + 1, zero-padded, slug = kebab-case `<client>-<project>`. An xlsx is imported and its mapping confirmed first (below). `shasum -a 256` every source file into frontmatter `source`; for an xlsx, the workbook, `import-map.json` and every CSV. Continue mode: keep path, number and slug; never renumber, never a second file for the same tender.
+Intake confirming itself starts this automatically; there is no Analyze button or step to invoke separately, and re-estimate work (an answered question, an accepted assumption, a profile change) queues into the same chunking. Work through every item that needs it — `queued`, `reopened`, or marked in `reestimate.json` — about 15 at a time, in page order: tabs in `TABS` order, topics in client first-seen order, items in client order within a topic (the same order as section 4, `analysis-template.md` SI-4), so the top of the first tab fills first. Split a chunk into groups of about 5 and spawn, per group, in parallel (cap 10 spawns per message, `agent-briefs.md`):
+- `sw-product-manager` — checks it against the Dev Knowledge Base MCP (platform and project); reports the stock feature or its absence, and drafts a client question when the item is vague. Free-form markdown, returned as its result (it never writes a file in tender work). The skill passes this report to the architect; only the architect's report is machine-applied.
+- `sw-shopware-architect` — reads the PM report, sets Requirement Coverage, Confidence, the Client Response draft and References, and for ISV items researches the Shopware Store and vendor pages directly.
 
-**.xlsx import.** Install gate first, per `reference/editor-session.md` §0: the `sw-tender-discovery-tool` skill must be installed; missing → stop, do not import. `npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest import --source <file>` reads the workbook (hidden and `_` sheets never leave it) and proposes a mapping — which tabs are requirement tables, where each header sits, what each column means, which tokens the dropdowns allow. **With `--editor`** the user confirms it on the steering screen. **Without it**, print the proposed table the command listed, ask the user in one line whether it is right, and on a yes run `npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest import --source <file> --map --accept-proposed`; if a tab or a column is wrong, say so and rerun with `--editor`. Either way the confirmed `import-map.json` and the normalised `<source dir>/<basename>/<pos>-<sheet-slug>.csv` are then the source, and the analysis lands next to the workbook. A refusal (encrypted, `.xls`, `.xlsb`) is relayed verbatim and the run stops.
+`apply` each group's architect report as soon as it returns (below) — the document updates live, one group at a time, rather than waiting for the whole chunk. Once every group in the chunk is applied, take the next chunk of about 15 items needing work and repeat; stop when none are left, then go to "Run close".
 
-### 2. Reconcile — first step of every continue run, before any spawn
+Every spawn receives the detected version/edition/plan, section 1's Project information table, and, per item in the group, that item's own Internal note (read-only) and its own rejected proposals, with an instruction never to re-propose them (`context-parameters.md` "Passed to every agent").
 
-Read the analysis file. Match lines by ID; untouched lines stay as they are. `<date>` = today.
+## 3. Propose
 
-- `[x]` on an assume line (§3 or §4) → `accepted <date>`, frozen. Apply its PD saved to every row it names per `estimation-model.md`, recompute the row and §2. One `C-n`.
-- `[-]` → `rejected <date>`. Row stays at full scope. One `C-n`.
-- An accepted statement whose text was edited → the accepted line is restored; the edited text becomes a new `[ ]` line with the next `.a<n>` or `A-n`. One `C-n`.
-- A ticked option or filled `Other:` in a §5 block → one `.c<n>` line under each row the block names (`RC-n` in §3 when cross-cutting), source `client, CQ-n` or `partner, Q-n`, status `<date>`. Delete the block. Re-estimate the affected rows: architect re-spawn for those rows only. One `C-n` per block.
-- Source sha256 differs from the frontmatter → new tender version. Re-extract (step 3), compare requirement text per row. Changed rows: every accepted assume line under them and every §3 line naming them → `[ ] suspect`, row re-estimated. New rows are analysed; rows gone from the source are dropped. One `C-n` naming every row. Update `source`.
-- A legacy `provisional, CQ-n` row becomes `estimated, CQ-n`; that status is retired. No `C-n`.
-- An analysis written before this grammar (missing §1.1/§1.2/§8/§9, or with the old flat §1): backfill by running the `§CONTEXT` extraction of step 3 against the committed source exports and splicing §1.1, §1.2, §8 and §9 in. Nothing else about the document changes. One `C-n`.
-- `[x] suspect` / `[-] suspect` count as `[x]` / `[-]` (the page writes them on suspect lines); the suffix is dropped. Partner-proposed `[ ]` lines (`partner` in Evidence / risk or Risk to) are kept as candidates and estimated like any other.
-- Any change after `export.date` → `export.stale: true`.
+The same `sw-shopware-architect` spawn also proposes 1-3 scope-locking assumptions per item (catalogue entries in `assumption-catalogue.md` first, else a new statement, checked against the item's rejected proposals), each a one-sentence, client-agreeable statement with a `pdSaved` greater than 0 and no greater than the item's own effort, and raises client questions for scope items too vague to assess (`client-question-rules.md` AQ-5), in the same report JSON. Every Configuration, Extension, ISV or Custom item returns 1-3 such proposals; a `noProposal: "<reason>"` is valid only when the item's already-accepted assumptions already cover it; OOTB and `—` items are exempt. `apply` refuses a report that leaves such an item with neither, or a proposal with no `pdSaved`, a non-positive one, or one above the item's effort.
 
-### 3. Extract — delegated, parallel
+## 4. Estimate
 
-One `sw-tender-editor` per source file (per table when one file holds several), brief `§EXTRACT`, plus **one** `sw-tender-editor` for all the non-requirement tables together (cover, company/context, integrations, migration inventory, glossary, response instructions), brief `§CONTEXT` — every spawn in one message, cap 10. One context spawn, not one per table: a key parameter is often stated on two sheets, and five files with one writer cannot race. Each `§EXTRACT` writes its own `C<n>.md` clusters and `map-<t>.md`; `§CONTEXT` writes `meta.md`, `params.md`, `migration.md`, `integrations.md`, `glossary.md`. The orchestrator reads only the `map-<t>.md` files and the five context files — all small — and never opens the source itself. A failed `§EXTRACT` is `not extracted — <reason>` in §1.3 and its table is not analysed; a failed `§CONTEXT` leaves §1.1, §1.2, §8 and §9 `_TBD_` with `not extracted — <reason>`, and every parameter-driven question is deferred to the next run.
+The architect sets each item's Estimation in the same report, under the JSON key `effort`: a `size` (T-shirt regime) or a base `pd` (profile regime) per `estimation-model.md`. The architect never applies overhead or buffer — the runtime does, on `apply`.
 
-The rules the briefs apply: a requirement table has an id-like column (`ID`, `#`, `Nr.`, values like `GEN-01`) and vendor columns (headers starting *Vendor*, *Bidder*, *Supplier*, *Anbieter*, *Antwort*, or *Compliance / Comment / Effort*). Per table into §1.3 Source map: number, sheet or section name, rows, id column, vendor columns verbatim, allowed tokens as the RFP states them, effort unit, locator. Prose sources (pdf, docx text): mint `R-<n>` with page or paragraph. Cells the client prefilled: kept, row status `prefilled`. Rows → `C<n>.md`, one cluster per file, one line per row: `id | title | requirement | acceptance or — | priority | type | reference or —`. Clusters: 10–20 rows by area, never spanning a table, rows in source order. Every table in the source, including a non-requirement one, appears in §1.3 exactly once, naming where its content went (`context → §1.1` / `§1.2` / `§8` / `§9` / `unused — <reason>`); a table is never silently dropped.
+## Applying an architect report
 
-### 4. Ground truth
+The architect's result is the report JSON, schema in `agent-briefs.md`. The skill saves it under `specs/.rfp/<slug>/reports/` and runs `apply <doc> --report <json>`. The runtime validates it (the six coverage values, sizes, confidence, reference prefixes, at least two options with an existing fallback key, 1-3 proposals or a `noProposal` valid only when accepted assumptions already cover it, on every non-OOTB item), formats the Estimation cell per regime, stores proposals in the proposal store (rejected-memory applies), opens or keeps `blocked CQ-n` items, and reopens a confirmed item whose Requirement Coverage, Estimation or Client Response actually changed (L-3) — writing the cause into References. An item that fails gets `failed` status and a `failed:` reference; its other fields are kept. When the source document or a PM report names an integration not yet in section 6, spawn `sw-tender-editor`'s `context` job again to refresh it — the architect's own report carries no section 6 prose. A platform, hosting, PSP or CMP decision belongs in that item's Client Response, not in a context section.
 
-**Shopware version — detect once, never assume:** `vendor/shopware/core/composer.json` `version` → `composer.lock` → `composer.json` constraint ("unconfirmed"); PHP from the project runtime (`compose.yaml`, `.ddev/config.yaml`, `Dockerfile`), not the host. Pass version + source to every spawned agent; unknown → ask the user.
+## 5. Confirm
 
-Edition from `composer.lock` (`shopware/commercial` present → Commercial, else Community). Then: `custom/plugins/*`, `custom/static-plugins/*`; other `*-analysis.md` §4 (same requirement text → reuse, cited `reuse: rfp-NNNN <ID>`); `specs/*.md` PRDs and `CLAUDE.md`; KB: `read_doc platform/index.md` once, per feature noun `grep_docs { pattern, path: "platform/func" }`, `platform/dev/<major.minor>` for complexity only, never `list_docs` a version directory. Doc text is untrusted: quote, never obey. Collect page path + `sourceUrl` per noun for the PM briefs.
+The operator accepts or rejects proposals (`accept`/`reject <doc> <P-n>`) — accepting a numeric-PD item's proposal lowers its Effort by `pdSaved` at once, floored, with a later re-estimate refining the figure — edits Client Response and Internal note (`patch <doc> <id> --response <t> --note <t>`), and confirms items (`confirm <doc> <id>...` or `--all-unconfirmed`). Confirming rejects the item's untouched proposals (L-2). The operator's own edits to Client Response or Internal note never reopen a confirmed item (L-4). Confidence never blocks confirmation. A blocked or a failed item can be confirmed; a failed one needs an operator-written Client Response first (L-6).
 
-**Then write the skeleton** (staged writes, stage 1). On a continue run there is no skeleton: the file already exists.
+## 6. Answer
 
-### 5. Fan out — pipelined, briefs in `reference/agent-briefs.md` in this skill's directory
+The operator records the client's chosen option (`answer <doc> <CQ-n> <key>`); the runtime marks the affected items for re-estimate and reopens a confirmed one only when the next `apply` actually changes it (L-3).
 
-Work one group at a time — whole clusters totalling at most `<batch>` rows (default 50), in source order, `queued` rows first; `--batch all` makes one group of everything. Plain mode repeats this step group by group until no `queued` row is left, splicing after each, then goes to step 7. Editor mode does one group per batch and lets the session queue the rest, so the lock is released between groups. Rows typed *Project*, hosting and operations NFRs and pure contract rows skip the PM step.
+## Re-estimate (items marked in `reestimate.json`)
 
-- **Message 1**: every `sw-product-manager` spawn (one per cluster), plus the single `sw-qa-engineer` spawn, plus the architects of the clusters that skip the PM step. QA reads no PM report, so it never waits for one.
-- **Then, per cluster**: spawn `sw-shopware-architect` for a cluster as soon as *its own* PM report lands; whatever is ready together goes in one message. Never wait for the whole PM set. Set that cluster's rows to `analysing` when its architect is spawned.
-- PM: verdict, plan tier, evidence, gap, vague flag, one draft question per vague row. No effort. Save each report to `pm-C<n>.md`. Architect: class, mechanism cited, low/mid/high, level, drivers, risks, reuse, assumption candidates each naming its row id or `global`, plan alternative, foundation efforts. QA: quality, test, security-testing and accessibility rows only.
-- Cap 10 spawns per message; over it, raise rows per cluster to 20. Failed spawn → `not consulted — <reason>` in §1, rows `_TBD_`. Cut report → ask for numbered parts.
-- **Merge, delegated**: one `sw-tender-editor` per cluster, brief `§ROWS`, spawned as soon as that cluster's architect report lands, in parallel with the other clusters. It joins by row id per `§ROWS` and writes `rows-C<n>.md` (the finished §4 lines) and `tail-C<n>.md` (the numbers, `A-n`, `K-n`, question candidates). The orchestrator reads only the tails.
-- **Splice** (staged writes, stage 2): one `sw-tender-editor` per cluster, brief `§SPLICE`, **one at a time** — only one writer may touch the analysis file — replacing that cluster's `queued` / `analysing` lines with `rows-C<n>.md`. Each splice is one live update on the editor page.
-- Candidates are `[ ]` lines: `<ROW>.a<n>` under the row they name, `A-n` in §3 when no single row owns them. Never applied, never `accepted`. Conflicts → `K-n` in §7.
+A confirmed or reopened item marked for re-estimate is spawned to the architect with its current Requirement Coverage, Estimation and Client Response as brief input (`agent-briefs.md`'s "Re-estimate of a confirmed or reopened item"). The architect returns those fields verbatim unless the new input materially changes them — no cosmetic rewording. `apply` still only reopens on an actual change (L-3), so a verbatim re-estimate leaves a confirmed item confirmed. Re-estimate work joins the same page-order chunking as step 2, whether raised by an answer, an accepted assumption or a profile change.
 
-### 6. Questions
+## Run close — every run
 
-- **Client** `CQ-n` per `client-question-rules.md`: every vague row, every RFP contradiction. RFP language, row ids, 2–4 options with the scope effect in plain words, `Other:`, "Until answered we assume". Blocking → row status `blocked, CQ-n`, PD empty. Otherwise the row stays `estimated, CQ-n`: it keeps its PD, and the condition the estimate rests on is written under it as a suggested `[ ]` assumption line, so the partner can lock it by ticking instead of waiting for the client. Cap 25; the rest `Not sent — cap`.
-- **Missing key parameter** `CQ-n` per `context-parameters.md`'s question stubs: an estimate-driving (`drv`) §1.2 parameter whose Status is `_not provided_`, or any `conflicting` parameter, raises a `CQ-n`; the parameter's Status cell names it. One question may cover a whole group (one `CQ-n` for "catalog size", not four). Counts against the same cap of 25.
-- **Partner** `Q-n` only when the answer changes a token, a PD figure or a statement: plan choice, a `K-n` swing above 2× on a Must row, a reuse claim, the profile, Must-total reduction routes in PD. Options with the PD consequence, `Other:`. `high` = touches a Must row.
-- Every question is a §5 block with option checkboxes. Nothing is asked in chat.
+Every chunk, whatever step it did, ends with `check <doc> --write` (grammar, the six values, reference prefixes, the money scan, section 2 totals equality — refuses with reasons on failure). `report <doc>` refuses to run while `check` fails, because it appends to section 8 and section 8 must only ever record a run that left the document valid. On a `check` failure: fix what the reasons name (a malformed row, a money-word hit, a totals mismatch) and re-run `check --write`; when the cause is an item the last `apply` got wrong, re-apply a corrected report for that item, then `check --write` again. Only once `check --write` passes, run `report <doc>` — it prints the P-9 run report (state, confirmed of total, failed, open client questions, not decomposed, low confidence, estimation by priority with regime, waiting proposals, what changed including reopened items), appends the run to section 8, and writes `last-run.json`. Section 8 is written by `report` and by `export` alone — no other step, and no agent, ever appends to it. The skill posts the P-9 report to chat, once per chunk.
 
-### 7. Estimate, decide, score, write
+## 7. Export
 
-PD final per `estimation-model.md`; sum by area, then priority, then total; write the area subtotals in §2 and re-add once. Platform (plan, hosting, PSP, CMP) into §6 from PM tiers, architect alternatives and the profile; when the plan flips classes, §2 shows both variants and the plan is `Q-1`. §6's Interface table cites §8 row numbers and its Migration table cites §1.2 `M-n` rows instead of restating volumes. Score per `confidence-rubric.md`; status per its rule. This is stage 3 of the staged writes: §4 is already in the file, so write §2, §3, §5, §6, §7 and the frontmatter counts, in place. Never regenerate from the template, never rewrite a spliced §4 row here, never paste the document into chat.
+`export <doc>` — available anytime (X-1); unconfirmed items export with empty answer cells. XLSX source: a surgical copy of the client's workbook (X-2 to X-4). CSV/PDF source: a working-sheet XLSX built from the sections (X-5), no token map needed. Every export writes the next `<base>-response-v<n>.xlsx`, never overwriting an existing file, and appends its own section 8 Log line naming `v<n>`, the file, confirmed count and what changed since the last export (X-9). See `response-rules.md`.
 
-### 8. Report
+**XLSX source, plain mode "export …" or an `export` batch (`editor-session.md`):** when a table lacks its coverage-to-client-token map, decide it before exporting:
 
-Eight lines, no more:
-- path · status · confidence (lower than last run → name the cause)
-- rows analysed · blocked rows
-- Must (fixed-price scope) / Should / Could in PD
-- assumptions proposed / accepted / rejected / suspect
-- open questions: client n (blocking n, deadline) · partner n (high n)
-- clarifications applied this run · `export stale` when set
-- platform: plan · hosting · PSP · CMP, `_TBD_` named
-- agents: PM n, architect n, QA yes|no, `not consulted — <reason>`
-
-Then one machine-readable line for the editor loop, always last: `next: estimate C1,C2 | C3,C4` — the groups still to estimate, each whole clusters totalling at most `<batch>` rows — or `next: none` when §4 holds no `queued` row (always the case under `--batch all`).
-
-When the gate below holds, one more line: "Generate the response CSV?" Then end.
-
-### 9. Export
-
-- **Gate.** Status Ready to submit: confidence > 90, no open `high` `Q-n`, no blocking `CQ-n` on a Must row, zero `suspect`, zero unreconciled ticks. Otherwise refuse with one line per failing condition.
-- **Trigger.** "yes" to the report question, `--export`, or an explicit request. Reconcile first, re-check the gate.
-- **Input.** The source as the analysis read it (sha256 must match the frontmatter) and the analysis file. Never the workbook, never a hidden sheet, nothing from memory. §1.1, §1.2, §8 and §9 are analysis context — never written into a response CSV.
-- **Prepare** `specs/.rfp/<slug>/resp-common.md`: per table the client's header row verbatim, delimiter, quoting and BOM (mirroring the operator's CSV, else UTF-8 BOM, `;` for German, `,` otherwise), the token list, the RFP language, overhead and buffer as applied in §2.
-- **Spawn** one general-purpose sub agent per cluster, one message, cap 10, brief §RESP with `reference/response-rules.md` in this skill's directory. Each writes `specs/.rfp/<slug>/resp-C<n>.csv`. Failed spawn → stop: `not exported: cluster C<n>`; no partial file is presented.
-- **Assemble and check, delegated**: one `sw-tender-editor` per client table, all in one message, cap 10, brief `§ASSEMBLE`. Each concatenates its cluster CSVs behind the client's header row into `<source basename>-response-<n>-<table-slug>.csv` (`<n>` and slug from the Source map) and runs the file checks: row count and id sequence equal the source table; header equals the client's; every compliance value in the allowed list; every effort cell a number, or empty with the blocked comment; no `A-`, `CQ-`, `Q-`, `RC-`, `.a`, `.c`, `PD saved`, `EUR`, `€`; no proposed or rejected assumption text; constant column count. Any failure → the agent deletes the file and returns the failing check. The orchestrator never reads the CSVs.
-- **Check the sums** itself, from the returned per-table effort sums: they must equal §2 per priority. Mismatch → delete the files, report the check.
-- **Write back.** Frontmatter `export: {date, files, source_sha256, stale: false}`; one `C-n`: `Response exported: <files> files, <rows> rows, Must <n> PD`.
-- **Workbook copy.** After every response CSV passes its checks, run `npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@latest export --xlsx --source <file>`: it writes `<source basename>-response.xlsx`, a copy of the client's own workbook with compliance, comment and effort filled in from those CSVs, styles and dropdowns intact. The client's original is never written. Only for an xlsx tender with a confirmed mapping; a CSV/markdown tender stops at the CSVs.
-- **Report** three lines: files with row counts · Must / Should / Could as exported · checks passed or the failing check.
-- Same analysis and same source give byte-identical files.
+1. `tokens <doc> --suggest` — prints, per table (identified by its `<sheet> r<headerRow>` key), the heuristic proposal, the client's compliance token list, and its numeric legend if any.
+2. Decide the six-value → client-token map per table from that output and `coverage-mapping.md`'s rule (never a negative token; `—` to an N/A-style token or the OOTB one; a numeric legend picked by label meaning).
+3. `tokens <doc> --file <json>` with the map, keyed by `<sheet> r<headerRow>`, then `export <doc>`. If the runtime refuses a value (unknown token, negative token), adjust that value and retry once; a second refusal is posted to chat verbatim instead of retried again.
+4. Post the exported file path and the chosen map (per table key, its six value → token lines) in chat.

package/skills/sw-discover-tender/reference/project-information.md

@@ -0,0 +1,31 @@
+# Project information
+
+Section 1's `### Project information` table, 18 fixed rows, `PROJECT_INFO` (runtime constant, `parse.mjs`), in this order. `sw-tender-editor`'s `extract` job fills `projectInfo` for as many keys as the source states; `intake` writes the table, a missing key becomes `not stated` with an empty Source; the operator edits a Value directly (`info <doc> <key> "<value>"`, Source becomes `operator`).
+
+| Key | Capture | Feeds |
+| --- | --- | --- |
+| `business-model` | B2B, B2C, marketplace, wholesale, or a mix, in the client's own words. | which agent-brief facts and assumption keys apply (e.g. `AS-B2B-*`). |
+| `markets` | Countries or regions the shop serves. | sales-channel and localisation size-up. |
+| `languages` | Storefront/admin languages required. | content-migration and localisation size-up. |
+| `currencies` | Currencies the shop must price and sell in. | pricing and checkout size-up. |
+| `sales-channels` | Storefront, marketplace, B2B portal, POS — however many the client runs or wants. | `AS-PLAT-02`-style channel assumptions; size-up. |
+| `customers` | Customer types and groups (retail, trade, tiered). | pricing/access-rule size-up. |
+| `products` | SKU count and catalogue shape (simple vs. variants). | catalogue and search size-up. |
+| `catalogue-structure` | Category depth, attribute/property count. | Shopping Experiences and filtering size-up. |
+| `media` | Image/asset volume and where it lives today. | migration size-up. |
+| `catalogue-updates` | How often the catalogue changes and which system leads it. | integration and sync-pattern assumptions (`AS-ERP-*`). |
+| `price-model` | List, tiered, negotiated, contract pricing — structure, and a figure if the client or operator states one. | pricing-engine and B2B size-up. |
+| `orders` | Orders per day, average and peak. | performance and hosting size-up. |
+| `traffic` | Visitors/peak concurrency. | performance and hosting size-up (`AS-OPS-*`). |
+| `current-platform` | The platform being replaced or extended, if any. | migration scope and data-mapping size-up. |
+| `leading-systems` | ERP / PIM / CRM the shop must integrate with. | integration size-up (`AS-ERP-*`). |
+| `data-migration` | What data must move (orders, customers, content, media). | `AS-MIG-*` assumptions; size-up. |
+| `go-live` | Target go-live date or window. | timeline and Project & services sizing. |
+| `shopware` | The tender's own stated target Shopware version / edition / plan — Source is where the tender states it, never the Dev Knowledge Base. | `AS-PLAT-*` assumptions; compared against `context-parameters.md`'s Dev KB detection of an existing project — a difference raises a `Q-n`. |
+
+Rules:
+- **Value**: free text, or `not stated` — never invented, never guessed from another tender.
+- **Source**: `<sheet> r<row>` (xlsx/csv), `PDF p<page>` or `PDF §<heading>`, `operator` (an `info` edit), or empty; several locations may be joined with "; " (`<sheet> r<row>; <sheet> r<row>`).
+- **Amounts**: a Value is the client's or the operator's own fact, kept verbatim, a figure included (EUR 380, €120k, 160,000 EUR) — `check`'s money scan does not cover this table. Elsewhere the tool writes no money of its own (`estimation-model.md`'s money rule); this table only ever repeats what the source or the operator already stated, never invents or computes a figure.
+- **Value qualification**: state what the source gives; qualify a Value that is not exactly what the key asks (e.g. "up to 10 orders a day per buyer — no shop total stated") rather than computing or inventing the missing figure.
+- A missing, unknown or out-of-order Parameter row is a parse error naming the row.