The read in four lines.
1 · L1 Mail Intake is the acute fire: a fresh P0 plus three P1s, all in the "mail silently lost" class.
2 · L3's #916 scare is RESOLVED (intake audit 2026-07-28: a list-endpoint 200-row cap made a creation flood look like data loss) — #917's audit trail remains the durable fix; the intake flood itself is now the P0 cleanup (#921).
3 · L5 Matching is the widest backlog but bottlenecked on one decision point: architect pass #875 resolves most of it wholesale.
4 · Two P0s are process, not code: the Odoo cutover (#893, do #903 first) and #875 itself. Immediate unlock remains billing → deploy (ships the #888 fix that plausibly causes today's 502s).
L1 · Mail Intake 1 P0 · 4 P1 · 3 P2
Theme: mail can be silently lost or invisibly stuck, and the UI cannot tell you.
P0#926Poll soft-timeout advances the watermark to now() — permanent silent skip of all unprocessed mail in the batch. Data-loss class.
P1#928watermark_frozen defeats the poison-message quarantine — a two-message pair can wedge a mailbox permanently.
P1#927Timeout-path losses are invisible: innocent-message quarantine, phantom audit rows, 24h-blind reconcile.
P1#919Failed inbox polls are invisible — UI shows "Not polled yet" forever because success is the only thing recorded.
P1#923Inbox onboarding: ask backfill scope at connect time — today every new inbox silently auto-processes 30 days.
P2#931 scope-skipped messages leave no trace · #930 boundary message re-classified every 5 min (paid calls) · #929 inbox row integrity
P1#846Likely closable: Gmail forwarder attribution — fix merged in PR #865 and included in the deployed build. Needs a close-with-evidence pass.
L2 · Triage / Classification 1 P0
P0#921Classification false-positive flood: geral@ backfill turned ~75% of non-RFQ mail into requests — bias-to-RFQ needs per-inbox scoping.
L3 · RFQ Creation & Identity 4 P1 · 4 P2
Theme: can we trust the RFQ record? Statuses drift, identity misses, and nothing is reconstructable.
P1#916Downgraded 2026-07-28: statuses never regressed — the list endpoint's 200-row cap + client-side tab counts faked it under the backfill flood. Remaining fix: server-side uncapped counts.
P1#917No audit trail for RFQ status changes — the reason #916 cannot be reconstructed. Fix together.
P1#856Client matching fails on an exact email (gisela.oliveira@voltenergy.pt, RFQ 257) despite 100% match in Odoo.
P1#177Salesperson auto-assign — design + mockup ready, forwarder blocker closed; buildable now.
P2#880 rematch re-pins the stale customer · #843 fallback owner (needs G+R decision) · #847 done-before-items window · #252 follow-up email linking
L5 · Catalog Matching 1 P0 · 10 P1 · ~15 P2
Theme: widest backlog, narrowest bottleneck — most items resolve wholesale through one decision point.
P0#875The umbrella: architect pass round 2 — 7 clustered directions awaiting Riccardo's per-cluster decision. Resolves the category family (#654/#655/#656), the contradiction-check gaps (#829/#826/#825) and most audit findings (#795-#799) as directions, not one-offs.
P1#552Datasheet spec architecture — actively being delivered by Raffaello's stacked PRs #904-#907 (merge after billing fix, strict order, #905 needs the eval before/after).
P1#203Competitor catalog ingestion — new hard evidence from the eval labeling: 0% of corpus competitor references are "known brands" (145/145 unknown). This is the single biggest match-quality lever for competitor RFQs.
P1#442Tabela recovery is Portugal-only — Spain/Italy get no category/dependency/attribute recovery.
P2Eval infra: #678/#679 · alternatives audit #914 (DUE in matrix) · prompt-injection corpus #680 · plus ~10 refinement findings riding on #875's outcome
L6 · Commercial (stock · pricing · commit) 4 P1 · 3 P2
Theme: price/stock provenance must harden before more autonomy.
P1#779Pricelist-based pricing engine overhaul (replace flat discount_percent with the Odoo pricelist mirror).
P1#665Block Odoo push when the price source is ambiguous; show the full calculation per line.
P1#903Catalogue staleness unmonitored — a stopped sync ages data silently. Do BEFORE the #893 cutover (it re-triggers the #684 failure class).
P1#398Learn and apply per-client second discount, with persistent override.
P2#841 untracked OCR spend · #397 Italy tabela reconcile
L7 · Review & Delivery 1 P1 · 4 P2
P1#912Long line-item UI redesign — Option A walkthrough delivered, PARKED on Giuseppe's verdict.
P2#913 display-state audit (4 findings in, 29 states inventoried) · #908 surface ficha link · #510 DECISION: reps start using the Odoo push daily? · #228 one-click feedback
Operations / cross-cutting 2 P0 · 1 P1 · ~6 P2
P0#893Odoo cutover staging → live production. Sequencing: #903 first (staleness monitor), it re-triggers the #684 DB-rename failure class.
P0#819Customer-intelligence agent V1 — built and parked; waiting on PRs #878/#885 review (Riccardo) + deploy.
P1#924Processing-pipeline audit (fit RFQs not auto-processed; Analyze 502 on RFQ 531, dead click on 421). Spans L1→L5 + infra; the 502 is plausibly worker starvation from the un-deployed #888 eval fix.
Unlock order (who moves what):
1 · Giuseppe: GitHub Actions billing → deploy current main (ships #888; plausibly ends the 502s of #924) → then merge Raffaello's #904-#907 in strict order.
2 · Riccardo: the decision queue — #875 clusters, #905 eval waiver, #878/#885 reviews, #843 A/B — one working session clears most of L5's bottleneck.
3 · Fix first once unblocked: L1 intake trio (#926/#928/#927) and L3's #916+#917 pair.