Дмитрий 97a93cb763 feat(смс-клиент): кнопка «Продолжить рассылку» — доводим до конца тех, на кого не хватило денег
Строка листа 4.13, решение владельца В-49 «надо обязательно». Рассылка встала
из-за денег → клиент пополнил кошелёк → нажал «Продолжить», и она идёт дальше
с того места, где остановилась.

🔴 Главная мина (В-151, подтверждена чтением кода): джоб отправки считает
обработанным ЛЮБОЙ номер, у которого есть запись в журнале этой рассылки, без
разбора статуса. А номер, на котором кончились деньги, записан как
«не хватило денег». Значит простой повторный запуск молча пропустил бы его:
человек заплатил бы за продолжение, а получатель не получил бы ничего.

🔴 И вторая находка, которой в плане не было (В-184): «оставить строку и просто
не считать номер обработанным» НЕВОЗМОЖНО физически — на журнале сообщений
уникальный ключ по (клиент, рассылка, номер), вторая запись не вставится.
Поэтому продолжение эти строки УДАЛЯЕТ, и по смыслу это верно: «не отправили
из-за денег» фиксирует НЕслучившееся и после пополнения перестаёт быть правдой.
Заодно замерен масштаб: при остановке пишется РОВНО ОДНА такая строка, у
остальных номеров записей нет вовсе.

Что сделано:
· POST /api/sms/campaigns/{id}/resume — убирает строки «не хватило денег»,
  ставит рассылку в очередь, гасит причину остановки (иначе экран продолжал бы
  объяснять человеку прошлую остановку у работающей рассылки);
· продолжаем ТОЛЬКО остановленную ИЗ-ЗА ДЕНЕГ (В-187). Остановленную человеком
  продолжать — значит отменить его решение; сорванную сторожем — наступить на ту
  же поломку. У каждой причины свой человеческий отказ, и текст под тестом;
· правило живёт в ОДНОМ месте на сервере (как enableDecision в Task 4): список
  рассылок отдаёт готовый признак can_resume и число «сколько ещё уйдёт». Счёт
  остатка — в читателе снимка, где уже живёт «кто ждёт» (одно место, В-96);
· кнопка «Продолжить» в таблице рассылок + подтверждение: сколько осталось
  отправить, что повторно никому не пойдёт, что цена прежняя;
· цену НЕ пересчитываем, снимок НЕ пересобираем, заново НЕ замораживаем
  (В-39, В-188): списание идёт поштучно с проверкой перед каждым номером, в
  минус рассылка не уйдёт — кончатся деньги, встанет снова с той же причиной.

🔴 Мой же тест поймал расхождение с моим же решением (В-189): проверку денег я
впихнул в правило «можно ли продолжить» — и кнопка исчезла бы именно у того,
кому она нужна. Разделил: состояние — признак для экрана, деньги — проверка по
нажатию с числами («свободно 0.00 ₽, одно сообщение 8.50 ₽»).

Право DELETE на журнал сообщений рабочей роли — миграция 2026_08_01_101000,
схема v9.22 (В-186, вторая половина мины В-152): без него продолжение на бою
падало бы «нет доступа». Сторож MigrationGrantsTest расширен.

Проверено: ClientSms 320/320 (13 пачек, все с первой попытки), приём лидов
17/17, фронт 1700 + 3 пропущенных (одна чужая давняя ошибка, В-57), phpstan 2
чужие давние, vue-tsc 5 чужих давних, pint чисто. Шесть вырезов, каждый
покраснел ровно там, где вырезан.

🔴 Живой прогон ДЕНЕЖНЫЙ и парный под боевой ролью crm_app_user: рассылка на 5
номеров при деньгах на 2 встала (ушло 2, списано 17.00 ₽, одна строка «не
хватило денег»); продолжение без пополнения — отказ с числами; БЕЗ пометки
клиента рассылка не видна вовсе (изоляция держит); после пополнения с пометкой —
ушло 5 из 5, списано 42.50 ₽, в журнале ровно 5 записей по одной на номер, «не
хватило денег» не осталось. В браузере: кнопка видна глазами, после нажатия и
прогона очереди рассылка «завершена, 5 из 5», кнопка исчезла, у нетронутой
рассылки осталась. Заодно поправлена речь: было «отправим ещё 3 сообщений».

Стенд возвращён и сверен; намеренное изменение одно — миграция накатана на
локальную dev-базу.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 11:24:35 +03:00
2026-06-01 16:26:02 +03:00
2026-06-01 19:07:51 +03:00
2026-06-01 19:07:51 +03:00
2026-06-01 16:26:02 +03:00
2026-06-01 16:26:02 +03:00

Прил. Л — 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.md v1.1. Если в проекте появятся новые токены — править надо брендбук, не прототип.

Источники истины

Что Где
Палитра, типографика, размерная сетка brandbook.md v1.1 §3, §4, §5, §8
SVG-логотипы brandbook.md §9.19.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.css Vue-проекта (но единственный источник истины — 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 (R0R13) — 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 (приватный)

S
Description
No description provided
Readme 187 MiB
Languages
PHP 53.5%
TypeScript 12.5%
Vue 11%
JavaScript 9.2%
HTML 7.2%
Other 6.6%