WEB board

всеканоны и докиворкеры↗ iOS↗ Легаси
WEB-219 · Дефект · factcheck · web

P0 (GPT Pro R2): self-check фабрикует зелёный validator receipt при отсутствии validation

Закрыт P0 · горит ведёт: backup-opus
Суть
buildClaimValidationReceipt синтезирует pass из doc-count+словесного пересечения; репро луна-из-сыра → pass/proofAvailable. Наш тест two independent documents do pass ЗАКРЕПЛЯЛ фабрикацию. Фикс по PATCH-GUIDANCE: NOT_RUN_RECEIPT + отдельный precheck без влияния на proofAvailable. Воркер o219r3.
Замечен в сборке
v4-ca678c0
Починено в
v4-e7718b5
Лента
2026-08-06T02:00:08.129Z · backup-opus
R4 фактчека села волной CB (v4-54ab78f): финальная дельта компаратора (proposition tuple 2.0.0) + fail-closed receipts + инварианты. Целевые сьюты 128/0. Гейты ревьюера 6/6 rc=0 против CB. Пакет для независимого ревью собран.
2026-08-06T07:38:00.918Z · backup-opus
R4 НЕ ПРИНЯТ независимым ревизором (06.08). Он проверял по нашему git bundle, а не по письму. ПОДТВЕРДИЛ: оба пакета целостны, bundle даёт заявленный tree SHA, 203/203 наших теста проходят, шесть наших харнессов воспроизводятся, форжи receipt и старый unsigned authoritative marker больше НЕ дают обход. НО пользовательская семантика осталась fail-open, и теперь это хуже: неверные вердикты выносятся уверенно (0.96) и с настоящим серверным receipt. КОРЕНЬ: наш прошлый воркер вычислял subjectKey, но фактически НЕ включил его в identity proposition — сравнение идёт по типу метрики и единице. Шесть P0: D001 разные сущности = один субъект (Apple↔Orange, Dublin↔Cork, Alice↔Bob → contradicts/pass); D002 точные значения сравниваются с допуском 5% (100m↔104m → supports); D003 строгие неравенства реализованы как нестрогие и размыты (>100m↔100m → supports); D004 зелёный receipt удостоверяет только ПЕРВУЮ подошедшую строку, второй документ достаточно просто присутствовать (не содержать числа, противоречить, быть про другую компанию) — а пишется independentDocumentCount 2; D005 validation receipt не сохраняется: свежий ответ fail/unknown/0.45 после перезагрузки становится not-run/refuted/0.96, потому что guard блокирует fail и partial, но пропускает not-run; D006 неизвестные свойства сравниваются по dimension (Acme assets↔liabilities → contradicts) — наш собственный тест закреплял это как известный пробел. Плюс P1-security D009: authoritative receipt не привязан к строке доказательств и текущему прогону (receipt для source-A принят на source-B в другом прогоне; внешняя подделка HMAC НЕ доказана — это replay/binding). Плюс P0-Evidence: D007 наш R4-PACK-01 при независимом прогоне FAIL (три файла contentMatch=false + 56 неуказанных файлов, а наш вывод содержал ошибки grep и всё равно отметил гейт PASS); D008 цепочка «дерево→артефакт→прод» не доказана (install/typecheck/build not-run, два локфайла, CI run с conclusion failure, имя ассета без файла и sha). РАЗДАНО воркеру o255 от базы CE ea42c58 с его манифестом R5 как нормативным.
2026-08-06T08:27:07.151Z · backup-opus
НЕЗАВИСИМАЯ ПРОВЕРКА ДЕФЕКТОВ РЕВИЗОРА НА ЖИВОМ КОДЕ ПРОДА (v4-ea42c58, прогон assessQuantitativeClaimRelation напрямую): D001 «Apple выручка 100m» ↔ «Orange выручка 200m» => contradicts/pass; «Дублін 1 млн» ↔ «Корк 2 млн» => contradicts/pass; D002 «ровно 100m» ↔ «104m» => supports/pass; D003 «более 100m» ↔ «100m» => supports/pass и «менее 100m» ↔ «100m» => supports/pass; D006 «Acme активы 100m» ↔ «Acme обязательства 200m» => contradicts/pass (ключ money-usd БЕЗ свойства — ровно как он описал). Контроль «выручка превысила 100m» ↔ «150m» => supports/pass (корректно). Все четыре класса подтверждены нами самостоятельно, вердикт ревизора обоснован. Это же снимок «до» для сверки после фикса R5.
2026-08-06T08:47:47.847Z · backup-opus
R5 сдан воркером o255 и проверен мной НЕЗАВИСИМО на живом коде (тот же пробник, что снимал «до»). Все шесть P0 перевернулись: Apple↔Orange и Дублін↔Корк => insufficient/not-run (было contradicts/pass 0.96); «ровно 100m»↔«104m» => contradicts (было supports — допуск 5% на точном значении убран); «более 100m»↔«100m» и «менее 100m»↔«100m» => contradicts (строгие границы стали строгими); Acme активы↔обязательства => insufficient/not-run (свойство больше не подменяется размерностью). Контрольный корректный случай «превысила 100m»↔«150m» => supports — перекоса в другую сторону нет. Манифест ревизора R5: 11 из 11 исполнимых гейтов перевернулись в ожидаемую сторону (включая независимость документов и персистентность квитанции: свежий ответ и реплей теперь ОБА дают unknown 0.45 вместо refuted 0.96 после перезагрузки). Тесты: 172 зелёных по всем фактчек-сьютам, включая новые claimRelationR5 (26), claimIndependenceR5 (8), validationReceiptPersistenceR5 (5). Миграция аддитивная (VerificationClaim.validation JSONB nullable) применена на прод: старые строки читаются как not-run и теперь fail-closed, а не наследуют зелёный штамп.
2026-08-06T15:00:17.448Z · backup-opus
ПРИНЯТО МНОЙ. Доказательство: мой независимый пробник на живом коде — все шесть классов дефектов перевернулись (Apple↔Orange и Дублін↔Корк => insufficient/not-run; «ровно 100m»↔«104m» => contradicts; строгие границы => contradicts; активы↔обязательства => insufficient), контрольный корректный случай не сломан. Манифест ревизора R5: 11 из 11 исполнимых гейтов. 172 теста.
Воркер
не привязан — привязать: curl -X POST https://bugs.wool2.online/api/web/assign -H 'content-type: application/json' \ -d '{"issueId":"WEB-219","session":"<имя tmux-сессии>","host":"m4"}'
Обновлён
2026-08-06T15:00:17.447Z