План разработки приложения «Расписание НГУЭУ»§

Версия плана: 1.0 · Дата: 9 сентября 2026 года · Основание: ТЗ 0.3.
Статус: комплект для начала реализации; приложение по этому плану ещё не разработано.
Исполнитель: GPT-6 Astra под контролем владельца продукта и ответственного за эксплуатацию.

1. Назначение и состав комплекта§

План превращает ТЗ версии 0.3 и политику составления расписания в 64 проверяемые задачи на 10 этапах. Он сохраняет весь базовый объём: 67 обязательных FR, календарные даты, точечные переносы, выделение группы, онлайн-формат, политику, миграцию, публикации и эксплуатацию. FR-059 и FR-060 остаются расширениями.

План не меняет предметные требования ТЗ. При расхождении исполнитель фиксирует вопрос и предлагает конкретную поправку; не выбирает удобное для реализации толкование молча. Изменение ТЗ требует повторной сверки этого плана и его контрольного хеша.

Комплект включает этот редактируемый Markdown, инструкцию и готовые запросы для Astra, производный список задач planning/backlog.json, матрицу покрытия, реестр состояния planning/progress.json и утилиту tools/implementation_plan.py. JSON формируется из Markdown; задачи редактируются здесь. Состояние выполнения и доказательства хранятся отдельно и не сбрасываются при пересборке документов.

2. Результаты анализа текущего ТЗ§

ТЗ уже подробно определяет поведение нового продукта, но текущий проект содержит исследование, извлечение данных, статические документы и исследовательский просмотрщик. Этот просмотрщик не является каркасом полноценного редактора: в нём нельзя считать реализованными Django-модель, объектные права, транзакционные команды, календарные исключения или публикации. Аналитические скрипты полезны как контрольные источники и примеры; их предположения нельзя автоматически переносить в рабочие правила.

Самые дорогие ошибки возникнут в четырёх местах: двойная занятость при гонке; потеря индивидуального переноса после генерации; двойное начисление нагрузки при общем занятии; публикация несовместимых периодов. Поэтому модель участников, транзакционные ограничения PostgreSQL и проверяемые команды появляются раньше развитого интерфейса. Первые пользовательские результаты строятся на настоящем API и БД.

До разработки зависимых миграций TASK-003 фиксирует ADR: единую терминологию DTO/БД, границу версии справочников и редакции, идентичность участников между периодами, порядок блокировок, происхождение выделенного события и повторяемость заданий. Это техническая детализация уже выбранной архитектуры. Часы, календарь и строгость норм остаются решениями соответствующих владельцев.

3. Архитектура и организация исходников§

Сохраняется модульный монолит: React/TypeScript → Django/DRF → PostgreSQL, фоновые задания Celery/Redis, Nginx и Docker Compose. PostgreSQL является серверной СУБД, SQLite — неизменяемым источником переноса. Delphi, BDE и Paradox не нужны для работы новой системы. GPT-6 Astra используется как исполнитель разработки; работа приложения не зависит от модели и OpenAI API.

Версии стека из ТЗ: React 19, Vite 8 / Node.js 24 LTS для сборки, Python 3.13, Django 5.2 LTS, DRF 3.16, PostgreSQL 18, psycopg 3, Celery 5.6, Redis 8. Это зафиксированная база планирования, а не новая проверка совместимости всех пакетов. В TASK-003 исполнитель сверяет официальные требования, поддержку и лицензии, в TASK-005 фиксирует точные версии в lock-файлах и образах. Несовместимость оформляется ADR и предложением изменения, а не скрытой заменой технологии.

Рабочее решение для размещения исходников — изолированный каталог product/ в текущем проекте с собственным контролем версий. Его можно перенести в отдельный репозиторий без изменения предметной модели. До начала работ TASK-001 проверяет фактическое состояние Git и не добавляет исследовательские БД в историю.

product/
  backend/        accounts, access, catalogs, participants, planning,
                  calendar, scheduling, policy, quality, imports,
                  workflow, publications, jobs, audit
  frontend/       app, shared/ui, shared/api, features
  tests/          unit, db, api, e2e, security, migration, load
  fixtures/       синтетические данные; приватный источник снаружи
  deploy/         Compose, Nginx, диагностика
  scripts/        импорт, backup, restore, release
  docs/           ADR, OpenAPI, ER, инструкции, решения, evidence
  Makefile        единый набор воспроизводимых команд

Корневая папка deploy/ продолжает обслуживать сайт исследования. Будущая product/deploy/ относится к приложению. Существующая парольная защита всего /data/, включая /data/policy/, сохраняется. Тестовые, приёмочные и рабочие базы, тома, домены/порты и секреты должны различаться.

4. Этапы и демонстрируемые результаты§

Этапы — контрольные рубежи. Исполняемый порядок определяют зависимости задач: TASK-040 относится к основе и выполняется до зависимых задач календаря/импорта, несмотря на его номер. Номер задачи — стабильный идентификатор, не жёсткий календарный порядок.

Первый содержательный показ пользователю: после TASK-021 и TASK-026 создать занятие 15 марта и открыть его в трёх режимах. Этот показ не требует завершённой исторической миграции. Следующий рубеж — TASK-032 с переносом группы и исключениями. Базовая поставка завершена только после всех обязательных задач, владельческого согласования применимых решений и производственной приёмки.

Критические цепочки: участники → бронирования → единые команды → исключения → совместность → перенос группы; политика → readiness → frozen snapshot → глобальная активация; staging → подтверждение семантики → commit → сверка миграции; стенд → backup/restore → обновление → пилот → ввод. Зависимости, включая боковые входы каждой цепочки, перечислены в карточках и проверяются программно.

Не назначаются вымышленные сроки по размеру контекста или названию модели. S — одна ограниченная задача; M — несколько связанных изменений с одной демонстрацией результата. Если M не помещается в один безопасный цикл реализации и проверки, Astra сначала делит её на подзадачи TASK-NNN/a, /b с собственными критериями, сохраняя родительскую приёмку. После TASK-009 и TASK-021 можно оценить темп по фактическим изменениям, дефектам и длительности проверок. Внешние согласования и серверные испытания оцениваются отдельно.

5. Решения владельца и блокировки§

Все 29 DEC передаются в машинный реестр. DEC-19 уже подтверждает точечные изменения новой версии. Остальные записи сохраняют нерешённые предметные вопросы до конкретного ответа или доказательства; некоторые вопросы допускают решение «не применяется к пилоту» с областью и обоснованием. Это не разрешение пропустить требование в окончательной поставке.

Поле «Решения» в карточке задаёт обязательный контекст. Оно не блокирует написание механизма на синтетических данных. Поле «Допуск» задаёт решения, необходимые для закрытия всей задачи, включая работу с реальными данными. Если закрыта только техническая часть, задача остаётся blocked или in_progress с точным остатком, а независимые готовые задачи продолжаются.

TASK-043 и TASK-046 содержат явные допуски реальной миграции. Перед TASK-061 владелец проверяет применимость всех DEC; для ограниченного пилота исключение имеет область, причину и подтверждение. TASK-062/063 требуют подтверждённого окна и порядка перехода. Модель не принимает эти решения за владельца и не выдаёт отсутствие ответа за согласие.

6. Проверки, которые нельзя отложить до финала§

В каждой задаче обязательны применимые права, миграции, сообщения об ошибках и документация. Для записи дополнительно обязательны транзакционность, аудит, версии и идемпотентность. Макет с моками, успешный unit-тест без PostgreSQL и фраза «должно работать» не подтверждают рабочую команду.

Стандартные точки запуска после TASK-006: make lint, make typecheck, make test-unit, make test-db, make test-api, make test-e2e, make build, make check-migrations. Это контракт будущего каркаса: сейчас в исследовательском проекте таких целей ещё нет. Специализированные make test-migration, make test-security, make test-load добавляются соответствующими задачами. В отчёте всегда указываются реально выполненная команда и её результат.

7. Порядок работы GPT-6 Astra§

Рабочая единица — одна доступная по зависимостям задача с законченным результатом. Модель читает общие инструкции, карточку, непосредственно связанные разделы ТЗ и фактический код, реализует задачу, выполняет проверку и сохраняет короткий handoff. Повторное чтение всего исследования при каждом запуске не требуется. Для сложной миграции, переноса группы и публикации нужен пересмотр решения с позиции конфликтов и частичного отказа перед завершением.

В официальном руководстве Astra отмечены чувствительность к инструкциям, склонность уточнять важные неопределённости и необходимость соразмерных проверок. Поэтому здесь явно заданы границы автономности, условия предметных решений и формат доказательств. Идентификатор модели — gpt-6-astra. Официальное руководство OpenAI по GPT-6 Astra.

Предлагаемые усилия в карточках — настройка процесса этого проекта: high для обычной реализации, xhigh для схемы, конкурентных операций, миграции и публикации. Это не гарантия качества и не лимит токенов. Конкретные доступные настройки проверяются в среде запуска; они не добавляются в код приложения. Последовательная работа — исходный режим. Дополнительные агенты возможны только при отдельном разрешении пользователя и независимых областях файлов; одновременные изменения общей схемы и API требуют единого согласованного контракта.

Полные готовые запросы, правила возобновления и формат отчёта находятся в инструкции Astra.

8. Карточки задач§

Ссылки требований используют идентификаторы действующего ТЗ. Диапазон AP-01..AP-23 включает обе границы. Размер и усилие помогают подготовить сеанс; они не заменяют критерии приёмки. Все задачи ниже относятся к базовой реализации B; каждая первоначально имеет статус todo.

TASK-001. Зафиксировать исходную точку проекта§

Работы. Создать изолированную область product/ и паспорт исходной точки. Проверить отсутствие чужих изменений, описать существующий исследовательский просмотрщик и границы нового продукта. Зафиксировать хеши ТЗ 0.3, политики и SQLite, структуру будущего репозитория; настроить исключение секретов, исходных БД и локальных томов из Git.

Приёмка. Изменения старого viewer/, DB/, exports/ и действующего deploy/ не требуются. Новый продукт не выдаётся за уже реализованный. Команды запуска пока помечены как будущие.

Проверка. Проверить пути и хеши; показать перечень добавленных файлов. Решить способ отдельного контроля версий, не добавляя массово исследовательские данные.

TASK-002. Вести предметные решения и условия допуска§

Работы. Перенести DEC-01–DEC-29 в рабочий реестр: владелец, вопрос, пример, доказательство, статус, блокируемая операция. DEC-19 пометить подтверждённым; остальные сверить с новыми ответами владельца. Для нерешённых дат, часов и ограничений подготовить короткие воспроизводимые примеры.

Приёмка. Ожидание ответа не закрывает решение. Явно различаются возможность разработки на синтетических данных и допуск исторической миграции или выпуска.

Проверка. Сверить все 29 DEC с ТЗ и таблицей условий допуска этого плана; составить один сгруппированный запрос владельцу только по действительно отсутствующим сведениям.

TASK-003. Согласовать технические контракты и ADR§

Работы. Подготовить ADR по модульному монолиту, границам периодов/редакций, глобальным ресурсам, версиям справочников, M:N серия–компонент, атомам участников, публикации и очереди. Согласовать имена start_at в API и starts_at в БД. Проверить официальную совместимость и лицензии зависимостей ТЗ перед фиксацией точных версий.

Приёмка. Архитектура сохраняет React/TypeScript, Django/DRF, PostgreSQL. Каждое ADR содержит инвариант, выбранный вариант, отклонённые варианты и проверку. Неподтверждённые нормы расписания не становятся техническими константами.

Проверка. Проверить контракты на примерах общего занятия разных планов, переноса А отдельно от Б и двух пересекающихся периодов; записать найденные противоречия до миграций.

TASK-004. Подготовить контрольные данные и каталог проверок§

Работы. Создать синтетические группы А/Б, подгруппы, два периода, преподавателей, комнаты, планы и даты 8/15/17/22 марта 2027 года. Составить обезличенные пограничные наборы. Реальный SQLite подключать только read-only в закрытом локальном профиле, с отдельным манифестом ожидаемых счётчиков.

Приёмка. Обычный CI не требует приватной БД; отдельный локальный прогон проверяет подлинные контрольные числа. Синтетические даты и нормы подписаны как тестовые.

Проверка. Проверить отсутствие персональных заметок и реквизитов подключения в публичных фикстурах; установить соответствие сценариев AP/AC-D/ACC тестовым идентификаторам.

TASK-005. Создать воспроизводимый каркас приложения§

Работы. Создать Django/DRF и React/TypeScript strict, локальные PostgreSQL и Redis, Dockerfile и Compose, lock-файлы и .env.example без секретов. Добавить единый origin через прокси, health/readiness и команды установки, lint, typecheck, test, build, migrate. Все ассеты поставлять локально.

Приёмка. Чистый checkout запускается по README. Данные переживают пересоздание контейнеров. Runtime БД не суперпользователь, миграции выполняются отдельной ролью. Приложение не требует OpenAI API для работы.

Проверка. В пустом окружении собрать контейнеры, применить пустую/начальную схему, открыть оболочку; пересоздать контейнеры и проверить сохранность контрольной записи.

TASK-006. Настроить CI и обязательные проверки§

Работы. Зафиксировать команды make lint, typecheck, test-unit, test-db, test-api, test-e2e, build и check-migrations. Поднять в CI PostgreSQL той же основной версии; разделить быстрые проверки PR, интеграционные и отдельный нагрузочный прогон. Выбранная CI-площадка заменяема локальными командами.

Приёмка. На каждом изменении видны реальные результаты и код завершения. Range constraints, блокировки и гонки никогда не проверяются заменой PostgreSQL на SQLite.

Проверка. Показать проход чистой сборки и обнаружение намеренно добавленного во временной ветке нарушения типов/миграции; удалить демонстрационную ошибку.

TASK-007. Реализовать индивидуальные учётные записи§

Работы. Добавить вход/выход, PostgreSQL-сессии, CSRF, защищённые cookies, отключение аккаунта, ограничения попыток и административный одноразовый сброс. Создавать первого администратора командой. Реализовать абсолютный и неактивный тайм-аут с предупреждением формы.

Приёмка. Нет встроенного пароля и токенов в localStorage; Redis не является хранилищем сессий. Отключение аккаунта завершает все его сеансы; отсутствие SMTP не мешает сбросу.

Проверка. Реальные HTTP-тесты входа, CSRF, просроченной и отозванной сессии, перебора и сброса; повторить чтение при недоступном Redis.

TASK-008. Ввести роли, области и доступ к полям§

Работы. Создать роли и явные области подразделений, отдельное policy.approve; применить единую проверку к объектам, спискам, счётчикам, поиску, журналам, заданиям и выгрузкам. Предоставить уполномоченному интерфейс управления пользователями, совмещением ролей и областями. Разделить публичный комментарий, внутреннюю заметку и закрытые реквизиты онлайн.

Приёмка. Скрытый UUID не раскрывает существование или поля объекта. Технический администратор не получает предметное утверждение политики неявно. По умолчанию анонимная выдача выключена.

Проверка. Матрица положительных/отрицательных тестов для всех ролей и прямых UUID; чужой конфликт возвращает нейтральную занятость. Итоговая матрица реальных сотрудников согласуется до пилота.

TASK-009. Создать корпоративную оболочку и формы§

Работы. Перенести корпоративные токены, Verdana и выбранный SVG «Сетка расписания» в локальные ассеты. Сделать навигацию, выбор периода, общие таблицы/формы/диалоги и состояния загрузки, пустоты, ошибки, отказа и несохранённого ввода.

Приёмка. Отступы компактные; текст на всю ширину колонки, таблицы прокручиваются локально. Фокус удерживается и возвращается; операция доступна без drag-and-drop.

Проверка. Проверить 1440×900, 1280×720, 390 px и масштаб 200%, клавиатуру и контраст; компонентные тесты на потерю ввода и смену периода.

TASK-010. Зафиксировать OpenAPI и инфраструктуру команд§

Работы. Описать версионированные маршруты, фильтрацию, пагинацию, единую ошибку, ETag/If-Match, expected_revision_version и Idempotency-Key. Реализовать общую регистрацию команды и повтор результата; настроить проверяемые типы клиента из OpenAPI. Бизнес-команды появятся в своих задачах.

Приёмка. Отсутствующее условие версии даёт 428, устаревшее 412, изменённое тело под тем же ключом 409. Лимит синхронной пачки 200 не допускает частичного успеха. Обычные ключи живут минимум 24 часа.

Проверка. Контрактные HTTP-тесты неизвестных полей, неверных ID, повторов и ошибок; временно недоступная БД даёт честную ошибку, не успешную квитанцию.

TASK-011. Реализовать общие справочники§

Работы. Создать организацию, факультеты, кафедры, уровни/курсы, преподавателей, дисциплины и виды занятий с UUID, архивированием и ограничением удаления используемых записей. Подключить унифицированные CRUD-формы, поиск кириллицей, пагинацию и версии.

Приёмка. Одинаковые ФИО и названия не сливаются. Должность преподавателя не порождает приоритеты. CourseNo не превращается в год обучения; е/ё различаются согласно ТЗ.

Проверка. Проверить архивирование связанного справочника, роли кафедры, одинаковые ФИО, поиск и конкурентную правку карточки.

TASK-012. Описать группы, подгруппы и административные потоки§

Работы. Создать группы с раздельными формой, уровнем, курсом, онлайн-признаком, билингвальностью и подтверждённой численностью. Ввести явные версии схем подгрупп, неизвестный состав и именованные административные потоки, отдельные от участников учебного плана.

Приёмка. Членство в потоке не создаёт занятия. Численность подгруппы не вычисляется делением общего числа; исходные обозначения сохраняются.

Проверка. Проверить несколько схем деления, повторное членство группы в разных планах и невозможность удалить используемую схему.

TASK-013. Реализовать подтверждённый классификатор групп§

Работы. Реализовать порядок распознавания в/о/Б, окончаний с нулём и без, префиксов м/а/9-/11- и подтверждённых СПО-исключений 11РВП. Сохранять исходный текст и отдельно нормализованную рабочую копию; предусмотреть ручное уточнение и неизвестный код.

Приёмка. 394 очные, 123 заочные, 37 вечерние, 23 онлайн и 6 билингвальных воспроизводятся на исходном снимке. Форма, уровень и модальность независимы.

Проверка. Синтетические тесты конфликтующих признаков, скобочных комментариев и нового кода; закрытый регрессионный прогон на 554 группах.

TASK-014. Создать каталог помещений и оснащения§

Работы. Описать корпуса, комнаты, типы, вместимость, оснащение, источник и дату проверки. Добавить редактор совместимости и матрицы переходов как явных данных. Не выводить корпус и назначение комнаты только из префикса.

Приёмка. Неизвестное значение отличается от нуля. Изменение справочника имеет версию; будущие публикации смогут фиксировать исторические подписи.

Проверка. Проверить неизвестную вместимость, обновление паспорта комнаты, права и отсутствие автоматического совпадения букв вида занятия и комнаты.

TASK-015. Настроить учебные периоды и звонки§

Работы. Добавить периоды с часовым поясом, календарём рабочих/исключённых дат, опорной неделей и звонками с отдельными началом/окончанием. Поддержать сессию и несколько пересекающихся периодов организации.

Приёмка. Дата за границей периода отклоняется; конец пары не выводится из следующего старта. Интервалы конечные [start,end), сохраняются timestamptz и ISO со смещением.

Проверка. Тесты полуночи, границ периода, часового пояса, смежных/пересекающихся интервалов и пользовательских дат с годом.

TASK-016. Реализовать учебную потребность и расчёт объёма§

Работы. Создать позиции плана и компоненты по видам нагрузки, составы групп/подгрупп, единицы, quantity_scope и округление. Рассчитывать остаток размещения отдельно от фактических минут, ресурсов и числа студентов. Предпросмотр изменения плана показывает затронутые занятия.

Приёмка. Новые явно заданные единицы работают; неизвестный исторический PlanQty не пересчитывается автоматически. Два плана одной группы остаются разными потребностями.

Проверка. Проверить три явно заданных типа нагрузки, пересчёт длительности, составов и повторений; ошибочное или незаданное значение единицы блокирует генерацию соответствующего компонента.

TASK-017. Построить атомарную модель участников§

Работы. Создать глобальные schedulable_resource, атомы подтверждённых непересекающихся составов и сопоставление разных схем. Ввести консервативное пересечение при неизвестном составе; изменение схемы должно выявлять затронутые события и публикации.

Приёмка. Целая группа занимает все свои атомы; отдельные подтверждённые части идут параллельно. Разные UUID разных схем не доказывают непересечение.

Проверка. На реальном PostgreSQL проверить целую группу, две части, неизвестную и сменённую схему, включая два периода; приложить ER и доказательство покрытия участников.

TASK-018. Создать редакции, серии и экземпляры§

Работы. Создать draft/frozen-редакции, series_component M:N, календарные экземпляры, назначения потребностей и ресурсы. Разделить unplaced/scheduled/cancelled, fixed и согласование. Ввести версию агрегата и запрет изменения frozen, включая обход через служебные операции.

Приёмка. Один редактируемый черновик на период. unplaced с историческими координатами не занимает ресурсы. У scheduled есть явные дата/время/участники/формат; известные ресурсы резервируются даже при неполноте.

Проверка. Проверить состояния и ограничения БД, миграции с чистой схемы, невозможность прямой записи в frozen разрешёнными прикладными путями.

TASK-019. Обеспечить транзакционную занятость ресурсов§

Работы. Реализовать resource_booking с PostgreSQL btree_gist и exclusion по редакции/ресурсу/[start,end). Задать порядок блокировок организация → редакция → глобальные группы/ресурсы UUID → строки UUID. Согласовать освобождение и повторное резервирование в одной транзакции.

Приёмка. Два независимых соединения не могут зафиксировать пересекающиеся самостоятельные события одного ресурса. Изолированные черновики допускаются, но публикация позже проверяется глобально.

Проверка. Гонки синхронизировать барьером между реальными соединениями; проверить соседние интервалы, разные атомы, deadlock/retry и откат на последнем ресурсе.

TASK-020. Связать команды, версии и предметный аудит§

Работы. Провести запись через единый доменный сервис: права, блокировки, проверка версии редакции и строк, правило, изменение, бронирования, аудит и результат идемпотентности. Установить формат предпросмотра с версиями политики/справочников и повторной проверкой применения.

Приёмка. Падение между бронированием и аудитом не оставляет частичный успех. Старый предпросмотр не резервирует ресурсы и не обходит актуальные правила.

Проверка. Проверить две правки одной карточки, повтор ключа после сетевого тайм-аута, смену правил между preview/apply и сокрытие закрытых полей аудита.

TASK-021. Создать разовое календарное занятие и онлайн-формат§

Работы. Реализовать API и форму «Создать на дату» с временем, участниками, компонентами потребности, преподавателем, форматом onsite/online и комнатой. Для разового события внутреннюю серию создавать автоматически; шаблон не является обязательным шагом пользователя.

Приёмка. Онлайн без физической комнаты допустим; преподаватель и участники заняты. Пустая комната не означает онлайн. Закрытая ссылка не попадает в публичный комментарий.

Проверка. Создать 15 марта 2027, отклонить недопустимую дату/интервал, проверить метку и защищённость реквизитов через API и форму.

TASK-022. Реализовать повторения и материализацию§

Работы. Материализовать еженедельные, двухнедельные от явной опоры и пользовательские даты с устойчивой идентичностью происхождения. Выдавать предпросмотр создаваемых экземпляров и конфликты; повтор одной генерации не даёт новых дубликатов.

Приёмка. Дата каждого проведения хранится явно. Праздники и исключённые даты учитываются по календарю периода; предполагаемая старая чётность не используется.

Проверка. Детерминированные тесты границ периода, опоры, списков дат, повторного запуска и конфликта последнего экземпляра; небольшой набор применяется атомарно.

TASK-023. Сохранить исключения и области изменения серии§

Работы. Добавить отмену/замещение конкретного origin_date и области одно/это и следующие/вся серия. При разделении серии сохранять происхождение и прежние исключения; предусмотреть ссылки для будущих group transfer. Повторная генерация показывает diff и сохраняет ручные изменения.

Приёмка. По умолчанию выбрано одно проведение. Отмена и индивидуальные дата/ресурсы/формат не теряются при генерации; серия не заменяет стабильный ID перенесённого события.

Проверка. Проверить 8/15/22 марта, отмену 15-го, перенос и изменение будущей части, повторную генерацию, конфликт и полный откат.

TASK-024. Генерировать неназначенные занятия и считать остатки§

Работы. Реализовать генерацию из явно заданного объёма с предпросмотром, остатками и журналом происхождения. Большой набор проводить через устойчивое задание; не заменять импортированные строки неподтверждённой формулой.

Приёмка. Повтор запуска не увеличивает учебную потребность и не стирает назначение. Неизвестные единицы удерживают только соответствующий компонент в ожидании.

Проверка. Проверить три типа нагрузки, дробные остатки и округление, изменение плана, повтор после переноса/отмены и восстановление прерванного задания.

TASK-025. Сделать ручное назначение и список неразмещённого§

Работы. Соединить список неразмещённого, фильтры периода/группы/преподавателя, выбор даты/времени и поиск свободных комнат с командой назначения. Предпросмотр показывает известные конфликты и неполноту; форма сохраняет ввод при ошибке.

Приёмка. Проверка свободной комнаты не гарантирует последующую запись: сервер повторно проверяет занятость. Назначение доступно с клавиатуры без drag-and-drop.

Проверка. Сквозной тест реального API: создать потребность, назначить, открыть карточку, получить 409 из-за конкурента и исправить вариант без потери полей.

TASK-026. Показать день, неделю и список одних событий§

Работы. Создать режимы День/Неделя/Список с датой, предыдущим/следующим днём и сегодня, фильтрами ресурсов и безопасной выдачей по диапазону. Сохранять выбранную область в URL. Для административного потока предусмотреть режимы полного расписания, двух слоёв повторения и экзаменов по явному календарю, не угадывая старую чётность; карточка доступна без наведения мыши. Ограничить DOM и размер ответа; показать текстовый формат и неполноту.

Приёмка. Все режимы используют одни occurrence ID и актуальную редакцию. 8 февраля открывает именно выбранный день; пустой день не подменяется ближайшей неделей.

Проверка. Сравнить набор ID и даты трёх представлений, проверить 390 px, клавиатуру, список для screen reader, часовой пояс и отсутствие выгрузки всего периода в браузер.

TASK-027. Переносить одно проведение без пересоставления§

Работы. Реализовать предпросмотр и применение переноса выбранного occurrence с устойчивым ID, причиной, версиями и исключением на исходную дату. Явно показывать область «одно проведение» и изменения ресурсов.

Приёмка. 15 марта переносится на 17-е, 8 и 22 марта неизменны. Конфликт не запускает перестановку других событий и не оставляет частичный перенос.

Проверка. Проверить исходные/новые bookings, audit, повтор Idempotency-Key и сохранность после повторной генерации; позже TASK-049 проверит публикацию этого изменения.

TASK-028. Выполнить атомарный обмен и замену ресурсов§

Работы. Реализовать обмен двух проведений и замену преподавателя/комнаты с общим preview/apply. Проверять версии обеих строк и агрегата, все освобождаемые/новые ресурсы и оба набора участников.

Приёмка. При успехе обмен меняет оба события вместе; при конфликте третьей комнаты или группы не меняется ни одно. События сохраняют происхождение и историю.

Проверка. Гонки обмена с обычным переносом, внешнее пересечение, устаревшая версия второго события; сверить полный откат занятости и аудита.

TASK-029. Реализовать снятие, отмену, фиксацию и массовую правку§

Работы. Разделить снять назначение, отменить с причиной, удалить допустимый черновой объект и закрепить. Показать историю в карточке; восстановление прежнего значения или отменённого проведения выполнять новой командой с актуальными правами, ресурсами, версиями и аудитом. Добавить массовый предпросмотр со списком объектов и версий; свыше 200 использовать задание без молчаливого частичного применения.

Приёмка. Снятие возвращает объём к размещению; отмена сохраняет историю. Fixed проверяется во всех командах; старый Stable не устанавливает его автоматически.

Проверка. Проверить освобождение бронирований, повторную генерацию отмены, правку закреплённого события и ошибку последнего участника массовой операции. Попытка восстановить прежнюю уже занятую комнату отклоняется; прежняя история сохраняется, попытка фиксируется согласно политике аудита.

TASK-030. Связать совместное проведение с несколькими потребностями§

Работы. Поддержать подтверждённое общее событие разных планов через series_component и occurrence_requirement с точными участниками/зачётами. Добавить явное создание, изменение состава и разъединение с проверкой ресурсов и объёма.

Приёмка. Преподаватель и комната бронируются один раз на реальное проведение, каждая потребность учитывается корректно. Совпадение имени/времени/PlanNo само не сливает записи.

Проверка. Проверить два плана с одинаковым полным предметом и разными ID, повтор группы, параллельные части и последующее разъединение; показать расчёт нагрузки.

TASK-031. Перенести выбранную группу из общего занятия§

Работы. Реализовать move-groups-preview/apply: выбранные group_ids, оба состава, ресурсы и дельта нагрузки. А получает новое разовое событие, Б сохраняет исходный ID/дату; записать transfer, source exception и перенос allocations в одной транзакции. Повторные выделения имеют одну эффективную exception и отдельные связи происхождения.

Приёмка. Все участники → обычный move с тем же ID; неизменённые время/ресурсы → no_change. Учебные часы группы не удваиваются; учитель при двух двухчасовых проведениях получает 4 вместо 2. Сброс exception не возвращает А без разрешения связанного события.

Проверка. Проверить AP-21/22, неоднократные выделения, часть подгрупп выбранной группы, stale preview, fixed, права, повтор ключа, смену формата/ресурса и полный откат при последнем конфликте. Проверить запрет изменения длительности через move-groups: оно выполняется отдельной командой; отсутствие room_id сохраняет комнату, null явно снимает её.

TASK-032. Принять календарную часть сквозными сценариями§

Работы. Выполнить пользовательский путь на живых React/API/PostgreSQL: разовое создание, три просмотра, обычный и групповой перенос, повторная генерация, онлайн без комнаты. Снять протокол изменений ID, составов и учебной/преподавательской нагрузки.

Приёмка. Ни один основной сценарий не считается пройденным по мокам. Пока публикация не реализована, её часть AP-20 остаётся явно ожидающей TASK-049.

Проверка. Браузерные сценарии плюс конкурентные тесты отдельных соединений; приложить команды, результат, снимки и ожидаемые оставшиеся проверки выпуска.

TASK-033. Ввести версии политики и предметное утверждение§

Работы. Создать draft/approved версии правил: область, тип, строгость, источник, категория доказательности, срок, параметры, утверждение и исключения. Утверждённая версия неизменяема; политика и конфигурация закрепляются за проверяемой редакцией.

Приёмка. policy.approve проверяется отдельно от административной роли. Наблюдаемая частота не означает утверждённую норму; служебные причины защищены.

Проверка. Проверить создание/сравнение/утверждение/смену политики, запрещённую активацию кафедрой, immutable approved и влияние смены версии на preview.

TASK-034. Применить доступность и запреты ресурсов§

Работы. Описать ограничения по датам/повторениям, подтверждённую строгость и исключения. Материализовать объединение жёстких интервалов с сохранением источников. Неисполненный свободный текст сохранять как основание, не превращая его в код.

Приёмка. Снятие одного перекрывающего запрета не снимает другой. Неизвестные применимые исторические ограничения блокируют выпуск до решения или обоснованного исключения.

Проверка. Проверить пересечение/слияние/удаление запретов, исключение на дату, смену политики при переносе и закрытые причины за чужой областью.

TASK-035. Настроить временные профили форм и уровней§

Работы. Создать редактор профилей форма × уровень × тип дня с источником, обязательностью и исключениями. Предложения из политики загрузить только черновыми шаблонами. Вычислять пересечение обязательных интервалов всех участников совместного занятия.

Приёмка. Вечерняя шестая пара, аспирантская суббота и очная онлайн-группа различаются. Неполная заочная выборка не порождает универсальную сессию; отсутствие отдельного ограничения требует явного решения.

Проверка. Тестировать утверждённые синтетические профили AP-07, пустое пересечение, неизвестную классификацию, субботу и исключения без активации неподтверждённых норм.

TASK-036. Проверять вместимость, назначение и переходы§

Работы. Рассчитывать уникальных участников, проверенную вместимость/возраст данных, матрицу типов, оборудование и межкорпусные переходы. Разделить предупреждение, неизвестное и запрет с объяснением источника и доступных исправлений.

Приёмка. Обычный комментарий не отменяет превышение вместимости. Неизвестное не равно нулю; префикс комнаты не задаёт переход. Применять только явно утверждённые жёсткие правила.

Проверка. Проверить 30 человек/24 места, дубли одной группы, неизвестную численность, обязательную лабораторию и переход 20 минут при перерыве 10; контроль исключений по роли и политике.

TASK-037. Рассчитывать качество и полноту расписания§

Работы. Рассчитывать окна групп/подгрупп/учителей, количество пустых слотов и участков отдельно, распределение по дням/парам, полноту, соседство дисциплины и последовательность видов. В рабочем режиме использовать даты, в аналитическом — исходные блоки и слои.

Приёмка. Однопозиционные дни исключены из знаменателя окон. Учитель общего события не умножается на группы. Нет скрытого общего балла, жёстких максимумов из статистики и выдуманных минут ожидания.

Проверка. Проверить {1}, {1,2}, {1,3,4}, {1,4}, лекцию/практику и уникальные события; локальный исходный прогон отдельно подтверждает 3571/3975 и 2859/3210.

TASK-038. Показывать последствия ручного изменения§

Работы. Встроить в preview переносов/обмена/состава раздельные дельты качества, нагрузки и нарушения. Показывать затронутые даты/ресурсы и версии вычисления. Повторить актуальную валидацию при apply в общем сервисе команд.

Приёмка. Уменьшение окон группы и увеличение окон учителя видны одновременно. Конфликтующий вариант не называется допустимым; старый preview после правки правила отклоняется или пересчитывается.

Проверка. Сравнить локальный пересчёт с полным на синтетических переносах; проверить неизменность незатронутых событий и целостность после конкурентной правки.

TASK-039. Принять политику и проверку готовности выпуска§

Работы. Проверить все реализованные сценарии политики на контрольных данных, привязать POL-01–POL-20 к коду и проверкам. Добавить единый readiness-отчёт неизвестных/блокирующих правил, прав, ресурсов и состава; основания читаются по доступу.

Приёмка. Черновые статистические шаблоны не могут незаметно попасть в действующую политику. Готовность не означает автоматического утверждения реальных норм владельца.

Проверка. Прогнать положительные и отрицательные AP, сравнить опубликованную позже политику с хешем кандидата; локальные исторические AP закрывает также TASK-046.

TASK-040. Реализовать устойчивые фоновые операции§

Работы. Хранить задания и outbox в PostgreSQL, передавать в Celery только ID. Добавить состояния, прогресс, heartbeat/lease, retry, идемпотентные шаги, отмену до необратимой стадии и приватные результаты. Предметная запись и outbox фиксируются одной транзакцией.

Приёмка. Отказ Redis приостанавливает выполнение, но не теряет принятую операцию. Повтор доставки не повторяет эффект; завершённый результат доступен только владельцу/уполномоченному.

Проверка. Убить worker после commit до подтверждения сообщения, перезапустить Redis/API, восстановить просроченную lease; проверить отсутствие двойного эффекта и ложного успеха.

TASK-041. Принять и сохранить полный исходный пакет§

Работы. Принимать SQLite, схему и манифест с лимитом 100 МБ, сигнатурой, целостностью и разрешённой схемой. Сохранить приватный неизменяемый пакет, хеши и все исходные строки/88 полей 19 таблиц; views учитывать отдельно. Парсер не исполняет SQL/скрипты из файла.

Приёмка. 75 909 активных строк доступны для сверки; исходный пакет не меняется. Невалидный или неизвестный вход не изменяет рабочие предметные таблицы.

Проверка. Проверить исходный read-only пакет, обрезанный файл, неверную схему/счётчики, превышение размера, попытку доступа по чужому UUID и прерывание загрузки.

TASK-042. Сопоставить справочники и происхождение полей§

Работы. Составить полную карту 88 полей, source_identity, UUID и статусы resolution. Восстановить GroupNo=-1 через GRPPLAN, сохранить подгруппы, STREAMS, CLASSINF/ClassesInf и расхождения, field-specific -1. Добавить закрытый экран «Требует сопоставления» с поиском и причинами. Защищённый технический просмотр содержит разрешённые сущности/импортные таблицы, описания всех исходных полей, счётчики, пагинацию, сортировку, фильтры и карточки со связями; различает NULL, пустую строку, ноль, false и -1, исключает служебные таблицы и SQL-консоль. Для согласованных CSV-шаблонов справочников и планов реализовать сопоставление столбцов, построчную диагностику и тот же preview/commit с происхождением; выборка и кодировка не должны изменять числовые единицы неявно.

Приёмка. Не создаются дубликаты Classes из ClassesInf, фиктивные факультеты и потоки по похожим именам. Неизвестные строки остаются видимыми, исходные HTML-сущности не исполняются.

Проверка. Для группы 434109 проверить 79 занятий (39+40), все 554 группы и 17 727 уникальных связей; отдельно расхождение счётчика 13 и аудитории.

TASK-043. Преобразовать подтверждённую историческую семантику§

Работы. Реализовать версионированные преобразования DayNo/OddWeek/EachWeek, единиц и ограничений только на основании принятых DEC; каждое правило имеет исходный и ожидаемый пример. До решения сохранять raw/staging и блокируемые поля без бронирований.

Приёмка. Код пути quarantine тестируется сразу. Применение правил к реальному снимку и закрытие задачи требуют подтверждённых решений по применимым полям; блок q не объявляется календарной неделей.

Проверка. Проверить 11 блоков, 23 EachWeek и 11 553 аналитических слоя отдельно от календаря; после согласования проверить ручные примеры всех режимов с диспетчером.

TASK-044. Проверить кандидатов совместных занятий при импорте§

Работы. Показывать кандидатов объединения с полными названиями/видами, всеми ClassNo/PlanNo/SubjectNo, участниками и ресурсами. Сохранять решение диспетчера и карту нескольких планов к одному проведению; дать предпросмотр разъединения.

Приёмка. 638 преподавательских и 572 аудиторных клеток — кандидаты, не 638/572 автоматически разрешённых слияний. До подтверждения участники и исходные строки сохраняются раздельно.

Проверка. Проверить случаи разных PlanNo, четырёх совпадающих названий с разными SubjectNo, неизвестной комнаты и максимума 27 строк; сверить обучение и фактическую нагрузку после решения.

TASK-045. Применить импорт атомарно и обеспечить безопасный откат§

Работы. Подготовить сверку, target draft и версии правил, повторяемый commit с устойчивыми UUID/происхождением; большой импорт готовить в изолированном кандидате и активировать атомарно. Откат сверяет последующие ручные изменения и предлагает компенсирующую редакцию.

Приёмка. Повтор пакета с теми же правилами возвращает прежний результат. Отмена до commit не меняет черновик. Откат не удаляет последующие ручные изменения и исходный пакет.

Проверка. Проверить повтор preview/commit, падение на последнем шаге, изменение черновика перед commit, смену правил, повторный импорт нового снимка и безопасный откат после ручного переноса.

TASK-046. Принять перенос и аналитические контрольные числа§

Работы. В закрытом окружении прогнать неизменённый контрольный SQLite и все сверки, составить ledger: сохранено raw, нормализовано, ожидает решения, отклонено с причиной. Отдельно подписать календарную и семантическую приёмку владельцем данных.

Приёмка. Успешный raw-импорт не выдаётся за готовое календарное расписание. Все 88 полей покрыты; все оставшиеся неоднозначности перечислены. Полный статус done требует подтверждённой части реальной миграции.

Проверка. Приложить манифест/хеши, команды и счётчики AP/AC-D; сопоставить 19 таблиц, 15 111 Classes и 11 530/3 581 assigned/unassigned, включая 288 координат неназначенных.

TASK-047. Реализовать кафедральные предложения и согласование§

Работы. Добавить передачу позиции на уточнение кафедре, назначенного ответственного, предложение и возврат/принятие с причиной. Разделить предложение, изменение ресурса и согласование выпуска; ресурс меняет только разрешённая предметная команда.

Приёмка. Кафедра видит свою область, не редактирует чужое расписание. Исторические передачи не восстанавливаются без доказательств; Assigned не означает публикацию.

Проверка. Проверить полный путь диспетчер → кафедра → предложение → принятие/отклонение, изменение версии за время согласования и запрет обхода прав.

TASK-048. Подготовить неизменяемый снимок публикации§

Работы. Создать candidate/frozen snapshot событий, составов, названий, параметров, approved-политики и исключений. Выполнить полную readiness-проверку на версии агрегата; фоновая подготовка не должна замораживать долгую работу читателей.

Приёмка. Редактирование во время подготовки обнаруживается по версии. После freeze никакой прикладной путь не меняет снимок; изменения справочников не меняют старые подписи.

Проверка. Гонки freeze с изменением события, справочника и политики; сверить хеш кандидата и прежнее чтение при сбое worker.

TASK-049. Атомарно активировать публикации разных периодов§

Работы. Создать active_publication_booking по глобальным ресурсам без revision в исключающем ключе, проверку пересечения разных схем участников и блокировки организации. Атомарно заменить активный снимок; повторная активация старого снимка тоже проверяет текущие ресурсы.

Приёмка. Две конфликтующие публикации разных периодов не активируются вместе. Неизвестное пересечение схем блокирует выпуск. Точечный перенос публикуется новым снимком без пересоставления остальных занятий.

Проверка. Синхронные гонки двух публикаций, разных схем и активации со сменой политики; проверить сохранность прежней публикации при отказе и стабильность ID остальных дат AP-20.

TASK-050. Открыть читательское и контролируемое публичное расписание§

Работы. Читателям показывать только целиком активный снимок; добавить выбранную архивную версию для уполномоченных. Анонимный режим включать отдельной настройкой с предпросмотром allowlist полей. Формат онлайн отображать текстом без закрытых реквизитов.

Приёмка. До явного включения анонимное чтение закрыто. Кэш и ссылки не смешивают версии, не раскрывают черновики, причины ограничений, заметки или закрытые файлы.

Проверка. Проверить выключенный/включённый режим, прямые UUID/версии и утечки в HTML/API/заголовках кэша; AP-23 выполнить для всех трёх видов.

TASK-051. Реализовать экспорт, печать и защищённые файлы§

Работы. Сделать CSV разрешённых справочников, планов и расписания; печать дня/недели/списка по явно выбранным фильтрам и версии, локальным ассетам и корпоративным токенам. Крупные выгрузки — приватные задания с ограниченным сроком и проверкой прав на скачивание.

Приёмка. Состав колонок зависит от роли. Формульные префиксы нейтрализуются в CSV без изменения БД; печать не раскрывает онлайн-пароли. Выдача фиксирует версию, а не смешивает текущие изменения.

Проверка. Сравнить экспорт с API по ID и часам, проверить CSV-инъекцию, чужую/просроченную ссылку, несколько страниц печати с длинными предметами и текстовую онлайн-метку.

TASK-052. Подготовить справку и инструкции рабочих ролей§

Работы. Описать действия диспетчера, кафедры, публикатора и администратора на реальных экранах новой версии: создать дату, выделить группу, объяснить конфликт, сопоставить импорт, утвердить политику, выпустить и напечатать.

Приёмка. Термины и снимки соответствуют работающему приложению; инструкции доступны автономно. Справка не содержит рабочих секретов.

Проверка. Незнакомый с реализацией пользователь проходит сценарии по инструкции; исправить найденные разрывы и проверить корпоративную печать/узкую ширину.

TASK-053. Провести сквозную проверку доступа и безопасности§

Работы. Проверить все маршруты и файловые каналы по матрице прав, CSRF, XSS/SQL и CSV-инъекции, сессии, ограничения загрузок/заданий и редактирование frozen. Проверить production-настройки Django, закрытые порты и безопасные логи.

Приёмка. Нет обхода области через поиск, счётчики, аудит, экспорт и конфликтную ошибку. Критическая утечка/ошибка авторизации блокирует выпуск; сканер не заменяет предметные отрицательные тесты.

Проверка. Автоматические HTTP-сценарии плюс инспекция конфигурации изнутри/снаружи стенда; отчёт содержит воспроизведение, исправление и повтор конкретной проверки.

TASK-054. Подтвердить скорость и конкурентную устойчивость§

Работы. Создать детерминированный генератор профиля ТЗ: 250 тыс. событий, 50 тыс. в редакции, 500 правил, 1 млн аудита и пересекающиеся периоды. Прогнать 50 читателей/10 редакторов 30 минут после прогрева на 4 vCPU/8 ГиБ; отдельно измерить импорт, качество и активацию.

Приёмка. Выполнены p95 500 мс справочники, 1,5 с календарь, 1 с запись, 2 с локальное качество; импорт/полный quality ≤60 с, блокирующая активация ≤5 с, неожиданные 5xx <0,1%. fsync не отключён.

Проверка. Приложить ресурсы стенда, seed, команды, EXPLAIN, распределения p95 и SQL/lock traces. Оптимизировать измеренные узкие места и повторять только затронутые прогоны.

TASK-055. Подготовить автономное развёртывание на сервере§

Работы. Собрать production Compose: Nginx/TLS, Gunicorn, Django, PostgreSQL, Redis, Celery, постоянные приватные тома, health и отдельные роли. Проверить фактические ресурсы целевого сервера, DNS/домен, диски, лимиты и сосуществование с сайтом исследования. Подготовить offline-пакет установки.

Приёмка. Чистый сервер устанавливается по инструкции. Исследовательский rsp.nsuemdev.ru и его /data/ не заменяются новой системой по совпадению папки deploy. Нет открытых наружу БД/Redis и зависимости от облака разработчика.

Проверка. Установить на изолированный стенд, отключить внешний доступ для основного пользовательского сценария; проверить контейнеры без root, health и переживание перезапуска.

TASK-056. Проверить резервное копирование и восстановление§

Работы. Реализовать ежедневный согласованный backup PostgreSQL+приватных файлов+версий с checksum и проверкой чтения. Настроить 7 ежедневных/4 еженедельных, одну внешнюю зашифрованную копию и месячное учебное восстановление; секреты получать отдельно.

Приёмка. Проведено изолированное восстановление с RPO ≤24 часа и RTO ≤4 часа, входом, публикациями, исходниками и историей. Ошибка новой копии не удаляет последнюю исправную.

Проверка. Симулировать потерю установки на стенде, восстановить из подготовленной копии, замерить время и сверить контрольные числа/ссылки; проверить отказ заполненного хранилища.

TASK-057. Подготовить обновление, обслуживание и откат§

Работы. Описать версионированные образы и одиночный запуск миграций, expand→migrate→switch→contract, maintenance и smoke-проверки. Для каждого изменения схемы определить совместимость прошлого образа и способ восстановления данных.

Приёмка. Возврат контейнера не обещается как откат любой схемы. Активная публикация сохраняется до переключения; новых подтверждённых изменений не теряют без явно согласованного сценария восстановления.

Проверка. На стенде провести успешное обновление и отказ миграции/health, восстановить совместимую версию; проверить вход, тестовую запись, очередь, права и backup.

TASK-058. Настроить диагностику, хранение и доступность§

Работы. Добавить безопасные структурированные логи request_id/job_id, метрики API/БД/блокировок/очереди/worker, диск, backup age и TLS. Настроить ротацию: технические логи 30 дней, аудит 365; периоды/публикации/принятые исходники автоматически не удалять.

Приёмка. Диагностика доступна без мессенджера. Метод расчёта целевых 99,5% и окно обслуживания согласованы; один сервер не объявлен отказоустойчивым кластером.

Проверка. Вызвать безопасные отказы БД/Redis/worker, просроченный backup и порог диска; проверить сигнал, request_id, восстановление и отсутствие секретов в логах.

TASK-059. Провести полную функциональную и визуальную приёмку§

Работы. Свести FR, POL, AP, AC-D и ACC с реализацией и доказательствами; выполнить недостающие сквозные пути на release candidate. Проверить корпоративные страницы, формы, печать, клавиатуру, 200% и поддерживаемые браузеры; каждый дефект имеет воспроизведение.

Приёмка. 67 базовых FR закрыты доказательствами; FR-059/060 остаются E. Пропущенный из-за среды тест не записывается пройденным. Критические дефекты блокируют пилот.

Проверка. Протокол с версиями кода/БД/политики/браузеров, командами и ссылками; повтор исправленного сценария и затронутой регрессии, а не произвольное многократное тестирование всего.

TASK-060. Собрать комплект передачи и карту старых функций§

Работы. Собрать исходники, lock/лицензии, OpenAPI/ER, словарь, все 88 полей, все LEG-01–59, POL-01–20, тестовые протоколы и инструкции. Для legacy-возможности указывать реализованный путь, уточнение владельца либо согласованное E, не объявляя весь старый интерфейс одинаковым.

Приёмка. Каждое требование связано с конкретным кодом и проверкой. Рабочие пароли передаются отдельно защищённым способом; сборка и инструкции воспроизводимы без автора.

Проверка. Валидировать ссылки и полноту манифеста, установить из передаваемого пакета по инструкции; сверить хеш release candidate с проверенной версией.

TASK-061. Провести пилот с диспетчером и владельцами правил§

Работы. Выбрать ограниченный учебный период и ответственных. Диспетчер выполняет реальные переносы, выделение группы, назначение онлайн, разрешение импортных проблем и выпуск. Владелец утверждает применимые профили, вместимость, доступ, часы и календарь; записать дефекты и решения.

Приёмка. Модель готовит демонстрацию и исправления, но не подменяет предметное утверждение владельца. Открытые DEC оцениваются по применимости и не закрываются истечением времени.

Проверка. Подписанный протокол сценариев и перечня открытых рисков; исправленные дефекты повторены на тех же примерах, readiness выбранного периода подтверждён.

TASK-062. Подготовить финальный переход и критерии отката§

Работы. Согласовать остановку изменений старой системы, финальный снимок, контрольную сверку, пользователей и момент перехода PostgreSQL в единственный источник записи. Подготовить конкретный план переключения домена/службы с резервной копией и границей отката до/после новых записей.

Приёмка. Никакой двусторонней синхронизации с Paradox и автослияния двух изменявшихся копий. План учитывает реальные ресурсы Timeweb и защищённый сайт исследования; новые расходы/переключение выполняются в согласованной области.

Проверка. Репетиция на стенде с финальным пакетом: импорт, readiness, публикация, восстановление, проверка паролей и прав; протокол подтверждает возможность запуска.

TASK-063. Выполнить согласованный ввод и контроль после запуска§

Работы. Выполнить утверждённую последовательность выпуска: backup, финальный импорт, сверка, активация и smoke-сценарии с ответственными. Проверить чтение групп/преподавателей, один перенос в тестовой области, печать, роли, очередь и первый backup.

Приёмка. Переход выполнен только после готовности и разрешённого окна. До появления новых записей доступен согласованный быстрый откат; после них сначала анализ/сохранение данных.

Проверка. Записать release ID, время переключения, итоговые хеши и результаты без секретов; подтвердить работу с реальным диспетчером.

TASK-064. Закрыть стабилизацию и передать дальнейший backlog§

Работы. В течение согласованного пилотом периода разобрать дефекты, проверить показатели доступности/backup, передать ответственность и известные ограничения. Отдельно сохранить идеи E: drag-and-drop, оптимизатор, SSO, видеоплатформы, дополнительные ресурсы и HA.

Приёмка. Объём B закрывается по критериям, а не по исчерпанию контекста модели. Длительность поддержки и SLA согласуются отдельно; расширения не подменяют незавершённые базовые требования.

Проверка. Итоговый протокол владельца/эксплуатации с открытыми задачами и ответственными, последним успешным восстановлением и планом очередного релиза.