fix(db,web): единна стойностна база за обобщенията и страниците (#98)

[todorkolev]

Какво и защо

Обобщенията (authority_totals, home_totals, company_totals, flow_pairs, sector_totals) сумират всеки ред с известна стойност в евро - amount_eur IS NOT NULL, независимо от value_flag. Това включва review, annex_suspect, value_low и поправените value_suspect.

Две заявки на страници обаче филтрираха строго по value_flag = 'ok' и затова подценяваха спрямо обобщенията. Най-осезаемо при home.ts, където се сумират пари: един и същ показател даваше различно число според това къде го гледаш - точно проблемът, описан в #98.

Промени

• Изравнени са двете заявки за „една оферта" към каноничната база, като филтърът bids_received = 1 е запазен - той дефинира самия показател.
• Инвариантът е документиран в docs/etl.md, в речника на данните за асистента и в коментарите на precompute.sql / схемата.
• Добавен е регресионен тест, който сравнява живите агрегации по институция, фирма и сектор срещу построените обобщения и пада при разминаване.

Проверка на останалата част от заявките

Прегледах целия слой: няма друга парична сума, която да се разминава. Ограниченията за положителни стойности в competition.ts (дял „една оферта", HHI, дялове по процедура) са умишлени - те трябва да останат ограничени - и вече носят изричен коментар защо са изключение. Използването на value_low в contractsSummary е броене за значка за качество на данните, не филтър върху пари.

Тестове

Пълният @sigma/db пакет минава локално: 29 файла / 201 теста, включително тестовете, които минават през sqlite3 и Wrangler. Typecheck на packages/db и apps/web е чист.

Closes #98

🤖 Generated with Claude Code

[ydimitrof]

Преглед на PR #98 — „единна стойностна база за обобщенията и страниците"

Бележка: прегледът е написан на български съгласно конфигурацията на задачата. Не са публикувани коментари в PR — това е чернова за вашата проверка.

Verdict

COMMENT — няма блокиращи проблеми; преди merge потвърдете двете точки по-долу.

Резюме на промяната

PR-ът уеднаквява „стойностната база" за паричните агрегати: страничните заявки вече сумират amount_eur IS NOT NULL независимо от value_flag, вместо стария филтър value_flag = 'ok' AND amount_eur > 0. Така страниците се изравняват с rollup-таблиците (home_totals, company_totals, authority_totals, sector_totals), които вече използват тази база. Реалните кодови промени са само в contracts.ts (listSingleOfferContracts, contractsSummary) и home.ts; всичко останало са коментари/документация плюс нов тест. Промяната отговаря на описанието на задачата (обща канонична база за суми).

Сигурност (Phase 0 + agent-level, OWASP)

• CLEAN. Няма твърдо кодирани тайни, промени по URL или нови зависимости (само вградени модули на Node + съществуващ vitest).
• SQL injection: променените заявки са безопасни — LIMIT ? е bind-нат, order е избор между два хардкоднати литерала, а заявката в home.ts е изцяло статична. Няма конкатенация на потребителски вход. directPlaceholders/where.join в competition.ts не са пипани от този PR.
• Целостност на данните: промените са read-only заявки + коментари + тест; няма миграции, които променят данни.

Качество и тестове

• Новият тест value-base-sql.test.ts е смислен, не е „cheater" — изгражда реалните rollup-и от миграциите + precompute.sql и сравнява живите агрегации с тях. Покрива всички варианти на value_flag, включително поправен value_suspect и NULL value_suspect (който правилно е изключен). Проверих числата ръчно: сума 1060 и 5 договора за single-offer, подредба [500, 300, 200, 100, -40] — коректни.
• Документацията (docs/etl.md, коментарите в SQL и describe-schema.ts) е обновена консистентно с новата дефиниция.

Точки за потвърждение преди merge

1. Отрицателни/value_low редове на публични страници. Премахването на amount_eur > 0 вкарва value_low редове (напр. -40 в теста) в списъците и сумите на началната страница за single-offer договори. За rollup-сравнимост това е правилно, но потвърдете, че показването на отрицателна/ниска стойност публично е желано (в режим „highest value" тя ще е накрая на списъка, така че на практика ще излиза само при много малък корпус).
2. Пълнота на уеднаквяването. Не можах да grep-на цялото хранилище (локално е наличен само review-ботът, не проектът automated-review). Моля потвърдете, че не е останал друг паричен агрегат, който още филтрира по value_flag = 'ok' или amount_eur > 0 (напр. sector/authority/company заявки извън диффа), за да не се получи нова несъгласуваност. Тестът покрива authority/company/sector/home пътищата — ако има други, добавете ги.

CLAUDE.md / gates

Няма частична имплементация, дублиран или мъртъв код, нито смесени концерни. Промяната е атомична и в обхвата на задачата. Единствената резерва за score >9/10 е невъзможността да потвърдя 100% покритие и липсата на пропуснат агрегат без достъп до пълното хранилище — оттам и verdict-ът COMMENT вместо APPROVE.

[lyubomir-bozhinov]

Проверих срещу самия diff. Реалната промяна в поведението е точно две заявки на страници — listSingleOfferContracts (contracts.ts) и паричната сума за „една оферта" в home.ts — минаващи от value_flag = 'ok' AND amount_eur > 0 към каноничната база amount_eur IS NOT NULL, с което се изравняват с обобщенията (точно #98). Останалото (competition.ts, precompute.sql, 0000_init.sql) е само коментари/документация — потвърждава, че агрегатите вече бяха на каноничната база, и — важно — няма промяна по схемата, тъй че няма миграционна дупка.

Ортогонално на #257: той пипа конверсията на анекс-валутата, ти пипаш филтъра — не се застъпват (координирайте само реда на merge заради общите файлове).

Регресионният тест е реален: сее по един ред от всеки value_flag (review/annex_suspect/value_low вкл. −40) и заковава, че тоталите на страниците .toBe() обобщенията по институция/фирма/сектор, а двете home single-offer заявки дават 1060 на не-NULL базата. Забелязвам, че single-offer списъкът вече включва value_low −40 ред — нарочно е (тестът го заковава изрично), не пропуск.

Одобрявам.

[midt-admin]

Одобрено - каноничната стойностна база е потвърдена (нула остатъчни value_flag филтъра в паричните агрегати, проверено с grep), нишките резолвнати, CI зелен.