portal

liderra/portal

Fork 0

Commit Graph

Author	SHA1	Message	Date
Дмитрий	b6a15c5bbf	merge: подтянул общую ветку в клиентские СМС — 227 записей отставания закрыты Ветка шла отдельно почти неделю и отставала на 227 записей, отставание росло каждый день. Направление сведения — общая В ветку: перевод main владелец отклонил, значит вливать в него нечего. Девять столкновений, каждое разобрано по существу. Журнал схемы: столкнулись НЕ три номера, как ожидалось, а ВСЕ - обе ветки независимо заняли v8.96-v9.25 и v9.32 разным содержимым. Обе стороны настоящие, выбросить нельзя ни одну, поэтому перенумерована ветка, а не общая: 31 запись уехала в свободный диапазон v9.33-v9.63. Содержание не тронуто - доказано сверкой с исходной версией через git, посимвольно. Соответствие старых номеров новым вписано в сам журнал, чтобы старые документы ветки оставались читаемыми. Прежняя пометка про "запас v9.32" заменена: запас не спас, v9.32 в общей ветке тоже был занят. Сборка тестовой базы: взята версия общей ветки. Она позже и доказана замером - двумя шагами вместо migrate:fresh, который спотыкался на типе-призраке и оставлял схему неполной. Список слов орфографии сведён объединением: 2106 наших + 2169 общих дали 2173, ни одно слово ни с одной стороны не потеряно - проверено сравнением. Расписание работ, маршруты экранов и админский слой: обе стороны добавляли своё в одно место, оставлены обе. Витрина рекламных каналов: каждая ветка сделала настоящим СВОЙ канал - ветка СМС свой, общая Телеграм. После сведения настоящих три, заглушки исключают все три. Сторож витрины принят вырезанием: убрал СМС из списка настоящих - покраснел, вернул - позеленел. СТОЛКНОВЕНИЕ ИМЁН, созданное самим сведением. Оба набора тестов объявляли глобального помощника pollCampaign - свой в СМС (один довод) и свой в Телеграме (от двух до четырёх). Две функции с одним именем в одном языке не живут: пока ветки шли врозь, этого не видел никто. Помощник СМС переименован в pollSmsCampaign. Проверено, что других таких пар в PHP-тестах нет ни одной. Статанализ ветки доведён с 674 замечаний до НУЛЯ, уровень не понижен и в baseline не заметено ничего. - 616 из 674 - ложный класс Pest, закрытый тремя узкими правилами; правила перенесены из рабочей ветки, где владелец их уже принял; - остальные 42 - свои, в новом коде ветки, и починены по существу: задвоенный ключ массива в трёх тестах (след копирования - комментарий оторвался от своей строки), врущие описания двух помощников (PHP сам делает из ключа-номера число), сужение типа возврата, прятавшее от анализатора свойства подставного отправителя, лишний знак вопроса и четыре бесполезных перенумерования списка. - Приёмка вырезанием: подложил несуществующий метод - анализатор назвал его поимённо и покраснел; убрал - ноль. Шапки 59 моделей обновлены пересборкой подсказчика и ОСТАВЛЕНЫ намеренно (правка только в комментариях, проверено): без них анализатор не связывает модель с описанием и не знает, что дата - это дата, а не строка. Откатил их сперва по привычке - получил 15 замечаний про даты, вернул - ноль. Орфография: 15 файлов проверено, 0 замечаний (смотрел и на число проверенных файлов, не только на число ошибок). Добавлены три слова из имён миграций ветки. Заодно: алиас ruflo-core в списке имён сторожа реестра - плагин описан в реестре групповым именем, сторож видел только машинное. Мостится ТОЛЬКО имя; 🔴 содержательный долг остаётся - реестр до сих пор зовёт ruflo изолированным, хотя его разморозили 28.07. Это чинить отдельно, через claude-md-management. Проверено: три фронтовых сторожа рекламы 18/18, статанализ 0, разметка 0, орфография 0, синтаксис PHP чист. Полный прогон тестов ветки - отдельным шагом, он ещё ни разу не делался. NB: в журнале схемы есть задвоенные номера v8.26 (пять раз) и v8.64 (два) - это досталось по наследству из общей ветки, ровно столько же их там и было. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 19:50:41 +03:00
Дмитрий	fc235bb5a6	feat(смс-клиент): недоставленное закрывается через трое суток, деньги возвращаются клиенту Этап 5, Task 4. ДЕНЕЖНАЯ задача — решения владельца В-198 и В-199. Что появилось: - через трое суток «ещё в пути» становится «не доставлено». Довод не только продуктовый: оператор помнит судьбу ровно трое суток, после этого ответа не будет вовсе — закрыть сообщение обязаны мы, иначе итог рассылки никогда не станет окончательным и досыл не будет знать, кого досылать; - за «не доставлено» и за «оператор не отправил» деньги возвращаются клиенту на кошелёк. МТС за недоставленное с нас не берёт (В-7), значит эти рубли лежали у нас ни за что; - у кошелька появился метод refund() — ОТДЕЛЬНО от пополнения, и это не украшение: у topup() нет ключа события, а команда по расписанию по своей природе повторяется. На topup() второй заход вернул бы деньги ДВАЖДЫ. ИДЕМПОТЕНТНОСТЬ ДВОЙНАЯ, и проверено, что нужны обе опоры: - ключ события sms:refund:{рассылка}:{номер} + уникальный ключ в базе; - отметка refunded_at на сообщении, ставится в ТОЙ ЖЕ транзакции. Вырез только ключа тест НЕ красит (спасает отметка). Вырез только отметки тоже. Сняв ОБЕ, тест краснеет числом 117.00 вместо 108.50 — деньги вернулись дважды. Так и должно быть: одна опора страхует другую. Вырезы (все вернуты): убрать «оператор не отправил» из возвращаемых -> 1 красный; убрать закрытие по сроку -> 3 красных; возвращать за ЛЮБУЮ судьбу -> 2 красных (значит тесты «за доставленное не возвращаем» и «за в пути не возвращаем» — настоящие приборы, а не зелень вхолостую). ЖИВОЙ ДЕНЕЖНЫЙ ПРОГОН (sandbox выключен — в песочнице деньги не двигаются вовсе, и прогон доказал бы НОЛЬ): баланс 100.00 -> 108.50 ₽, движение типа refund ровно одно, отметка у недоставленного стоит, у доставленного нет. ВТОРОЙ заход той же команды: баланс тот же, движений по-прежнему одно. Стенд возвращён в исходное. Прогоны: модуль 343/343 (13 пачек, все с первой попытки), рекламный кошелёк 5/5 (я трогал общий AdWalletService), phpstan ровно 2 чужие давние, pint чисто.	2026-07-31 06:36:27 +03:00
Дмитрий	5356bf3ed6	feat(смс-клиент): опрос судьбы отправленных сообщений у операторов Этап 5, Task 3. Появилась команда client-sms:poll-delivery — каждые десять минут спрашивает у канала, что стало с отправленными сообщениями, и проставляет судьбу в журнал. Устройство: - умение рассказать судьбу — способность КАНАЛА: канал без разъёма просто пропускается. Когда у Т2/Мегафона/Билайна появятся кабинеты, команда не изменится ни строчкой; - отчёт ПРАВИТ существующую строку, новых не пишет (В-204): сторож зависших меряет движение рассылки по последней записи журнала, и новые строки делали бы зависшую рассылку «живой» — деньги остались бы замороженными; - спрашиваем только реально отправленные этим каналом, с номером сообщения, не старше трёх суток и с неокончательной судьбой. Оператор помнит судьбу трое суток — спрашивать про старое бессмысленно; - незнакомое слово оператора судьбу НЕ меняет: пишем слово в журнал и оставляем графу как была. Угадать значило бы соврать про деньги. ЖИВОЙ ПРОГОН ПОД БОЕВОЙ РОЛЬЮ, тройкой (политика srv_bypass воспроизведена тем же текстом, что в db/03, — на стенде их нет ни одной): А) право UPDATE есть + политика есть -> «уточнено: 1», судьба delivered; Б) права UPDATE нет -> команда ПАДАЕТ «нет доступа к таблице» (видно); В) права есть, политики нет -> «успех», «уточнено: 0», судьба пустая (НЕ видно). Подтверждает В-181: у двух опор разная цена отказа, и опаснее вторая. Стенд вернулся в исходное, политик srv_bypass не осталось. ПРО ПРИБОРЫ — два теста оказались НЕ приборами, починены, а не подогнаны: - «незнакомое слово не меняет судьбу» не отличал «графу не тронули» от «записали пусто» — теперь у сообщения есть стартовая судьба, и проверяется, что она цела; - «пробное не спрашиваем» краснел бы не от того: пробное отсекает фильтр по КАНАЛУ, а не по статусу. Переименован по тому, что реально охраняет, и под две оставшиеся защиты заведены свои тесты. После починки каждый из четырёх вырезов добавляет ровно один красный тест. Прогоны: модуль 336/336 (13 пачек, все с первой попытки), phpstan ровно 2 чужие давние, pint чисто. Команда в расписании — проверено schedule:list.	2026-07-31 06:23:24 +03:00

Author

SHA1

Message

Date

Дмитрий

b6a15c5bbf

merge: подтянул общую ветку в клиентские СМС — 227 записей отставания закрыты

Ветка шла отдельно почти неделю и отставала на 227 записей, отставание росло
каждый день. Направление сведения — общая В ветку: перевод main владелец
отклонил, значит вливать в него нечего.

Девять столкновений, каждое разобрано по существу.

Журнал схемы: столкнулись НЕ три номера, как ожидалось, а ВСЕ - обе ветки
независимо заняли v8.96-v9.25 и v9.32 разным содержимым. Обе стороны
настоящие, выбросить нельзя ни одну, поэтому перенумерована ветка, а не
общая: 31 запись уехала в свободный диапазон v9.33-v9.63. Содержание не
тронуто - доказано сверкой с исходной версией через git, посимвольно.
Соответствие старых номеров новым вписано в сам журнал, чтобы старые
документы ветки оставались читаемыми. Прежняя пометка про "запас v9.32"
заменена: запас не спас, v9.32 в общей ветке тоже был занят.

Сборка тестовой базы: взята версия общей ветки. Она позже и доказана
замером - двумя шагами вместо migrate:fresh, который спотыкался на
типе-призраке и оставлял схему неполной.

Список слов орфографии сведён объединением: 2106 наших + 2169 общих дали
2173, ни одно слово ни с одной стороны не потеряно - проверено сравнением.

Расписание работ, маршруты экранов и админский слой: обе стороны добавляли
своё в одно место, оставлены обе.

Витрина рекламных каналов: каждая ветка сделала настоящим СВОЙ канал -
ветка СМС свой, общая Телеграм. После сведения настоящих три, заглушки
исключают все три. Сторож витрины принят вырезанием: убрал СМС из списка
настоящих - покраснел, вернул - позеленел.

СТОЛКНОВЕНИЕ ИМЁН, созданное самим сведением. Оба набора тестов объявляли
глобального помощника pollCampaign - свой в СМС (один довод) и свой в
Телеграме (от двух до четырёх). Две функции с одним именем в одном языке
не живут: пока ветки шли врозь, этого не видел никто. Помощник СМС
переименован в pollSmsCampaign. Проверено, что других таких пар в PHP-тестах
нет ни одной.

Статанализ ветки доведён с 674 замечаний до НУЛЯ, уровень не понижен и в
baseline не заметено ничего.
  - 616 из 674 - ложный класс Pest, закрытый тремя узкими правилами; правила
    перенесены из рабочей ветки, где владелец их уже принял;
  - остальные 42 - свои, в новом коде ветки, и починены по существу:
    задвоенный ключ массива в трёх тестах (след копирования - комментарий
    оторвался от своей строки), врущие описания двух помощников (PHP сам
    делает из ключа-номера число), сужение типа возврата, прятавшее от
    анализатора свойства подставного отправителя, лишний знак вопроса и
    четыре бесполезных перенумерования списка.
  - Приёмка вырезанием: подложил несуществующий метод - анализатор назвал его
    поимённо и покраснел; убрал - ноль.

Шапки 59 моделей обновлены пересборкой подсказчика и ОСТАВЛЕНЫ намеренно
(правка только в комментариях, проверено): без них анализатор не связывает
модель с описанием и не знает, что дата - это дата, а не строка. Откатил их
сперва по привычке - получил 15 замечаний про даты, вернул - ноль.

Орфография: 15 файлов проверено, 0 замечаний (смотрел и на число
проверенных файлов, не только на число ошибок). Добавлены три слова из имён
миграций ветки.

Заодно: алиас ruflo-core в списке имён сторожа реестра - плагин описан в
реестре групповым именем, сторож видел только машинное. Мостится ТОЛЬКО имя;
🔴 содержательный долг остаётся - реестр до сих пор зовёт ruflo изолированным,
хотя его разморозили 28.07. Это чинить отдельно, через claude-md-management.

Проверено: три фронтовых сторожа рекламы 18/18, статанализ 0, разметка 0,
орфография 0, синтаксис PHP чист. Полный прогон тестов ветки - отдельным
шагом, он ещё ни разу не делался.

NB: в журнале схемы есть задвоенные номера v8.26 (пять раз) и v8.64 (два) -
это досталось по наследству из общей ветки, ровно столько же их там и было.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-01 19:50:41 +03:00

Дмитрий

fc235bb5a6

feat(смс-клиент): недоставленное закрывается через трое суток, деньги возвращаются клиенту

Этап 5, Task 4. ДЕНЕЖНАЯ задача — решения владельца В-198 и В-199.

Что появилось:
- через трое суток «ещё в пути» становится «не доставлено». Довод не только
  продуктовый: оператор помнит судьбу ровно трое суток, после этого ответа не
  будет вовсе — закрыть сообщение обязаны мы, иначе итог рассылки никогда не
  станет окончательным и досыл не будет знать, кого досылать;
- за «не доставлено» и за «оператор не отправил» деньги возвращаются клиенту на
  кошелёк. МТС за недоставленное с нас не берёт (В-7), значит эти рубли лежали
  у нас ни за что;
- у кошелька появился метод refund() — ОТДЕЛЬНО от пополнения, и это не
  украшение: у topup() нет ключа события, а команда по расписанию по своей
  природе повторяется. На topup() второй заход вернул бы деньги ДВАЖДЫ.

ИДЕМПОТЕНТНОСТЬ ДВОЙНАЯ, и проверено, что нужны обе опоры:
  - ключ события sms:refund:{рассылка}:{номер} + уникальный ключ в базе;
  - отметка refunded_at на сообщении, ставится в ТОЙ ЖЕ транзакции.
Вырез только ключа тест НЕ красит (спасает отметка). Вырез только отметки тоже.
Сняв ОБЕ, тест краснеет числом 117.00 вместо 108.50 — деньги вернулись дважды.
Так и должно быть: одна опора страхует другую.

Вырезы (все вернуты): убрать «оператор не отправил» из возвращаемых -> 1 красный;
убрать закрытие по сроку -> 3 красных; возвращать за ЛЮБУЮ судьбу -> 2 красных
(значит тесты «за доставленное не возвращаем» и «за в пути не возвращаем» —
настоящие приборы, а не зелень вхолостую).

ЖИВОЙ ДЕНЕЖНЫЙ ПРОГОН (sandbox выключен — в песочнице деньги не двигаются вовсе,
и прогон доказал бы НОЛЬ): баланс 100.00 -> 108.50 ₽, движение типа refund ровно
одно, отметка у недоставленного стоит, у доставленного нет. ВТОРОЙ заход той же
команды: баланс тот же, движений по-прежнему одно. Стенд возвращён в исходное.

Прогоны: модуль 343/343 (13 пачек, все с первой попытки), рекламный кошелёк 5/5
(я трогал общий AdWalletService), phpstan ровно 2 чужие давние, pint чисто.

2026-07-31 06:36:27 +03:00

Дмитрий

5356bf3ed6

feat(смс-клиент): опрос судьбы отправленных сообщений у операторов

Этап 5, Task 3. Появилась команда client-sms:poll-delivery — каждые десять минут
спрашивает у канала, что стало с отправленными сообщениями, и проставляет судьбу
в журнал.

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

ЖИВОЙ ПРОГОН ПОД БОЕВОЙ РОЛЬЮ, тройкой (политика srv_bypass воспроизведена тем же
текстом, что в db/03, — на стенде их нет ни одной):
  А) право UPDATE есть + политика есть -> «уточнено: 1», судьба delivered;
  Б) права UPDATE нет -> команда ПАДАЕТ «нет доступа к таблице» (видно);
  В) права есть, политики нет -> «успех», «уточнено: 0», судьба пустая (НЕ видно).
Подтверждает В-181: у двух опор разная цена отказа, и опаснее вторая. Стенд
вернулся в исходное, политик srv_bypass не осталось.

ПРО ПРИБОРЫ — два теста оказались НЕ приборами, починены, а не подогнаны:
- «незнакомое слово не меняет судьбу» не отличал «графу не тронули» от «записали
  пусто» — теперь у сообщения есть стартовая судьба, и проверяется, что она цела;
- «пробное не спрашиваем» краснел бы не от того: пробное отсекает фильтр по
  КАНАЛУ, а не по статусу. Переименован по тому, что реально охраняет, и под две
  оставшиеся защиты заведены свои тесты.
После починки каждый из четырёх вырезов добавляет ровно один красный тест.

Прогоны: модуль 336/336 (13 пачек, все с первой попытки), phpstan ровно 2 чужие
давние, pint чисто. Команда в расписании — проверено schedule:list.

2026-07-31 06:23:24 +03:00

3 Commits