Похоже, исходных “данных” в этом чате нет. Ниже даю удобный шаблон техзадания (ТЗ) с готовыми разделами и чек-листами. Заполните выделенные места — и я соберу из этого финальную версию без лишних вопросов.

Шаблон ТЗ для разработчиков

Проект: ‹название›
Версия ТЗ: ‹v1.0› • Дата: ‹ДД.ММ.ГГГГ› • Владелец: ‹ФИО/роль›

1) Цель и контекст

• Бизнес-цель: ‹какую проблему решаем и как измерим успех (метрика/целевое значение)›
• Целевая аудитория: ‹сегменты пользователей, ключевые персоны›
• Ограничения/допущения: ‹платформы, бюджет, сроки, регуляторика›

2) Область работ (In/Out of scope)

• In scope: ‹что точно делаем›
• Out of scope: ‹что точно не делаем сейчас›

3) Роли и доступы

• Роли: ‹Админ, Менеджер, Пользователь…›
• Матрица прав (CRUD по сущностям):

  Сущность	Просмотр	Создание	Изменение	Удаление
  ‹Сущность›	✅/❌	✅/❌	✅/❌	✅/❌

4) Пользовательские сценарии (use cases)

Коротко по схеме: Когда… Пользователь… Тогда…

• UC-1: ‹описание шага за шагом›
• UC-2: ‹…›

5) Функциональные требования

Записываем как проверяемые требования (Given/When/Then):

• FR-1: Given ‹предусловие›, When ‹действие›, Then ‹результат›.
• FR-2: …

6) Нефункциональные требования

• Производительность: ‹например, P95 время отклика ≤ ‹X› мс при ‹N› RPS›
• Надёжность: ‹SLO/SLI, аптайм, бэкапы, ретенции›
• Безопасность: ‹OAuth2/SSO, шифрование в покое/транзите, секрет-менеджмент›
• Совместимость: ‹браузеры/OS/устройства›
• Локализация/часы/валюты: ‹языки, форматы›
• Доступность (a11y): ‹уровень WCAG, требования к навигации с клавиатуры›
• Логи/аудит: ‹какие события, уровни, хранилище›

7) Модель данных

Сущности и поля (минимальный ER-скетч текстом):

• ‹Entity›(id ‹UUID›, ‹поле›:тип:обязательность, …), связи: ‹1-N/N-M›
• Правила валидации/уникальности/индексы.

8) API-контракты (если применимо)

Базовый URL: ‹…›
POST /v1/‹resource› — создать
Request:

json
{
  "name": "string (1..80)",
  "email": "email",
  "tags": ["string"],
  "meta": {"key": "value"}
}

Response 201:

json
{"id":"uuid","createdAt":"ISO-8601"}

Ошибки: 400 ‹валидация›, 401, 403, 404, 409, 429, 5xx (тела ошибок по RFC 7807/Problem+JSON).

Повторите для всех эндпоинтов: GET list/detail, PATCH/PUT, DELETE, пагинация (limit/offset или cursor), сортировка/фильтры.

9) UI/UX (если есть фронтенд)

• Карты экранов: ‹перечень экранов›
• Состояния: загрузка/пусто/ошибки/пагинация
• Компоненты: ‹таблицы, формы, поля, маски, хинты›
• Правила валидации на клиенте

10) Интеграции

• Системы: ‹CRM, платёжка, почта, внешние API›
• Протоколы/методы: ‹webhook, REST, gRPC, S3›
• SLA внешних систем, таймауты, ретраи, идемпотентность

11) Миграции и данные

• Импорт/экспорт: форматы (CSV/JSON), объёмы, дедупликация
• Миграции БД: порядок, откаты, блокирующие/онлайн

12) Мониторинг и алерты

• Метрики: RPS, ошибки по кодам, P95/P99
• Дашборды/алерты: пороги, каналы уведомлений

13) Тестирование и приемка

• Уровни: unit/ интеграционные/ e2e
• Набор тест-кейсов по ключевым UC
• Критерии приемки (DoD): список проверяемых пунктов, см. ниже.

14) Планы и риски

• Этапы/вехи (milestones): ‹M1, M2…›
• Риски и планы обхода: ‹технические, продуктовые›

15) Приложения

• Глоссарий терминов
• Макеты/линки на прототипы
• Чек-листы

---

Чек-лист критериев приёмки (пример)

• Все API отвечают за ≤ ‹X› мс (P95) при ‹N› RPS
• Роли и ACL покрыты автотестами
• Локальные и серверные валидации совпадают
• Логи по критическим событиям попадают в ‹систему› за ≤ 30 сек
• Ошибки формата RFC 7807
• Документация OpenAPI 3.0 доступна по /swagger
• Покрытие unit-тестами ≥ ‹Y›% на критичных модулях

---

Мини-пример заполнения (для ориентира)

Проект: «Заявки на обслуживание оборудования»
Цель: сократить SLA обработки заявок с 5 до 2 дней, увеличить NPS на 15%.

Роли: Админ, Диспетчер, Техник, Клиент.

UC-1 (Клиент создает заявку):
Given авторизованный Клиент, When заполняет форму (оборудование, описание, фото) и нажимает «Отправить», Then система создает заявку в статусе Новая, отправляет e-mail подтверждение и пуш Диспетчеру.

FR-1: Статус заявки автоматически меняется на В работе при назначении Техника.
FR-2: При загрузке фото до 10 МБ выполняется антивирусная проверка; неподходящие форматы отклоняются.

НФ-требования: P95 ≤ 400 мс при 50 RPS; SLO аптайм 99.9%; OAuth2 + MFA; шифрование TLS 1.2+ и AES-256 at rest.

Модель данных (фрагмент):

• Ticket(id UUID, createdAt, status ENUM[New, InProgress, Done, Rejected], priority ENUM[Low,Med,High], customerId UUID, technicianId UUID?)
• Индексы: (status, priority, createdAt), (customerId, createdAt)

API (фрагмент):
POST /v1/tickets → 201 {id, createdAt, status:"New"}
GET /v1/tickets?status=InProgress&limit=50&cursor=…
Идемпотентность: заголовок Idempotency-Key.

Приемка (фрагмент):

• Создание заявки с 3 фото (по 8 МБ) — проходит; некорректный формат — 400
• Автопереход статуса при назначении Техника — работает
• Уведомления Диспетчеру в ≤ 10 сек

---

Что нужно от вас, чтобы я собрал точное ТЗ

Скопируйте в ответ и заполните кратко:

1. О проекте (1–2 предложения): ‹…›
2. Роли: ‹…›
3. Ключевые сценарии (3–6 пунктов): ‹…›
4. Ограничения (сроки, платформы, интеграции): ‹…›
5. Метрики успеха: ‹…›
6. Особые правила/бизнес-логика: ‹…›

Как только добавите эти пункты (можно тезисно), я оформлю из них готовое ТЗ в строгом формате.