Дмитрий
d242819e27
Продолжение приёмки Этапа 3 по указанию владельца: «проверь замечание — так это или нет — и посмотри всё окружение на этот класс ошибок». Замечание оказалось верным, и рядом с ним нашлось ещё два блокера того же семейства. Ни один из трёх не виден ни одному тесту. 🔴 В-125. Джоб отправки читал снимок получателей ВНЕ пометки клиента: строки 115 и 139 стояли голыми в handle(), а обёртка открывалась только внутри цикла. Чтение снимка ленивое — запрос уходит не тогда, когда читателя позвали, а когда забирают очередную пачку, то есть уже за пределами чужой транзакции, а SET LOCAL живёт только до её конца. Замер у самой базы на ОДНОЙ строке снимка: суперпользователь (так идут все наши тесты) — 1 строка, боевая роль crm_app_user без пометки — 0, она же с пометкой — 1. Без ошибки, молча. На бою: рассылка закрывается «готово, отправлено 0»; а если в снимке есть ждущие своего утра — статус «ждёт утра», заморозка НЕ снимается, команда добора будит рассылку каждые 15 минут, та снова читает ноль, и деньги висят замороженными без конца. Починка стоит в самом читателе, а не у зовущего: он оборачивает КАЖДЫЙ свой запрос сам. Полагаться на внимательность каждого, кто его позовёт, оказалось нельзя — ровно на этом дыра и выросла. Зовущим не мешает: под запросом человека пометка уже стоит, вложенная транзакция ставит то же значение. 🔴 В-126 и В-127. Этап 3 научил двух помощников ПРАВИТЬ снимок и клиентскую базу — проставлять найденный у ДаДаты регион, пояс и оператора. А обе таблицы заводились под путь «строки только вставляют и удаляют»: прав на правку им не выдавали. Замер: UPDATE под боевой ролью — «нет доступа к таблице», SELECT той же ролью работает. На бою: номер, у которого пояс не был известен сразу, не получил бы его НИКОГДА, а номер без пояса не отправляется вовсе (решение владельца В-85). Для канала «своя база» пояс не известен ни у одного номера, пока помощник его не проставит, — то есть этот канал не отправил бы ни одного сообщения. Добавочная миграция (прежние прод не перезапускает), гард на существование роли, запись схемы v9.16. Сторож прав расширен: он спрашивал базу только про то, что модуль обещал, и обещание опять оказалось неполным — как в В-122 неделей раньше. ⚠️ В-128, не чиню, называю. В трёх докблоках записано, будто служебная роль обходит изоляцию. ПИЛОТ.md от 07.07: на боевом кластере её не обходит НИ ОДНА роль. Значит служебное соединение живо не обходом, а политиками srv_bypass, и перезапуск db/03_service_bypass_policies.sql при выкате — не подстраховка, а несущая опора. Правка текстов — уровень всего приложения, не этапа. Доказательства. · Тест В-125 проверяет не результат (его подделать нельзя — суперпользователь всё видит), а ПОРЯДОК: каждый запрос к снимку обязан идти внутри той же открытой транзакции, где уже выставлена пометка. Уровень вложенности отличает «пометка здесь и сейчас» от «стояла раньше, в другой, уже закрытой». Красный до починки показал 5 чтений, все без пометки. · Живой прогон НАСТОЯЩЕГО джоба под боевой ролью (SET ROLE crm_app_user), парно: с починкой — «отправлено 2 из 2, статус готово»; без починки — «отправлено 0 из 2, статус готово, джоб не упал». Тот самый молчаливый сбой, вживую. · Права: живой UPDATE под боевой ролью — до миграции «нет доступа» по обеим таблицам, после миграции обе правки проходят. Данные пробы откатаны. · Вырезами трижды: убрал обёртку у чтения снимка — тест краснеет; опечатка в имени роли ВНУТРИ гарда (та самая, что ошибки не даёт и права молча не выдаёт) — сторож краснеет; выдал права только одной таблице из двух — краснеет на второй. Всё возвращено. Обход всего окружения на этот же класс: 35 фоновых помощников и 36 команд классифицированы по тому, ставят ли они пометку клиента и каким соединением ходят. Те, что работают без пометки, трогают только таблицы БЕЗ изоляции (портал продаж, бот, внешние балансы). Отдельно искал именно ловушку «ленивое чтение уезжает из чужой обёртки» — в рекламном модуле и сборщике аудитории всё внутри. Права на автономера у всех новых таблиц выданы обеим ролям, по кошельку перекосов нет. Не проверял вглубь маршруты портала (их закрывает общая прослойка) и модули вне рекламы/СМС. Прогоны: СМС 241/241 (11 пачек, все с первой попытки), приём лидов 17/17, фронт 1676 зелёных + 3 пропущенных (не трогал), phpstan 2 чужие давние, pint чисто. Стенд возвращён: dev-база — те же 12 клиентов и нули по модулю, пробные строки в тестовой базе откатаны. 🔴 При выкате ветки порядок прежний и обязателен: миграции → db/03_service_bypass_policies.sql → контрольный подсчёт политик srv_bypass (должно стать на 8 больше). Права и изоляция — разные механизмы, эта миграция того шага не заменяет.
Прил. Л — HTML-прототипы Лидерра
Самодостаточные HTML-прототипы 8 ключевых экранов клиентского приложения и админки SaaS. Это не боевой код — это референс для дизайнера (Диз-1) и рабочая заготовка для frontend-команды в спринтах 1, 4, 5, 8, 14.
Как пользоваться
открыть web/index.html → выбрать экран → двойной клик
Структура проекта
liderra/
├── README.md ← этот файл (про прототипы)
├── CLAUDE.md ← оперативная карта для Claude Code (приоритет правил, 33 инструмента)
├── docs/ ← документация, инструкции, аудиты, брендбук, Прил. Н (tooling)
├── web/ ← HTML-прототипы экранов
└── db/ ← schema.sql и changelog схемы
Каждый прототип:
- Полностью офлайн-самодостаточный, кроме одного запроса к Google Fonts за
InterиJetBrains Mono(можно заменить на локальный fallback за минуту). - Содержит «пилюлю i» в правом нижнем углу — открывает спецификацию экрана: состояния, API-контракты, требования безопасности, что не реализовано.
- Использует только токены из
brandbook.mdv1.1. Если в проекте появятся новые токены — править надо брендбук, не прототип.
Источники истины
| Что | Где |
|---|---|
| Палитра, типографика, размерная сетка | brandbook.md v1.1 §3, §4, §5, §8 |
| SVG-логотипы | brandbook.md §9.1–9.5 |
| Поведение экранов | CRM_bp-gr_Инструкция_v8_5.md v8.5 |
| Админка SaaS (экран 08) | Админка_SaaS_v8_2.md |
| Открытые вопросы по дизайну | Открытые_вопросы_v8_3.md Диз-1, Диз-3 |
Статус экранов
| # | Экран | Статус | Сессия |
|---|---|---|---|
| 01 | Логин · Регистрация · 2FA · Recovery | ✅ Готово | 05.05.2026 |
| 02 | Дашборд | ✅ Готово | 05.05.2026 |
| 03 | Список сделок | ✅ Готово | 06.05.2026 |
| 04 | Карточка сделки | ⏸ В очереди | — |
| 05 | Канбан-доска | ⏸ В очереди | — |
| 06 | Биллинг и тарифы | ⏸ В очереди | — |
| 07 | Настройки тенанта | ⏸ В очереди | — |
| 08 | Админка SaaS | ⏸ В очереди | — |
Прототипы выпускаются по одному за сессию.
Что прототип НЕ делает
- Не подключается к API. Все формы отправляют заглушки (
alertили симулированный успех). - Не использует Vue/Vuetify — это сознательно, чтобы прототип открывался в браузере и читался без npm.
- Не покрывает все пограничные состояния (loading skeletons, ошибки сети). Эти состояния перечислены в spec-аннотации каждого экрана.
- Не финализирует слабо проработанные в ТЗ места — их я отмечаю в спецификации тегом
[?](по соглашениюPravila_raboty_Claude_v1_1.md§3.1).
Что брать из прототипа в боевой код
- CSS-переменные из
:root— копировать вresources/css/brand.cssVue-проекта (но единственный источник истины —brandbook.md §8.1). - Структура DOM и aria-атрибуты — переносить в
.vueкомпоненты как есть. - JavaScript-логику — переписывать на Composition API, но логика валидаций (zxcvbn-эвристика, TOTP-таймер, ввод по 1 цифре с автопереходом) уже близка к боевой.
Версионирование
Каждый файл прототипа фиксирует свою версию в шапке (<!-- Версия: vX.Y от ДД.ММ.ГГГГ -->). При смене узла брендбука или narrative — обновляем затронутые прототипы и фиксируем в этой таблице:
| Дата | Что изменилось |
|---|---|
| 05.05.2026 | v0.1 — прототип №01 (Логин/Регистрация/2FA/Recovery) |
| 05.05.2026 | v0.2 — прототип №02 (Дашборд) |
| 06.05.2026 | v0.3 — добавлен корневой CLAUDE.md и docs/Tooling_v8_3.md (Прил. Н v1.0). Архив документации v8.3.2 → v8.3.3. Прототипы не менялись. |
| 06.05.2026 | v0.4 — прототип №03 (Список сделок). Narrative переведён на v8.4 (все 13 разделов плана переписаны, файл переименован → CRM_bp-gr_Инструкция_v8_4.md). Schema → v8.4 (+ outbound_webhook_*). |
Прил. Л v0.4 от 06.05.2026 — 3/8 прототипов готовы (01–03), narrative на v8.4, schema на v8.5 (07.05.2026 — реализация 27 решений аудита C; narrative v8.5 готовится).
Документация для разработчика
| Документ | Что в нём |
|---|---|
| CLAUDE.md | Оперативная карта для Claude Code: приоритет правил (6 уровней + Pravila §12 hard rule), стек проекта, карта 29 инструментов «когда что использовать», 11 запретов, текущая фаза |
| docs/Tooling_v8_3.md | Прил. Н v1.10 — полный реестр 29 активных инструментов в 4 фазах (фаза 0 — документация; +1 Laravel; +2 Vue + Frontend Design plugin; +3 pre-prod), конфликты и решения, процедура перехода между фазами, особенности Windows + PowerShell |
| docs/Pravila_raboty_Claude_v1_1.md v1.6 | Продуктовые правила работы Claude в проекте (включая §12 Superpowers hard rule + §13 Frontend Design paired stack + §13.9 hard-link на R10) |
| docs/Plugin_stack_rules_v1.md v1.3 | Координация Superpowers + Frontend Design (R0–R13) — gate, фазы UI-фичи, разделение TDD/визуал, ревью по аспекту |
| docs/README_АРХИВ_v8_5.md v8.5 | Состав архива, навигатор по документам |
| docs/CRM_bp-gr_Инструкция_v8_5.md v8.5 | Главное ТЗ из 28 разделов (v8.5 — реализация 27 решений аудита C от 07.05.2026; v8.4 финал был 06.05.2026) |
| db/schema.sql v8.11 | Схема БД PostgreSQL 16 (56 базовых таблиц + 12 партиций, 97 индексов, 38 RLS-политик, 4 роли, 13 триггеров, 5 функций — после v8.11 от 09.05.2026, audit P0-02 + O-perf-02/03) |
Репозиторий
https://github.com/CoralMinister/liderra (приватный)