fregat/web-frontend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Renumber technical specification sections

Browse Source
This commit is contained in:
Ruslan Bakiev
2026-05-01 14:50:06 +07:00
parent d514eac990
commit eb6dcf9a52
13 changed files with 152 additions and 152 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/.vitepress/config.ts
View File

@@ -13,17 +13,17 @@ export default defineConfig({
{ {
text: 'Техническое задание', text: 'Техническое задание',
items: [ items: [
{ text: '0. Общие положения', link: '/' }, { text: '1. Общие положения', link: '/' },
{ text: '1. Основания для разработки и нормативные материалы', link: '/tz/normative-base' }, { text: '2. Основания для разработки и нормативные материалы', link: '/tz/normative-base' },
{ text: '2. Назначение и границы программного продукта', link: '/tz/product-scope' }, { text: '3. Назначение и границы программного продукта', link: '/tz/product-scope' },
{ text: '3. Роли пользователей и права доступа', link: '/tz/roles-access' }, { text: '4. Роли пользователей и права доступа', link: '/tz/roles-access' },
{ text: '4. Функциональные требования', link: '/tz/functional-requirements' }, { text: '5. Функциональные требования', link: '/tz/functional-requirements' },
{ text: '5. Требования к данным и интеграциям', link: '/tz/data-integrations' }, { text: '6. Требования к данным и интеграциям', link: '/tz/data-integrations' },
{ text: '6. Техническая архитектура, стек и состав компонентов', link: '/tz/technical-architecture' }, { text: '7. Техническая архитектура, стек и состав компонентов', link: '/tz/technical-architecture' },
{ text: '7. Структура данных и модель базы данных', link: '/tz/database-model' }, { text: '8. Структура данных и модель базы данных', link: '/tz/database-model' },
{ text: '8. Нефункциональные требования', link: '/tz/non-functional-requirements' }, { text: '9. Нефункциональные требования', link: '/tz/non-functional-requirements' },
{ text: '9. Экранные формы и прототипы интерфейсов', link: '/tz/stage-1/' }, { text: '10. Экранные формы и прототипы интерфейсов', link: '/tz/stage-1/' },
{ text: '10. Порядок приемки и состав передаваемых материалов', link: '/tz/acceptance' }, { text: '11. Порядок приемки и состав передаваемых материалов', link: '/tz/acceptance' },
], ],
}, },
{ {

34
docs/index.md
View File

@@ -1,6 +1,6 @@
# Техническое задание на разработку программного продукта # Техническое задание на разработку программного продукта
## 0. Общие положения ## 1. Общие положения
Наименование программного продукта: `Личный кабинет Фрегат`. Наименование программного продукта: `Личный кабинет Фрегат`.
@@ -14,7 +14,7 @@
Настоящее техническое задание устанавливает требования к составу, функциям, данным, интеграциям, интерфейсным формам, условиям приемки и составу материалов, подлежащих передаче заказчику по результатам выполнения работ. Настоящее техническое задание устанавливает требования к составу, функциям, данным, интеграциям, интерфейсным формам, условиям приемки и составу материалов, подлежащих передаче заказчику по результатам выполнения работ.
## 0.1 Назначение программного продукта ## 1.1 Назначение программного продукта
Программный продукт предназначен для автоматизации взаимодействия между ООО `Фрегат Групп` и B2B-клиентами компании в части: Программный продукт предназначен для автоматизации взаимодействия между ООО `Фрегат Групп` и 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/normative-base)
2. [Назначение и границы программного продукта](/tz/product-scope) 3. [Назначение и границы программного продукта](/tz/product-scope)
3. [Роли пользователей и права доступа](/tz/roles-access) 4. [Роли пользователей и права доступа](/tz/roles-access)
4. [Функциональные требования](/tz/functional-requirements) 5. [Функциональные требования](/tz/functional-requirements)
5. [Требования к данным и интеграциям](/tz/data-integrations) 6. [Требования к данным и интеграциям](/tz/data-integrations)
6. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture) 7. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
7. [Структура данных и модель базы данных](/tz/database-model) 8. [Структура данных и модель базы данных](/tz/database-model)
8. [Нефункциональные требования](/tz/non-functional-requirements) 9. [Нефункциональные требования](/tz/non-functional-requirements)
9. [Экранные формы и прототипы интерфейсов](/tz/stage-1/) 10. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
10. [Порядок приемки и состав передаваемых материалов](/tz/acceptance) 11. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
11. [Приложение. Текущее состояние программного продукта](/appendix/current-state) 12. [Приложение. Текущее состояние программного продукта](/appendix/current-state)

12
docs/tz/acceptance.md
View File

@@ -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 Порядок фиксации замечаний
Каждое замечание, выявленное при приемке, должно содержать: Каждое замечание, выявленное при приемке, должно содержать:

30
docs/tz/data-integrations.md
View File

@@ -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С должна обеспечивать обмен данными, необходимыми для сопровождения каталога и заказов. Интеграция с 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 Требования к данным бонусного контура
Для бонусной и реферальной программы система должна хранить: Для бонусной и реферальной программы система должна хранить:

20
docs/tz/database-model.md
View File

@@ -1,6 +1,6 @@
# 7. Структура данных и модель базы данных # 8. Структура данных и модель базы данных
## 7.1 Общие положения ## 8.1 Общие положения
Основное хранилище данных программного продукта реализуется на `PostgreSQL`. Прикладной доступ к данным осуществляется через `Prisma ORM`. Основное хранилище данных программного продукта реализуется на `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` - настройки параметров по товарному направлению хранятся в `CatalogProductTypeSetting`
- реферальные связи реализуются через `ReferralLink`, связывающий одного пользователя с другим пользователем - реферальные связи реализуются через `ReferralLink`, связывающий одного пользователя с другим пользователем
## 7.8 Требования к хранению прикладных данных ## 8.8 Требования к хранению прикладных данных
Модель базы данных должна обеспечивать: Модель базы данных должна обеспечивать:
@@ -157,7 +157,7 @@
- хранение истории статусов и действий - хранение истории статусов и действий
- хранение интеграционных идентификаторов для связи с внешними системами - хранение интеграционных идентификаторов для связи с внешними системами
## 7.9 Требования к расширяемости модели ## 8.9 Требования к расширяемости модели
Структура базы данных должна позволять: Структура базы данных должна позволять:

24
docs/tz/functional-requirements.md
View File

@@ -1,6 +1,6 @@
# 4. Функциональные требования # 5. Функциональные требования
## 4.1 Требования к регистрации и подключению клиентов ## 5.1 Требования к регистрации и подключению клиентов
Система должна поддерживать два базовых сценария подключения клиента: Система должна поддерживать два базовых сценария подключения клиента:
@@ -18,7 +18,7 @@
7. После завершения регистрации клиент должен получить доступ к личному кабинету. 7. После завершения регистрации клиент должен получить доступ к личному кабинету.
8. Система должна поддерживать подключение доступных каналов уведомлений для клиентской учетной записи. 8. Система должна поддерживать подключение доступных каналов уведомлений для клиентской учетной записи.
## 4.2 Требования к каталогу готовой продукции ## 5.2 Требования к каталогу готовой продукции
Система должна предоставлять клиенту каталог готовой продукции без отображения цены до обработки менеджером. Система должна предоставлять клиенту каталог готовой продукции без отображения цены до обработки менеджером.
@@ -33,7 +33,7 @@
7. Система должна исключать отображение стоимости до момента публикации условий менеджером. 7. Система должна исключать отображение стоимости до момента публикации условий менеджером.
8. Для параметров товара система должна отображать пояснения, помогающие клиенту понять назначение параметра и ограничения выбора. 8. Для параметров товара система должна отображать пояснения, помогающие клиенту понять назначение параметра и ограничения выбора.
## 4.3 Требования к параметрам каталога и кастомизации ## 5.3 Требования к параметрам каталога и кастомизации
Система должна поддерживать настройку параметров по каждому товарному направлению. Система должна поддерживать настройку параметров по каждому товарному направлению.
@@ -47,7 +47,7 @@
6. Наборы стандартных параметров должны редактироваться в административном контуре. 6. Наборы стандартных параметров должны редактироваться в административном контуре.
7. Изменение набора стандартных параметров не должно приводить к потере уже сохраненных заказных данных. 7. Изменение набора стандартных параметров не должно приводить к потере уже сохраненных заказных данных.
## 4.4 Требования к корзине и заявке на заказ ## 5.4 Требования к корзине и заявке на заказ
Система должна позволять клиенту собрать корзину и направить заявку на заказ. Система должна позволять клиенту собрать корзину и направить заявку на заказ.
@@ -61,7 +61,7 @@
6. Для заявки должны сохраняться дата создания, инициатор и закрепленный менеджер. 6. Для заявки должны сохраняться дата создания, инициатор и закрепленный менеджер.
7. До обработки менеджером стоимость в заявке не должна отображаться клиенту. 7. До обработки менеджером стоимость в заявке не должна отображаться клиенту.
## 4.5 Требования к обработке заявки менеджером ## 5.5 Требования к обработке заявки менеджером
Менеджер должен иметь возможность обработать клиентскую заявку вручную. Менеджер должен иметь возможность обработать клиентскую заявку вручную.
@@ -77,7 +77,7 @@
8. Менеджер должен иметь возможность перевести заявку в работу. 8. Менеджер должен иметь возможность перевести заявку в работу.
9. Менеджер должен иметь возможность отменить заявку с фиксацией основания отмены. 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. В карточке заказа должна отображаться дата актуальности данных. 5. В карточке заказа должна отображаться дата актуальности данных.
6. При наличии обновлений из внешней системы сведения по заказу должны синхронизироваться и отображаться пользователю. 6. При наличии обновлений из внешней системы сведения по заказу должны синхронизироваться и отображаться пользователю.
## 4.9 Требования к уведомлениям ## 5.9 Требования к уведомлениям
Система должна поддерживать уведомления по нескольким каналам связи. Система должна поддерживать уведомления по нескольким каналам связи.
@@ -154,7 +154,7 @@
- изменение бонусного баланса - изменение бонусного баланса
- обработка заявки на использование либо вывод бонусов - обработка заявки на использование либо вывод бонусов
## 4.10 Требования к бонусной и реферальной программе ## 5.10 Требования к бонусной и реферальной программе
Система должна включать бонусный контур как самостоятельную функциональную область. Система должна включать бонусный контур как самостоятельную функциональную область.
@@ -170,7 +170,7 @@
8. Менеджер должен иметь возможность обрабатывать операции бонусного контура. 8. Менеджер должен иметь возможность обрабатывать операции бонусного контура.
9. Система должна уведомлять клиента об изменениях бонусного состояния. 9. Система должна уведомлять клиента об изменениях бонусного состояния.
## 4.11 Требования к административным настройкам ## 5.11 Требования к административным настройкам
Система должна содержать административные разделы для управления следующими объектами: Система должна содержать административные разделы для управления следующими объектами:

20
docs/tz/index.md
View File

@@ -4,16 +4,16 @@
## Содержание ## Содержание
1. [Основания для разработки и нормативные материалы](/tz/normative-base) 2. [Основания для разработки и нормативные материалы](/tz/normative-base)
2. [Назначение и границы программного продукта](/tz/product-scope) 3. [Назначение и границы программного продукта](/tz/product-scope)
3. [Роли пользователей и права доступа](/tz/roles-access) 4. [Роли пользователей и права доступа](/tz/roles-access)
4. [Функциональные требования](/tz/functional-requirements) 5. [Функциональные требования](/tz/functional-requirements)
5. [Требования к данным и интеграциям](/tz/data-integrations) 6. [Требования к данным и интеграциям](/tz/data-integrations)
6. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture) 7. [Техническая архитектура, стек и состав компонентов](/tz/technical-architecture)
7. [Структура данных и модель базы данных](/tz/database-model) 8. [Структура данных и модель базы данных](/tz/database-model)
8. [Нефункциональные требования](/tz/non-functional-requirements) 9. [Нефункциональные требования](/tz/non-functional-requirements)
9. [Экранные формы и прототипы интерфейсов](/tz/stage-1/) 10. [Экранные формы и прототипы интерфейсов](/tz/stage-1/)
10. [Порядок приемки и состав передаваемых материалов](/tz/acceptance) 11. [Порядок приемки и состав передаваемых материалов](/tz/acceptance)
## Назначение раздела ## Назначение раздела

18
docs/tz/non-functional-requirements.md
View File

@@ -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С и иными внешними системами - расширения интеграционного обмена с 1С и иными внешними системами
## 8.7 Требования к данным и актуальности сведений ## 9.7 Требования к данным и актуальности сведений
Система должна обеспечивать: Система должна обеспечивать:
@@ -60,7 +60,7 @@
- отображение даты актуальности сведений, полученных из внешних систем, когда это применимо - отображение даты актуальности сведений, полученных из внешних систем, когда это применимо
- защиту от потери данных при обновлении параметров каталога и заказных сущностей - защиту от потери данных при обновлении параметров каталога и заказных сущностей
## 8.8 Требования к документации ## 9.8 Требования к документации
По результатам выполнения работ должна быть сформирована документация, достаточная для: По результатам выполнения работ должна быть сформирована документация, достаточная для:

10
docs/tz/normative-base.md
View File

@@ -1,6 +1,6 @@
# 1. Основания для разработки и нормативные материалы # 2. Основания для разработки и нормативные материалы
## 1.1 Основания для разработки ## 2.1 Основания для разработки
Разработка программного продукта выполняется на основании следующих документов: Разработка программного продукта выполняется на основании следующих документов:
@@ -9,13 +9,13 @@
- согласованные требования заказчика к клиентскому, менеджерскому, бонусному и интеграционному контурам - согласованные требования заказчика к клиентскому, менеджерскому, бонусному и интеграционному контурам
- действующее состояние клиентской и серверной кодовой базы, используемое как фактическая основа для детализации требований - действующее состояние клиентской и серверной кодовой базы, используемое как фактическая основа для детализации требований
## 1.2 Нормативные и методические материалы ## 2.2 Нормативные и методические материалы
При подготовке настоящего технического задания используется структура технической документации, соответствующая общепринятой практике составления ТЗ на программные продукты, включая подходы, применяемые в `ГОСТ 19.201-78`. При подготовке настоящего технического задания используется структура технической документации, соответствующая общепринятой практике составления ТЗ на программные продукты, включая подходы, применяемые в `ГОСТ 19.201-78`.
Настоящий документ устанавливает требования к программному продукту применительно к современному веб-решению с разграничением ролей, интеграцией с учетной системой, журналированием событий и поддержкой клиентских и менеджерских сценариев. Настоящий документ устанавливает требования к программному продукту применительно к современному веб-решению с разграничением ролей, интеграцией с учетной системой, журналированием событий и поддержкой клиентских и менеджерских сценариев.
## 1.3 Исходные материалы для детализации требований ## 2.3 Исходные материалы для детализации требований
При разработке технического задания использованы следующие исходные материалы: При разработке технического задания использованы следующие исходные материалы:
@@ -27,7 +27,7 @@
- требования к обмену данными с учетной системой 1С - требования к обмену данными с учетной системой 1С
- требования к уведомлениям, бонусной программе и административным настройкам - требования к уведомлениям, бонусной программе и административным настройкам
## 1.4 Назначение настоящего документа ## 2.4 Назначение настоящего документа
Настоящий документ предназначен для: Настоящий документ предназначен для:

22
docs/tz/product-scope.md
View File

@@ -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С как первичного источника учетных данных - замены учетной системы 1С как первичного источника учетных данных
## 2.4 Пользовательские контуры ## 3.4 Пользовательские контуры
В системе должны быть предусмотрены следующие пользовательские контуры: В системе должны быть предусмотрены следующие пользовательские контуры:
@@ -55,16 +55,16 @@
Административный контур предназначен для управления настройками каталога, уведомлений, интеграционных параметров и отдельных сервисных настроек системы. Административный контур предназначен для управления настройками каталога, уведомлений, интеграционных параметров и отдельных сервисных настроек системы.
## 2.5 Основные бизнес-сценарии ## 3.5 Основные бизнес-сценарии
### 2.5.1 Подключение клиента ### 3.5.1 Подключение клиента
1. Потенциальный клиент получает приглашение на регистрацию либо подает заявку на подключение самостоятельно. 1. Потенциальный клиент получает приглашение на регистрацию либо подает заявку на подключение самостоятельно.
2. Менеджер проверяет сведения о клиенте и принимает решение о подтверждении либо отклонении заявки. 2. Менеджер проверяет сведения о клиенте и принимает решение о подтверждении либо отклонении заявки.
3. При положительном решении клиенту предоставляется доступ к завершению регистрации. 3. При положительном решении клиенту предоставляется доступ к завершению регистрации.
4. После завершения регистрации клиент получает доступ к личному кабинету. 4. После завершения регистрации клиент получает доступ к личному кабинету.
### 2.5.2 Заказ готовой продукции ### 3.5.2 Заказ готовой продукции
1. Клиент открывает каталог готовой продукции. 1. Клиент открывает каталог готовой продукции.
2. Клиент выбирает товарное направление. 2. Клиент выбирает товарное направление.
@@ -75,21 +75,21 @@
7. Менеджер указывает стоимость, условия поставки и комментарий. 7. Менеджер указывает стоимость, условия поставки и комментарий.
8. Система публикует обновленные условия клиенту. 8. Система публикует обновленные условия клиенту.
### 2.5.3 Заявка на расчет индивидуальной продукции ### 3.5.3 Заявка на расчет индивидуальной продукции
1. Клиент переходит в режим расчета индивидуальной продукции. 1. Клиент переходит в режим расчета индивидуальной продукции.
2. Клиент указывает параметры требуемого изделия. 2. Клиент указывает параметры требуемого изделия.
3. Клиент направляет заявку менеджеру. 3. Клиент направляет заявку менеджеру.
4. Менеджер подготавливает коммерческие условия и публикует их клиенту. 4. Менеджер подготавливает коммерческие условия и публикует их клиенту.
### 2.5.4 Сопровождение заказа ### 3.5.4 Сопровождение заказа
1. Заказ получает уникальный идентификатор и статус. 1. Заказ получает уникальный идентификатор и статус.
2. Данные по заказу обновляются в системе по мере обработки. 2. Данные по заказу обновляются в системе по мере обработки.
3. Клиент отслеживает состав, статус, сроки и иные существенные сведения. 3. Клиент отслеживает состав, статус, сроки и иные существенные сведения.
4. При изменении статуса либо условий система направляет уведомления. 4. При изменении статуса либо условий система направляет уведомления.
### 2.5.5 Бонусная и реферальная программа ### 3.5.5 Бонусная и реферальная программа
1. Для клиента фиксируются правила участия в бонусной программе и, при наличии, реферальные связи. 1. Для клиента фиксируются правила участия в бонусной программе и, при наличии, реферальные связи.
2. Система ведет учет начислений, списаний и остатка бонусов. 2. Система ведет учет начислений, списаний и остатка бонусов.

14
docs/tz/roles-access.md
View File

@@ -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 Ограничения доступа и требования к безопасности
Система должна обеспечивать: Система должна обеспечивать:

40
docs/tz/stage-1/index.md
View File

@@ -1,6 +1,6 @@
# 9. Экранные формы и прототипы интерфейсов # 10. Экранные формы и прототипы интерфейсов
## 9.1 Карта экранов ## 10.1 Карта экранов
Ниже приведен базовый состав экранов, подлежащих реализации и сопровождению в рамках программного продукта. Ниже приведен базовый состав экранов, подлежащих реализации и сопровождению в рамках программного продукта.
@@ -26,7 +26,7 @@
| Настройки синхронизации | `/settings-sync` | суперменеджер | мониторинг и управление обменом | | Настройки синхронизации | `/settings-sync` | суперменеджер | мониторинг и управление обменом |
| Бонусная система | `/bonus-system/*` | менеджер/суперменеджер | рефералы, транзакции, выводы | | Бонусная система | `/bonus-system/*` | менеджер/суперменеджер | рефералы, транзакции, выводы |
## 9.2 Общие требования к экранным формам ## 10.2 Общие требования к экранным формам
Экранные формы должны обеспечивать: Экранные формы должны обеспечивать:
@@ -42,9 +42,9 @@
- остатки и доступные варианты отображаются в наглядном виде - остатки и доступные варианты отображаются в наглядном виде
- пользователь понимает ограничения выбора и возможность кастомизации - пользователь понимает ограничения выбора и возможность кастомизации
## 9.3 Клиентские экранные формы ## 10.3 Клиентские экранные формы
### 9.3.1 Главная страница клиента ### 10.3.1 Главная страница клиента
Назначение страницы: Назначение страницы:
@@ -64,7 +64,7 @@
<NamedMermaidDiagram name="dashboard" /> <NamedMermaidDiagram name="dashboard" />
### 9.3.2 Каталог продукции ### 10.3.2 Каталог продукции
Назначение страницы: Назначение страницы:
@@ -83,7 +83,7 @@
<NamedMermaidDiagram name="catalog-grid" /> <NamedMermaidDiagram name="catalog-grid" />
### 9.3.3 Карточка товара ### 10.3.3 Карточка товара
Назначение страницы: Назначение страницы:
@@ -124,7 +124,7 @@
- правила по втулке с логотипом - правила по втулке с логотипом
- правила по нанесению индивидуальной надписи - правила по нанесению индивидуальной надписи
### 9.3.4 Корзина ### 10.3.4 Корзина
Назначение страницы: Назначение страницы:
@@ -146,7 +146,7 @@
<NamedMermaidDiagram name="cart" /> <NamedMermaidDiagram name="cart" />
### 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 @@
<NamedMermaidDiagram name="bonus-cabinet" /> <NamedMermaidDiagram name="bonus-cabinet" />
## 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 @@
<NamedMermaidDiagram name="manager-orders" /> <NamedMermaidDiagram name="manager-orders" />
### 9.4.5 Настройки каталога ### 10.4.5 Настройки каталога
Назначение страницы: Назначение страницы:
@@ -307,7 +307,7 @@
- списки стандартных параметров - списки стандартных параметров
- единое действие сохранения настроек - единое действие сохранения настроек
### 9.4.6 Настройки синхронизации и уведомлений ### 10.4.6 Настройки синхронизации и уведомлений
Назначение страницы: Назначение страницы:

38
docs/tz/technical-architecture.md
View File

@@ -1,12 +1,12 @@
# 6. Техническая архитектура, стек и состав компонентов # 7. Техническая архитектура, стек и состав компонентов
## 6.1 Общая архитектурная схема ## 7.1 Общая архитектурная схема
Программный продукт реализуется по клиент-серверной модели и включает веб-клиент, сервер бизнес-логики, базу данных, модуль интеграции и вспомогательные сервисы уведомлений. Программный продукт реализуется по клиент-серверной модели и включает веб-клиент, сервер бизнес-логики, базу данных, модуль интеграции и вспомогательные сервисы уведомлений.
<NamedMermaidDiagram name="architecture-overview" /> <NamedMermaidDiagram name="architecture-overview" />
## 6.2 Состав прикладных сервисов ## 7.2 Состав прикладных сервисов
Согласно действующей карте деплоя в составе проекта используются следующие сервисы: Согласно действующей карте деплоя в составе проекта используются следующие сервисы:
@@ -19,7 +19,7 @@
Основные прикладные сервисы `web-frontend` и `apollo-backend` разворачиваются через `dokploy_webhook` на сервере `main`. Основные прикладные сервисы `web-frontend` и `apollo-backend` разворачиваются через `dokploy_webhook` на сервере `main`.
## 6.3 Технологический стек фронтенда ## 7.3 Технологический стек фронтенда
Клиентская часть программного продукта реализуется на следующих технологиях: Клиентская часть программного продукта реализуется на следующих технологиях:
@@ -31,7 +31,7 @@
- `Storybook` — контур изоляционного просмотра компонентов - `Storybook` — контур изоляционного просмотра компонентов
- `VitePress` — подготовка проектной документации - `VitePress` — подготовка проектной документации
## 6.4 Технологический стек серверной части ## 7.4 Технологический стек серверной части
Серверная часть программного продукта реализуется на следующих технологиях: Серверная часть программного продукта реализуется на следующих технологиях:
@@ -43,7 +43,7 @@
- `Zod` — валидация структур данных в прикладных сценариях - `Zod` — валидация структур данных в прикладных сценариях
- `Nodemailer` — отправка уведомлений по электронной почте - `Nodemailer` — отправка уведомлений по электронной почте
## 6.5 Архитектура клиентской части ## 7.5 Архитектура клиентской части
Клиентская часть организована по следующим слоям: Клиентская часть организована по следующим слоям:
@@ -64,11 +64,11 @@
- `/catalog-settings` — административные настройки каталога - `/catalog-settings` — административные настройки каталога
- `/bonus-program`, `/bonus-system/*` — бонусный контур - `/bonus-program`, `/bonus-system/*` — бонусный контур
## 6.6 Карта слоев и компонентов ## 7.6 Карта слоев и компонентов
<NamedMermaidDiagram name="component-map" /> <NamedMermaidDiagram name="component-map" />
## 6.7 Архитектура серверной части ## 7.7 Архитектура серверной части
Серверная часть организована по следующим основным модулям: Серверная часть организована по следующим основным модулям:
@@ -81,7 +81,7 @@
- `src/prisma-client.js` — точка подключения Prisma - `src/prisma-client.js` — точка подключения Prisma
- `src/messenger*.js`, `src/telegram*.js`, `src/max-mini-app.js` — мессенджерный контур и мини-приложения - `src/messenger*.js`, `src/telegram*.js`, `src/max-mini-app.js` — мессенджерный контур и мини-приложения
## 6.8 Взаимодействие фронтенда и backend ## 7.8 Взаимодействие фронтенда и backend
Взаимодействие клиентской и серверной части строится через GraphQL API. Взаимодействие клиентской и серверной части строится через GraphQL API.
@@ -98,7 +98,7 @@
- централизованно передавать авторизационные данные - централизованно передавать авторизационные данные
- поддерживать единый клиентский GraphQL endpoint - поддерживать единый клиентский GraphQL endpoint
## 6.9 Интеграционные и вспомогательные HTTP-точки ## 7.9 Интеграционные и вспомогательные HTTP-точки
Помимо GraphQL API, во фронтенд-контуре реализованы вспомогательные серверные маршруты: Помимо GraphQL API, во фронтенд-контуре реализованы вспомогательные серверные маршруты:
@@ -109,7 +109,7 @@
- `/api/dadata/party` — подсказки контрагентов - `/api/dadata/party` — подсказки контрагентов
- `/api/messenger-avatar/[connectionId]` — выдача изображений, связанных с мессенджерными подключениями - `/api/messenger-avatar/[connectionId]` — выдача изображений, связанных с мессенджерными подключениями
## 6.10 Компонентные требования к реализации ## 7.10 Компонентные требования к реализации
Архитектура программного продукта должна сохранять следующие правила: Архитектура программного продукта должна сохранять следующие правила:
@@ -120,13 +120,13 @@
- серверная логика доступа к данным должна проходить через Prisma - серверная логика доступа к данным должна проходить через Prisma
- бизнес-правила доступа должны контролироваться серверной частью, а не только интерфейсом - бизнес-правила доступа должны контролироваться серверной частью, а не только интерфейсом
## 6.11 Требования к конфигурации и секретам ## 7.11 Требования к конфигурации и секретам
Сервисы программного продукта должны получать прикладные секреты из `Vault`. Сервисы программного продукта должны получать прикладные секреты из `Vault`.
В конфигурации сервисов допускается хранение только bootstrap-параметров для подключения к Vault. Бизнес-секреты, ключи интеграций и иные чувствительные данные должны загружаться из Vault при старте приложения. В конфигурации сервисов допускается хранение только bootstrap-параметров для подключения к Vault. Бизнес-секреты, ключи интеграций и иные чувствительные данные должны загружаться из Vault при старте приложения.
## 6.12 Инфраструктура, деплой и эксплуатационный контур ## 7.12 Инфраструктура, деплой и эксплуатационный контур
Текущая инфраструктурная схема проекта включает прикладные сервисы, сервис секретов, мессенджерные сервисы и вспомогательный worker-контур. Текущая инфраструктурная схема проекта включает прикладные сервисы, сервис секретов, мессенджерные сервисы и вспомогательный worker-контур.
@@ -152,7 +152,7 @@
Эксплуатационные операции доступа и диагностики выполняются через Tailscale SSH. Эксплуатационные операции доступа и диагностики выполняются через Tailscale SSH.
## 6.13 Dokploy и цепочка развёртывания ## 7.13 Dokploy и цепочка развёртывания
Для основных сервисов проекта используется режим `dokploy_webhook`. Для основных сервисов проекта используется режим `dokploy_webhook`.
@@ -171,7 +171,7 @@
- `apollo-backend` стартует через загрузку Vault env, `prisma migrate deploy` и запуск `src/server.js` - `apollo-backend` стартует через загрузку Vault env, `prisma migrate deploy` и запуск `src/server.js`
- bot-сервисы стартуют через общий паттерн загрузки Vault env и запуск `node src/server.js` - bot-сервисы стартуют через общий паттерн загрузки Vault env и запуск `node src/server.js`
## 6.14 Vault и хранение секретов ## 7.14 Vault и хранение секретов
Сервис `vault` развернут как отдельное приложение на базе образа `hashicorp/vault:1.21.3`. Сервис `vault` развернут как отдельное приложение на базе образа `hashicorp/vault:1.21.3`.
@@ -190,7 +190,7 @@
- загружает project secrets - загружает project secrets
- экспортирует секреты в runtime environment процесса - экспортирует секреты в runtime environment процесса
## 6.15 Структура сервисных каталогов ## 7.15 Структура сервисных каталогов
Текущая сервисная структура репозитория: Текущая сервисная структура репозитория:
@@ -203,7 +203,7 @@
- `vault` — Dockerfile, конфигурация и entrypoint Vault - `vault` — Dockerfile, конфигурация и entrypoint Vault
- `hatchet` — docker-compose инфраструктурного контура Hatchet - `hatchet` — docker-compose инфраструктурного контура Hatchet
## 6.16 Контур фоновых процессов ## 7.16 Контур фоновых процессов
В проекте присутствует отдельный контур фонового исполнения задач: В проекте присутствует отдельный контур фонового исполнения задач:
@@ -214,7 +214,7 @@
Конфигурация этого контура находится в `hatchet/docker-compose.yml`. Конфигурация этого контура находится в `hatchet/docker-compose.yml`.
## 6.17 Зафиксированные runtime-версии и технологические зависимости ## 7.17 Зафиксированные runtime-версии и технологические зависимости
### Базовые runtime и контейнерные образы ### Базовые runtime и контейнерные образы
@@ -259,7 +259,7 @@
| `nodemailer` | `8.0.4` | email notifications | | `nodemailer` | `8.0.4` | email notifications |
| `dotenv` | `17.3.1` | env bootstrap in local/runtime layers | | `dotenv` | `17.3.1` | env bootstrap in local/runtime layers |
## 6.18 Технические конфигурационные файлы ## 7.18 Технические конфигурационные файлы
Ключевые технические файлы текущей реализации: Ключевые технические файлы текущей реализации: