@execuro-sw-ecosystem/sw-ecosystem-agentic-harness 0.1.0

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

@@ -0,0 +1,135 @@
+# Agent briefs
+
+`<work>` = `specs/.rfp/<slug>/`. `<analysis>` = the analysis file.
+
+## Parallelism, caps, delivery
+
+- Pipeline, not two barriers. Message 1 carries every `sw-product-manager` spawn, PLUS the single `sw-qa-engineer` spawn (it reads no PM report), PLUS the `sw-shopware-architect` spawns for clusters that skip wave 1 entirely (Rows typed *Project*, hosting/operations NFRs, pure contract rows).
+- Each remaining `sw-shopware-architect` is spawned as soon as its OWN cluster's PM report lands — whatever is ready together goes in one message; never wait for the whole PM set to finish before spawning any architect.
+- One estimate group per run: whole clusters totalling at most `<batch>` rows (SKILL.md *Batch size*, default 50; `all` = every row in one run). The spawns below cover that group only.
+- Cap 10 spawns per message. Over the cap: raise rows per cluster to 20.
+- A failed or empty spawn is `not consulted — <reason>` in §1; its rows stay `_TBD_`. Never fill them from memory. A failed response or `sw-tender-editor` spawn stops the export.
+- Every brief carries the detected Shopware and PHP version **with evidence**, the edition, and the hidden-sheet prohibition.
+- **Delivery rule, in every brief.** Agents with a Write tool (`sw-shopware-architect`, `sw-qa-engineer`, the response agents, `sw-tender-editor`) write their report to the file(s) named in the brief and end their turn with one line (path + sum); those files are the only ones they may write. `sw-product-manager` has no Write tool: it delivers its report as its final message, in numbered parts under 7,000 characters each. A cut report is not a result: ask for the parts again.
+- `sw-tender-editor` delivery: one line back, listing only the file(s) its brief named — never the file's content, never a file it wasn't asked to write.
+- Save every PM report as received to `<work>/pm-C<n>.md`. Architect, QA and `§ROWS` briefs read files, never chat.
+- Shared material (baseline with evidence, plan variants, estimation-model excerpt, class definitions, report format, prohibitions) goes once into `<work>/arch-common.md`; each architect brief points at it plus its cluster file and PM report.
+- Rows are passed by file: `<work>/C<n>.md`, one line each: `<id> | <title> | <requirement> | <acceptance or —> | <priority> | <type> | <reference or —>`. Client context: `<work>/context.md`, `meta.md`, `params.md`, `migration.md`, `integrations.md`, `glossary.md` (`§CONTEXT`, spawned alongside `§EXTRACT`).
+
+## §EXTRACT — `sw-tender-editor`, per source file or table (step 3, before any spawn wave)
+
+> Extract requirement rows from tender source. Source `<file>`, table `<t>` (`<sheet or section name>`), `<client>`, RFP language `<en|de>`.
+>
+> Read only `<file>` (this table). Never open a hidden sheet, or any sheet, table or file whose name starts with `_` — for an xlsx tender they were never written to a CSV at all. When the tender has an `import-map.json` (an xlsx the user steered), that mapping is **authoritative**: it names this table's id column, its requirement and answer columns and the client's allowed tokens, all confirmed by a human — do not re-derive them. Without a mapping (csv, markdown, pdf), fall back to the heuristic: a requirement table has an id-like column (`ID`, `#`, `Nr.`, values like `GEN-01`) and vendor columns (headers starting *Vendor*, *Bidder*, *Supplier*, *Anbieter*, *Antwort*, or *Compliance / Comment / Effort*). Prose sources (pdf, docx text): mint `R-<n>` with page or paragraph.
+>
+> Write, disjoint from every other `§EXTRACT` spawn:
+> - `<work>/C<n>.md` per cluster (10–20 rows by area, never spanning a table, source order): one line each `<id> | <title> | <requirement> | <acceptance or —> | <priority> | <type> | <reference or —>`.
+> - `<work>/map-<t>.md`: this table's §1 Source-map row — number, sheet or section name, rows, id column, vendor columns verbatim, allowed tokens as the RFP states them, effort unit, locator — plus minted `R-<n>` ids, cells the client prefilled (kept, noted `prefilled`), hidden or `_`-prefixed sheets ignored by name, warnings (missing attachments, truncated text), and, for a non-requirement table, where its content went (`context → §1.1` / `§1.2` / `§8` / `§9` / `unused — <reason>`).
+> - `<work>/context-<t>.md`: context material this spawn happens to see in its own table (cover, profile, constraints, instructions, weights, glossary), or "none". Do **not** write `meta.md`, `params.md`, `migration.md`, `integrations.md` or `glossary.md` — `§CONTEXT` is their only writer, and a second writer loses rows. `§CONTEXT` reads these dumps.
+>
+> Never invent a row, an id or a token that is not in the source; a cell the source leaves blank stays blank, never `_TBD_` at this stage — that marking is the estimating agents' job.
+> Delivery: these files are the only ones this spawn may write. End the turn with one line: table #, row count, cluster files written, id column.
+
+## §CONTEXT — `sw-tender-editor`, once for every non-requirement table (step 3, same message as `§EXTRACT`)
+
+One spawn, not one per table. The context tables are small (a cover sheet, a profile, a register), and a single key parameter is often stated on two of them — the catalog size on the company sheet, the go-live date on the cover — so one agent has to see them all to fill `params.md` once. It is also the only way the five files have exactly one writer: parallel spawns appending to the same file race and lose rows.
+
+> Extract client context from tender source. Source files `<list>`, tables `<t1 …>` (`<sheet or section names>`), `<client>`, RFP language `<en|de>`.
+> Installed Shopware `<version>` (per `<evidence>`), PHP `<version>` (per `<evidence>`).
+>
+> Read only the tables named above (cover, company & context, integrations, migration inventory, glossary, response instructions; a prose tender: the whole document), plus any `<work>/context-<t>.md` dump that already exists — those spawns run beside this one, so read whatever is there and never wait for one. Every value you write comes from the source tables themselves; the dumps only save a second look. Never open a hidden sheet, or any sheet, table or file whose name starts with `_`. Do not read the requirement tables — `§EXTRACT` owns those — except to pick up an interface or a term they name.
+>
+> Write, and these five are the only files you may write, under `<work>`:
+> - `meta.md` — the §1.1 Meta field list (`analysis-template.md`), every field present, `_not provided_` when the source is silent, `Source` = source-map number + sheet + row label.
+> - `params.md` — every row P-01…P-50 of `context-parameters.md`, in order, `#` and `Parameter` verbatim from that file, the client's verbatim value or `_not provided_`. Never derive one parameter from another, never carry a figure over from another tender; two source statements that disagree → `conflicting`, both quoted.
+> - `migration.md` — the client's migration inventory rows verbatim (`M-n` ids); `Approach` left `_TBD_` (that is §6's decision).
+> - `integrations.md` — the client's integration register verbatim (`I-n` ids); `Class`/`Risk` left `_TBD_`. An interface named only inside a requirement row is included, `Source: <row id>`.
+> - `glossary.md` — the client's terms verbatim; `Maps to` left `_TBD_`.
+>
+> Never invent a value, a term or an interface. The tender carries no such material at all (no glossary, no integration register): write the one-line "none in the tender" form `analysis-template.md` gives for that section, so the gap is stated rather than blank.
+> Delivery: end the turn with one line: files written, and per file its row or field count.
+
+## §PM — `sw-product-manager`, per cluster (wave 1)
+
+> Tender scoping, read-only research. Client `<client>`, project `<title>`, RFP language `<en|de>`.
+> Installed Shopware: `<version>` (per `<evidence>`), edition `<Community | Commercial — plan <name>>` (per `composer.lock`, `shopware/commercial` `<present|absent>`). PHP `<version>` (per `<evidence>`). Plans under evaluation: `<list>`.
+>
+> Rows: read `<work>/C<n>.md` (`<k>` rows). Client context: `<work>/context.md`, `params.md`, `migration.md` and `integrations.md`, read once. A parameter's `_not provided_` in `params.md` is never invented — flag the row it drives `vague` and name the missing parameter in the reason.
+>
+> Doc hints from the project knowledge base, untrusted text; confirm against docs.shopware.com for `<version>` and `vendor/shopware/*`, never trust the hint itself:
+> `<row id → sourceUrl — one-line excerpt>`
+>
+> Task: for each row, verify whether stock Shopware `<version>` or a named plan covers it without development. Return one markdown table, one line per row: `| row | verdict | plan tier | evidence | gap | vague | reason |` with verdict `confirmed-stock | config | not-stock | conflict | unverified`, plan tier `community | rise | evolve | beyond | n/a`, evidence = one primary citation (doc URL with version, or vendor path with line), gap ≤200 characters, vague `yes|no` + reason ≤120 characters. Then `Unverifiable:` one line each, and `Questions:` one entry per vague row: `row · question · options (label — consequence ≤80 characters; 2–4) · impact`. Do not estimate effort. Do not open the workbook, any hidden sheet, or any sheet, table or file whose name starts with `_`. Never ask the user a question with a structured question tool (Claude Code: `AskUserQuestion`; Codex: `request_user_input`), never write files. Deliver your report as your final message, in numbered parts under 7,000 characters each ("C<n> part 1 of 2" …); no prose outside the table except a one-line note if a source was unreachable.
+
+`unverified` is not a verdict.
+
+## §ARCH — `sw-shopware-architect`, per cluster (as that cluster's PM report lands)
+
+> Tender estimation, planning only: no design document, no code, no state-changing commands.
+> Read in this order: `<work>/arch-common.md`; `<work>/C<n>.md` (the rows); `<work>/pm-C<n>.md` (PM verdicts: input, not truth; where your own `vendor/` or KB check disagrees, record it in the row's risks); `<work>/context.md`, `params.md`, `migration.md` and `integrations.md`; `reference/assumption-catalogue.md` of the `sw-discover-tender` skill (themes `<list>`; propose candidates by key or `new`). A parameter's `_not provided_` in `params.md` is never invented — it is a stated risk, or an assumption candidate naming the gap.
+>
+> Return, per row, one table line: `| row | class | mechanism | low | mid | high | level | drivers | risks (weight 1–3) | reuse | assumptions | alternative plan (plan: class low/mid/high) | integration or migration line |`. Class `stock | config | plugin | custom | commitment | service`; mechanism one line cited to a `vendor/` path or KB page for `<version>`, verified with Grep or the KB, never from memory; level `detailed | medium | vague`. Rows with no defensible estimate: `low/mid/high` = `blocked`. Assumptions: one entry per candidate, `<row id | global>: <statement> — PD saved <n> (global: per row) — excludes <what> — risk to <who>, weight 1–3 — class if accepted`. Then `Foundation:` name — PD — attach to row (one line each), and `Open questions:` only what the client or the partner can answer. Do not fold overhead or buffer into your numbers. PD only, never a currency amount. Do not double count with other clusters: `<named overlaps>`.
+>
+> Delivery: WRITE the report to `<work>/arch-C<n>.md` (the only file you may write), under 12,000 characters. End your turn with one line: the path and the sum of mid PD. Do not paste the report into your final message. Do not open the workbook, any hidden sheet, or any sheet, table or file whose name starts with `_`.
+
+Re-estimate after a clarification or a source change: same brief, `<work>/C<n>.md` replaced by the affected rows and their `.c` lines, report to `<work>/arch-C<n>-r<k>.md`.
+
+## §QA — `sw-qa-engineer`, once (in message 1, with the PM spawns)
+
+> Planning only: no commands, no tests written, no files except the one named below.
+> Installed Shopware `<version>` (per `<evidence>`), PHP `<version>` (per `<evidence>`). Read `<work>/arch-common.md` and `<work>/context.md`, then these rows from the cluster files: `<quality, test concept, load and performance testing, security testing, accessibility testing rows>`. Partner QA overhead in the profile: `<n>%`.
+> Return: a test-concept outline in ≤15 lines; per row one table line `| row | class (service | commitment | custom) | mechanism (tooling) | low | mid | high | drivers |`; one line stating whether `<n>%` QA overhead is plausible for `<total dev PD>` and why; `Risks:` with weight 1–3. PD only, never a currency amount.
+> Delivery: WRITE to `<work>/qa.md` (the only file you may write), under 6,000 characters; end your turn with one line (path + mid-PD sum). Do not open any hidden sheet, or any sheet, table or file whose name starts with `_`.
+
+## §ROWS — `sw-tender-editor`, per cluster (as that cluster's architect report lands, parallel)
+
+> Join cluster C<n> into finished §4 row blocks. `<analysis>` grammar: `analysis-template.md`.
+>
+> Read only: `<work>/C<n>.md`, `<work>/pm-C<n>.md`, `<work>/arch-C<n>.md`, `<work>/qa.md` (only when it holds rows of this cluster), `reference/estimation-model.md` and `reference/assumption-catalogue.md`, both in this skill's directory.
+>
+> Join rules (same rules as the former §MERGE, now executed here):
+> - Join by row id. Class from the PM verdict unless the architect cites a concrete gap with a mechanism; PD from the architect (QA for its rows). Foundation PD is added to the row it attaches to, on low, mid and high alike, and named in that row's Text.
+> - `vague` = PM vague OR architect level `vague`.
+> - `unverified` → evidence `unverified`; class from the architect's mechanism.
+> - PM stock/config vs architect custom (or the reverse) → `K-n` with the resolution; a swing above 2× on a Must row → `Q-n`. Plugin vs config is not a conflict.
+> - Architect open questions only the client can answer → `CQ-n` candidates; only the partner → `Q-n` candidates; anything else is dropped.
+> - Assumption candidates: de-duplicate by statement; a candidate naming one row becomes `<ROW>.a<n>` under that row; a candidate naming several rows or `global` becomes `A-n` with PD saved per row. Every line is written as `[ ]` with its PD saved, risk to and class-if-accepted. Nothing is applied.
+>
+> Write, in analysis-template grammar exactly:
+> - `<work>/rows-C<n>.md`: the finished §4 lines for this cluster's rows — each `req` line plus its `.a` lines, ready to splice verbatim.
+> - `<work>/tail-C<n>.md`: at most 25 lines — PD by area and by priority for this cluster, `A-n` candidates, `K-n` conflicts, CQ/Q candidates. The orchestrator reads only this file, never `pm-C<n>.md` or `arch-C<n>.md` directly, so keep it complete.
+>
+> Delivery: these two files are the only ones this spawn may write. End the turn with one line: both paths, row count, mid-PD sum.
+
+## §SPLICE — `sw-tender-editor`, per cluster (sequential)
+
+> Splice cluster C<n>'s finished rows into `<analysis>` §4. Run these spawns one at a time — only one writer may touch the analysis file at once; the page watcher re-renders on every write.
+>
+> Read `<work>/rows-C<n>.md` and the current `<analysis>`. By Edit, replace this cluster's rows in §4 — the lines whose status is `queued` or `analysing` for the ids listed — with the content of `<work>/rows-C<n>.md`, in place.
+>
+> Never touch: any other cluster's rows, any other section, the frontmatter, a frozen `accepted`/`rejected` line, a `[x]`/`[-]` a human wrote, or a `[ ]` line marked `partner`. §1.1, §1.2, §8 and §9 are never touched by this brief and must survive byte-identical. After the write, all nine sections of the analysis file must remain present and parseable.
+>
+> Delivery: `<analysis>` is the only file this spawn may write. End the turn with one line: rows spliced.
+
+## §MERGE
+
+Retired — the join rules formerly here are now executed by `§ROWS`, one spawn per cluster, writing directly to `<work>/rows-C<n>.md` and `<work>/tail-C<n>.md`.
+
+## §RESP — general-purpose agent, per cluster (export)
+
+> Response CSV for cluster C<n> of `<rfp>`. Read `reference/response-rules.md` of the `sw-discover-tender` skill first, then `<work>/resp-common.md` (client header row verbatim, delimiter, quoting, BOM, allowed compliance tokens, RFP language, overhead and buffer as applied), `<work>/C<n>.md` (source rows in order), and in `<analysis>` the §4 lines of those rows and the §3 lines naming them. §1.1, §1.2, §8 and §9 are analysis context, never a response table — do not read them for this file. Context cells come from the source export `<source path>` (the file the analysis read, never the workbook), copied unchanged.
+> Write `<work>/resp-C<n>.csv`: no header, one line per source row in source order, every client column; context cells unchanged; compliance, comment and effort per the rules; every other vendor cell empty. Only `accepted` assumption lines and `.c` / `RC-n` clarifications may appear in a comment, in plain words, no ids. Never open the workbook, a hidden sheet or a `_`-prefixed file; never invent a token or a figure; never a currency amount.
+> Delivery: that file is the only one you may write. End your turn with one line: path + row count.
+
+## §ASSEMBLE — `sw-tender-editor`, per client table (export, after §RESP)
+
+> Assemble and check the final response CSV for table `<n>` (`<table-slug>`) of `<rfp>`. Run after every `§RESP` spawn for this table's clusters has returned.
+>
+> Read `<work>/resp-common.md` (client header row verbatim, delimiter, quoting, BOM, allowed compliance tokens) and each `<work>/resp-C<n>.csv` for this table, in source order.
+>
+> Write `<source basename>-response-<n>-<table-slug>.csv`: the client's header row verbatim, then this table's cluster CSVs concatenated in source order, no blank lines, no totals row.
+>
+> Then check the file just written: row count and id sequence equal the source table; header equals the client's; every compliance value in the allowed list; every effort cell numeric or empty with the blocked comment; no `A-`, `CQ-`, `Q-`, `RC-`, `.a`, `.c`, `PD saved`, `EUR`, `€`; no proposed or rejected assumption text; constant column count across every row; no §1.1, §1.2, §8 or §9 content — they are analysis context, never a response table. (The effort-sums-equal-§2 check stays with the orchestrator, which holds §2.)
+>
+> Any check failing → delete the file, do not leave a partial one.
+> Delivery: that file is the only one you may write (and delete, on a failed check). End your turn with one line: path · rows · effort sum per priority (Must / Should / Could) · pass — or, on failure, the single failing check.

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

@@ -0,0 +1,224 @@
+# Analysis template
+
+Copy verbatim, fill, delete every `<!-- -->` hint. The document is written in stages (SKILL.md *Staged writes*): the first write carries §1 complete — including §1.1 Meta, §1.2 Company & context, §8 Integrations and §9 Glossary, which need no estimate — plus every source row as a `queued` `req` line, with §2/§3/§5/§6/§7 `_TBD_`. Every later write must leave all nine sections and the four §1 subsections in place and parseable — a live page re-renders on each one. Section numbers, subsection numbers and titles are fixed; the rubric, reconciliation, the editor's tabs and the export key off them. Unknown content stays `_TBD_`; a parameter the tender does not state is `_not provided_`; an empty section is a signal, an invented one is a defect. Every assumption line is written as `[ ]`.
+
+The nine sections mirror the client's own document where it has one: §1.1 Meta and §1.2 Company & context, §4 grouped by source table, §8 Integrations and §9 Glossary are the tender's material; §2, §3, §5, §6 and §7 are ours.
+
+---
+
+```markdown
+---
+rfp: RFP-NNNN
+kind: rfp                      # rfp | rfi | rfq
+client: <name>
+source:
+  - {file: <name as given>, size: <bytes>, sha256: <hex>}
+shopware: <version> <edition> (<evidence>); PHP <version> (<evidence>)
+status: Draft                  # Draft | Review | Ready to submit
+batch: 50                      # requirement rows per estimate run; all = one run for the whole document
+confidence: 0
+updated: YYYY-MM-DD
+counts:
+  rows: 0
+  assumptions: {proposed: 0, accepted: 0, rejected: 0, suspect: 0}
+  questions: {client: 0, blocking: 0, partner: 0, high: 0}
+  clarifications: 0
+export: {date: null, files: [], source_sha256: null, stale: false}
+---
+
+# RFP-NNNN — <Client> — <Project>
+
+## 1. Context
+
+### 1.1 Meta
+
+Every field below is present. The tender is silent: `_not provided_`. Values are the client's words, dates as the client wrote them (their time zone kept).
+
+| Field | Value | Source |
+| --- | --- | --- |
+| RFP reference | <!-- HIB-RFP-2026-03 --> | <!-- 1 Cover · RFP reference --> |
+| Kind | <!-- rfp / rfi / rfq, as the document calls itself --> | |
+| Issuing company | | |
+| Address | | |
+| Contact | <!-- name, role, address as given --> | |
+| Technical contact | | |
+| Date of issue | | |
+| Questions until | <!-- with the answer-distribution rule if stated --> | |
+| Proposal due | | |
+| Vendor presentations | | |
+| Contract award | | |
+| Kickoff | | |
+| Go-live | <!-- and whether it is fixed or a target, if stated --> | |
+| Response instructions | <!-- which columns to fill, which documents to submit, page limits --> | |
+| Compliance tokens | <!-- the client's own token list verbatim, or "none stated; scale: …" --> | |
+| Effort unit | <!-- PD / hours / none stated --> | |
+| Evaluation weights | | |
+| Deliverables | | |
+| Confidentiality | | |
+| Attachments | <!-- listed by name; note which are referenced but not supplied --> | |
+| Out of scope per RFP | <!-- the client's own exclusions; each also an X-n in §3 --> | |
+| Budget as stated | <!-- verbatim, or "none stated". Context only: never compared, never priced --> | |
+
+### 1.2 Company & context
+
+**Profile.** <!-- business, customers, markets, sales organisation — the client's own summary in two or three lines -->
+
+**Current landscape.** <!-- shop platform and version, ERP, other systems, today's integration — one line each -->
+
+**Pain points and goals.** <!-- what the client says is broken, and the goals/KPIs they state -->
+
+**Constraints.** <!-- what the client fixes: leading system, who designs, cutover model, out of scope. Budget stays in §1.1 -->
+
+**Key parameters.** The fixed template is `reference/context-parameters.md` in this skill's directory: every row P-01…P-50 is present, in order, whether or not the tender states it. Never derived from another row, never carried over from another tender.
+
+| # | Parameter | Value | Source | Drives | Status |
+| --- | --- | --- | --- | --- | --- |
+| P-01 | Sellable SKUs / variants | <!-- 25,000 --> | <!-- 2 Company & Context · Volumes/Products --> | import, indexing, migration, search | stated |
+| P-12 | Customer-specific price rows | _not provided_ | — | price sync volume, performance | _not provided_ ⚠ CQ-7 |
+
+**Migration inventory.** The client's own inventory, verbatim; the approach column is ours. Volumes live here and are cited, never restated, by §6.
+
+| # | Object | Source | Volume | Must migrate | Approach | Rows | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| M-1 | <!-- products and variants --> | <!-- SW5 database + ERP --> | <!-- 25,000 SKUs / 6,000 parents --> | <!-- Yes / No / Partly / Should, client's word --> | <!-- ours, one line; "_TBD_" until §6 decides --> | <!-- MIG-01, INT-01 --> | |
+
+No inventory in the tender: one line `No migration inventory in the tender` and, when the tender asks for a migration at all, a `CQ-n` per P-44.
+
+### 1.3 Source map
+
+| # | Table (sheet / section) | Rows | Id column | Vendor columns (client's words) | Tokens | Effort unit | Locator |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 2 | <!-- 2 Requirements --> | <!-- 91 --> | ID | <!-- every vendor column verbatim; cost columns listed, never filled --> | <!-- Stock, Config, Plugin, Custom, Not offered — or "none stated; scale: …" --> | PD | <!-- rows 2–92 / page 4–9 --> |
+
+Every table in the source appears here exactly once, including the ones that carry no requirement row: its `Rows` count stands, its Id column is `—`, and its Vendor columns cell says where its content went — `context → §1.1`, `context → §1.2`, `context → §8`, `context → §9`, or `unused — <reason>`. A table is never silently dropped.
+
+Minted IDs: <!-- R-1..R-n for prose sources with page or paragraph, or "none" --> · Prefilled vendor cells: <!-- none | rows … (kept) --> · Ignored: <!-- hidden or _-prefixed sheets by name, or "none" --> · Warnings: <!-- missing attachments, truncated text, or "none" -->
+
+### 1.4 Ground truth
+
+Shopware <!-- version, edition, evidence --> · Project plugins <!-- name: covers, or "none" --> · Partner assets <!-- from the profile, or "none" --> · Prior analyses reused <!-- rfp-NNNN <ID> → row, or "none" --> · KB pages <!-- one line --> · Agents <!-- PM clusters …; architect clusters …; QA yes|no; not consulted — <reason> -->
+
+## 2. Summary
+
+| Scope | PD |
+| --- | --- |
+| Must (fixed-price scope) | |
+| Should | |
+| Could | |
+| of which Services | |
+| **Total** | |
+
+By area: <!-- area: PD, … — must add up to the priority totals --> · Foundation efforts: <!-- name → row (PD) --> · Overhead / buffer: <!-- n% folded · buffer n% separate · level buffers 0/10/25%, or "_TBD_ — PD stated before overhead and buffer" --> · Plan variants: <!-- Evolve: Must n · Community: Must n, or "single variant" --> · Blocking rows: <!-- ids, or "none" -->
+
+| Dimension | Weight | Score | Points |
+| --- | --- | --- | --- |
+| Coverage evidence | 20 | 0 | 0.0 |
+| Estimate basis | 20 | 0 | 0.0 |
+| Scope lock | 20 | 0 | 0.0 |
+| Platform decision | 15 | 0 | 0.0 |
+| Integration & migration | 15 | 0 | 0.0 |
+| Consistency | 10 | 0 | 0.0 |
+| **Total** | **100** | | **0%** |
+
+Weakest dimension: <!-- name — what raises it; every status blocker by id -->
+
+## 3. Global assumptions
+
+Lines no single row owns. Same status grammar as §4.
+
+| ID | Kind | Rows | Statement | PD saved | Risk to | Status |
+| --- | --- | --- | --- | --- | --- | --- |
+| A-1 | assume | <!-- GEN-06, STF-01..STF-10 --> | <!-- rewritten for this tender --> | <!-- per row: STF-01 −5 · STF-03 −3 --> | client | [ ] |
+| X-1 | exclude | <!-- GEN-04 --> | <!-- what the RFP itself excludes, restated --> | | | rfp |
+| RC-1 | clarify | <!-- rows --> | <!-- decision --> | | client, CQ-5 | YYYY-MM-DD |
+
+## 4. Requirement analysis
+
+| ID | Kind | Prio | Class | L/M/H | Lvl | PD | Text | Evidence / risk | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| STF-03 | req | Must | custom | 12/16/22 | vague | 17.5 | <!-- mechanism, one line; "Includes foundation: <name> (n PD)" --> | <!-- pm: not-stock (…); arch: vendor path / KB page; unverified; reuse: rfp-NNNN ID --> | estimated, CQ-3 |
+| STF-03.a1 | assume | | | | | −5 | <!-- statement --> | risk to client | [ ] |
+| STF-03.a2 | assume | | config | | | −2 | <!-- statement --> | risk to client | accepted YYYY-MM-DD |
+| STF-03.c1 | clarify | | | | | | <!-- decision --> | client, CQ-3 | YYYY-MM-DD |
+
+Kinds: `req` one per source row · `assume` `<ROW>.a<n>` · `clarify` `<ROW>.c<n>`. Req status: `queued` (extracted, not yet estimated — PD and L/M/H empty) · `analysing` (its agents are running) · `estimated` · `estimated, CQ-n` (estimated, with an open question named; the estimate's condition is a `[ ]` assumption line under the row) · `blocked, CQ-n` or `blocked, Q-n` (PD empty; a partner question blocks the same way) · `prefilled`. There is no `provisional` status: a row is either estimated — under stated assumptions and, where needed, an open question — or blocked. A finished run leaves no `queued` or `analysing` row. Assume status: `[ ]` · `[x]` · `[-]` · `accepted YYYY-MM-DD` · `rejected YYYY-MM-DD` · `[ ] suspect`. Class on an assume line = the class the row takes once accepted. Lvl `detailed | medium | vague`.
+
+## 5. Open questions
+
+### CQ-1 · <!-- rows --> · blocking: <!-- yes | no -->
+<!-- question, RFP language, one decision -->
+- [ ] A — <!-- option: effect on scope in plain words -->
+- [ ] B — <!-- option -->
+- [ ] Other:
+Until answered we assume <!-- option, or "no effort stated" -->.
+
+### Q-1 · <!-- high | medium | low --> · <!-- rows or § -->
+<!-- question the partner can answer -->
+- [ ] A — <!-- option (recommended): consequence in PD -->
+- [ ] B — <!-- option -->
+- [ ] Other:
+Until answered we assume <!-- option -->.
+
+Not sent — cap: <!-- row ids, or "none" -->
+
+## 6. Approach
+
+| Item | Decision | Reason (rows served, source) | Alternative · PD delta |
+| --- | --- | --- | --- |
+| Plan | <!-- Community / Rise / Evolve / Beyond --> | | <!-- Community: +n PD --> |
+| Hosting | | | |
+| PSP | | | |
+| CMP | | | |
+
+| Interface | Pattern | Owner split | Risk |
+| --- | --- | --- | --- |
+| <!-- ERP → shop master data --> | <!-- queue consumers, idempotent upserts --> | <!-- bidder: shop side; ERP partner: API pages --> | <!-- one line --> |
+
+| Migration object | Approach | Volume | Tool | Reuse |
+| --- | --- | --- | --- | --- |
+| <!-- products --> | | | | |
+
+## 7. Log
+
+Append-only. Never a transcript.
+
+| ID | Date | Topic | Decision |
+| --- | --- | --- | --- |
+| C-1 | YYYY-MM-DD | <!-- accepted / rejected / answered / suspect / exported / partner decision --> | <!-- one line, ids named --> |
+| K-1 | YYYY-MM-DD | <!-- PM vs architect on B2B-03 --> | <!-- resolved: … / → Q-n --> |
+
+## 8. Integrations
+
+The client's integration register, verbatim; `Class` and `Risk` are ours. One line per interface the tender names, in source order. §6's Interface table decides the pattern and the owner split and cites these numbers instead of repeating them.
+
+| # | System | Direction | Objects | Frequency | Protocol | Counterpart owner | Rows | Class | Risk |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| I-1 | <!-- Microsoft Dynamics 365 Business Central --> | <!-- ERP → shop, client's arrow kept --> | <!-- products, prices, stock --> | <!-- nightly full, 15-min delta --> | <!-- OData v4 REST --> | <!-- client's ERP partner --> | <!-- INT-01, CAT-01..CAT-10 --> | <!-- stock / config / plugin / custom / service, or _TBD_ before the estimate --> | <!-- one line, or "—" --> |
+
+No integration table in the tender: one line `No integration register in the tender`, and every interface named inside a requirement row still gets a line here, `Source: <row id>` in Notes-position of the `#` cell. This section is never exported; it is not a response table.
+
+## 9. Glossary
+
+The client's terms, verbatim, in the client's order. `Maps to` is ours: the Shopware or partner vocabulary the term corresponds to, and the row ids that use it — this is the mapping the Tender Discovery Tool shows on the requirement rows.
+
+| Term | Meaning | Maps to |
+| --- | --- | --- |
+| <!-- PU / Packaging unit --> | <!-- the client's definition, verbatim --> | <!-- purchase unit / `purchaseUnit`, `referenceUnit` · CAT-07, CHK-02 --> |
+
+A term the client defines but nothing in Shopware matches: `Maps to` = `no equivalent — <one line>`. A term we cannot map yet: `_TBD_`. Never invent a definition, never correct the client's. No glossary in the tender: one line `No glossary in the tender`. This section is never exported; it is not a response table.
+```
+
+---
+
+Status grammar:
+
+```
+[ ]  proposed  --human--> [x] | [-]  --next run--> accepted YYYY-MM-DD (frozen, PD applied, row recomputed, C-n)
+                                                   rejected YYYY-MM-DD (row at full scope, C-n)
+source sha256 changed   --next run-->  affected accepted lines become [ ] suspect (C-n)
+question option ticked  --next run-->  .c line under each row named, or RC-n in §3; the block dissolves (C-n)
+```
+
+Every source row has one `req` line; none is dropped to shorten the file. A `_TBD_` cell is a truthful gap; a guessed one reaches the client as a wrong number. `_not provided_` in §1.2 is the same promise about the tender: it says the client never stated the figure, not that the figure is zero or unknown to us.
+
+Export (SKILL.md step 9) reads §1.3, §2 and §4 only. §1.1, §1.2, §8 and §9 are analysis context and are never written into a response CSV.

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

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

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

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

package/skills/sw-discover-tender/reference/confidence-rubric.md

@@ -0,0 +1,80 @@
+# Confidence rubric
+
+Score each dimension 0–100 against its bands, multiply by weight, sum, round to a whole percent. `points = score × weight / 100`. Score the document as written; a verdict given in chat does not count.
+
+## Coverage evidence — weight 20
+
+| Score | Band |
+| --- | --- |
+| 100 | Every Must `req` line's class rests on a PM verdict or a mechanism cited to `vendor/` or a KB page; ≤5% of rows `unverified` |
+| 70 | ≤15% `unverified`; Should/Could rows partly evidenced |
+| 40 | The PM wave was partly not consulted, or >15% `unverified` |
+| 0 | Classes set from memory |
+
+## Estimate basis — weight 20
+
+| Score | Band |
+| --- | --- |
+| 100 | Every estimated row has low/mid/high, a level and drivers; foundation efforts attached to named rows |
+| 70 | ≤10% of estimated rows lack a three-point |
+| 40 | The architect was not consulted for at least one cluster |
+| 0 | PD figures without agent input |
+
+## Scope lock — weight 20
+
+Counts `accepted` lines only. `[ ]`, an unreconciled `[x]`, `rejected` and `suspect` count as nothing.
+
+| Score | Band |
+| --- | --- |
+| 100 | ≥80% of Must PD sits on rows that are `detailed` or covered by an accepted line; every vague Must row has a `CQ-n` |
+| 70 | 60–80% of Must PD locked; every vague Must row has a `CQ-n` |
+| 40 | <60% locked, or a vague Must row without a `CQ-n` |
+| 0 | No accepted line and no client question |
+
+## Platform decision — weight 15
+
+| Score | Band |
+| --- | --- |
+| 100 | Plan, hosting, PSP and CMP decided in §6, each with a reason naming the rows it serves and a source (profile, PM tier, architect alternative); the plan's PD delta stated |
+| 70 | One §6 platform item `_TBD_` or open in a `Q-n` |
+| 40 | Two or more `_TBD_` or open, or the plan undecided |
+| 0 | Profile missing, or the §6 platform table empty |
+
+## Integration & migration — weight 15
+
+| Score | Band |
+| --- | --- |
+| 100 | Every interface and migration object the RFP names is in §6 with pattern and owner split; §8 and §1.2 are complete for every estimate-driving parameter and migration volume |
+| 70 | Main interfaces covered; secondary ones or the owner split missing; §8/§1.2 mostly complete |
+| 40 | Approach lines missing for named interfaces, or an estimate-driving §1.2 parameter or a §1.2 migration volume is missing without a `CQ-n` |
+| 0 | §6 interface and migration tables `_TBD_` |
+
+## Consistency — weight 10
+
+| Score | Band |
+| --- | --- |
+| 100 | All probes run (plugins, prior analyses, PRDs, partner assets, RFP-internal); every conflict resolved or logged as `K-n` in §7 |
+| 70 | Probes run; a `K-n` unresolved |
+| 40 | Probes run only partially |
+| 0 | A known conflict unrecorded |
+
+## Status
+
+| Confidence | Open `high` `Q-n` | Blocking `CQ-n` on a Must row | `suspect` lines | Unreconciled ticks | Status |
+| --- | --- | --- | --- | --- | --- |
+| > 90 | none | none | none | none | **Ready to submit** |
+| > 90 | any of the four present | | | | **Review** |
+| 80–90 | | | | | **Review** |
+| < 80 | | | | | **Draft** |
+
+The four conditions override the arithmetic. §2 *Weakest dimension* names every blocker by id.
+
+## Honesty rules
+
+- Do not round up to cross 80 or 90.
+- Never raise a score because the deadline is close or the user wants the response finished.
+- A row with an open non-blocking question (`estimated, CQ-n`) caps *Scope lock* at 70 for the share of Must PD it carries, unless the assumption its estimate rests on is `accepted`.
+- `_TBD_` anywhere in §6 caps that dimension at 40.
+- `_TBD_` overhead or buffer in the profile caps *Estimate basis* at 70; §2 states that PD is given before both.
+- `reuse: rfp-NNNN <ID>` is evidence only if the source row carried a verdict, not a guess.
+- If the total moved down since the last run, the report says so and names the cause.