tremble7681andClaude Opus 5
5dbf9b1549
Задача CRM 4439. Плитка в меню действий → поиск по госномеру → список ремонтов машины (дата, госномер, модель, пробег, состав работ) → существующая карточка ремонта. Вход в историю есть и прямо из карточки авто, там же блок последних ремонтов. Что стоило внимания: - поиск ищет и по машинам, выведенным из парка (их ремонты никуда не делись, и в осмотрах такая машина видна), но не по проданным — парк ими не занимается. Текст пустого результата говорит ровно это: механик с опечаткой в номере делает вывод по этой строке, и она обязана совпадать с поведением бэкенда; - сбой сети отличим от «ничего не нашли», и под ошибкой не остаётся выдача прошлого запроса — иначе можно тапнуть и уехать в историю чужой машины; - «Назад» возвращает туда, откуда пришли (лента, история машины, карточка авто), а не в ленту всего парка. Прямая ссылка при пустом стеке не запирает экран; - форма правки больше не оставляет лишнюю запись в стеке: до этого «Назад» из карточки ремонта после «Отмены» возвращал обратно в форму правки; - история и блок в карточке авто запрашивают ленту без фото — превью там не рисуется, а бэкенд ради него лазил в хранилище на каждую строку. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mechanic-pwa
Собственное приложение для сотрудников-механиков PremiumPark — замена вендорского приложения «Механик» (NaughtySoft, com.naughtysoft.ttc). Все данные осмотров уходят в собственную PostgreSQL внутри Premium CRM, фото — в собственный MinIO. Никакого вендора и его 1С на критическом пути.
Контекст
Сейчас механики PremiumPark делают осмотры машин через приложение вендора NaughtySoft, поставляемое на условиях абонентки. Подрядчик заморозил разработку, парк хочет независимости. После разведки вендорского стека (см. recon/findings/01-static-analysis.md) принято решение строить собственное PWA — оно охватывает все ключевые сценарии вендора (фото, метки повреждений, история, дифф «было/стало») и хостится в нашей экосистеме.
Объём проекта
Только приложение механика. Это первый sub-project в umbrella-плане замены вендорских приложений. Будущие sub-projects (не в этом репозитории):
| Sub-project | Описание | Статус |
|---|---|---|
| mechanic-pwa (этот репо) | PWA для сотрудников-механиков парка | в работе |
| driver-app | Приложение для водителей — балансы, штрафы, платежи, обращения | отложено, будем после mechanic |
| vendor-bridge | Импорт исторических осмотров от вендора | отложено |
Структура
mechanic-pwa/ ← корень git репо
├── docs/superpowers/
│ ├── specs/
│ │ ├── 2026-05-11-driver-app-recon-design.md ← разведка обоих вендорских приложений
│ │ └── 2026-05-16-premium-mechanic-design.md ← дизайн нашего mechanic-приложения
│ └── plans/
│ └── 2026-05-16-premium-mechanic-phase1.md ← план реализации Phase 1 MVP
├── mechanic-pwa/
│ ├── frontend/ ← React+Vite PWA (создаётся в Phase G)
│ └── assets/vendor-reference/ ← извлечённые из APK иконки вендора
├── recon/
│ ├── findings/ ← отчёт разведки (карта API, диаграммы)
│ ├── scripts/ ← mitmproxy фильтры, frida-скрипты, утилиты
│ ├── artifacts/ ← APK, декомпил, mitm dumps (не в git, .gitignore)
│ └── patched/ ← патченые APK для перехвата трафика (не в git)
├── ops/
│ ├── Caddyfile.fragment ← конфигурация Caddy для mechanic.pptaxi.ru
│ └── minio-cors.json ← CORS policy для bucket pp-inspections
└── README.md
Внимание: backend-модуль
mechanic(Phase B-F плана) живёт не в этом репо, а в виде веткиfeat/mechanic-mvpвнутри репозиторияpremium-crm. Этот репо — только frontend + специфика, документация и ops.
Текущая фаза
Phase 1 MVP — см. docs/superpowers/plans/2026-05-16-premium-mechanic-phase1.md. 10 phases (A-J), ~40 задач, 3-4 недели разработки.
Деплой
Production URL: https://mechanic.pptaxi.ru (поддомен от 100.64.0.12, обслуживается Caddy)
Бэкенд: модуль mechanic в FastAPI Premium CRM (тот же VDS)
Хранилище фото: MinIO pp-inspections (тот же VDS)