mirror of https://github.com/wasrusgen/zov-tech.git synced 2026-06-03 20:04:48 +00:00

wasrusgen 34b83899b5 fix client create — 7 багов + правило самопроверки

#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.

2026-05-14 00:09:14 +03:00

4.2 KiB

Raw Blame History

Правило самопроверки перед выдачей на тест

Действует на каждый коммит/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 если есть

Применять до каждого «готово, тестируй» сообщения пользователю.

4.2 KiB Raw Blame History Unescape Escape