diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts
index 61ceb80..4533426 100644
--- a/docs/.vitepress/config.ts
+++ b/docs/.vitepress/config.ts
@@ -13,17 +13,17 @@ export default defineConfig({
{
text: 'Техническое задание',
items: [
- { text: '0. Общие положения', link: '/' },
- { text: '1. Основания для разработки и нормативные материалы', link: '/tz/normative-base' },
- { text: '2. Назначение и границы программного продукта', link: '/tz/product-scope' },
- { text: '3. Роли пользователей и права доступа', link: '/tz/roles-access' },
- { text: '4. Функциональные требования', link: '/tz/functional-requirements' },
- { text: '5. Требования к данным и интеграциям', link: '/tz/data-integrations' },
- { text: '6. Техническая архитектура, стек и состав компонентов', link: '/tz/technical-architecture' },
- { text: '7. Структура данных и модель базы данных', link: '/tz/database-model' },
- { text: '8. Нефункциональные требования', link: '/tz/non-functional-requirements' },
- { text: '9. Экранные формы и прототипы интерфейсов', link: '/tz/stage-1/' },
- { text: '10. Порядок приемки и состав передаваемых материалов', link: '/tz/acceptance' },
+ { text: '1. Общие положения', link: '/' },
+ { text: '2. Основания для разработки и нормативные материалы', link: '/tz/normative-base' },
+ { text: '3. Назначение и границы программного продукта', link: '/tz/product-scope' },
+ { text: '4. Роли пользователей и права доступа', link: '/tz/roles-access' },
+ { text: '5. Функциональные требования', link: '/tz/functional-requirements' },
+ { text: '6. Требования к данным и интеграциям', link: '/tz/data-integrations' },
+ { text: '7. Техническая архитектура, стек и состав компонентов', link: '/tz/technical-architecture' },
+ { text: '8. Структура данных и модель базы данных', link: '/tz/database-model' },
+ { text: '9. Нефункциональные требования', link: '/tz/non-functional-requirements' },
+ { text: '10. Экранные формы и прототипы интерфейсов', link: '/tz/stage-1/' },
+ { text: '11. Порядок приемки и состав передаваемых материалов', link: '/tz/acceptance' },
],
},
{
diff --git a/docs/index.md b/docs/index.md
index 67b9a7e..5f8fb43 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,6 +1,6 @@
# Техническое задание на разработку программного продукта
-## 0. Общие положения
+## 1. Общие положения
Наименование программного продукта: `Личный кабинет Фрегат`.
@@ -14,7 +14,7 @@
Настоящее техническое задание устанавливает требования к составу, функциям, данным, интеграциям, интерфейсным формам, условиям приемки и составу материалов, подлежащих передаче заказчику по результатам выполнения работ.
-## 0.1 Назначение программного продукта
+## 1.1 Назначение программного продукта
Программный продукт предназначен для автоматизации взаимодействия между ООО `Фрегат Групп` и B2B-клиентами компании в части:
@@ -27,11 +27,11 @@
- направления клиентских уведомлений
- ведения бонусной и реферальной программы
-## 0.2 Объект автоматизации
+## 1.2 Объект автоматизации
Объектом автоматизации являются процессы клиентского обслуживания и внутренней обработки заявок, выполняемые менеджерами ООО `Фрегат Групп` при работе с готовой и индивидуальной продукцией.
-## 0.3 Состав системы
+## 1.3 Состав системы
В состав программного продукта входят:
@@ -44,7 +44,7 @@
- модуль бонусной программы
- модуль административных настроек
-## 0.4 Общие принципы работы системы
+## 1.4 Общие принципы работы системы
Система должна обеспечивать следующие базовые принципы:
@@ -54,16 +54,16 @@
- история изменений по заявкам, заказам и бонусным операциям фиксируется в системе
- сведения о товарах, остатках, заказах и статусах могут обновляться из внешней учетной системы
-## 0.5 Содержание технического задания
+## 1.5 Содержание технического задания
-1. [Основания для разработки и нормативные материалы](/tz/normative-base)
-2. [Назначение и границы программного продукта](/tz/product-scope)
-3. [Роли пользователей и права доступа](/tz/roles-access)
-4. [Функциональные требования](/tz/functional-requirements)
-5. [Требования к данным и интеграциям](/tz/data-integrations)
-6. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
-7. [Структура данных и модель базы данных](/tz/database-model)
-8. [Нефункциональные требования](/tz/non-functional-requirements)
-9. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
-10. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
-11. [Приложение. Текущее состояние программного продукта](/appendix/current-state)
+2. [Основания для разработки и нормативные материалы](/tz/normative-base)
+3. [Назначение и границы программного продукта](/tz/product-scope)
+4. [Роли пользователей и права доступа](/tz/roles-access)
+5. [Функциональные требования](/tz/functional-requirements)
+6. [Требования к данным и интеграциям](/tz/data-integrations)
+7. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
+8. [Структура данных и модель базы данных](/tz/database-model)
+9. [Нефункциональные требования](/tz/non-functional-requirements)
+10. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
+11. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
+12. [Приложение. Текущее состояние программного продукта](/appendix/current-state)
diff --git a/docs/tz/acceptance.md b/docs/tz/acceptance.md
index 3d5a5a0..d397d6a 100644
--- a/docs/tz/acceptance.md
+++ b/docs/tz/acceptance.md
@@ -1,6 +1,6 @@
-# 10. Порядок приемки и состав передаваемых материалов
+# 11. Порядок приемки и состав передаваемых материалов
-## 10.1 Общие положения приемки
+## 11.1 Общие положения приемки
Приемка результата работ должна подтверждать соответствие программного продукта требованиям настоящего технического задания, условиям договора и согласованным требованиям заказчика.
@@ -16,7 +16,7 @@
- бонусный и реферальный контур
- интеграционный обмен в согласованном объеме
-## 10.2 Критерии приемки
+## 11.2 Критерии приемки
Программный продукт считается соответствующим требованиям, если:
@@ -28,7 +28,7 @@
- менеджер имеет возможность обработать заявку и опубликовать условия
- история изменений сохраняется и доступна в предусмотренных сценариях
-## 10.3 Состав передаваемых материалов
+## 11.3 Состав передаваемых материалов
В состав передаваемых заказчику материалов должны входить:
@@ -40,7 +40,7 @@
- описание состава пользовательских ролей и прав доступа
- материалы, необходимые для сопровождения и эксплуатации продукта
-## 10.4 Требования к документации
+## 11.4 Требования к документации
Передаваемая документация должна позволять:
@@ -49,7 +49,7 @@
- сопровождать клиентский и менеджерский контуры
- использовать систему в рамках согласованных ролей и сценариев
-## 10.5 Порядок фиксации замечаний
+## 11.5 Порядок фиксации замечаний
Каждое замечание, выявленное при приемке, должно содержать:
diff --git a/docs/tz/data-integrations.md b/docs/tz/data-integrations.md
index ae74a78..f7a6e12 100644
--- a/docs/tz/data-integrations.md
+++ b/docs/tz/data-integrations.md
@@ -1,6 +1,6 @@
-# 5. Требования к данным и интеграциям
+# 6. Требования к данным и интеграциям
-## 5.1 Основные сущности данных
+## 6.1 Основные сущности данных
Система должна оперировать следующими основными сущностями:
@@ -20,9 +20,9 @@
- бонусная операция
- заявка на использование либо вывод бонусов
-## 5.2 Обязательные данные по сущностям
+## 6.2 Обязательные данные по сущностям
-### 5.2.1 Пользователь
+### 6.2.1 Пользователь
Обязательные данные:
@@ -35,7 +35,7 @@
- связанный контрагент
- подключенные каналы уведомлений
-### 5.2.2 Контрагент
+### 6.2.2 Контрагент
Обязательные данные:
@@ -47,7 +47,7 @@
- контактные лица
- закрепленный менеджер
-### 5.2.3 Товар
+### 6.2.3 Товар
Обязательные данные:
@@ -60,7 +60,7 @@
- остатки по складам
- признаки доступности и кастомизации
-### 5.2.4 Заявка на заказ
+### 6.2.4 Заявка на заказ
Обязательные данные:
@@ -76,7 +76,7 @@
- стоимость после обработки
- условия поставки после обработки
-### 5.2.5 Заявка на расчет
+### 6.2.5 Заявка на расчет
Обязательные данные:
@@ -90,7 +90,7 @@
- стоимость после обработки
- условия поставки после обработки
-### 5.2.6 Заказ
+### 6.2.6 Заказ
Обязательные данные:
@@ -103,7 +103,7 @@
- условия поставки
- ссылка на исходную клиентскую заявку
-### 5.2.7 Бонусная операция
+### 6.2.7 Бонусная операция
Обязательные данные:
@@ -115,7 +115,7 @@
- дата и время операции
- текущий статус операции
-## 5.3 Требования к данным каталога
+## 6.3 Требования к данным каталога
Для каждой позиции и для каждого товарного направления система должна хранить и отображать:
@@ -128,7 +128,7 @@
- остатки по складам
- сведения об актуальности данных
-## 5.4 Требования к интеграции с 1С
+## 6.4 Требования к интеграции с 1С
Интеграция с 1С должна обеспечивать обмен данными, необходимыми для сопровождения каталога и заказов.
@@ -141,7 +141,7 @@
- статусы заказов
- изменения состава, стоимости, доставки и иных существенных параметров заказа
-## 5.5 Требования к интеграционному обмену
+## 6.5 Требования к интеграционному обмену
Интеграционный слой должен обеспечивать:
@@ -151,7 +151,7 @@
- повторную обработку неуспешных сообщений
- хранение истории обновлений по интеграционным операциям
-## 5.6 Требования к журналированию данных
+## 6.6 Требования к журналированию данных
Для ключевых действий и изменений система должна сохранять:
@@ -162,7 +162,7 @@
- дату и время изменения
- пользователя либо источник, выполнивший изменение
-## 5.7 Требования к данным бонусного контура
+## 6.7 Требования к данным бонусного контура
Для бонусной и реферальной программы система должна хранить:
diff --git a/docs/tz/database-model.md b/docs/tz/database-model.md
index 01883df..dc58f20 100644
--- a/docs/tz/database-model.md
+++ b/docs/tz/database-model.md
@@ -1,6 +1,6 @@
-# 7. Структура данных и модель базы данных
+# 8. Структура данных и модель базы данных
-## 7.1 Общие положения
+## 8.1 Общие положения
Основное хранилище данных программного продукта реализуется на `PostgreSQL`. Прикладной доступ к данным осуществляется через `Prisma ORM`.
@@ -18,7 +18,7 @@
- уведомлений и мессенджерных подключений
- бонусных и реферальных сущностей
-## 7.2 Логические группы сущностей
+## 8.2 Логические группы сущностей
В модели базы данных выделяются следующие логические группы:
@@ -29,7 +29,7 @@
- бонусный и реферальный контур
- административные настройки каталога
-## 7.3 Справочник пользователей и компаний
+## 8.3 Справочник пользователей и компаний
Базовые сущности группы:
@@ -57,7 +57,7 @@
- один пользователь может иметь несколько адресов доставки
- один пользователь может иметь несколько подключенных мессенджеров
-## 7.4 Каталог и складской контур
+## 8.4 Каталог и складской контур
Базовые сущности группы:
@@ -97,7 +97,7 @@
- разрешение на индивидуальную надпись
- списки стандартных значений ширины, длины, толщины, втулки, цвета и надписи
-## 7.5 Корзина и заказный контур
+## 8.5 Корзина и заказный контур
Базовые сущности группы:
@@ -121,7 +121,7 @@
- заказ хранит состав позиций, статус, стоимость, условия поставки и историю изменений
- события статуса обеспечивают аудит переходов между состояниями
-## 7.6 Бонусный и реферальный контур
+## 8.6 Бонусный и реферальный контур
Базовые сущности группы:
@@ -135,7 +135,7 @@
- хранение бонусных начислений и списаний
- хранение заявок на использование либо вывод бонусов
-## 7.7 Основные связи между сущностями
+## 8.7 Основные связи между сущностями
Укрупненная структура связей определяется следующими правилами:
@@ -147,7 +147,7 @@
- настройки параметров по товарному направлению хранятся в `CatalogProductTypeSetting`
- реферальные связи реализуются через `ReferralLink`, связывающий одного пользователя с другим пользователем
-## 7.8 Требования к хранению прикладных данных
+## 8.8 Требования к хранению прикладных данных
Модель базы данных должна обеспечивать:
@@ -157,7 +157,7 @@
- хранение истории статусов и действий
- хранение интеграционных идентификаторов для связи с внешними системами
-## 7.9 Требования к расширяемости модели
+## 8.9 Требования к расширяемости модели
Структура базы данных должна позволять:
diff --git a/docs/tz/functional-requirements.md b/docs/tz/functional-requirements.md
index 2d4c461..3209e8a 100644
--- a/docs/tz/functional-requirements.md
+++ b/docs/tz/functional-requirements.md
@@ -1,6 +1,6 @@
-# 4. Функциональные требования
+# 5. Функциональные требования
-## 4.1 Требования к регистрации и подключению клиентов
+## 5.1 Требования к регистрации и подключению клиентов
Система должна поддерживать два базовых сценария подключения клиента:
@@ -18,7 +18,7 @@
7. После завершения регистрации клиент должен получить доступ к личному кабинету.
8. Система должна поддерживать подключение доступных каналов уведомлений для клиентской учетной записи.
-## 4.2 Требования к каталогу готовой продукции
+## 5.2 Требования к каталогу готовой продукции
Система должна предоставлять клиенту каталог готовой продукции без отображения цены до обработки менеджером.
@@ -33,7 +33,7 @@
7. Система должна исключать отображение стоимости до момента публикации условий менеджером.
8. Для параметров товара система должна отображать пояснения, помогающие клиенту понять назначение параметра и ограничения выбора.
-## 4.3 Требования к параметрам каталога и кастомизации
+## 5.3 Требования к параметрам каталога и кастомизации
Система должна поддерживать настройку параметров по каждому товарному направлению.
@@ -47,7 +47,7 @@
6. Наборы стандартных параметров должны редактироваться в административном контуре.
7. Изменение набора стандартных параметров не должно приводить к потере уже сохраненных заказных данных.
-## 4.4 Требования к корзине и заявке на заказ
+## 5.4 Требования к корзине и заявке на заказ
Система должна позволять клиенту собрать корзину и направить заявку на заказ.
@@ -61,7 +61,7 @@
6. Для заявки должны сохраняться дата создания, инициатор и закрепленный менеджер.
7. До обработки менеджером стоимость в заявке не должна отображаться клиенту.
-## 4.5 Требования к обработке заявки менеджером
+## 5.5 Требования к обработке заявки менеджером
Менеджер должен иметь возможность обработать клиентскую заявку вручную.
@@ -77,7 +77,7 @@
8. Менеджер должен иметь возможность перевести заявку в работу.
9. Менеджер должен иметь возможность отменить заявку с фиксацией основания отмены.
-## 4.6 Требования к заявке на расчет индивидуальной продукции
+## 5.6 Требования к заявке на расчет индивидуальной продукции
Система должна поддерживать отдельный сценарий расчета продукции с индивидуальными параметрами.
@@ -101,7 +101,7 @@
- иные параметры в зависимости от вида продукции
- текстовый комментарий клиента
-## 4.7 Требования к статусам заявок
+## 5.7 Требования к статусам заявок
Система должна обеспечивать сквозное сопровождение заявок по статусам.
@@ -122,7 +122,7 @@
- пользователя или источник, выполнивший изменение
- комментарий, если он предусмотрен сценарием
-## 4.8 Требования к заказам и их сопровождению
+## 5.8 Требования к заказам и их сопровождению
Система должна предоставлять клиенту и менеджеру доступ к списку заказов и карточке каждого заказа.
@@ -135,7 +135,7 @@
5. В карточке заказа должна отображаться дата актуальности данных.
6. При наличии обновлений из внешней системы сведения по заказу должны синхронизироваться и отображаться пользователю.
-## 4.9 Требования к уведомлениям
+## 5.9 Требования к уведомлениям
Система должна поддерживать уведомления по нескольким каналам связи.
@@ -154,7 +154,7 @@
- изменение бонусного баланса
- обработка заявки на использование либо вывод бонусов
-## 4.10 Требования к бонусной и реферальной программе
+## 5.10 Требования к бонусной и реферальной программе
Система должна включать бонусный контур как самостоятельную функциональную область.
@@ -170,7 +170,7 @@
8. Менеджер должен иметь возможность обрабатывать операции бонусного контура.
9. Система должна уведомлять клиента об изменениях бонусного состояния.
-## 4.11 Требования к административным настройкам
+## 5.11 Требования к административным настройкам
Система должна содержать административные разделы для управления следующими объектами:
diff --git a/docs/tz/index.md b/docs/tz/index.md
index 63e5c4f..e458efe 100644
--- a/docs/tz/index.md
+++ b/docs/tz/index.md
@@ -4,16 +4,16 @@
## Содержание
-1. [Основания для разработки и нормативные материалы](/tz/normative-base)
-2. [Назначение и границы программного продукта](/tz/product-scope)
-3. [Роли пользователей и права доступа](/tz/roles-access)
-4. [Функциональные требования](/tz/functional-requirements)
-5. [Требования к данным и интеграциям](/tz/data-integrations)
-6. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
-7. [Структура данных и модель базы данных](/tz/database-model)
-8. [Нефункциональные требования](/tz/non-functional-requirements)
-9. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
-10. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
+2. [Основания для разработки и нормативные материалы](/tz/normative-base)
+3. [Назначение и границы программного продукта](/tz/product-scope)
+4. [Роли пользователей и права доступа](/tz/roles-access)
+5. [Функциональные требования](/tz/functional-requirements)
+6. [Требования к данным и интеграциям](/tz/data-integrations)
+7. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
+8. [Структура данных и модель базы данных](/tz/database-model)
+9. [Нефункциональные требования](/tz/non-functional-requirements)
+10. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
+11. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
## Назначение раздела
diff --git a/docs/tz/non-functional-requirements.md b/docs/tz/non-functional-requirements.md
index 25adb17..9f88d55 100644
--- a/docs/tz/non-functional-requirements.md
+++ b/docs/tz/non-functional-requirements.md
@@ -1,10 +1,10 @@
-# 8. Нефункциональные требования
+# 9. Нефункциональные требования
-## 8.1 Общие требования к архитектуре
+## 9.1 Общие требования к архитектуре
Программный продукт должен быть реализован как веб-система с разделением клиентского и менеджерского контуров, серверной бизнес-логикой, постоянным хранением данных и возможностью интеграционного обмена с внешними системами.
-## 8.2 Требования к доступности интерфейсов
+## 9.2 Требования к доступности интерфейсов
Система должна обеспечивать корректную работу:
@@ -14,7 +14,7 @@
Интерфейсы должны сохранять работоспособность и читаемость при адаптивном отображении.
-## 8.3 Требования к производительности
+## 9.3 Требования к производительности
При штатной эксплуатации система должна обеспечивать:
@@ -24,7 +24,7 @@
Точные количественные показатели производительности подлежат фиксации в рабочей документации по инфраструктуре и тестированию.
-## 8.4 Требования к безопасности
+## 9.4 Требования к безопасности
Система должна обеспечивать:
@@ -34,7 +34,7 @@
- хранение и передачу чувствительных данных с использованием защищенных механизмов
- исключение несанкционированного доступа к административным функциям
-## 8.5 Требования к надежности и журналированию
+## 9.5 Требования к надежности и журналированию
Система должна обеспечивать:
@@ -43,7 +43,7 @@
- фиксацию ошибок интеграционного обмена
- фиксацию значимых системных и пользовательских событий
-## 8.6 Требования к сопровождаемости
+## 9.6 Требования к сопровождаемости
Реализация должна обеспечивать возможность:
@@ -52,7 +52,7 @@
- изменения параметров каталога и уведомлений без переработки базовой структуры системы
- расширения интеграционного обмена с 1С и иными внешними системами
-## 8.7 Требования к данным и актуальности сведений
+## 9.7 Требования к данным и актуальности сведений
Система должна обеспечивать:
@@ -60,7 +60,7 @@
- отображение даты актуальности сведений, полученных из внешних систем, когда это применимо
- защиту от потери данных при обновлении параметров каталога и заказных сущностей
-## 8.8 Требования к документации
+## 9.8 Требования к документации
По результатам выполнения работ должна быть сформирована документация, достаточная для:
diff --git a/docs/tz/normative-base.md b/docs/tz/normative-base.md
index 944d955..07d368e 100644
--- a/docs/tz/normative-base.md
+++ b/docs/tz/normative-base.md
@@ -1,6 +1,6 @@
-# 1. Основания для разработки и нормативные материалы
+# 2. Основания для разработки и нормативные материалы
-## 1.1 Основания для разработки
+## 2.1 Основания для разработки
Разработка программного продукта выполняется на основании следующих документов:
@@ -9,13 +9,13 @@
- согласованные требования заказчика к клиентскому, менеджерскому, бонусному и интеграционному контурам
- действующее состояние клиентской и серверной кодовой базы, используемое как фактическая основа для детализации требований
-## 1.2 Нормативные и методические материалы
+## 2.2 Нормативные и методические материалы
При подготовке настоящего технического задания используется структура технической документации, соответствующая общепринятой практике составления ТЗ на программные продукты, включая подходы, применяемые в `ГОСТ 19.201-78`.
Настоящий документ устанавливает требования к программному продукту применительно к современному веб-решению с разграничением ролей, интеграцией с учетной системой, журналированием событий и поддержкой клиентских и менеджерских сценариев.
-## 1.3 Исходные материалы для детализации требований
+## 2.3 Исходные материалы для детализации требований
При разработке технического задания использованы следующие исходные материалы:
@@ -27,7 +27,7 @@
- требования к обмену данными с учетной системой 1С
- требования к уведомлениям, бонусной программе и административным настройкам
-## 1.4 Назначение настоящего документа
+## 2.4 Назначение настоящего документа
Настоящий документ предназначен для:
diff --git a/docs/tz/product-scope.md b/docs/tz/product-scope.md
index 6eeab48..73b40b4 100644
--- a/docs/tz/product-scope.md
+++ b/docs/tz/product-scope.md
@@ -1,6 +1,6 @@
-# 2. Назначение и границы программного продукта
+# 3. Назначение и границы программного продукта
-## 2.1 Назначение системы
+## 3.1 Назначение системы
Программный продукт `Личный кабинет Фрегат` предназначен для организации единого цифрового канала взаимодействия между ООО `Фрегат Групп` и клиентами компании.
@@ -15,7 +15,7 @@
- информирование клиентов о значимых изменениях
- ведение бонусной и реферальной программы
-## 2.2 Границы программного продукта
+## 3.2 Границы программного продукта
В состав программного продукта входят следующие функциональные области:
@@ -31,7 +31,7 @@
- бонусный кабинет
- административные настройки
-## 2.3 Функции, не входящие в состав программного продукта
+## 3.3 Функции, не входящие в состав программного продукта
Программный продукт не предназначен для выполнения следующих функций:
@@ -41,7 +41,7 @@
- прямого редактирования клиентом внутренних бизнес-правил компании
- замены учетной системы 1С как первичного источника учетных данных
-## 2.4 Пользовательские контуры
+## 3.4 Пользовательские контуры
В системе должны быть предусмотрены следующие пользовательские контуры:
@@ -55,16 +55,16 @@
Административный контур предназначен для управления настройками каталога, уведомлений, интеграционных параметров и отдельных сервисных настроек системы.
-## 2.5 Основные бизнес-сценарии
+## 3.5 Основные бизнес-сценарии
-### 2.5.1 Подключение клиента
+### 3.5.1 Подключение клиента
1. Потенциальный клиент получает приглашение на регистрацию либо подает заявку на подключение самостоятельно.
2. Менеджер проверяет сведения о клиенте и принимает решение о подтверждении либо отклонении заявки.
3. При положительном решении клиенту предоставляется доступ к завершению регистрации.
4. После завершения регистрации клиент получает доступ к личному кабинету.
-### 2.5.2 Заказ готовой продукции
+### 3.5.2 Заказ готовой продукции
1. Клиент открывает каталог готовой продукции.
2. Клиент выбирает товарное направление.
@@ -75,21 +75,21 @@
7. Менеджер указывает стоимость, условия поставки и комментарий.
8. Система публикует обновленные условия клиенту.
-### 2.5.3 Заявка на расчет индивидуальной продукции
+### 3.5.3 Заявка на расчет индивидуальной продукции
1. Клиент переходит в режим расчета индивидуальной продукции.
2. Клиент указывает параметры требуемого изделия.
3. Клиент направляет заявку менеджеру.
4. Менеджер подготавливает коммерческие условия и публикует их клиенту.
-### 2.5.4 Сопровождение заказа
+### 3.5.4 Сопровождение заказа
1. Заказ получает уникальный идентификатор и статус.
2. Данные по заказу обновляются в системе по мере обработки.
3. Клиент отслеживает состав, статус, сроки и иные существенные сведения.
4. При изменении статуса либо условий система направляет уведомления.
-### 2.5.5 Бонусная и реферальная программа
+### 3.5.5 Бонусная и реферальная программа
1. Для клиента фиксируются правила участия в бонусной программе и, при наличии, реферальные связи.
2. Система ведет учет начислений, списаний и остатка бонусов.
diff --git a/docs/tz/roles-access.md b/docs/tz/roles-access.md
index bd0fdf7..52e4981 100644
--- a/docs/tz/roles-access.md
+++ b/docs/tz/roles-access.md
@@ -1,6 +1,6 @@
-# 3. Роли пользователей и права доступа
+# 4. Роли пользователей и права доступа
-## 3.1 Состав ролей
+## 4.1 Состав ролей
В системе должны быть предусмотрены следующие роли пользователей:
@@ -8,7 +8,7 @@
- менеджер
- суперменеджер
-## 3.2 Роль клиента
+## 4.2 Роль клиента
Пользователь с ролью `Клиент` представляет организацию-контрагента и работает только с данными своей компании.
@@ -29,7 +29,7 @@
- просмотр бонусного баланса и истории бонусных операций
- подача заявки на использование либо вывод бонусов при наличии соответствующих правил
-## 3.3 Роль менеджера
+## 4.3 Роль менеджера
Пользователь с ролью `Менеджер` представляет сотрудника компании, закрепленного за клиентами.
@@ -47,7 +47,7 @@
- просмотр карточек клиентов, заявок и заказов
- выполнение операций в бонусном контуре в пределах полномочий
-## 3.4 Роль суперменеджера
+## 4.4 Роль суперменеджера
Пользователь с ролью `Суперменеджер` обладает всеми правами менеджера и дополнительными административными полномочиями.
@@ -60,7 +60,7 @@
- управление параметрами интеграции и синхронизации
- расширенное управление бонусным и реферальным контуром
-## 3.5 Матрица доступа
+## 4.5 Матрица доступа
| Действие | Клиент | Менеджер | Суперменеджер |
| --- | --- | --- | --- |
@@ -79,7 +79,7 @@
| Управление параметрами синхронизации | Нет | Нет | Да |
| Управление бонусными правилами | Нет | Да | Да |
-## 3.6 Ограничения доступа и требования к безопасности
+## 4.6 Ограничения доступа и требования к безопасности
Система должна обеспечивать:
diff --git a/docs/tz/stage-1/index.md b/docs/tz/stage-1/index.md
index b72fb32..fc9b578 100644
--- a/docs/tz/stage-1/index.md
+++ b/docs/tz/stage-1/index.md
@@ -1,6 +1,6 @@
-# 9. Экранные формы и прототипы интерфейсов
+# 10. Экранные формы и прототипы интерфейсов
-## 9.1 Карта экранов
+## 10.1 Карта экранов
Ниже приведен базовый состав экранов, подлежащих реализации и сопровождению в рамках программного продукта.
@@ -26,7 +26,7 @@
| Настройки синхронизации | `/settings-sync` | суперменеджер | мониторинг и управление обменом |
| Бонусная система | `/bonus-system/*` | менеджер/суперменеджер | рефералы, транзакции, выводы |
-## 9.2 Общие требования к экранным формам
+## 10.2 Общие требования к экранным формам
Экранные формы должны обеспечивать:
@@ -42,9 +42,9 @@
- остатки и доступные варианты отображаются в наглядном виде
- пользователь понимает ограничения выбора и возможность кастомизации
-## 9.3 Клиентские экранные формы
+## 10.3 Клиентские экранные формы
-### 9.3.1 Главная страница клиента
+### 10.3.1 Главная страница клиента
Назначение страницы:
@@ -64,7 +64,7 @@
-### 9.3.2 Каталог продукции
+### 10.3.2 Каталог продукции
Назначение страницы:
@@ -83,7 +83,7 @@
-### 9.3.3 Карточка товара
+### 10.3.3 Карточка товара
Назначение страницы:
@@ -124,7 +124,7 @@
- правила по втулке с логотипом
- правила по нанесению индивидуальной надписи
-### 9.3.4 Корзина
+### 10.3.4 Корзина
Назначение страницы:
@@ -146,7 +146,7 @@
-### 9.3.5 Карточка заявки или заказа
+### 10.3.5 Карточка заявки или заказа
Назначение страницы:
@@ -169,7 +169,7 @@
- история статусов
- системные комментарии
-### 9.3.6 Страница логина и регистрации
+### 10.3.6 Страница логина и регистрации
Назначение страницы:
@@ -184,7 +184,7 @@
- ссылка на самостоятельную заявку на подключение
- блок пояснения по дальнейшему сценарию доступа
-### 9.3.7 Список заказов
+### 10.3.7 Список заказов
Назначение страницы:
@@ -197,13 +197,13 @@
- таблица заказов
- переход в карточку конкретного заказа
-### 9.3.8 Уведомления
+### 10.3.8 Уведомления
Назначение страницы:
- просмотр истории уведомлений по заказам, заявкам и бонусным операциям
-### 9.3.9 Бонусный кабинет
+### 10.3.9 Бонусный кабинет
Назначение страницы:
@@ -223,9 +223,9 @@
-## 9.4 Менеджерские экранные формы
+## 10.4 Менеджерские экранные формы
-### 9.4.1 Список клиентов
+### 10.4.1 Список клиентов
Назначение страницы:
@@ -239,7 +239,7 @@
- индикаторы активности и количества заказов
- действие приглашения нового клиента
-### 9.4.2 Карточка клиента
+### 10.4.2 Карточка клиента
Назначение страницы:
@@ -255,7 +255,7 @@
- список бонусных операций
- связанные рефералы
-### 9.4.3 Карточка обработки заявки
+### 10.4.3 Карточка обработки заявки
Назначение страницы:
@@ -278,7 +278,7 @@
- история изменений
- блок действий со статусом
-### 9.4.4 Список заказов менеджера
+### 10.4.4 Список заказов менеджера
Назначение страницы:
@@ -290,7 +290,7 @@
-### 9.4.5 Настройки каталога
+### 10.4.5 Настройки каталога
Назначение страницы:
@@ -307,7 +307,7 @@
- списки стандартных параметров
- единое действие сохранения настроек
-### 9.4.6 Настройки синхронизации и уведомлений
+### 10.4.6 Настройки синхронизации и уведомлений
Назначение страницы:
diff --git a/docs/tz/technical-architecture.md b/docs/tz/technical-architecture.md
index 3eadb60..ae13e6d 100644
--- a/docs/tz/technical-architecture.md
+++ b/docs/tz/technical-architecture.md
@@ -1,12 +1,12 @@
-# 6. Техническая архитектура, стек и состав компонентов
+# 7. Техническая архитектура, стек и состав компонентов
-## 6.1 Общая архитектурная схема
+## 7.1 Общая архитектурная схема
Программный продукт реализуется по клиент-серверной модели и включает веб-клиент, сервер бизнес-логики, базу данных, модуль интеграции и вспомогательные сервисы уведомлений.
-## 6.2 Состав прикладных сервисов
+## 7.2 Состав прикладных сервисов
Согласно действующей карте деплоя в составе проекта используются следующие сервисы:
@@ -19,7 +19,7 @@
Основные прикладные сервисы `web-frontend` и `apollo-backend` разворачиваются через `dokploy_webhook` на сервере `main`.
-## 6.3 Технологический стек фронтенда
+## 7.3 Технологический стек фронтенда
Клиентская часть программного продукта реализуется на следующих технологиях:
@@ -31,7 +31,7 @@
- `Storybook` — контур изоляционного просмотра компонентов
- `VitePress` — подготовка проектной документации
-## 6.4 Технологический стек серверной части
+## 7.4 Технологический стек серверной части
Серверная часть программного продукта реализуется на следующих технологиях:
@@ -43,7 +43,7 @@
- `Zod` — валидация структур данных в прикладных сценариях
- `Nodemailer` — отправка уведомлений по электронной почте
-## 6.5 Архитектура клиентской части
+## 7.5 Архитектура клиентской части
Клиентская часть организована по следующим слоям:
@@ -64,11 +64,11 @@
- `/catalog-settings` — административные настройки каталога
- `/bonus-program`, `/bonus-system/*` — бонусный контур
-## 6.6 Карта слоев и компонентов
+## 7.6 Карта слоев и компонентов
-## 6.7 Архитектура серверной части
+## 7.7 Архитектура серверной части
Серверная часть организована по следующим основным модулям:
@@ -81,7 +81,7 @@
- `src/prisma-client.js` — точка подключения Prisma
- `src/messenger*.js`, `src/telegram*.js`, `src/max-mini-app.js` — мессенджерный контур и мини-приложения
-## 6.8 Взаимодействие фронтенда и backend
+## 7.8 Взаимодействие фронтенда и backend
Взаимодействие клиентской и серверной части строится через GraphQL API.
@@ -98,7 +98,7 @@
- централизованно передавать авторизационные данные
- поддерживать единый клиентский GraphQL endpoint
-## 6.9 Интеграционные и вспомогательные HTTP-точки
+## 7.9 Интеграционные и вспомогательные HTTP-точки
Помимо GraphQL API, во фронтенд-контуре реализованы вспомогательные серверные маршруты:
@@ -109,7 +109,7 @@
- `/api/dadata/party` — подсказки контрагентов
- `/api/messenger-avatar/[connectionId]` — выдача изображений, связанных с мессенджерными подключениями
-## 6.10 Компонентные требования к реализации
+## 7.10 Компонентные требования к реализации
Архитектура программного продукта должна сохранять следующие правила:
@@ -120,13 +120,13 @@
- серверная логика доступа к данным должна проходить через Prisma
- бизнес-правила доступа должны контролироваться серверной частью, а не только интерфейсом
-## 6.11 Требования к конфигурации и секретам
+## 7.11 Требования к конфигурации и секретам
Сервисы программного продукта должны получать прикладные секреты из `Vault`.
В конфигурации сервисов допускается хранение только bootstrap-параметров для подключения к Vault. Бизнес-секреты, ключи интеграций и иные чувствительные данные должны загружаться из Vault при старте приложения.
-## 6.12 Инфраструктура, деплой и эксплуатационный контур
+## 7.12 Инфраструктура, деплой и эксплуатационный контур
Текущая инфраструктурная схема проекта включает прикладные сервисы, сервис секретов, мессенджерные сервисы и вспомогательный worker-контур.
@@ -152,7 +152,7 @@
Эксплуатационные операции доступа и диагностики выполняются через Tailscale SSH.
-## 6.13 Dokploy и цепочка развёртывания
+## 7.13 Dokploy и цепочка развёртывания
Для основных сервисов проекта используется режим `dokploy_webhook`.
@@ -171,7 +171,7 @@
- `apollo-backend` стартует через загрузку Vault env, `prisma migrate deploy` и запуск `src/server.js`
- bot-сервисы стартуют через общий паттерн загрузки Vault env и запуск `node src/server.js`
-## 6.14 Vault и хранение секретов
+## 7.14 Vault и хранение секретов
Сервис `vault` развернут как отдельное приложение на базе образа `hashicorp/vault:1.21.3`.
@@ -190,7 +190,7 @@
- загружает project secrets
- экспортирует секреты в runtime environment процесса
-## 6.15 Структура сервисных каталогов
+## 7.15 Структура сервисных каталогов
Текущая сервисная структура репозитория:
@@ -203,7 +203,7 @@
- `vault` — Dockerfile, конфигурация и entrypoint Vault
- `hatchet` — docker-compose инфраструктурного контура Hatchet
-## 6.16 Контур фоновых процессов
+## 7.16 Контур фоновых процессов
В проекте присутствует отдельный контур фонового исполнения задач:
@@ -214,7 +214,7 @@
Конфигурация этого контура находится в `hatchet/docker-compose.yml`.
-## 6.17 Зафиксированные runtime-версии и технологические зависимости
+## 7.17 Зафиксированные runtime-версии и технологические зависимости
### Базовые runtime и контейнерные образы
@@ -259,7 +259,7 @@
| `nodemailer` | `8.0.4` | email notifications |
| `dotenv` | `17.3.1` | env bootstrap in local/runtime layers |
-## 6.18 Технические конфигурационные файлы
+## 7.18 Технические конфигурационные файлы
Ключевые технические файлы текущей реализации: