СервисТрек — учёт оборудования сервисной службы

Внутренняя система инвентаризации и учёта оборудования сервисного отдела компании. Реальный контекст: производство (площадки Волховец, Волотово, Захарьино, Рабочая 6, склад) — 342 единицы техники; далее подключаются магазины сети. Заявки приходят из MAX и на почту repair@osen-vn.com, учёт сегодня ведётся вручную в xlsx.

Стадия проекта: Этап 2 — демо на реальных данных опубликовано, интервью с заказчиком (см. docs/STATUS.md).

Что это за проект

Система должна уметь:

Реестр оборудования: что, где стоит, в каком состоянии, модель, серийный номер, дата установки, гарантия.
История работ: ремонты, замены запчастей, регламентные ТО — кто, когда, что сделал.
Склад запчастей: остатки, расход по работам, минимальные остатки, совместимость с моделями.
Регламентные работы: план ТО, задачи на месяц, просрочки.
Интеграция с мессенджером (Telegram / MAX): мастер пишет свободным текстом → ИИ разбирает сообщение → запись попадает в базу (ремонт, замена запчасти, выезд).
Дашборд: текущее состояние парка, задачи месяца, проблемное оборудование.

Как посмотреть демо (этап 2 — показ заказчику)

Онлайн: https://projects.gcetera.com/service-inventory/demo/ Локально: открыть файл demo/index.html (двойной клик). Демо автономное, данные — реальный перенос из рабочих xlsx производства + вымышленный сценарий «магазины» до данных от Марины. Пересборка после правок: python3 tools/build_demo.py (править demo/_template.html, не index.html).

Публичная витрина проекта

https://projects.gcetera.com — портал, демо и документы для заказчика. Обновление после изменений: bash deploy/deploy.sh (подробнее — docs/SERVER.md).

Структура проекта

service-inventory/
├── README.md            ← вы здесь: обзор проекта
├── AGENTS.md            ← инструкция для любой ИИ, как продолжать работу
├── docs/
│   ├── STATUS.md        ← ТЕКУЩАЯ стадия: что сделано, что дальше (обновлять каждую сессию!)
│   ├── VISION.md        ← видение продукта: цели, роли, функциональные блоки
│   ├── DATA-MODEL.md    ← схема данных: сущности, поля, статусы
│   ├── DECISIONS.md     ← журнал решений: какое решение приняли и почему
│   ├── INTERVIEW.md     ← вопросы для интервью с заказчиком + шаблон ТЗ
│   ├── SERVER.md        ← инфраструктура: серверы, публикация, деплой
│   └── CHANGELOG.md     ← история изменений проекта
├── demo/                ← демо-сайт: _template.html (шаблон) + vendor.qrcode.js → index.html (сборка)
├── tools/               ← build_demo.py — сборка демо из шаблона и data/source-xlsx
├── data/source-xlsx/    ← копии рабочих файлов заказчика (источник данных для демо/MVP)
├── deploy/              ← деплой и сборка публичных страниц
└── src/                 ← рабочий код (появится после интервью)

Правила ведения документации (критично!)

Контекст между сессиями передаётся через документацию; источник правды — git на сервере (projects:/srv/git/service-inventory.git, ветка main), локально — клон:

Перед началом работы любая ИИ (или человек) читает docs/STATUS.md и AGENTS.md.
После каждой рабочей сессии обновляется docs/STATUS.md (что сделали, что осталось), затем коммит и git push.
Любое архитектурное решение фиксируется в docs/DECISIONS.md с датой и обоснованием.
Ответы заказчика после интервью добавляются в docs/INTERVIEW.md и превращаются в ТЗ (docs/SPEC-DRAFT.md).
Рабочие xlsx заказчика кладутся в data/source-xlsx/ (копии), чтобы сборка демо была воспроизводимой.