mirror of
https://github.com/wasrusgen/zov-tech.git
synced 2026-06-03 15:24:48 +00:00
34b83899b5
#7 — submit-flow: - При успехе скрываем CTA с «Сохраняем...» (style.display=none) - Обработчики «Ещё клиент» / «Открыть карточку» прикрепляются к result-блоку (был form.querySelector — там их нет) - Backend возвращает client_key = name.lower() — совместимо с тем как ищет _handle_clients - clientsCache = null после успеха #3 — голос дублировался: - Переписан алгоритм: финальные транскрипты пересчитываются с нуля из ev.results[0..N] каждое событие (не аккумулируем дельтами). - confirmedFinal фиксируется в baseText только на onend. - Применено в measurements.js + clients.js #2 — телефон: - Frontend normalizePhone: убирает не-цифры, +7/8 → +7, добавляет +7 к 10-значным; auto-нормализация на blur - Backend _normalize_phone(): тот же алгоритм - Валидация: ровно 11 цифр начиная с 7 - Field-error «Введите корректный российский номер...» #1 — адрес: - Min 5 chars (улица + дом) - Backend проверка длины - Hint «Укажите город, улицу, дом, кв.» #5 — номер клиента: - Новая колонка client_no - _next_client_no() — максимум для текущего менеджера + 1 - Шильд #N рядом с именем в карточке клиента #6 — номер договора: - Новые колонки contract_no, contract_date - Поля в форме «Новый клиент» (опционально) - Шильд «📋 договор N» в карточке клиента #4 — удаление клиента: - Soft-delete через колонку archived_at - Endpoint /api/client_delete - «⚠️ Опасная зона» в карточке клиента (collapsible) - Confirm dialog через Telegram.WebApp.showConfirm - Архивированные клиенты не показываются в /api/clients #8 — правило самопроверки: - docs/SELF_CHECK_RULE.md — 10 пунктов чек-листа перед «готово» (end-to-end, ключи, UI-состояния, валидация, голос, deploy, логи) Cache bust v=20260514a.
77 lines
4.2 KiB
Markdown
77 lines
4.2 KiB
Markdown
# Правило самопроверки перед выдачей на тест
|
||
|
||
**Действует на каждый коммит/PR в `master`.**
|
||
|
||
## Чек-лист перед «готово, тестируй»
|
||
|
||
### 1. Поток end-to-end на бумаге
|
||
|
||
Каждое новое действие пользователя пройти мысленно от UI до Sheets:
|
||
- ✅ Пользователь нажимает «Сохранить»
|
||
- ✅ Frontend отправляет POST → правильный endpoint + правильный body
|
||
- ✅ Backend валидирует → пишет в Sheets с правильным набором колонок
|
||
- ✅ Backend возвращает ответ → frontend меняет UI (НЕ зависает «Сохраняем...»)
|
||
- ✅ Следующее действие (например «Открыть карточку») находит ровно эту запись
|
||
|
||
### 2. Ключи и идентификаторы
|
||
|
||
При создании сущности проверить что **возвращаемый ID/key совпадает с тем по которому потом ищется**:
|
||
- Если backend возвращает `client_key`, а frontend ищет по `name.lower()` — БАГ
|
||
- Если создаём `Measurement` с `manager_tg_id=A`, а `/api/measurements` фильтрует по `requested_by_tg_id` — БАГ
|
||
|
||
### 3. Состояния UI
|
||
|
||
После любого POST:
|
||
- Кнопка «Сохраняем...» должна СБРОСИТЬСЯ (или замениться, или скрыться)
|
||
- Не должно быть «зависших» загрузчиков
|
||
- Сообщение об ошибке/успехе должно быть видно
|
||
- Обработчики новых кнопок должны привязываться к НУЖНОМУ контейнеру (`result.querySelector` ≠ `form.querySelector`)
|
||
|
||
### 4. Валидация ввода
|
||
|
||
Для каждого поля формы спросить:
|
||
- Минимальная длина / формат?
|
||
- Нормализация (телефон в +7XXXXXXXXXX, имя trim'ить)?
|
||
- Дубликаты (тот же телефон уже есть)?
|
||
- XSS-эскейпинг при отображении?
|
||
|
||
### 5. Удаление и редактирование
|
||
|
||
Для каждой создаваемой сущности заложить:
|
||
- Возможность удалить (с подтверждением)
|
||
- Возможность отредактировать
|
||
- Soft-delete (флаг `archived`) предпочтительнее hard-delete
|
||
|
||
### 6. Нумерация
|
||
|
||
Для бизнес-сущностей (клиент, замер, договор) — **последовательный человекочитаемый номер** в дополнение к UUID. Иначе пользователь не сможет ссылаться на «клиента №123».
|
||
|
||
### 7. Голосовой ввод
|
||
|
||
При работе с SpeechRecognition:
|
||
- Финальные транскрипты не должны дублироваться
|
||
- Промежуточные не должны накапливаться
|
||
- При повторных запусках записи — продолжение, не сброс
|
||
|
||
### 8. Деплой и кэш
|
||
|
||
- Bump `v=...` в `index.html` для каждого изменения статики
|
||
- Дождаться раскатки GH Pages (~30 сек) перед уведомлением о готовности
|
||
- Backend redeploy: `docker compose build && up -d` ИЛИ `docker cp` + `restart` если Docker Hub rate-limit
|
||
|
||
### 9. Логи и наблюдение
|
||
|
||
После деплоя — заглянуть в `docker logs zov-backend --tail 20`:
|
||
- Нет ли `[WARN]` про новые endpoints
|
||
- При первом тестовом запросе — увидеть его в логах
|
||
|
||
### 10. Документация
|
||
|
||
Если коммит вводит **новый workflow** — описать его краткое:
|
||
- В коммит-сообщении
|
||
- В README или CHANGELOG если есть
|
||
|
||
---
|
||
|
||
**Применять до каждого «готово, тестируй» сообщения пользователю.**
|