diff --git a/docs/tz.txt b/docs/tz.txt
new file mode 100644
index 0000000..43e5f47
--- /dev/null
+++ b/docs/tz.txt
@@ -0,0 +1,179 @@
+Техническое задание на разработку программной системы «Бизнес.Точка» (b.point)
+1. Введение
+1.1. Назначение документа
+Настоящее техническое задание определяет требования к разработке программной системы «Бизнес.Точка» (далее — Система), представляющей собой модульную SaaS-платформу для автоматизации бизнес-процессов микробизнеса и индивидуальных предпринимателей на территории Российской Федерации. Документ содержит полное описание функциональных и нефункциональных требований, архитектурных решений, интерфейсных спецификаций и процедур разработки. ТЗ служит основой для всех этапов создания Системы, включая проектирование, программирование, тестирование и внедрение, и является юридическим документом, определяющим границы ответственности Исполнителя и Заказчика.
+Документ предназначен для использования командой разработки, проектным менеджментом, специалистами по тестированию, а также для согласования с Заказчиком. Все изменения в функциональности Системы должны быть задокументированы в виде дополнений к настоящему ТЗ, утверждённых обеими сторонами. Особое внимание уделено описанию механизмов мультитенантности и работы с организациями, поскольку данный функционал является ключевым архитектурным решением, определяющим масштабируемость и удобство использования платформы для различных категорий пользователей.
+1.2. Общее описание продукта
+«Бизнес.Точка» — это комплексная платформа, объединяющая в себе инструменты для управления клиентами (CRM), онлайн-записи на приём, согласования файлов с клиентами (Proof) и управления задачами. Платформа построена по модульной архитектуре, что позволяет пользователям приобретать и активировать только те функциональные блоки, которые необходимы для их бизнеса. Каждый модуль функционирует как независимая подсистема с собственным набором сущностей и бизнес-логики, при этом все модули интегрированы в единое пространство и используют общие данные о клиентах, пользователях и организациях.
+Ключевой особенностью Системы является поддержка мультитенантности с возможностью принадлежности одного пользователя к нескольким организациям. Данный подход позволяет использовать платформу как индивидуальным предпринимателям, работающим самостоятельно, так и небольшим командам, где сотрудники могут быть частью нескольких организаций (например, бухгалтер, работающий с несколькими компаниями). При авторизации пользователь получает возможность выбрать организацию, в контексте которой он будет работать, либо продолжить работу в режиме индивидуального пользователя без привязки к организации.
+1.3. Целевая аудитория
+Основной целевой аудиторией Системы являются представители микробизнеса Российской Федерации — индивидуальные предприниматели, владельцы малых предприятий с численностью сотрудников до 10 человек, самозанятые и фрилансеры. По данным Федеральной налоговой службы, в России зарегистрировано более 4 миллионов индивидуальных предпринимателей и более 7 миллионов самозанятых, что формирует значительный потенциальный рынок для подобного решения. Целевая аудитория характеризуется ограниченным бюджетом на автоматизацию, отсутствием штатных IT-специалистов и потребностью в простых, интуитивно понятных инструментах, не требующих длительного обучения.
+Вторичной целевой аудиторией являются B2B-клиенты — бухгалтерские и консалтинговые компании, управляющие несколькими организациями, а также HR-агентства и рекрутинговые фирмы, работающие с различными заказчиками. Для этих пользователей критически важна возможность централизованного управления несколькими организациями из-под одной учётной записи с быстрым переключением между ними. Также целевой аудиторией являются самозанятые граждане, которые могут использовать базовый функционал Системы бесплатно, что обеспечивает низкий порог входа и возможность органического роста пользовательской базы.
+2. Терминология и определения
+2.1. Базовые понятия
+Для однозначного понимания требований настоящего ТЗ вводится следующая система терминов и определений. Организация — это сущность в Системе, представляющая юридическое или физическое лицо, использующее платформу для ведения бизнеса. Организация может быть зарегистрирована на конкретного пользователя (индивидуальный предприниматель) или представлять команду сотрудников. Каждая организация имеет собственное пространство данных, включая клиентов, сделки, записи, проекты и задачи, которые изолированы от данных других организаций на уровне базы данных.
+Пользователь — это учётная запись физического лица, имеющая доступ к Системе. Пользователь характеризуется уникальным email-адресом, который служит основным идентификатором, а также набором персональных данных (имя, телефон, аватар). Один пользователь может принадлежать к нескольким организациям, при этом для каждой организации может быть назначена определённая роль с соответствующими правами доступа. Пользователь без привязки к организации работает в режиме индивидуального использования, где все созданные данные автоматически ассоциируются с личным пространством пользователя.
+Модуль — это функциональный блок Системы, предоставляющий определённый набор возможностей. Модули являются опциональными и активируются отдельно для каждой организации или пользователя. Модуль «Базовый» (base) включает обязательный минимум функционала (профиль, настройки, уведомления + модуль Клиенты) и доступен всем без дополнительной оплаты. Остальные модули (CRM, Booking, Proof, Tasks) предоставляются по подписке и могут быть активированы по желанию пользователя.
+2.2. Роли и права доступа
+Система предусматривает гибкую систему ролей для управления доступом к функциям в рамках организации. Владелец организации — это пользователь, создавший организацию и имеющий полный доступ ко всем функциям и настройкам. Владелец может приглашать других пользователей, назначать роли, управлять подписками и удалять организацию. Владелец является единственным пользователем с правом удаления организации и смены тарифного плана.
+Администратор организации — это роль, назначаемая Владельцем другим пользователям. Администратор обладает расширенными правами, включая управление пользователями организации, просмотр и редактирование всех данных организации, управление модулями и просмотр финансовой отчётности. Администратор не может удалить организацию или изменить её владельца. Данная роль предназначена для руководителей малых команд или доверенных лиц владельца.
+Менеджер — это роль для обычных сотрудников организации с полным доступом к функционалу модулей, но без возможности управления пользователями и настройками организации. Менеджер может создавать, редактировать и удалять клиентов, сделки, записи, проекты и задачи в рамках своих рабочих обязанностей. Данная роль является ролью по умолчанию для приглашённых пользователей.
+Гость — это ограниченная роль с доступом только к просмотру данных, назначаемым внешним пользователям для демонстрации информации без возможности редактирования. Гость может просматривать список клиентов и сделок, но не может создавать новые записи или изменять существующие. Данная роль используется для предоставления доступа клиентам к системе согласования файлов или просмотра статуса записи.
+3. Функциональные требования
+3.1. Модуль аутентификации и авторизации
+3.1.1. Регистрация нового пользователя
+Процесс регистрации нового пользователя должен обеспечивать минимальное количество шагов для снижения порога входа. Пользователь указывает своё имя, email-адрес и пароль длиной не менее 6 символов. Система автоматически создаёт личное пространство пользователя, которое не привязано к какой-либо организации, и позволяет в дальнейшем создать организацию или присоединиться к существующей. После успешной регистрации пользователю на email отправляется письмо с ссылкой для подтверждения адреса. Ссылка действительна в течение 24 часов, после чего пользователь может запросить повторное письмо.
+При регистрации Система должна автоматически активировать Базовый модуль для нового пользователя, что обеспечивает доступ к профилю, настройкам и уведомлениям. Также необходимо реализовать регистрацию через социальные сети (ВКонтакте, Яндекс) для упрощения процесса входа. При первом входе через социальную сеть Система автоматически создаёт учётную запись пользователя с данными из профиля социальной сети, если такой пользователь ещё не существует. Пароль в этом случае не устанавливается, и аутентификация осуществляется исключительно через социальную сеть. Интеграция входа через социальные сети добавляется уже после запуска в продакшен.
+3.1.2. Процесс аутентификации
+Аутентификация пользователя осуществляется по email и паролю. При успешной аутентификации Система проверяет список организаций, к которым принадлежит пользователь. Если пользователь принадлежит одной организации, происходит автоматический вход в контексте этой организации. Если пользователь принадлежит нескольким организациям или не принадлежит ни одной, отображается страница выбора организации. Пользователь может выбрать одну из существующих организаций или создать новую. Также доступна опция «Работать как индивидуальный пользователь» для работы без привязки к организации.
+Система должна поддерживать функцию «Запомнить меня» сроком на 30 дней для удобства постоянных пользователей. При обнаружении подозрительной активности (вход с нового устройства или IP-адреса) может потребоваться дополнительное подтверждение через email. Все сессии пользователя должны отслеживаться, и пользователь должен иметь возможность просматривать и завершать активные сессии из настроек профиля. Максимальное количество одновременных сессий — 3, при превышении этого лимита старые сессии автоматически завершаются.
+Также необходимо реализовать механизм блокировки пользователя на 15 минут после 5 неудачных попыток входа для защиты от автоматизированных атак.
+3.1.3. Восстановление доступа
+Функционал восстановления пароля реализуется через отправку письма с уникальной ссылкой на указанный пользователем email. Ссылка действительна в течение 1 часа. При переходе по ссылке пользователь устанавливает новый пароль. После успешной смены пароля все активные сессии пользователя завершаются для обеспечения безопасности. Если ссылка не использована в течение часа, она становится недействительной, и пользователь может запросить новую. Также необходимо реализовать механизм блокировки email-адреса на 15 минут после 5 неудачных попыток восстановления пароля для защиты от автоматизированных атак.
+3.2. Модуль управления организациями
+3.2.1. Создание организации
+Пользователь может создать организацию из интерфейса Системы, указав название, при необходимости — юридические реквизиты (ИНН, ОГРН, адрес), контактные данные и логотип. При создании организации пользователь автоматически становится её Владельцем. Система должна валидировать уникальность названия организации в рамках одного владельца (не допускается создание двух организаций с одинаковым названием одним пользователем). Также необходимо обеспечить возможность указания нескольких организационных единиц (филиалов, подразделений) внутри организации для более детальной структуризации данных.
+При создании организации автоматически создаётся пространство данных, включающее базовые справочники и настройки по умолчанию. Организация получает доступ ко всем модулям в режиме триального использования сроком на 14 дней, после чего для продолжения работы с модулями необходимо оформить подписку. Владелец организации может в любой момент удалить организацию, при этом все данные организации безвозвратно удаляются из системы через 30 дней (с возможностью мгновенного удаления по запросу). Удаление организации не затрагивает учётную запись Владельца.
+3.2.2. Приглашение участников
+Владелец и Администраторы организации могут приглашать новых участников по email. Приглашённый пользователь получает письмо со ссылкой для присоединения к организации. Если пользователь с указанным email уже существует в Системе, он сразу добавляется в организацию с выбранной ролью. Если пользователя не существует, создаётся приглашение, которое ждёт регистрации пользователя с этим email в течение 7 дней. После регистрации пользователь автоматически присоединяется к организации.
+Каждый пользователь может принадлежать к неограниченному количеству организаций. Принадлежность к организации не ограничивает возможности пользователя в других организациях. Для каждой организации пользователь может иметь разную роль. Система должна отображать список всех организаций пользователя на странице выбора при входе, с возможностью быстрого переключения между ними без повторной аутентификации. Также необходимо реализовать возможность покинуть организацию для пользователей с ролью Менеджера или Гостя (Владелец не может покинуть организацию, не передав права другому пользователю).
+3.2.3. Переключение между организациями
+Принадлежность пользователя к нескольким организациям реализуется через механизм переключения контекста. После успешной аутентификации пользователь попадает на страницу выбора организации, где отображаются все организации, к которым он принадлежит, а также опция «Личное пространство» для работы без привязки к организации. При выборе организации в сессии сохраняется текущий контекст, и все последующие действия выполняются в рамках выбранной организации. Переключение между организациями возможно в любой момент через интерфейс шапки приложения.
+При переключении организации Система должна обеспечивать сохранение незавершённых действий и корректную загрузку данных новой организации. Интерфейс должен визуально отображать текущую организацию (логотип, название) и обеспечивать быстрый доступ к списку всех доступных организаций. Должна быть реализована история недавних организаций для быстрого переключения между наиболее используемыми. Переключение организации не требует повторной аутентификации, но может потребовать обновления данных пользователя в случае изменения его роли в новой организации.
+3.3. Модуль CRM (Customer Relationship Management)
+3.3.1. Управление клиентами
+Модуль CRM предоставляет функционал для ведения базы клиентов с полной историей взаимодействия. Каждая карточка клиента содержит обязательные поля: имя, контактный телефон, email, дата создания. Опциональные поля включают: компанию (для B2B-клиентов), должность, адрес, источник привлечения, теги для классификации и произвольные заметки. Система должна поддерживать импорт клиентов из CSV-файла с возможностью сопоставления полей, а также экспорт клиентов для формирования отчётов или переноса в другие системы.
+Поиск клиентов должен осуществляться по всем текстовым полям с мгновенной фильтрацией (typeahead). Должна быть реализована поддержка сегментации клиентов по тегам, источникам и дате последнего взаимодействия. Для каждого клиента отображается история всех взаимодействий: звонков, встреч, сделок, заказов. При создании нового клиента Система автоматически проверяет наличие дубликатов по email и телефону и предлагает объединить записи при обнаружении совпадений. Также необходимо реализовать функционал объединения дублирующихся карточек клиентов вручную.
+3.3.2. Воронка продаж
+Система должна предоставлять гибко настраиваемую воронку продаж с возможностью создания произвольного количества этапов. Этапы по умолчанию включают: «Новый лид», «Первичный контакт», «Квалификация», «Коммерческое предложение», «Переговоры», «Успешная сделка», «Потерянная сделка». Для каждого этапа можно настроить цветовую маркировку, автоматические действия при переходе (отправка уведомления, создание задачи) и правила расчёта вероятности успеха.
+Каждая сделка привязывается к клиенту, имеет плановую и фактическую дату закрытия, сумму, валюту и ответственного менеджера. Сделка может содержать связанные контакты, файлы (коммерческие предложения, договоры), комментарии и историю перемещений между этапами. Система должна автоматически рассчитывать показатели эффективности воронки: конверсию по этапам, среднее время жизни сделки, прогноз выручки на основе вероятностей этапов. Должна быть реализована возможность копирования сделок для типовых сценариев продаж.
+3.3.3. Отчётность и аналитика
+Модуль CRM должен предоставлять базовый набор отчётов для анализа эффективности продаж. Отчёт по воронке отображает количество сделок и сумму на каждом этапе с возможностью фильтрации по периоду, ответственному менеджеру и источнику. Отчёт по менеджерам показывает количество закрытых сделок, сумму выручки и средний чек для каждого сотрудника. Отчёт по клиентам отображает RFM-сегментацию (Recency, Frequency, Monetary) для выявления наиболее ценных клиентов.
+Все отчёты должны быть доступны в формате PDF для печати и отправки клиентам, а также в формате CSV для дальнейшей обработки в табличных редакторах. Должна быть реализована возможность сохранения настроенных фильтров и регулярной отправки отчётов на email по расписанию. Интерфейс отчётов должен включать визуализацию данных в виде графиков и диаграмм для наглядного представления тенденций. Для индивидуальных пользователей (без организации) отчёты формируются на основе их личных данных без возможности фильтрации по менеджерам.
+3.4. Модуль записи на приём (Booking)
+3.4.1. Управление услугами
+Модуль Booking предоставляет функционал для онлайн-записи клиентов на приём. Администраторы организации создают каталог услуг с указанием названия, описания, продолжительности в минутах, стоимости и категории. Услуги могут быть сгруппированы по категориям (например, «Консультации», «Процедуры», «Сервисное обслуживание») для удобства навигации. Для каждой услуги можно настроить цветовую маркировку для отображения в календаре, а также правила отмены и переноса записи.
+Система должна поддерживать указание нескольких специалистов для одной услуги с возможностью выбора конкретного специалиста клиентом или автоматическим распределением по нагрузке. Для каждого специалиста настраивается индивидуальное расписание работы, перерывы и выходные дни. Также должна быть реализована возможность настройки буферного времени между записями для подготовки к следующему клиенту. Услуги могут быть отмечены как доступные для онлайн-записи или только для записи через администратора.
+3.4.2. Календарь и запись
+Основной интерфейс модуля — календарь с отображением всех записей на выбранный период (день, неделя, месяц). Записи отображаются цветными блоками с указанием клиента, услуги, времени и статуса. Система должна поддерживать перетаскивание записей для быстрого изменения времени (drag-and-drop), а также изменение размера для корректировки продолжительности. При перетаскивании записи Система автоматически проверяет доступность времени и не допускает наложения записей.
+Создание новой записи возможно через клик на свободное время в календаре или через карточку клиента в CRM. При создании записи выбирается клиент (из существующих или создаётся новый), услуга, специалист и время. Система автоматически проверяет доступность выбранного специалиста и не допускает создания конфликтующих записей. Клиенту отправляется email и/или сообщение в телеграмм с подтверждением записи с возможностью самостоятельной отмены или переноса (если настроено). Записи можно отмечать статусами: «Подтверждена», «В ожидании», «Завершена», «Отменена», «Неявка».
+3.4.3. Уведомления и напоминания
+Система должна автоматически отправлять напоминания о предстоящих записях. По умолчанию напоминание отправляется за 24 часа и за 1 час до записи. Настройки напоминаний индивидуальны для каждой организации и могут быть изменены Владельцем или Администратором. Напоминания отправляются через email, а также через сообщение в телеграмм (при наличии).
+При создании записи клиент может указать предпочтительный способ получения напоминаний. Система должна поддерживать отправку уведомлений через Telegram при интеграции с соответствующим API. В случае отмены записи клиентом или специалистом всем заинтересованным сторонам отправляется уведомление об отмене. Также должна быть реализована функция автоматического напоминания о повторных визитах (например, запись на следующий месяц при завершении текущего).
+3.5. Модуль согласования файлов (Proof)
+3.5.1. Проекты и файлы
+Модуль Proof предназначен для согласования файлов с клиентами — дизайн-макетов, документов, фотографий и других материалов. Проект объединяет связанные файлы и комментарии в единое пространство. Каждый проект имеет название, описание, привязку к клиенту (опционально) и список участников. Участниками проекта являются сотрудники организации с ролью Менеджер или выше, а также внешние клиенты с ролью Гость для просмотра и комментирования.
+Загрузка файлов в проект осуществляется через drag-and-drop или стандартный диалог выбора файлов. Система должна поддерживать предпросмотр изображений, PDF-документов и видеофайлов без скачивания. Для каждого файла отображается история версий — все загруженные версии файла с датой, автором и комментарием. При загрузке новой версии предыдущие версии сохраняются и доступны для скачивания. Максимальный размер загружаемого файла — 100 МБ, общее хранилище на организацию — 5 ГБ (расширяется при активации расширенного хранилища).
+3.5.2. Комментарии и утверждение
+Каждый файл в проекте может иметь неограниченное количество комментариев. Комментарии привязываются к конкретной области файла с использованием координат (pin) для точного указания места, к которому относится комментарий. Это позволяет вести диалог о конкретных элементах дизайн-макета или документа. При добавлении комментария создаётся уведомление для всех участников проекта.
+Система должна поддерживать статусы утверждения для каждой версии файла: «На рассмотрении», «Требует правок», «Утверждено», «Отклонено». Клиент может одним кликом подтвердить соответствие файла требованиям или отклонить с указанием причины. При утверждении файла создаётся финальная версия проекта, недоступная для дальнейших правок. Все действия с файлами (загрузка, комментарий, утверждение, отклонение) фиксируются в журнале активности проекта с указанием автора, времени и деталей действия.
+3.5.3. Публичные ссылки
+Для каждого проекта может быть сгенерирована публичная ссылка для внешнего доступа. Ссылка содержит уникальный токен и позволяет просматривать файлы и комментарии без авторизации в Системе. Это удобно для отправки материалов клиентам, которые не имеют учётной записи в b.point. Публичная ссылка может быть защищена паролем, иметь ограниченный срок действия и лимит количества просмотров.
+При переходе по публичной ссылке отображается веб-интерфейс просмотра файлов с возможностью добавления комментариев (если включено). Комментарии, добавленные через публичную ссылку, сохраняются в проекте и видны авторизованным пользователям. Владелец организации может в любой момент отключить публичный доступ или сгенерировать новую ссылку. Для защиты конфиденциальных данных рекомендуется использовать защищённые паролем ссылки.
+3.6. Модуль управления задачами (Tasks)
+3.6.1. Задачи и проекты задач
+Модуль Tasks предоставляет функционал для управления задачами и проектами в формате канбан-доски. Задача содержит название, описание, исполнителя, срок выполнения, приоритет и метки. Задачи объединяются в доски по проектам или произвольным категориям (например, «Текущие задачи», «Бэклог», «На этой неделе»). Каждая доска состоит из колонок, которые пользователь настраивает самостоятельно.
+По умолчанию создаётся доска «Мои задачи» с колонками «К выполнению», «В работе», «На проверке», «Завершено». Система должна поддерживать перетаскивание задач между колонками с автоматическим обновлением статуса. Каждая задача может иметь подзадачи для декомпозиции сложных работ. Также должна быть реализована возможность добавления вложений к задачам, создания чек-листов и указания зависимостей между задачами (блокирующие и зависимые задачи).
+3.6.2. Комментарии и уведомления
+К каждой задаче можно добавлять комментарии для обсуждения деталей выполнения. При изменении задачи (изменение статуса, назначение исполнителя, добавление комментария) создаются уведомления для всех заинтересованных пользователей. Уведомления отображаются в интерфейсе приложения и отправляются на email. Система должна поддерживать подписку на задачи — пользователь автоматически получает уведомления о всех изменениях в задачах, на которые он подписан.
+Также должна быть реализована функция упоминания пользователей в комментариях с помощью символа @. При упоминании пользователь получает уведомление независимо от того, подписан ли он на задачу. Для организации работы команды рекомендуется использовать упоминания для делегирования задач и запроса обратной связи. Должна быть реализована возможность массового изменения задач (изменение исполнителя, срока, меток для выбранных задач).
+3.6.3. Интеграция с другими модулями
+Модуль Tasks должен быть интегрирован с модулем CRM для автоматического создания задач по сделкам. Например, при переводе сделки на этап «Коммерческое предложение» автоматически создаётся задача на подготовку КП. При завершении сделки может создаваться задача на отправку благодарственного письма клиенту. Правила автоматизации настраиваются администратором организации.
+Также должна быть реализована интеграция с модулем Booking — после завершения записи на приём автоматически создаётся задача на подготовку к встрече или обработку результатов. При создании задачи из интерфейса клиента в CRM автоматически привязывается этот клиент. Все созданные задачи отображаются в карточке клиента во вкладке «Активность» для полной картины взаимодействия.
+3.7. Модуль уведомлений
+3.7.1. Центр уведомлений
+Система должна предоставлять централизованный интерфейс для просмотра всех уведомлений пользователя. Уведомления группируются по модулям и отображаются в хронологическом порядке. Каждое уведомление содержит тип (информационное, предупреждение, ошибка), заголовок, сообщение, ссылку на связанный объект и время создания. Непрочитанные уведомления визуально выделяются и отображаются в счётчике в шапке приложения.
+Пользователь может пометить уведомление как прочитанное кликом или автоматически при переходе по ссылке. Должна быть реализована функция «Отметить все как прочитанные» и настройка автоматической очистки уведомлений старше 30 дней. При поступлении нового уведомления пользователь получает визуальный индикатор (красная точка на иконке колокольчика) и, при наличии соответствующего разрешения, Push-уведомление в браузере.
+3.7.2. Каналы уведомлений
+Система должна поддерживать несколько каналов доставки уведомлений. Email-уведомления отправляются для важных событий (регистрация, смена пароля, подтверждение записи, завершение сделки). Push-уведомления в браузере используются для оперативного информирования о новых сообщениях и обновлениях задач. В будущих версиях планируется добавление Telegram-уведомлений.
+Настройки уведомлений индивидуальны для каждого пользователя и позволяют отключить определённые типы уведомлений или каналы доставки. По умолчанию все каналы уведомлений включены, но пользователь может отключить, например, Push-уведомления в браузере или email-уведомления о задачах. Настройки хранятся в профиле пользователя и применяются ко всем организациям, в которых состоит пользователь.
+4. Нефункциональные требования
+4.1. Требования к производительности
+Система должна обеспечивать приемлемое время отклика для типовых операций пользователя. Время загрузки любой страницы не должно превышать 2 секунд при стандартном интернет-соединении (10 Мбит/с). Время отклика на действия пользователя (клик, ввод данных) — не более 200 миллисекунд. Операции, требующие длительной обработки (импорт данных, генерация отчётов), должны выполняться в фоновом режиме с отображением индикатора прогресса.
+Система должна поддерживать одновременную работу не менее 1000 активных пользователей без деградации производительности. При превышении этого порога должна быть реализована горизонтальная масштаруемость для добавления серверных мощностей. Время восстановления работоспособности после сбоя (RTO) не должно превышать 1 часа, целевая точка восстановления (RPO) — 15 минут для критических данных.
+4.2. Требования к безопасности
+Все коммуникации между клиентом и сервером должны осуществляться по протоколу HTTPS с использованием TLS 1.2 или выше. Пароли пользователей должны храниться в базе данных в виде bcrypt-хеша с автоматической генерацией соли. Система должна обеспечивать защиту от распространённых веб-атак: SQL-инъекций, XSS (межсайтовый скриптинг), CSRF (межсайтовая подделка запросов), Clickjacking.
+Сессии пользователей должны быть защищены от фиксации и перехвата. При обнаружении подозрительной активности (множественные неудачные попытки входа, вход с необычного IP) система должна блокировать учётную запись или требовать дополнительного подтверждения. Журналирование действий пользователей должно включать: вход/выход, изменение критических данных (пароль, email, настройки организации), финансовые операции. Журналы должны храниться не менее 90 дней.
+4.3. Требования к доступности
+Целевой показатель доступности Системы — 99,5% (не более 43,8 часа простоя в год). Плановые технические работы должны проводиться в ночное время по московскому часовому поясу (с 2:00 до 6:00) с предварительным уведомлением пользователей за 24 часа. Экстренные обновления безопасности могут проводиться без предварительного уведомления.
+Система должна быть размещена на инфраструктуре, обеспечивающей отказоустойчивость: дублирование серверов, автоматическое переключение на резервные мощности в случае сбоя. Данные пользователей должны регулярно резервироваться (ежедневно инкрементные бэкапы, еженедельно полные) с хранением копий в географически удалённом дата-центре.
+4.4. Требования к масштабируемости
+Архитектура Системы должна обеспечивать возможность горизонтального масштабирования для увеличения производительности и ёмкости. Модульная структура позволяет независимо масштабировать отдельные компоненты системы в зависимости от нагрузки. База данных должна поддерживать репликацию для распределения нагрузки на чтение и обеспечения отказоустойчивости.
+Хранилище файлов должно быть реализовано с использованием объектного хранилища (S3-совместимого) для неограниченного масштабирования и эффективной работы с медиафайлами. Система должна поддерживать работу в облачной инфраструктуре (AWS, Yandex Cloud, VK Cloud) с возможностью размещения on-premise для корпоративных клиентов с повышенными требованиями к безопасности.
+5. Архитектура системы
+5.1. Общая архитектура
+Система построена на трёхуровневой архитектуре с использованием паттерна MVC (Model-View-Controller). Веб-приреализовано на фреймворке CodeIgniter 4, обеспечивающем высокую производительность и низкий порог входа для разработчиков. Бэкенд-часть реализует REST API для основного веб-интерфейса и мобильных приложений. Клиентская часть использует серверный рендеринг с минимальным количеством JavaScript для интерактивных элементов.
+База данных — реляционная СУБД MySQL 8.0 с использованием InnoDB в качестве движка хранения. MySQL обеспечивает ACID-транзакции, необходимые для финансовых операций и целостности данных организации. Для кэширования часто запрашиваемых данных используется Redis, также применяемый для хранения сессий пользователей и очередей фоновых задач. Файлы хранятся в объектном хранилище S3-совместимого типа с CDN для быстрой доставки статического контента.
+5.2. Мультитенантность
+5.2.1. Модель данных
+Для реализации мультитенантности с поддержкой организаций и индивидуальных пользователей используется следующая модель данных. Сущность Organization содержит информацию об организации: название, реквизиты, настройки, связь с тарифным планом. Сущность OrganizationUser представляет связь между пользователем и организацией с указанием роли, статуса (активен, приглашён, заблокирован) и даты присоединения. Для индивидуальных пользователей создаётся виртуальная организация с типом «personal», не отображаемая в интерфейсе.
+Все бизнес-сущности (клиенты, сделки, записи, проекты, задачи) имеют обязательное поле organization_id, определяющее принадлежность к организации. Для индивидуальных пользователей это поле ссылается на их личную организацию. Запросы к данным всегда включают условие фильтрации по organization_id, что обеспечивает изоляцию данных на уровне приложения. Дополнительно используется поле user_id для указания создателя или ответственного, что позволяет реализовать персональные списки и персональные задачи.
+5.2.2. Изоляция данных
+Изоляция данных между организациями обеспечивается комбинацией технических и организационных мер. На уровне базы данных все запросы к бизнес-сущностям включают условие WHERE organization_id = ? с подстановкой текущей организации из контекста сессии. Это исключает возможность случайного или намеренного доступа к данным другой организации через манипуляцию параметрами запроса.
+На уровне приложения реализована проверка прав доступа при выполнении операций. Пользователь может работать только с данными организаций, к которым он принадлежит. При попытке доступа к данным другой организации возвращается ошибка 403 Forbidden. Журналирование всех действий включает идентификатор организации, что позволяет проводить аудит и выявлять попытки несанкционированного доступа.
+5.2.3. Переключение контекста
+При аутентификации пользователя Система определяет список доступных организаций и отображает интерфейс выбора. Выбранная организация сохраняется в сессии пользователя и используется как контекст для всех последующих запросов. Переключение организации осуществляется через специальный API-эндпоинт, который обновляет контекст в сессии и возвращает обновлённые данные интерфейса.
+Для обеспечения быстрого переключения между организациями данные часто используемых организаций кэшируются в Redis с привязкой к сессии. При переключении организации сброс кэша не требуется, так как данные каждой организации хранятся отдельно. Интерфейс приложения отображает текущую организацию и предоставляет выпадающий список для быстрого переключения.
+5.3. Модульная архитектура
+5.3.1. Структура модулей
+Каждый функциональный модуль (CRM, Booking, Proof, Tasks) реализован как самодостаточный компонент с собственной структурой контроллеров, моделей, представлений и сервисов. Модули расположены в отдельных пространствах имён (App\Modules[ModuleName]) и загружаются динамически при активации. Это позволяет добавлять новые модули без изменения ядра системы.
+Общие компоненты (аутентификация, уведомления, работа с файлами) вынесены в ядро системы и используются всеми модулями. Модули могут расширять функциональность ядра через события и хуки. Например, при создании клиента в CRM модуль Tasks может автоматически создать задачу на первичный контакт через подписку на событие.
+5.3.2. Активация модулей
+Активация модуля для организации осуществляется через сервис Billing. При активации модуля создаётся запись в таблице user_modules с указанием организации, модуля, статуса подписки и периода оплаты. Модуль становится доступным в интерфейсе организации после успешной активации и оплаты.
+Доступ к функциям модуля контролируется сервисом ModuleManager, который проверяет наличие активной подписки перед выполнением любой операции модуля. Если подписка истекла или отменена, пользователь перенаправляется на страницу продления подписки. При отмене подписки данные модуля сохраняются в течение 90 дней, после чего могут быть безвозвратно удалены.
+5.4. Технологический стек
+Бэкенд-часть Системы реализована на языке PHP 8.1 с использованием фреймворка CodeIgniter 4. CodeIgniter выбран за высокую производительность, низкое потребление памяти и простоту освоения для разработчиков с опытом работы с PHP. Фреймворк обеспечивает реализацию паттерна MVC, маршрутизацию запросов, работу с базой данных через Active Record и встроенные механизмы безопасности.
+База данных — MySQL 8.0 с использованием InnoDB. InnoDB обеспечивает поддержку транзакций, внешних ключей и блокировок на уровне строк, необходимых для целостности данных. Для кэширования используется Redis, также применяемый для хранения сессий и реализации очередей задач через механизм Redis Queue. Очереди задач используются для фоновой обработки отправки уведомлений, генерации отчётов и импорта данных.
+Клиентская часть реализована с использованием серверного рендеринга через Twig в качестве шаблонизатора. Для интерактивных элементов используется чистый JavaScript без тяжёлых фреймворков. Стилизация выполнена на CSS с использованием переменных для theming и медиа-запросов для адаптивности. Активы (CSS, JS, изображения) сжимаются и обслуживаются через CDN для ускорения загрузки.
+6. Интерфейсные требования
+6.1. Общие принципы дизайна
+Интерфейс Системы должен следовать принципам минимализма и функциональности. Дизайн выполнен в светлой цветовой схеме с акцентным синим цветом для основных действий. Типографика основана на системных шрифтах для максимальной производительности и совместимости. Все интерактивные элементы имеют чёткие состояния (по умолчанию, наведение, нажатие, фокус, недоступно).
+Адаптивный дизайн обеспечивает корректное отображение на устройствах с разрешением от 320px (мобильные телефоны) до 4K (большие мониторы). На мобильных устройствах боковая панель скрывается и доступна через меню-гамбургер. Списки и таблицы адаптируются для прокрутки по горизонтали с фиксацией первого столбца (название) для контекста.
+6.2. Навигация и структура
+Основная навигация реализована через боковую панель, содержащую пункты меню для активных модулей. Пункты меню отображаются только для модулей, на которые у организации есть активная подписка. Для неактивных модулей отображается плитка с информацией о модуле и кнопкой активации в разделе «Модули». Это обеспечивает контекстную навигацию и направляет пользователя к приобретению дополнительного функционала.
+В шапке приложения отображается название текущей организации с возможностью переключения, уведомления и профиль пользователя. Переключение организаций реализовано через выпадающий список с поиском для быстрого доступа к нужной организации. Профиль пользователя содержит ссылку на настройки и выход из системы. Навигация должна обеспечивать переход к любому разделу Системы не более чем за 3 клика.
+6.3. Формы и ввод данных
+Все формы в Системе должны использовать визуальную валидацию с отображением ошибок под соответствующим полем. Обязательные поля помечаются звёздочкой и проверяются перед отправкой формы. Состояние кнопки отправки блокируется при наличии ошибок валидации и разблокируется после их исправления. Длинные формы разбиваются на логические шаги с индикатором прогресса.
+Автозаполнение полей реализовано через AJAX-запросы к серверу для обеспечения актуальности данных. Например, при вводе названия организации в поле «Клиент» отображаются существующие клиенты с похожим названием. Выбор из списка осуществляется через стрелки навигации и Enter для быстрого ввода без использования мыши. Для полей с большим количеством вариантов (выбор клиента, услуги) реализован виртуальный скроллинг для эффективной работы с тысячами записей.
+6.4. Таблицы и списки
+Списки объектов отображаются в табличном виде с возможностью сортировки по столбцам, фильтрации и поиска. Пагинация реализована через бесконечную прокрутку для мобильных устройств и классическую постраничную для десктопа. Для таблиц с большим количеством столбцов реализована горизонтальная прокрутка с фиксацией первых столбцов (ID, название).
+Экспорт данных в CSV и PDF доступен для всех списочных экранов. Экспорт в CSV включает все отображаемые столбцы и позволяет выбрать дополнительные для включения. Экспорт в PDF генерирует отформатированный документ с логотипом организации, датой выгрузки и навигацией по страницам. Массовые операции (удаление, изменение статуса) доступны через чекбоксы в первой колонке таблицы.
+7. Биллинг и монетизация
+7.1. Модель ценообразования
+Система использует модель подписки с помесячной или годовой оплатой. Базовый модуль предоставляется бесплатно и включает минимальный функционал (профиль, настройки, уведомления, Клиенты). Дополнительные модули оплачиваются отдельно: CRM, Booking, Proof, Tasks — по 300 ₽ в месяц за каждый модуль. При оплате за год предоставляется скидка 10% (3000 ₽ за модуль в год).
+При приобретении всех четырёх модулей предоставляется пакетная скидка: полный комплект стоит 1000 ₽ в месяц (экономия 200 ₽) или 10000 ₽ в год (экономия 2000 ₽). Для организаций, работающих в штатном режиме без привязки к организации (индивидуальные пользователи), цены идентичны. Все цены указаны с учётом НДС 20%.
+7.2. Триальный период
+Каждая организация получает 14-дневный триальный период для всех платных модулей. Триал активируется автоматически при создании организации и не требует ввода платёжных данных. По истечении триального периода модуль автоматически деактивируется, но данные сохраняются в течение 90 дней. При активации модуля в триальный период возвращается оплата за неиспользованные дни.
+Повторный триальный период для одного модуля одной организации не предоставляется. При необходимости повторного тестирования модуля рекомендуется использовать демо-организацию с ограниченным доступом. Для особых случаев (крупные корпоративные клиенты) может быть предоставлен расширенный триальный период по согласованию с отделом продаж.
+7.3. Платёжные интеграции
+Оплата принимается через платёжный агрегатор Robokassa, поддерживающий все популярные в России способы оплаты: банковские карты (Visa, Mastercard, Мир), электронные кошельки (ЮMoney, Qiwi), рассрочка (Халва, Совесть), банковский перевод для юридических лиц. Robokassa выбран за простоту интеграции, надёжность и соответствие требованиям 54-ФЗ о кассах.
+При оплате юридическим лицом выставляется счёт на оплату с реквизитами организации. Счёт действителен в течение 5 рабочих дней. После поступления оплаты подписка активируется вручную бухгалтерией. Для регулярных платежей реализовано сохранение карты и автосписание по истечении периода подписки с предварительным уведомлением за 7 дней.
+7.4. Возвраты и отмена
+Возврат денежных средств возможен в течение 14 дней с момента оплаты при условии, что подписка не была использована (отсутствие активности в модуле). Возврат осуществляется на карту или счёт, с которого была произведена оплата, в течение 5 рабочих дней. Для юридических лиц возврат оформляется актом сверки и возвратом на расчётный счёт.
+Отмена подписки возможна в любое время через интерфейс биллинга. При отмене подписки доступ к модулю сохраняется до конца оплаченного периода. Досрочное прекращение подписии без возврата средств не предусмотрено, кроме случаев технических сбоев, подтверждённых службой поддержки. При отмене подписки пользователь получает уведомление за 7 дней до окончания периода с предложением продлить.
+8. Развёртывание и эксплуатация
+8.1. Требования к инфраструктуре
+Для работы Системы требуется веб-сервер с поддержкой PHP 8.1 и выше (рекомендуется PHP 8.2), база данных MySQL 8.0, Redis для кэширования и очередей. Минимальная конфигурация для тестовой среды: 2 CPU, 2 GB RAM, 20 GB SSD. Рекомендуемая конфигурация для рабочей среды с нагрузкой до 1000 пользователей: 4 CPU, 8 GB RAM, 50 GB SSD. Горизонтальное масштабирование достигается добавлением веб-серверов за балансировщиком нагрузки.
+Для хранения файлов рекомендуется использовать S3-совместимое объектное хранилище (Yandex Object Storage, VK Cloud Storage, AWS S3). Объём хранилища масштабируется автоматически по мере загрузки файлов. Для доставки статического контента рекомендуется использовать CDN (Cloudflare, VK Cloud CDN) для ускорения загрузки страниц в регионах, удалённых от сервера.
+8.2. Процесс развёртывания
+Развёртывание Системы осуществляется через следующие шаги: клонирование репозитория, установка зависимостей через Composer, настройка конфигурации через файл .env, запуск миграций базы данных, заполнение справочников через сидеры, настройка веб-сервера (Nginx/Apache), настройка SSL-сертификата, запуск рабочих процессов для очередей задач.
+Для production-развёртывания рекомендуется использовать Docker с готовыми образами. Docker Compose определяет сервисы: веб-приложение, MySQL, Redis, Redis Queue Worker. Образы собираются на базе официальных образов PHP-FPM и Nginx с оптимизацией для CodeIgniter. При обновлении версии достаточно заменить образ приложения и запустить миграции.
+8.3. Мониторинг и логирование
+Система должна быть оснащена комплексным мониторингом для оперативного выявления проблем. Метрики собираются через Prometheus и визуализируются в Grafana. Отслеживаемые метрики включают: время ответа сервера, количество запросов, использование CPU и памяти, размер очередей, количество активных сессий, количество ошибок по типам.
+Логи приложения хранятся в структурированном формате JSON для удобства анализа. Логи сохраняются локально и ротируются ежедневно с хранением за последние 30 дней. Для production-среды рекомендуется централизованное логирование через ELK-стек (Elasticsearch, Logstash, Kibana) или облачные решения (Yandex Monitoring, CloudWatch). Алерты настраиваются на критические события (высокая нагрузка, ошибки базы данных, недоступность сервисов) с уведомлением в Telegram и на email дежурного администратора.
+9. Сроки и этапы разработки
+9.1. Этап 1: Фундамент и базовый модуль (текущий)
+Создание базовой архитектуры системы: настройка CodeIgniter 4, миграции базы данных, базовые модели и контроллеры, система аутентификации и авторизации, механизм мультитенантности и организаций, базовый интерфейс и навигация, сервисы для работы с модулями и уведомлениями, модуль Клиенты. Срок реализации: 1 неделя.
+9.2. Этап 2: Модуль CRM
+Реализация модуля CRM: управление клиентами, воронка продаж, сделки, история взаимодействий, отчётность, импорт/экспорт данных, интеграция с модулем задач. Срок реализации: 2 недели.
+9.3. Этап 3: Модуль Booking
+Реализация модуля записи на приём: каталог услуг, календарь, управление расписанием, запись клиентов, уведомления и напоминания, статусы записей. Срок реализации: 2 недели.
+9.4. Этап 4: Модуль Proof
+Реализация модуля согласования файлов: проекты, загрузка и версионирование файлов, комментарии с привязкой к области, статусы утверждения, публичные ссылки. Срок реализации: 2 недели.
+9.5. Этап 5: Модуль Tasks
+Реализация модуля управления задачами: канбан-доски, задачи и подзадачи, комментарии и упоминания, интеграция с другими модулями. Срок реализации: 1,5 недели.
+9.6. Этап 6: Биллинг и платежи
+Реализация биллинговой системы: тарифные планы, активация модулей, интеграция с Robokassa, личный кабинет с историей платежей. Срок реализации: 1,5 недели.
+10.7. Этап 7: Тестирование и запуск
+Комплексное тестирование, исправление ошибок, подготовка документации, развёртывание production-среды, запуск публичного доступа. Срок реализации: 1 неделя.
+Общая оценочная продолжительность разработки: 11 недель.