Журнал решений (ADR)
Новые решения добавлять СВЕРХУ. Формат: номер, дата, статус, решение, почему, альтернативы.
D15 · 2026-08-22 · принято
Решение: MVP реализован: src/ — Fastify
+ встроенный node:sqlite (Node ≥ 22.5, без нативных
модулей), импорт трёх xlsx идемпотентным скриптом
src/tools/import-xlsx.mjs. API слушает только
127.0.0.1:8090 на .26 (systemd servicetrack), наружу не
публикуется до появления авторизации. Почему: нулевое
администрирование БД, минимум зависимостей; публикация сырого API в
интернет недопустима. Альтернатива better-sqlite3 отклонена (компиляция
нативного модуля на двух ОС). Находка импорта: в
«Заявках производства» дубли номеров (№269×8, №420×2, №463×2) — вынесено
на интервью; номер оставлен не-UNIQUE.
D14 · 2026-08-22 · принято
Решение: Два бота MAX как два аккаунта (два токена) поверх одного движка диалогов: бот «Заявки» (анкета-приём для всех сотрудников) и бот «Мастер» (лента заявок + чеклист выполнения). Общий чат производства на первом этапе не трогаем; позже можно добавить туда бота-«наблюдателя» с ИИ-распознаванием заявок. Почему: запрос владельца; анкеты дают структурированные данные вместо «отсебятины» из Excel, а разделение ботов не путает роли.
D13 · 2026-08-22 · принято
Решение: ИИ никогда не пишет в БД напрямую. Единственный писатель — backend: llm-adapter переводит свободный текст в JSON, правила валидируют, человек подтверждает карточку, затем INSERT. Чеклисты по кнопкам работают без ИИ вообще. Почему: предсказуемость данных (номера, остатки, статусы), работоспособность при недоступности модели, простота аудита. Альтернатива «ИИ-агент с доступом к базе» отклонена как рискованная на старте.
D12 · 2026-08-22 · принято
Решение: Источник правды — bare-git репозиторий НА
СЕРВЕРЕ: projects:/srv/git/service-inventory.git (ветка
main). Локальная папка — клон; в конце каждой сессии обязателен
git push. Почему: локальные файлы проекта
были удалены владельцем вместе с git-историей. Сервер .26 надёжен (LXC,
бэкапы Proxmox планируются) и доступен с любого ПК.
D11 · 2026-08-22 · принято
Решение: Демо собирается автоматически:
python3 tools/build_demo.py берёт шаблон
demo/_template.html, реальные xlsx из
data/source-xlsx/ и библиотеку QR
(demo/vendor.qrcode.js), генерирует самодостаточный
demo/index.html. Ручные правки index.html запрещены —
только через шаблон/скрипт. Почему: данные будут
обновляться (файлы Марины по магазинам) — пересборка одной командой без
ручного переноса 342+ строк.
D10 · 2026-08-22 · принято
Решение: В демо добавлена вкладка «QR-метки»:
печатный лист этикеток для реальных единиц + сценарий сканирования в
мастер-боте; QR также в карточке оборудования. Библиотека
qrcode-generator (MIT, Kazuhiko Arase) встроена в файл.
Почему: запрос владельца показать заказчику механику
QR; payload — будущий адрес
https://projects.gcetera.com/e/<инв№>.
D9 · 2026-08-22 · принято
Решение: Демо переведено с вымышленных данных на
реальный перенос из трёх рабочих xlsx (копии в
data/source-xlsx/): инвентаризация производства (342 ед.,
площадки Волховец/Волотово/Захарьино/Рабочая 6/Склад), заявки (564),
заказы (410). Вымышленный сценарий «сеть магазинов» сохранён как
отдельная вкладка-заготовка до данных Марины. Почему:
заказчик должен узнать свои процессы и объём; вымышленные витрины Polair
вводили в заблуждение — производство это цеха и котельные.
D8 · 2026-08-22 · принято
Решение: Инфраструктура из двух узлов: сервер
проектов 10.90.21.26 (Debian 13, LXC — контент, приложения,
БД) и фронтовой nginx-прокси 10.90.21.21 (существующий, там
же другие домены компании). Публикация:
https://projects.gcetera.com → proxy_pass на
.26. Детали в docs/SERVER.md.
Почему: заказчик должен видеть демо и прогресс онлайн;
прокси вынесен туда, где уже terminates TLS для остальных доменов
(единая схема Let's Encrypt).
D7 · 2026-08-22 · принято
Решение: Документы проекта публикуются как HTML,
генерируемый pandoc'ом из .md при каждом деплое
(deploy/refresh-public.sh); исходники .md тоже
выкладываются рядом (status/md/). Портал со списком
проектов — статический deploy/assets/portal-index.html →
/srv/www/index.html. Почему: заказчик
читает статус и документы в браузере без доступа к репозиторию; сборка
воспроизводима одной командой.
D6 · 2026-08-22 · принято
Решение: Сервер проектов — единый каталог
/srv/projects/<проект>/repo (копия репозитория) +
публикация в /srv/www/<путь>/; деплой через rsync с
ПК владельца; источник правды — git на ПК. Почему:
владелец ведёт все проекты на одном сервере; rsync не требует git на
сервере и исключает случайные правки напрямую в проде.
D5 · 2026-08-22 · принято
Решение: Демо для заказчика — один самодостаточный HTML-файл без сборки и зависимостей. Почему: открывается двойным кликом на любом ПК, легко править любой ИИ, ничего нельзя сломать зависимостями. Альтернативы: React/Next.js макет — избыточно для показа, требует npm install и dev-сервера.
D4 · 2026-08-22 · принято
Решение: Первый канал для мастеров — Telegram Bot API; архитектура предусматривает абстракцию канала, чтобы позже добавить MAX без переписывания логики разбора сообщений. Почему: Telegram Bot API зрелый, бесплатный, привычен пользователям; MAX — российский мессенджер, поддержка появится по требованию заказчика после интервью.
D3 · 2026-08-22 · принято
Решение: Разработка только локально на этом ПК;
git-репозиторий обязателен с первого дня. Почему: урок
из аудита проекта Magnika (Magnika_Handover_Report.md):
отсутствие git — риск №1, потеря контекста и кода. Здесь код и история
изменений должны пережить любые сессии ИИ.
D2 · 2026-08-22 · принято (предварительно, подтвердить после интервью)
Решение: Целевой стек рабочего приложения — Node.js (без сборки фронтенда: сервер раздаёт статические страницы + JSON API) + SQLite как БД. Почему: на ПК есть node v24 и sqlite3, нет Docker; SQLite не требует отдельного сервиса, бэкапится копированием одного файла, масштаба (сотни единиц оборудования) хватает с запасом. Альтернативы: Python FastAPI + PostgreSQL (системный python старый 3.9); PostgreSQL понадобится только при многопользовательском сетевом доступе — вернуться к вопросу, если заказчик захочет веб-доступ для нескольких пользователей одновременно.
D1 · 2026-08-22 · принято
Решение: Подход «демо-first»: сначала показать заказчику кликабельный макет с реалистичными данными, провести интервью, собрать ТЗ, и только потом писать рабочий код. Почему: дешевле скорректировать ожидания на макете, чем переделывать готовую систему; заодно интервью выявит реальные процессы (регламент ТО, учёт запчастей, отчётность мастеров).
D0 · 2026-08-22 · принято
Решение: Контекст проекта передаётся через
документацию в docs/; docs/STATUS.md — точка
входа, обновляется каждую сессию; решения фиксируются здесь (этот файл).
Почему: требование владельца проекта: любая ИИ должна
иметь возможность продолжить работу без потери контекста.