Добавить Банкротство.Про.md

Банкротство.Про.md

@@ -0,0 +1,312 @@
+
+# КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ
+**Тема:** Разработка автоматизированной системы управления делами о банкротстве физических лиц «Банкротство.Про» (рабочее название)
+
+## 1. Цели и бизнес-ценность
+**Проблема:** Ведение сотен дел вручную приводит к риску пропуска процессуальных сроков (что грозит отстранением АУ и убытками), рутине при рассылке запросов в госорганы и сложности в контроле этапов (РДГ, РиГ).
+**Решение:** Создание единой цифровой среды, где каждый шаг алгоритма (согласно загруженному файлу) превращается в автоматическую задачу, а рутина (запросы, публикации, расчеты) делегируется системе.
+**Результат:** 
+* Снижение трудозатрат на 1 дело на **60-70%**.
+* Исключение пропусков процессуальных сроков (система не даст провести дело дальше, если не закрыт предыдущий блок).
+* Возможность вести на одного юриста не 20-30, а **100-150 дел** одновременно.
+
+---
+
+## 2. Архитектура и Этапы разработки
+
+Разработка разделена на 3 последовательных этапа. Такой подход позволяет быстро получить работающий инструмент (MVP) и постепенно внедрять сложный функционал.
+
+### ЭТАП 1: Базовый интерфейс и цифровой архив (Фундамент)
+**Цель этапа:** Оцифровать все дела, создать единое пространство для документов и жесткий контроль процессуальных сроков.
+**Функционал:**
+1. **Ролевая модель и Авторизация:** Руководитель, Юрист.
+   * Юрист (Исполнитель): Видит только свои дела. Заполняет данные, загружает документы, отмечает выполнение шагов алгоритма. Не может удалять дела или менять глобальные настройки.
+   * Руководитель (Администратор): Видит все дела всех юристов. Имеет доступ к сводному Дашборду рисков.
+    Ключевая функция «Войти как» (Impersonation): В таблице дел рядом с ФИО юриста есть кнопка. При нажатии открывается новая вкладка браузера, где руководитель автоматически авторизуется под учетной записью этого юриста (без ввода пароля), чтобы проверить корректность заполнения карточки глазами сотрудника.
+2. **Карточка Дела (Досье должника):** Создаётся на основе запоненной "Формы должника" разработанной ранее.
+   * Паспортные данные, СНИЛС, ИНН, контакты, занятость, семейное положение и т.д. 
+   * Блок «Кредиторы» (с привязкой к очередям РТК), дорабатывается в процессе хода дела. 
+   * Блок «Имущество» (электронная опись), дорабатывается в процессе хода дела.
+3. **Умный Календарь и Трекер сроков (Критически важно):**
+   * Автоматический расчет сроков на основе алгоритма (например: *«+2 месяца от даты Ъ для требований кредиторов»*, *«+15 дней от утверждения ФУ для запросов в ГИБДД/ФНС»*).
+   * Цветовая индикация (зеленый/желтый/красный) и push/email уведомления ответственным за 3 дня до дедлайна.
+4. **Хранилище документов:** Загрузка, тегирование и привязка документов к конкретным шагам алгоритма (Определения суда, чеки ЕФРСБ, ответы ЗАГС/ФНС).
+5. **Список дел:** Визуализация портфеля дел по статусам (Сбор документов -> РДГ -> ФА/СК -> РиГ -> Завершение).
+
+* **Срок реализации:** 1.5 месяца
+* **Стоимость:** 170 000 ₽
+
+---
+
+### ЭТАП 2: Внешние интеграции и автоматизация рутины
+**Цель этапа:** Убрать ручное составление типовых запросов, интеграция с внешними сервисами для публикации и сбора данных. Возможность интеграции определяется на момент заключения договора.
+**Функционал:**
+1. **Генератор простых документов и массовая рассылка:**
+   * Автоматическая генерация пакетов запросов в госорганы (ГИБДД, ГИМС, ЗАГС, ФНС, ПФР, Роспатент) и банки (на основе данных из ФНС).
+   * Интеграция с API Почты России / сервисами электронного документооборота (СДЭК, Диадок) для автоматической отправки бумажных и ЭД писел.
+2. **Интеграция с ЕФРСБ и Коммерсантъ:**
+   * Прямая API-интеграция (или полуавтоматическая выгрузка XML/JSON макетов) для публикации сообщений о введении РДГ, итогах СК, переходе в РиГ.
+   * Автоматическое получение появляющихся документов из ЕФРСБ
+   * Автоматическое сохранение чеков и ID публикаций в карточку дела (Блок расходов).
+3. **Интеграция с «Мой Арбитр» (Кад Арбитр):**
+   * Парсинг событий по делу (автоматическое подтягивание новых Определений суда в карточку).
+   * Формирование пакетов документов для подачи через систему ЭДО «Мой Арбитр».
+4. **Клиентский портал / Telegram-бот:**
+   * Уведомление должника о ходе процесса.
+   * Автоматическая отправка должнику запросов на предоставление недостающих документов (чек-листы). Одноразовая страница загрузки данных.
+
+* **Срок реализации:** 2 месяца
+* **Стоимость:** ~200 000 ₽
+
+---
+
+### ЭТАП 3: Интеллект, Финансовый анализ и сложные документы
+**Цель этапа:** Автоматизировать самую сложную и дорогую часть работы юриста/помощника — анализ сделок, подготовку отчетов и проведение Собраний кредиторов (СК).
+**Функционал:**
+1. **AI Модуль Финансового Анализа (ФА) и Заключений:**
+   * Импорт выписок по счетам (парсинг PDF/Excel/1C).
+   * Автоматический расчет движения денежных средств, выявление транзакций, подпадающих под признаки оспариваемых сделок (неравноценное встречное исполнение, вывод активов).
+   * Генератор черновиков «Заключения о наличии/отсутствии признаков фиктивного/преднамеренного банкротства».
+2. **Продвинутый генератор процессуальных документов:**
+   * Автоматическое формирование «Отчета АУ», «Ходатайства о переходе в РиГ», «Возражений на требования кредиторов» (на основе данных из РТК и карточки дела).
+3. **Автоматизация Собрания Кредиторов (СК):**
+   * Автоматическая генерация Бюллетеней для голосования на основе утвержденного РТК.
+   * Модуль подсчета голосов (при заочном голосовании): загрузка сканов/ЭЦП, автоматический расчет кворума и принятия решений.
+   * Генерация Протокола СК и автоматическая подготовка макета публикации результатов в ЕФРСБ.
+4. **Аналитика для Руководства:**
+   * Дашборды: загрузка сотрудников, рентабельность каждого дела (Доходы минус РХ на публикации/почту), карта рисков (дела, где скоро истекают критические сроки).
+
+* **Срок реализации:** 2.5 месяца
+* **Стоимость:** ~500 000 ₽
+
+---
+
+## 3. Сводные сроки и бюджет
+
+| Этап | Описание | Сроки | Стоимость (ориентир) |
+| :--- | :--- | :--- | :--- |
+| **Этап 1** | CRM, Карточки дел, Календарь сроков, Роли, Архив | 1.5 мес. | 170 000 ₽ |
+| **Этап 2** | Интеграции (ЕФРСБ, Почта, Кад Арбитр), Бот для клиентов, Авто-запросы | 2 мес. | 200 000 ₽ |
+| **Этап 3** | ФА, Парсинг выписок, Генерация Отчетов АУ, Модуль СК | 2.5 мес. | 500 000 ₽ |
+| **ИТОГО** | **Полный цикл разработки и внедрения** | **~ 6 мес.** | **~ 1 650 000 ₽** |
+
+*Примечание: После сдачи проекта предполагается выделение 10-15% от бюджета на ежемесячную техническую поддержку, обновление интеграций (т.к. API госорганов и ЕФРСБ периодически меняются) и доработку мелкого функционала. Также, необходим выделенный виртульный сервер для размещения проекта, стартовая стоимость 3-5т.р./мес*
+
+---
+
+## 4. Предлагаемый Стек технологий
+Учитывая требования к надежности, масштабируемости и современным стандартам веб-разработки, предлагается следующий стек:
+
+* **Backend (Серверная часть):** Node.js (NestJS или Express) — отлично подходит для высоконагруженных систем, работы с очередями задач (отправка писем, парсинг) и интеграциями.
+* **Frontend (Интерфейс):** Vue.js 3 (Composition API) + Vuetify или Element Plus — быстрый, отзывчивый интерфейс, удобные таблицы для РТК и канбан-доски.
+* **База данных:** PostgreSQL — строгая реляционная БД критически важна для финансовых данных, РТК, связей "Дело-Кредитор-Транзакция" и обеспечения целостности данных. MongoDB - пользователи, статуса, конфигурация процесса.
+* **Инфраструктура:** Docker, CI/CD (GitLab/GitHub Actions), развертывание на выделенном VPS или в облаке (Yandex Cloud / Selectel) с ежедневным бэкапом БД.
+
+---
+
+## 5. Окупаемость (ROI) для юридической фирмы
+* **Текущие потери:** Допустим, компания ведет 300 дел. Ручная подготовка запросов, контроль сроков и составление отчетов съедает до 40% рабочего времени пула юристов и помощников. Ошибка в сроках стоит от 50 000 до 200 000 ₽ (штрафы, отстранение, репутация).
+* **Эффект от ПО:** Высвобождается эквивалент 2-3 фул-тайм сотрудников. Система окупается за **4-6 месяцев** исключительно за счет экономии на фонде оплаты труда (ФОТ) линейного персонала и отсутствия штрафов за пропущенные сроки.
+
+---
+
+Для удобства управления большим количеством дел в ПО нельзя использовать плоский список из 20+ шагов. Вместо этого алгоритм группируется в **7 макростатусов (этапов)**, внутри которых система автоматически контролирует микро-шаги и дедлайны.
+
+---
+
+### 📊 Модель статусов дела (Kanban / Pipeline)
+
+Каждое дело в системе имеет один из следующих статусов. Переход между статусами может быть как ручным (подтверждение юристом), так и автоматическим (при выполнении условий).
+
+| № | Статус дела (Этап) | Триггер входа в статус | Ключевые задачи внутри статуса (из Excel) |
+|---|---|---|---|
+| **1** | **Старт и введение РДГ** | Загружено Определение суда о введении РДГ (п. 1.00–3.00) | Внесение данных должника, публикация в ЕФРСБ/Ъ (3 дня), уведомление кредиторов и должника (7 дней). |
+| **2** | **Сбор информации и опись** | Утвержден Финансовый управляющий (ФУ) / получены первые ответы (п. 6.00–12.00) | Рассылка запросов в госорганы (15 дн.) и банки (5 дн. после ФНС). Опись имущества. Обработка ответов или отсутствие ответов. |
+| **3** | **Формирование РТК** | Опубликована заметка в «Коммерсантъ» (п. 13.00–13.50) | Прием требований (2 мес.), подготовка возражений (за 10 дн. до суда), включение в РТК (5 раб. дней после определения). |
+| **4** | **Аналитика и отчетность** | РТК сформирован или назначена дата СК/суда (п. 14.00–17.00) | Финансовый анализ (ФА), заключения (о сделках, о фиктивном/преднамеренном банкротстве), Отчет АУ. |
+| **5** | **Подготовка и проведение СК** | Готовы отчеты и заключения (п. 18.00–18.30) | Назначение заочного СК, рассылка бюллетеней, проведение, составление протокола (5 дн.), публикация итогов. |
+| **6** | **Судебное заседание и переход в РиГ** | Проведено СК (п. 19.00–19.40) | Подача пакета документов в АС (за 10 дн. до суда), ходатайство о переходе в РиГ, контроль согласия СРО, финальная публикация в ЕФРСБ (10 дн.). |
+| **7** | **Завершение и передача в бухг.** | Вынесено решение о переходе в РиГ или завершении РДГ (п. 20.00–20.10) | Передача заявки в бухгалтерию на выплату (35 дн.), контроль выплат, архивация дела. |
+
+---
+
+### ⏱️ Схема контроля сроков (Логика работы ПО)
+
+Система не просто показывает дату, она **динамически рассчитывает** дедлайны на основе «Даты-триггера» и управляет действиями исполнителя.
+
+#### Правило расчета сроков:
+`Дедлайн = Дата-триггер + Срок из алгоритма (в днях)`
+*Система хранит все "Даты-триггеры" (дата определения, дата публикации в Ъ, дата отправки запроса).*
+
+#### Детальная схема контроля по статусам:
+
+**Статус 1: Старт и введение РДГ**
+*   **Триггер:** Дата определения суда о введении РДГ.
+*   **Контроль 1:** `Триггер + 3 дня` → Дедлайн публикации в ЕФРСБ и Ъ. *(Если не загружен чек: статус задачи "Красный", уведомление юристу).*
+*   **Контроль 2:** `Дата публикации в Ъ + 7 дней` → Дедлайн уведомления кредиторов.
+*   **Контроль 3:** `Дата определения + 7 дней` → Дедлайн уведомления должника.
+
+**Статус 2: Сбор информации и опись (Критический блок автоматизации)**
+*   **Триггер:** Дата утверждения ФУ / Дата отправки конкретного запроса.
+*   **Контроль 1 (Госорганы):** `Дата утверждения ФУ + 15 дней` → Дедлайн рассылки запросов (ГИБДД, ЗАГС, ФНС и т.д.).
+*   **Контроль 2 (Банки):** `Дата ответа ФНС + 5 дней` → Дедлайн рассылки запросов в банки.
+*   **АВТОМАТИЧЕСКИЙ КОНТРОЛЬ "35 ДНЕЙ" (п. 6.20, 7.20, 8.20, 9.20, 10.20):** 
+    *   Система ставит внутренний таймер на каждый отправленный запрос.
+    *   Если через 35 дней в поле "Ответ получен" нет галочки → Система **автоматически меняет статус подзадачи** на "Нет ответа" и создает задачу помощнику: *"Сформировать заявление в АС об истребовании / в полицию"* (срок исполнения: 5 дней с 35-го дня).
+
+**Статус 3: Формирование РТК**
+*   **Триггер:** Дата публикации в «Коммерсантъ».
+*   **Контроль 1:** `Дата публикации + 2 месяца` → Дедлайн поступления требований кредиторов. Система блокирует возможность закрытия этапа раньше этого срока (если нет досрочного закрытия).
+*   **Контроль 2 (Возражения):** `Дата судебного заседания (из карточки дела) - 10 дней` → Жесткий дедлайн подготовки и отправки возражений. *(Уведомление юристу за 15 дней до дедлайна).*
+*   **Контроль 3:** `Дата определения о включении + 5 раб. дней` → Дедлайн публикации о включении в РТК и обновления реестра в ПО.
+
+**Статус 4: Аналитика и отчетность**
+*   **Триггер:** Дата проведения СК или Дата судебного заседания (указывается вручную или парсится из «Мой Арбитр»).
+*   **Контроль:** `Дата СК/Суда - 35 дней` (или -50 дней до суда) → Единый дедлайн для загрузки в систему: ФА, Заключения (о сделках, о преднамеренном банкротстве), Отчета АУ. 
+*   *Логика:* Система не даст перевести дело в Статус 5, пока не будут загружены эти 4 документа.
+
+**Статус 5: Подготовка и проведение СК**
+*   **Триггер:** Готовность отчетов.
+*   **Контроль 1:** `Дата проведения СК - 15 дней` → Дедлайн фактического проведения заочного ознакомления/голосования.
+*   **Контроль 2:** `Дата проведения СК + 5 дней` → Дедлайн публикации протокола и результатов СК в ЕФРСБ (при наличии кворума).
+
+**Статус 6: Судебное заседание и переход в РиГ**
+*   **Триггер:** Дата проведения СК.
+*   **Контроль 1:** `Дата проведения СК + 5 раб. дней` (но не позднее чем `Дата суда - 10 дней`) → Дедлайн подачи пакета документов (Отчет, ФА, заключения, бюллетени) и Ходатайства о переходе в РиГ через «Мой Арбитр».
+*   **Контроль 2:** `Дата определения о введении РиГ + 10 дней` → Дедлайн размещения финального отчета на ЕФРСБ.
+
+**Статус 7: Завершение и передача в бухг.**
+*   **Триггер:** Дата решения о взыскании / переходе в РиГ.
+*   **Контроль:** `Дата решения + 35 дней` → Дедлайн передачи заявки в бухгалтерию АС на выплату вознаграждения/расходов.
+
+---
+
+### ⚙️ Технические требования к модулю контроля сроков (для разработчиков)
+
+1. **Цветовая индикация (Светофор):**
+   * 🟢 **Зеленый:** До дедлайна > 3 дней.
+   * 🟡 **Желтый:** До дедлайна ≤ 3 дней (отправка push/email уведомления ответственному).
+   * 🔴 **Красный:** Дедлайн пропущен (уведомление руководителю практики + блокировка возможности закрыть этап без комментария).
+
+2. **Каскадное обновление дат:** Если дата судебного заседания переносится (парсинг из «Мой Арбитр» или ручной ввод), система должна **автоматически пересчитать** все зависимые дедлайны (например, дедлайн подачи возражений или отчетов), которые отсчитываются "от даты суда".
+
+3. **Чек-листы обязательности:** Для перехода из Статуса 2 в Статус 3 система должна проверить наличие в карточке: 
+   * [x] Чеки ЕФРСБ/Ъ
+   * [x] Заполненная опись имущества (или акт о том, что имущество не найдено)
+   * [x] Подтверждение отправки запросов в госорганы.
+
+4. **Дашборд просрочек:** На главной странице руководителя должен быть виджет "Дела с критическими рисками", показывающий дела, где пропущен срок подачи возражений, срок публикации или срок ответа на запрос (35 дней).
+
+---
+
+Ниже представлена детализированная постановка задачи (Техническое Задание, ТЗ) для команды разработки, адаптированная под ваши уточнения: **отказ от Канбан-доски в пользу табличного интерфейса**, упрощенная ролевая модель (Юрист, Руководитель) и специфическая функция руководителя.
+
+ТЗ структурировано так, чтобы разработчик мог сразу декомпозировать его на задачи (Jira/YouTrack).
+
+---
+
+# ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Система учета дел о банкротстве (Этапы 1 и 2)
+
+## 1. Ролевая модель и права доступа (RBAC)
+В системе предусмотрено ровно две роли. Разграничение прав строгое.
+
+1. **Юрист (Исполнитель):**
+   * Видит только назначенные ему дела.
+   * Может создавать и редактировать карточки дел, загружать документы.
+   * Может менять статусы шагов алгоритма, вводить триггерные даты.
+   * Не может удалять дела или изменять глобальные настройки алгоритма.
+2. **Руководитель (Администратор практики):**
+   * Видит **все** дела всех юристов.
+   * Имеет доступ к сводному Дашборду.
+   * **Функция "Войти как" (Impersonation):** Рядом с ФИО любого юриста в таблице есть кнопка "Войти как [Имя]". При нажатии открывается **новая вкладка браузера**, в которой система автоматически авторизует руководителя под учетной записью выбранного юриста (без запроса пароля), чтобы увидеть интерфейс и данные ровно так, как их видит сотрудник.
+
+---
+
+## 2. ЭТАП 1: Базовый интерфейс, учет и контроль сроков
+
+### 2.1. Модели данных (Core Entities)
+Разработчику необходимо создать следующие сущности в БД:
+*   `User`: id, role, full_name, login, password_hash.
+*   `Debtor` (Должник): id, full_name, inn, snils, birth_date, address.
+*   `Case` (Дело): id, debtor_id, lawyer_id, case_number (А40-...), current_macro_status, created_at.
+*   `Creditor` (Кредитор): id, case_id, name, inn, debt_amount, queue_number (1, 2, 3, реестровые/текущие).
+*   `Document`: id, case_id, file_name, file_url, document_type (из справочника), uploaded_at.
+*   `WorkflowStep` (Шаг алгоритма): id, case_id, step_code (напр., "1.00"), step_name, trigger_date, deadline_date, status (pending, warning, overdue, completed), required_doc_type.
+
+### 2.2. Пользовательский интерфейс (UI) – Табличное представление
+Весь интерфейс строится на данных таблицах (Data Grid) с фильтрацией и сортировкой. Возможен вариант в виде Kanban досок.
+
+1. **Экран "Дашборд Руководителя" (Главная):**
+   * Виджеты: "Всего дел в работе", "Просроченных дедлайнов (Красных)", "Дел по каждому юристу".
+   * Таблица "Все дела": Колонки: № дела, Должник, Ответственный юрист, Текущий этап, Ближайший дедлайн (с цветовой индикацией), Действия (кнопка "Войти как").
+2. **Экран "Мои дела" (для Юриста):**
+   * Таблица дел, где `lawyer_id` = id текущего пользователя.
+   * Колонки: № дела, Должник, Текущий макро-статус, Ближайший дедлайн, Прогресс выполнения шагов (напр., "15/40").
+3. **Экран "Карточка дела" (Детальная):**
+   * Вкладки: 
+     * **Основное:** Данные должника, номер дела, выбор ответственного юриста.
+     * **Кредиторы (РТК):** Простая таблица (Добавить/Редактировать/Удалить) с полями из п. 4.00/13.50 Excel (Наименование, ИНН, Очередь, Сумма).
+     * **Документы:** Список загруженных файлов с типом документа и датой. Кнопка "Загрузить".
+     * **Чек-лист алгоритма (Ключевой модуль):** Список шагов из конфигурации (1.00, 2.00, 4.00 и т.д.). 
+       * *Вид строки шага:* [Чекбокс выполнения] | Название шага | Введенная дата-триггер | Рассчитанный дедлайн | Статус (🟢/🟡/🔴) | Кнопка "Загрузить документ".
+
+### 2.3. Бизнес-логика и Контроль сроков (Workflow Engine)
+Система должна динамически рассчитывать сроки на основе данных из конфигурации.
+
+*   **Правило расчета:** `Дедлайн = Дата-триггер + Смещение (в днях)`.
+*   **Пример реализации (п. 1.00 -> п. 4.00):** 
+    1. Юрист в шаге "1.00" вводит "Дату принятия заявления" и загружает "Определение суда".
+    2. Система автоматически рассчитывает дедлайн для шага "4.00" как `Дата_триггер + 3 дня`.
+    3. Если до дедлайна > 3 дней: статус 🟢.
+    4. Если до дедлайна ≤ 3 дней: статус 🟡 (желтый), отправка email-уведомления юристу.
+    5. Если дедлайн прошел: статус 🔴 (красный), дело попадает в виджет "Просрочено" на дашборд руководителя.
+*   **Валидация закрытия шага:** Шаг нельзя отметить галочкой "Выполнено", если не загружен документ, указанный в колонке "Документы подтверждающие" (например, для п. 13.50 обязательно наличие "определение о включении в РТК").
+*   **Автоматический контроль "35 дней" (п. 6.20, 7.20, 8.20, 9.20, 10.20):** 
+    * Система ежедневно (cron job) проверяет шаги типа "Запрос отправлен". 
+    * Если `Текущая дата >= Дата_отправки + 35 дней` И статус ответа ≠ "Получен", система автоматически меняет статус шага на 🔴 и создает внутреннюю задачу: "Подготовить заявление в АС об истребовании".
+
+---
+
+## 3. ЭТАП 2: Внешние интеграции, генерация документов и оповещения
+
+### 3.1. Модуль генерации документов (Document Generator)
+*   **Механизм:** Как использование шаблонов `.docx` с плейсхолдерами (например, `{{debtor_full_name}}`, `{{case_number}}`, `{{court_name}}`, `{{current_date}}`), полная генерация по харкрду, возможно доработка с ИИ.
+*   **Автоматизация по триггерам:** 
+    * При срабатывании правила "35 дней без ответа" (п. 6.20, 7.20 и т.д.) система **автоматически генерирует** готовый `.docx` файл "Заявление в АС об истребовании", подставляя данные должника, номер дела и наименование госоргана, в который изначально шел запрос. Файл сразу прикрепляется к карточке дела как черновик.
+    * Генерация "Возражений на требования кредиторов" (п. 13.30): Юрист выбирает кредитора из таблицы РТК, система генерирует шаблон возражения с подставленными суммами и датами.
+
+### 3.2. Интеграции (API / Парсинг)
+1. **Кад.Арбитр (Мой Арбитр):**
+   * *Функция:* По номеру дела (А40-...) система должна уметь получать базовые данные о последних судебных актах (через открытый API или парсинг, если API недоступен).
+   * *Цель:* Автоматическое предложение юристу обновить статус дела при появлении нового "Определения о введении РДГ" (п. 3.00) или "Определения о включении в РТК" (п. 13.50).
+2. **Почтовые сервисы (SMTP / Yandex Mail API):**
+   * Возможность отправить "Уведомление должника" (п. 6.00) или "Уведомление кредиторов" (п. 5.00) прямо из интерфейса системы. Система подставляет шаблон письма, прикрепляет сгенерированный PDF и отправляет, фиксируя факт отправки в истории дела.
+3. **ЕФРСБ / Коммерсантъ (Подготовка макетов):**
+   * Полная авто-публикация на Этапе 2 не требуется (из-за сложности ЭЦП), но система должна генерировать **готовый текст макета** для копирования в личный кабинет ЕФРСБ, подставляя ИНН, ФИО и номер дела, а также предоставлять поле для загрузки чека об оплате (п. 4.00, 13.20).
+
+### 3.3. Оповещение клиентов (Должников)
+*   **Канал:** Telegram/МАКС-бот или Email-рассылка.
+*   **Сценарий:** При создании дела или переходе на этап "Сбор информации" (п. 6.00), система позволяет юристу нажать кнопку "Отправить запрос документов должнику".
+*   **Действие:** Клиенту приходит сообщение: *"Уважаемый [Имя], для продолжения процедуры банкротства по делу № [Номер] пожалуйста, загрузите следующие документы: [Список из п. 6.00]. Ссылка для загрузки: [ссылка на простую веб-форму]"*.
+*   **Веб-форма для клиента:** Простая страница без авторизации (по уникальной одноразовой ссылке), где должник может загрузить сканы своих документов. Загруженные файлы автоматически попадают в раздел "Документы" карточки дела с пометкой "От должника".
+
+---
+
+## 4. Технические требования и стек (Рекомендация для разработчика)
+
+*   **Backend:** Node.js 
+*   **Frontend:** Vue.js 3 + UI-библиотеки с мощными таблицами.
+*   **База данных:** PostgreSQL (строгая типизация обязательна для финансовых данных и связей) + MongoDB.
+*   **Хранение файлов:** Локальное хранилище на сервере или S3-совместимое (Yandex Object Storage) для надежности.
+*   **Безопасность:** 
+    * Реализация механизма Impersonation через временные JWT-токены с ограниченным временем жизни (например, 15 минут), чтобы руководитель мог безопасно "войти как юрист".
+    * Хэширование паролей (bcrypt).
+
+---
+
+## 5. Критерии приемки (Definition of Done) для Этапа 1
+
+1. Руководитель может создать пользователя-юриста, назначить ему дело и нажать "Войти как", оказавшись в интерфейсе юриста в новой вкладке.
+2. Юрист может ввести дату для шага 1.00, и система автоматически рассчитает и подсветит дедлайн для шага 4.00.
+3. Юрист не может отметить шаг 13.50 как "Выполненный", пока не загрузит файл в поле "Определение о включении в РТК".
+4. Все данные отображаются в таблицах с возможностью сортировки по дедлайнам и фильтрации по статусам (🟢/🟡/🔴). Канбан-элементы отсутствуют.