Дневник разработки · обновляется по мере работы

Как мы строим FinderBot — день за днём

Мы открыто показываем, как развивается проект. Здесь — честная история разработки: что сделали, что было сложно, что узнали, что дальше. Это не релиз-нотс, это живой дневник команды.

1 запись с 2026-06-10
Источник: DOC/PUBLIC/DEV_DIARY/
Последние записи

Что было в работе команды

10 июня 2026·Тема: Admin Release Gate + Build-in-public rule

Admin Release Gate — прошли первую большую acceptance волну

Закрыли 7 ключевых направлений, прошли финальный browser E2E regression, закрепили правило build-in-public как часть продукта.

Сегодня сделали

  • Прошли финальный browser E2E regression — реально открыли 10 страниц админки и пользовательского кабинета
  • Закрыли 7 ключевых направлений: помощник, SLA, уведомления, run-trace, аудит ошибок доставки, активный reminder, build-in-public
  • Получили release decision: GO WITH NOTED FOLLOW-UPS
  • Закрепили правило build-in-public как часть работы проекта (этот пост — первый акт нового правила)

Что решили

  • Не переключать parser timer в active автоматически. Это сознательный выбор владельца — manual mode + понятное объяснение в UI + помощник умеет рассказать
  • Не отправлять реальные уведомления в ходе проверок. Любая publicly-affecting задача — только с owner confirmation
  • Не делать landing-страницу roadmap сразу — сначала закрепить правило в проекте

Почему это важно

FinderBot — это продукт, который должен быть прозрачным для владельца и пользователей. До этой волны помощник владельца отвечал «не смог прочитать» на простые вопросы про SLA или таймер парсера. Страница /admin/support показывала «авария без причины». Endpoint, через который должна была видна история запусков парсера, возвращал 500. Теперь помощник видит реальные числа уведомлений, умеет объяснить почему SLA устарел и что с этим делать; страница /admin/support явно показывает, что это не авария, а выбранная политика; endpoint /admin/factory/run-trace/recent возвращает реальные данные.

Что было сложно

Главный root cause в админ-помощнике оказался очень банальным: импорты указывали на модули, которых не существует. ImportError ловился — и пользователь видел «не смог прочитать». Это типичный случай, когда «честная отчётность об ошибке» в коде маскирует root cause от владельца. Понимание stale SLA как «expected behavior» (а не bug) потребовало нескольких итераций. Документировали decision matrix с 4 опциями — это помогло отделить «срочный фикс» от «прозрачное объяснение».

Что дальше

  • Создать публичную страницу roadmap на лендинге (визуальная progress timeline)
  • Регулярные daily updates в дневнике
  • Первый Telegram-пост для комьюнити (после owner approval)

Public-safe notes

  • 44 backend теста PASS на VPS (3 файла тестов от разных задач)
  • ~90+ скриншотов из реального production браузера под owner-сессией
  • 0 critical HTTP 500 в финальной проверке
  • 0 изменений production state в ходе release gate (никаких писем, тиков, политик)
Куда движется проект

Дневник связан с открытой дорожной картой

Каждое решение из дневника появляется на дорожной карте. Хронология проекта собрана отдельно — лента ключевых событий по датам.

Прогресс проекта
обновлено 10 июня 2026

7 закрыто · 4 в работе · 12 в планах

23 пункта на открытой карте. 30% уже сделано. Каждый закрытый пункт сопровождён записью в этом дневнике.

Открыть карту
Следить за развитием

Подпишитесь — и увидите, как проект развивается

Новые записи дневника, релизы, решения — всё открыто. Никакого маркетингового шума, только реальная работа.