Task 8, приёмка Этапа 4. Кода она не приносит по замыслу: все двенадцать строк
листа (4.1–4.8, 4.11–4.14) закрыты ДВУМЯ доказательствами каждая — тест И живой
прогон, — экранные строки отдельно посмотрены глазами в браузере. Итоговая
таблица Этапа 4 заполнена в приёмочном листе (лист в git не лежит).
В git уходит ровно одна правка — порядок импортов в шести файлах тестов (В-192).
Причина, по которой она вообще нашлась: три этапа подряд `pint` гонялся ТОЛЬКО
по свежим файлам, а по всей области модуля не гонялся ни разу. Заодно выяснено,
что жалобы `line_ending` чинить не надо — это виндовые переводы строк рабочей
копии, в git их нет вовсе (pint «исправил», git не увидел ни одного изменения).
Перегнаны тесты этих шести файлов: 41/41 зелено.
🔴 ДЕНЕЖНАЯ МИНА СВЕРХ ПОСТРОЕННОГО (В-190). Права спросил у самой базы матрицей
по всем таблицам модуля — и увидел, что у рабочей роли crm_app_user есть право
писать в таблицу заморозок, а на её счётчик номеров ad_wallet_holds_id_seq права
нет. Живой прогон парно: без права заморозка денег под боевой ролью ПАДАЕТ («нет
доступа к последовательности»), с правом идёт. Заморозка делается при КАЖДОМ
заказе рассылки, при заказе имени и при запуске рекламной кампании Яндекса.
Промах был мой: в В-142 я привёл стенд к эталону двумя точечными командами по
именам из плана вместо `ON ALL SEQUENCES`, как делает сам db/02_grants.sql.
Памятка выката переписана: вместо списка имён счётчиков — запрос, который САМ
находит все счётчики без права. На бою проверить (косвенно там всё в порядке —
рекламные кампании запускаются тем же кодом, но довод косвенный).
🔴 И ПЕРВЫЙ ЗАХОД ПРИЁМКИ ПРОШЁЛ «ЗЕЛЕНО», НЕ ДОКАЗАВ НИ ОДНОЙ ДЕНЕЖНОЙ СТРОКИ
(В-191): песочница гасит и возврат заморозки при срыве, и ночного работника
целиком. Датчик на будущее — не сдвинулась ни одна копейка, значит прогон не
доказал ничего, даже когда всё зелено.
Ещё три промаха своих же приборов: В-193 и В-194 (прогон не доходил до
состояния — сторож законно даёт попытке дожать её срок, а имя без отметки
согласования кнопка законно не включает: правда была в коде), В-195 (браузерный
замер читал таблицу рассылок вместо базы и «доказал» поломку, которой нет —
класс В-121, соврал прибор).
Живьём под боевой ролью crm_app_user: сторож зависших тремя заходами (пометка →
выдержка срока → срыв, заморозка 17.00 → 0.00); имя за долг вернулось и списало
ровно 100 ₽, отключённое владельцем осталось выключенным при 5 000 ₽; кнопка
включения отказала числами, без пометки клиента 404, с пометкой списала 600 ₽;
номера руками легли пятью видами записи; продолжение довело 5 из 5 за 42.50 ₽.
Под служебной ролью — чистка снимка тройкой (без права падение, без политики
srv_bypass «успешный ноль», с обоими удалено 3).
Прогоны: ClientSms 320/320 (13 пачек, все с первой попытки), приём лидов 17/17,
фронт 1700 + 3 пропущенных (одна чужая давняя ошибка, В-57), phpstan ровно 2
чужие давние, vue-tsc ровно 5 чужих давних в 5 файлах (git blame: от 25.07),
pint чисто.
Стенд сверен со снимком «до» поле за полем и совпал. Намеренное изменение одно:
рабочей роли выданы права на ВСЕ счётчики схемы, как в эталоне db/02_grants.sql.
🟡 Открытый вопрос владельцу — В-182: номера в журнале сообщений живут без срока,
обязательство «90 дней» закрывает только снимок получателей.
Ветка НЕ влита в main и НЕ выкачена. Порядок выката: миграции →
db/03_service_bypass_policies.sql → подсчёт политик srv_bypass (+8) → права →
контрольный запуск чистки снимка.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Дмитрий
b6c837e28a