tremble7681andClaude Opus 4.8 bbaef9bc7d fix(repairs): количество запчасти можно поменять — «залипшая единица» (4123)
Поле количества приводилось к минимуму на КАЖДЫЙ onChange
(`Math.max(1, Number(v))`), поэтому стирание единицы мгновенно возвращало
её обратно: набрать «4 свечи» было нельзя — цифра дописывалась и выходило
«14». Ровно этот же баг однажды чинили в цене работы (3b7b2ae), там ""
уже разрешено как промежуточное состояние стейта.

- общий QtyStepper: "" остаётся в стейте, пока печатают; приведение — на
  blur и ещё раз на отправке (пустое = 1 шт: строка есть, значит деталь
  ставили);
- тап по полю выделяет число — набор поверх заменяет, а не дописывает;
- кнопки −/+: 4 свечи набираются одним пальцем в перчатках, мобильная
  цифровая клавиатура для этого слишком долгая;
- то же в форме правки ремонта — там я повторил ту же ошибку при переводе
  запчастей на складской каталог;
- регрессионные тесты на стирание/blur/степпер: баг повторился второй раз
  на том же паттерне, пусть дальше ловится сам.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-30 16:16:43 +10:00

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)

S
Description
Premium Механик — PWA для механиков: приёмка и осмотр авто, фото с разметкой повреждений, ремонт и СТО, интеграция 1С (TT) + MinIO. Live: mechanic.pptaxi.ru
Readme
2.7 MiB
Languages
TypeScript 96.8%
Python 1.4%
CSS 1%
JavaScript 0.4%
HTML 0.2%
Other 0.2%