Структура репозитория системы «Обратная связь — регион»
Каждая строка описывает назначение папки или значимого артефакта. Ссылки ведут к материалам этого самостоятельного репозитория; нормативные определения читаются из исходных документов, а отчёты — из generated/.
Файлы в корне
| Артефакт | Назначение |
|---|---|
| .gitattributes | Правила обработки текстовых файлов и переводов строк. Поддерживают единый формат Markdown, JSON, Python и YAML в разных рабочих окружениях. |
| .gitignore | Исключения Git для окружений, секретов, временных файлов и вычисляемых отчётов. Исходные документы и необходимые материалы требований сохраняются в репозитории. |
| .gitlab-ci.yml | Конфигурация проверок для самостоятельного репозитория: lint --ready, отчёты и тесты инструментов. В составе комплекта файл находится во вложенном каталоге и не подключается корневой конфигурацией. |
| AGENTS.md | Рабочие правила для агентов: сохранение ID, источников истины, связей и выбранных проверок. Применяются при подготовке изменений в этом репозитории. |
| README.md | Точка входа в репозиторий: порядок чтения, основные ссылки и команды начала работы. Подробное назначение папок и артефактов приведено в STRUCTURE.md. |
| requirements-tools.txt | Зафиксированные зависимости Python для инструментов проверки. Используется для воспроизводимой установки окружения локально и в CI. |
| STRUCTURE.md | Справочник размещения и назначения папок и значимых артефактов. Помогает выбрать место для нового материала и найти его канонический источник. |
acceptance/
| Папка или артефакт | Назначение |
|---|---|
| acceptance/ | План приёмки: сценарии, проверяемые наблюдения, тестовые данные и порядок получения доказательств. Связи CHECK с REQ показывают запланированное покрытие, а результаты исполнения учитываются отдельно. |
| acceptance/datasets/ | Исходные состояния и эталоны приёмочных сценариев, сгруппированные в наборы DATA и случаи CASE. Наборы указывают контракт входа, подготовку и очистку данных. |
| acceptance/datasets/architecture-dependencies.json | Набор DATA-ARC-DEPENDENCIES: Положительный и отрицательный кандидат для проверки транзитивного доступа. CASE задают конкретные входы и эталоны, а метаданные описывают контракт входа, подготовку и очистку. |
| acceptance/datasets/architecture-transaction.json | Набор DATA-ARC-TRANSACTION: План испытания сохранности outbox на границе фиксации. CASE задают конкретные входы и эталоны, а метаданные описывают контракт входа, подготовку и очистку. |
| acceptance/datasets/architecture-technology.json | Синтетические инвентаризации DATA-ARC-TECHNOLOGY для проверки разрешённого состава, неподтверждённой замены и плавающей версии. Эталоны инспекции не являются сведениями о реально установленном ПО. |
| acceptance/datasets/data-pos-analytics.json | Набор DATA-POS-ANALYTICS: Ручной эталон аналитики: поручения не удваивают жалобы, срез и границы сроков. CASE задают конкретные входы и эталоны, а метаданные описывают контракт входа, подготовку и очистку. |
| acceptance/datasets/data-pos-clock.json | Набор DATA-POS-CLOCK: Дедлайн и переходы без изменения исходного срока. CASE задают конкретные входы и эталоны, а метаданные описывают контракт входа, подготовку и очистку. |
| acceptance/datasets/data-pos-intake.json | Набор DATA-POS-INTAKE: Корректный ввод, повтор, конфликт ключа и границы контракта приёма. CASE задают конкретные входы и эталоны, а метаданные описывают контракт входа, подготовку и очистку. |
| acceptance/datasets/data-pos-load.json | Набор DATA-POS-LOAD: Условный нагрузочный профиль без вложений. CASE задают конкретные входы и эталоны, а метаданные описывают контракт входа, подготовку и очистку. |
| acceptance/datasets/data-pos-workflow.json | Набор DATA-POS-WORKFLOW: Контексты прохождения жалобы, нескольких поручений, отказов прав и уведомлений. CASE задают конкретные входы и эталоны, а метаданные описывают контракт входа, подготовку и очистку. |
| acceptance/evidence/ | Правила оформления результатов испытаний и ссылок на доказательства. Фактические логи, протоколы и снимки сохраняются как CI artifacts или в согласованном хранилище. |
| acceptance/evidence/README.md | Состав результата реальной проверки: наблюдение, статус, версии продукта/требований/тестов/данных и ссылки на доказательства. Различает успешное исполнение, пропуск и блокировку проверки. |
| acceptance/scenarios/ | Приёмочные сценарии с GIVEN/WHEN и именованными CHECK. Один сценарий может проверять несколько REQ, а каждая CHECK задаёт аспекты обязательства, ожидаемый результат и способ проверки. |
| acceptance/scenarios/scn-arc-001.json | Задаёт приёмочный сценарий «Проверка архитектурного ограничения 001» (SCN-ARC-001). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-arc-002.json | Задаёт приёмочный сценарий «Проверка архитектурного ограничения 002» (SCN-ARC-002). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-arc-003.json | Сценарий SCN-ARC-003 инспектирует соответствие поставки технологическому базису. Четыре CHECK различают выбор продукта и фиксацию сборки, включая отрицательные случаи. |
| acceptance/scenarios/scn-pos-001.json | Задаёт приёмочный сценарий «Полный путь жалобы в одно ведомство» (SCN-POS-001). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-002.json | Задаёт приёмочный сценарий «Корректная регистрация» (SCN-POS-002). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-003.json | Задаёт приёмочный сценарий «Повтор и конфликт ключа» (SCN-POS-003). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-004.json | Задаёт приёмочный сценарий «Некорректный ввод» (SCN-POS-004). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-005.json | Задаёт приёмочный сценарий «Подсказка и уточнение» (SCN-POS-005). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-006.json | Задаёт приёмочный сценарий «Нет маршрута» (SCN-POS-006). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-007.json | Задаёт приёмочный сценарий «Два ведомства и неполный комплект» (SCN-POS-007). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-008.json | Задаёт приёмочный сценарий «Полный комплект двух ведомств и повтор публикации» (SCN-POS-008). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-009.json | Задаёт приёмочный сценарий «Переназначение и запоздавший ответ» (SCN-POS-009). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-010.json | Задаёт приёмочный сценарий «Исполнитель другого ведомства» (SCN-POS-010). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-011.json | Задаёт приёмочный сценарий «Чужой заявитель» (SCN-POS-011). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-012.json | Задаёт приёмочный сценарий «Возврат на доработку» (SCN-POS-012). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-013.json | Задаёт приёмочный сценарий «Отказ внешнего канала» (SCN-POS-013). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-014.json | Задаёт приёмочный сценарий «Принято провайдером и прочитано автором» (SCN-POS-014). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-015.json | Задаёт приёмочный сценарий «Аналитика когорты и временного среза» (SCN-POS-015). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-016.json | Задаёт приёмочный сценарий «Аналитическая роль и запрещённые поля» (SCN-POS-016). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-017.json | Задаёт приёмочный сценарий «Дедлайн при переходе даты» (SCN-POS-017). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-018.json | Задаёт приёмочный сценарий «Конкурентная маршрутизация» (SCN-POS-018). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/scenarios/scn-pos-019.json | Задаёт приёмочный сценарий «Нагрузочная приёмка регистрации» (SCN-POS-019). CHECK связывают наблюдения с REQ и аспектами обязательств, а ссылки на DATA выбирают начальные условия и случаи. |
| acceptance/strategy.md | Риски, категории сценариев, методы проверки, среда и условия готовности к приёмке. Объясняет достаточность выбранного плана и сочетания, для которых требуется дополнительная проверка. |
architecture/
| Папка или артефакт | Назначение |
|---|---|
| architecture/ | Проект архитектуры: границы, части, данные, взаимодействия, размещение и обеспечение качеств. Обязательные правила реализации оформляются как REQ, а причины выбора — как DEC. |
| architecture/README.md | Маршрут чтения архитектуры и вопросы, на которые отвечают представления. Показывает, где искать собственные факты каждого представления и общие определения. |
| architecture/catalog.md | Канонические определения элементов, связей, владельцев данных, распределения REQ и нормативных ограничений. Выбранные каталоговые инварианты проверяются при явном включении архитектурного контроля. |
| architecture/concepts.md | Описание сквозных механизмов, используемых несколькими частями системы. Область действия и ограничения механизма задаются в одном месте. |
| architecture/context.md | Граница системы, внешние участники и взаимодействия через эту границу. Названия и определения элементов берутся из общего каталога. |
| architecture/data.md | Границы данных и объяснение владения, записи и чтения. Владельцы и разрешённые доступы определяются в каталоге, а предметные состояния — в модели и REQ. |
| architecture/deployment.md | Размещение экземпляров по средам, сетевые границы и границы отказа. Неопределённые параметры целевой среды явно связываются с открытыми вопросами. |
| architecture/quality.md | Связь значимых качественных требований с механизмами, решениями и способами проверки. Показывает проектное обоснование, которое должно быть подтверждено испытаниями реализации. |
| architecture/runtime.md | Последовательности существенных взаимодействий, транзакционные границы и отказные ветки. Детализирует выбранные механизмы, а не каждый пользовательский сценарий. |
| architecture/technology-stack.md | Базис технологий, который заполняет архитектор: продукты, версии, обязательность, источники и область применения. Представления и нормативные REQ ссылаются на этот документ, а состав конкретной поставки подтверждается инвентаризацией. |
| architecture/structure.md | Декомпозиция на части, их ответственность и интерфейсы. Объясняет, какие элементы участвуют в выполнении требований, без повторного определения общих фактов каталога. |
contracts/
| Папка или артефакт | Назначение |
|---|---|
| contracts/ | Машинные схемы предметных входов и представлений данных, используемых сценариями. Они задают проверяемые форматы; полный интеграционный контракт дополнительно описывает протокол, авторизацию, версии и ошибки. |
| contracts/README.md | Назначение предметных схем, границы доверия и дальнейшая детализация интеграционного контракта. Объясняет, как использовать отдельные форматы без приписывания им полноты API. |
| contracts/agency-response.schema.json | Формат представления согласованного ответа ведомства и версии назначения. Согласование должно подтверждаться системой после проверки роли. |
| contracts/analytics-input.schema.json | Формат синтетического снимка для вычисления эталонов аналитики. Позволяет повторить расчёт по заданному временному срезу. |
| contracts/architecture-dependencies.schema.json | Формат кандидатных зависимостей и прав для инспекции аналитического доступа. Реальная проверка должна извлекать соответствующие сведения из реализации и среды. |
| contracts/architecture-transaction.schema.json | Формат входов испытания остановки на границе транзакции публикации. Используется для описания ожидаемого восстановления, а не как продуктовый API. |
| contracts/complaint-submit.schema.json | Формат отправки жалобы с ключом, текстом, территорией и первичной категорией. Автор определяется доверенной сессией и не задаётся произвольным клиентским полем. |
| contracts/technology-inventory.schema.json | Контракт входной инвентаризации для инспекции состава поставки. Проверяет форму наблюдаемых продуктов и версий, без дублирования разрешённого технологического базиса. |
| contracts/workflow-context.schema.json | Формат начальных контекстов приёмочных сценариев с разрешёнными дополнительными полями. Корректность по схеме не подтверждает допустимость бизнес-состояния. |
docs/
| Папка или артефакт | Назначение |
|---|---|
| docs/ | Контекст продукта, верхнеуровневые требования и общие предметные определения. Здесь также находятся вопросы, решения, допущения и оценка применимости областей требований. |
| docs/applicability.md | Оценка применимости областей чек-листа: что рассмотрено, что применимо и где находятся соответствующие артефакты. Обоснование пишется в Markdown; pending означает незавершённое рассмотрение области. |
| docs/assumptions.md | Допущения, на которых основаны требования и проектные решения. Для каждого указываются основания, риск, способ подтверждения и при необходимости блокируемые требования. |
| docs/decisions.md | Предлагаемые, рабочие и окончательно принятые решения с обоснованием, альтернативами и последствиями. Архитектурные DEC-ARCH хранятся в том же реестре, чтобы у выбора был один источник. |
| docs/glossary.md | Единые определения предметных терминов и допустимых названий. Другие документы ссылаются на эти определения вместо создания собственных трактовок. |
| docs/models.md | Общие модели сущностей, состояний, прав и правил расчёта. Спецификации явно указывают, какие части модели являются нормативными для соответствующего REQ. |
| docs/overview.md | Проблема, ожидаемый результат, пользователи, контекст и границы системы. Определяет, какие возможности входят в текущую область требований и какие требуют дальнейшей детализации. |
| docs/performance.md | Условия нагрузочного испытания регистрации: метрики, нагрузка, измерение, состав стенда и сохраняемые результаты. Численные обязательства принадлежат REQ-NFR-001. |
| docs/questions.md | Открытые и разрешённые вопросы с вариантами, влиянием и ответственными. Контрольные поля задают блокировки и раздельные ссылки на рабочий вариант и окончательный ответ; рабочий вариант сохраняет вопрос открытым. |
| docs/requirements/ | Канонические HLR, сгруппированные по предметным областям и сквозным гарантиям. Оглавление помогает читать комплект; определения и статусы требований находятся в документах пакетов. |
| docs/requirements.md | Ссылка с прежнего адреса на оглавление каталога requirements/. В новом комплекте не содержит собственных определений HLR. |
| docs/requirements/README.md | Карта областей и ссылки на канонические HLR. Навигационная группировка не добавляет уровня требований и не дублирует их статусы или приоритеты. |
| docs/requirements/agency-interaction/ | Взаимодействие с ведомствами: направление жалобы, сбор и согласование ответов. В одном пакете находятся HLR-POS-003 и HLR-POS-004 и связанные иллюстрации. |
| docs/requirements/agency-interaction/README.md | Взаимодействие с ведомствами: направление жалобы, сбор и согласование ответов. Канонические определения HLR-POS-003, HLR-POS-004 содержат метаданные, результат, границы и приёмку. |
| docs/requirements/agency-interaction/assets/ | Материалы, принадлежащие одному пакету HLR, с описанием их происхождения и нормативной роли. Иллюстрации и приложения размещаются раздельно. |
| docs/requirements/agency-interaction/assets/README.md | Описание или перечень материалов: назначение, источник/версия, связанные HLR и роль. Позволяет отличить поясняющую картинку от нормативного источника. |
| docs/requirements/agency-interaction/assets/attachments/ | Приложения предметной области: формы и исходные документы. Для нормативного источника фиксируются версия и применимые разделы. |
| docs/requirements/agency-interaction/assets/attachments/README.md | Назначение приложений области и правила фиксации их источника, версии и применимых разделов. Связывает исходные документы с описанием материалов и нормативными требованиями. |
| docs/requirements/agency-interaction/assets/images/ | Изображения предметной области: схемы, иллюстрации и макеты. Подпись и описание материала определяют его назначение и обязательность визуальных деталей. |
| docs/requirements/agency-interaction/assets/images/multi-agency.svg | Редактируемая SVG-иллюстрация одной жалобы и отдельных поручений двум ведомствам. Поясняет взаимодействие для HLR-POS-003/004, без введения правил полноты и версий. |
| docs/requirements/analytics/ | Воспроизводимые показатели обработки жалоб с ограничением детализации данных. Здесь определён HLR-POS-006. |
| docs/requirements/analytics/README.md | Воспроизводимые показатели обработки жалоб с ограничением детализации данных. Канонические определения HLR-POS-006 содержат метаданные, результат, границы и приёмку. |
| docs/requirements/complaint-intake/ | Возможность приёма и регистрации жалобы, включая наблюдаемый результат повторной отправки. Здесь определён HLR-POS-001. |
| docs/requirements/complaint-intake/README.md | Возможность приёма и регистрации жалобы, включая наблюдаемый результат повторной отправки. Канонические определения HLR-POS-001 содержат метаданные, результат, границы и приёмку. |
| docs/requirements/cross-cutting/ | Сквозные гарантии защиты, аудита, сроков и устойчивости. Они детализируются в нескольких областях REQ и не принадлежат одному пользовательскому потоку. |
| docs/requirements/cross-cutting/security.md | Определение HLR-POS-007: защита доступа и восстановление существенных изменений по аудиту. Конкретные права и события детализируются в REQ. |
| docs/requirements/cross-cutting/service-continuity.md | Определение HLR-POS-008: сохранение сроков и эксплуатационная устойчивость обработки. Условия измерения и реакции на сбои задаются в спецификациях. |
| docs/requirements/preliminary-processing/ | Предварительная обработка жалобы: классификация, достаточность сведений и уточнение у автора. Здесь определён HLR-POS-002. |
| docs/requirements/preliminary-processing/README.md | Предварительная обработка жалобы: классификация, достаточность сведений и уточнение у автора. Канонические определения HLR-POS-002 содержат метаданные, результат, границы и приёмку. |
| docs/requirements/response-delivery/ | Публикация итогового ответа в кабинете и доставка уведомления заявителю. Здесь определён HLR-POS-005. |
| docs/requirements/response-delivery/README.md | Публикация итогового ответа в кабинете и доставка уведомления заявителю. Канонические определения HLR-POS-005 содержат метаданные, результат, границы и приёмку. |
| docs/requirements/shared/ | Общие материалы нескольких пакетов HLR. Документы областей ссылаются на один источник вместо копирования файлов. |
| docs/requirements/shared/assets/ | Файлы и описание общих материалов: их назначение, происхождение и нормативная роль. Глоссарий и предметные модели сохраняют отдельные канонические документы. |
| docs/requirements/shared/assets/README.md | Описание или перечень материалов: назначение, источник/версия, связанные HLR и роль. Позволяет отличить поясняющую картинку от нормативного источника. |
generated/
| Папка или артефакт | Назначение |
|---|---|
| generated/ | Вычисляемые отчёты покрытия и прослеживаемости. Это необязательный кэш или CI artifacts; авторские требования здесь не редактируются. |
| generated/coverage.md | Вычисляемая матрица планового покрытия REQ и аспектов через CHECK и случаи данных. Выявляет объявленные пробелы; не подтверждает исполнение проверок. |
| generated/traceability.md | Вычисляемый индекс связей HLR → REQ для навигации и ревью. Связи определяются в метаданных спецификаций и здесь вручную не редактируются. |
handbook/
| Папка или артефакт | Назначение |
|---|---|
| handbook/ | Методическая инструкция, включённая в самостоятельный репозиторий. Объясняет качество требований, форматы, архитектурный подход и выбор автоматизации. |
| handbook/ARCHITECTURE.md | Место архитектуры относительно HLR/REQ, вопросы представлений и распределение источников истины. Объясняет переход от проектного решения к обязательству разработки. |
| handbook/ARTIFACTS.md | Обоснование формы каждого артефакта и выбора автоматизации. Фиксирует, где достаточно Markdown и агентского ревью, а где нужен машинный формат или вычисляемый отчёт. |
| handbook/FORMAT.md | Канонические источники, выбранные контрольные поля и смысл связей между артефактами. Объясняет, какую часть Markdown проверяет скрипт и какую оценивает ревьюер. |
| handbook/GUIDE.md | Основная инструкция: качество требований, состав комплекта, два уровня детализации, процесс изменения и приёмка. Содержит чек-лист применимости и порядок наполнения пакетов HLR. |
| handbook/TOOLS.md | Команды проверки, условия готовности, формирование отчётов и ограничения автоматизации. Помогает запускать необходимые проверки и правильно читать результат. |
impact/
| Папка или артефакт | Назначение |
|---|---|
| impact/ | Знания о влиянии изменений и сохранённые результаты пересмотра. Матрица задаёт «изменил X → пересмотри Y», а конкретный разбор фиксирует выводы и основания. |
| impact/reviews/ | Разборы конкретных изменений с перечнем затронутых артефактов, статусами пересмотра и основаниями выводов. Незакрытые обязательные позиции учитываются выбранной проверкой готовности. |
| impact/reviews/technology-stack.md | Разбор влияния входящего технологического базиса на требования, представления и приёмку. Фиксирует основания согласованности проекта и сохраняет открытые промышленное размещение и испытания. |
| impact/reviews/working-notification-policy.md | Разбор влияния рабочего решения о повторах уведомления на требования, части системы и план приёмки. Фиксирует сохранение текущего поведения и открытый вопрос для его последующего подтверждения. |
| impact/reviews/reassign.md | Сохранённый разбор переназначения жалобы и его влияния на связанные требования, модели и проверки. Содержит статусы пересмотра, выводы и ссылки на основания. |
| impact/stretch-matrix.md | Авторские правила обязательного пересмотра при изменении ID или путей. Причина каждой зависимости объясняет, почему затронутый материал нужно пересмотреть. |
openspec/
| Папка или артефакт | Назначение |
|---|---|
| openspec/ | Нормативные спецификации REQ и жизненный цикл их изменений. Текущий согласованный снимок отделён от предложений, дельт и архива. |
| openspec/changes/ | Отдельные пакеты изменений: предложение, проектный подход, задачи и дельты спецификаций. Они описывают переход к новому состоянию, а не заменяют действующий снимок. |
| openspec/changes/archive/ | Завершённые пакеты изменений для восстановления истории решений. Исторические определения и ID не включаются в реестр действующих требований. |
| openspec/changes/archive/2026-10-07-preserve-deadline/ | Архив изменения переназначения жалобы с защитой от устаревшего ответа и сохранением исходного срока. Сохраняет основание изменения, проектный подход, задачи и дельту REQ-RTE-003. |
| openspec/changes/archive/2026-10-07-preserve-deadline/.openspec.yaml | Служебные метаданные пакета OpenSpec: схема и дата создания. Не содержат нормативных обязательств продукта. |
| openspec/changes/archive/2026-10-07-preserve-deadline/design.md | Проектный подход к версии назначения, сохранению срока и исключению устаревшего ответа. Объясняет изменение предметной модели и связанных правил. |
| openspec/changes/archive/2026-10-07-preserve-deadline/proposal.md | Проблема запоздавшего ответа после переназначения, ожидаемый результат и область изменения. Связывает изменение с анализом влияния и проверкой комплекта. |
| openspec/changes/archive/2026-10-07-preserve-deadline/specs/ | Исторические дельты спецификаций, вошедшие в завершённое изменение. Текущее обязательство читается из openspec/specs/. |
| openspec/changes/archive/2026-10-07-preserve-deadline/specs/routing/ | Дельта области маршрутизации в составе архивного изменения. Показывает, какое обязательство было уточнено при переназначении. |
| openspec/changes/archive/2026-10-07-preserve-deadline/specs/routing/spec.md | Архивная дельта REQ-RTE-003 о переназначении, версиях ответов и сохранении срока. Историческое описание отдельно от действующей спецификации маршрутизации. |
| openspec/changes/archive/2026-10-07-preserve-deadline/tasks.md | Задачи подготовки требований, сценария и разбора влияния со статусами выполнения. Выполнение этих задач не объявляет реализованными код продукта и его испытания. |
| openspec/config.yaml | Настройки OpenSpec, схема процесса и контекст для подготовки изменений. Инструкции конфигурации дополняют нормативные документы, а не заменяют их. |
| openspec/specs/ | Действующие спецификации по областям поведения и ограничений. Каждый REQ содержит нормативный текст, выбранные метаданные и сценарии. |
| openspec/specs/analytics/ | Действующий нормативный срез области аналитики. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/analytics/spec.md | Нормативные правила области аналитики в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
| openspec/specs/architecture/ | Действующий нормативный срез области архитектурных ограничений. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/architecture/spec.md | Нормативные правила области архитектурных ограничений в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
| openspec/specs/delivery/ | Действующий нормативный срез области публикации и доставки ответа. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/delivery/spec.md | Нормативные правила области публикации и доставки ответа в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
| openspec/specs/intake/ | Действующий нормативный срез области приёма жалоб. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/intake/spec.md | Нормативные правила области приёма жалоб в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
| openspec/specs/moderation/ | Действующий нормативный срез области предварительной обработки. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/moderation/spec.md | Нормативные правила области предварительной обработки в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
| openspec/specs/operations/ | Действующий нормативный срез области сроков и эксплуатации. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/operations/spec.md | Нормативные правила области сроков и эксплуатации в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
| openspec/specs/responses/ | Действующий нормативный срез области ответов ведомств. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/responses/spec.md | Нормативные правила области ответов ведомств в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
| openspec/specs/routing/ | Действующий нормативный срез области маршрутизации. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/routing/spec.md | Нормативные правила области маршрутизации в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
| openspec/specs/security/ | Действующий нормативный срез области доступа и аудита. Каталог объединяет спецификацию и при необходимости её дополнительные материалы. |
| openspec/specs/security/spec.md | Нормативные правила области доступа и аудита в виде REQ и сценариев OpenSpec. Родители HLR, источники и аспекты проверки задаются в выбранных метаданных. |
profile/
| Папка или артефакт | Назначение |
|---|---|
| profile/ | Конфигурация выбранных механических проверок и схемы их метаданных. Строгость контроля определяется проверяемыми инвариантами, частотой проверки и ценой ошибки. |
| profile/profile.json | Режим профиля, рассматриваемые области и включение выбранных архитектурных проверок. Это конфигурация инструмента, а не описание поведения продукта. |
| profile/schemas/ | JSON Schema для настроек профиля, метаданных требования, сценария и набора данных. Эти схемы проверяют устройство артефактов, а предметные входные данные описываются в contracts/. |
| profile/schemas/dataset.schema.json | Форма набора DATA и случаев CASE с входами, эталонами и условиями подготовки. Предметный формат входа проверяется отдельной схемой из contracts/. |
| profile/schemas/profile.schema.json | Допустимые поля и значения настройки профиля. Защищает от неоднозначной или ошибочной конфигурации проверки. |
| profile/schemas/requirement.schema.json | Форма контрольных метаданных HLR/REQ: ID, статус, владелец, связи, риск и аспекты проверки. Нормативный текст требования остаётся в Markdown. |
| profile/schemas/scenario.schema.json | Форма метаданных приёмочного сценария и CHECK, включая ссылки на обязательства и данные. Проверяет устройство плана, а не достаточность его наблюдений. |
scripts/
| Папка или артефакт | Назначение |
|---|---|
| scripts/ | Инструменты проверки комплекта, расчёта отчётов и анализа влияния. Скрипты проверяют выбранные формальные условия; содержательное ревью остаётся отдельной работой. |
| scripts/architecture_profile.py | Чтение каталога и проверка выбранных архитектурных инвариантов, ссылок и запретов. Диаграммы, достаточность механизмов и соответствие кода оцениваются отдельным ревью и испытаниями. |
| scripts/check_analytics_oracles.py | Пересчёт эталонов аналитики по синтетическим входам. Проверяет согласованность формул и тестовых ожиданий, без вызова работающего продукта. |
| scripts/doclinks.py | Помощник оформления локальных ссылок в Markdown. Учитывает расположение документа и пропускает кодовые блоки, чтобы команды и примеры не меняли смысл. |
| scripts/markdown_records.py | Чтение контрольных полей Markdown-реестров и таблиц. Позволяет проверять статусы, блокировки и связи без преобразования авторских документов в JSON. |
| scripts/reqtool.py | Основной CLI: структурный lint, проверки готовности, отчёты покрытия/прослеживаемости и план влияния изменения. Читает канонические Markdown-источники и выбранные машинные метаданные. |
| scripts/tests/ | Регрессионные и отказные проверки инструментов репозитория. Подтверждают обнаружение ошибок метаданных, связей и форматов; это не испытания продукта. |
| scripts/tests/test_architecture.py | Проверки выбранных ограничений каталога, владельцев и доступа к данным. Выявляют нарушения проектной модели, без анализа реального кода или прав среды. |
| scripts/tests/test_doclinks.py | Проверки формирования относительных локальных ссылок. Защищают от повреждения кода, команд и уже оформленных ссылок. |
| scripts/tests/test_markdown_records.py | Проверки чтения Markdown-реестров, контрольных значений и блокировок. Подтверждают обнаружение неоднозначных полей и ошибочных ссылок. |
| scripts/tests/test_reqtool.py | Отказные проверки связей, покрытия, готовности и отчётов основного инструмента. Подтверждают, что ошибочный план не считается корректным. |
| scripts/tests/test_requirement_packages.py | Проверки вложенных пакетов HLR, исключения приложений, уникальности ID и влияния файла с несколькими HLR. Также подтверждают работу без прежнего requirements.md. |
templates/
| Папка или артефакт | Назначение |
|---|---|
| templates/ | Заготовки документов, метаданных и разделов для создания новых артефактов. Их копируют в предметную область, заполняют и присваивают собственные ID. |
| templates/acceptance-strategy.md | Заготовка риск-ориентированного плана приёмки, категорий сценариев и доказательств. Объясняет выбор проверок и условий их выполнения. |
| templates/architecture-constraint.md | Заготовка обязательного архитектурного REQ с областью действия и методом проверки реализации. Отличает нормативный запрет от предпочтения проектировщика. |
| templates/architecture-decision.md | Архитектурное решение DEC-ARCH с требованиями-основаниями, альтернативами и компромиссами. Использует общий реестр решений. |
| templates/architecture-view.md | Заготовка представления с вопросом, областью, собственными фактами и ссылками на общие определения. Помогает отделить представление от дублирующей модели. |
| templates/assumption.md | Карточка допущения с основанием, риском и способом подтверждения. При необходимости задаёт блокируемые требования. |
| templates/change-proposal.md | Предложение изменения: проблема, ожидаемый результат, область и влияние. Объясняет, зачем менять текущие обязательства. |
| templates/contract.md | Состав API/событийного контракта: структура данных, протокол, ошибки, безопасность, версии и совместимость. Машинная схема дополняет этот текст. |
| templates/dataset.json | Машинные метаданные DATA и CASE с входами, эталонами, подготовкой и очисткой. Контракт входа указывается явно. |
| templates/decision.md | Карточка решения с обоснованием, альтернативами, последствиями и источником. Замещение принятого выбора оформляется ссылкой на предыдущее решение. |
| templates/high-level.md | Карточка HLR: потребность, пользователи, результат, границы, основные потоки и критерии успеха. Выбранные метаданные обеспечивают идентификацию и связи. |
| templates/impact-review.md | Разбор конкретного изменения с затронутыми материалами, статусами и основаниями выводов. Заполняется после формирования плана пересмотра. |
| templates/impact-rule.md | Правило «изменил X → пересмотри Y» с триггерами и причиной каждой зависимости. Сохраняет авторские знания о влиянии изменения. |
| templates/migration.md | План изменения данных и совместимости, включая включение, проверку и откат. Применяется при переходе между версиями продукта или справочников. |
| templates/models.md | Заготовка предметных сущностей, состояний, ролей и таблиц решений. Общие определения формируются один раз и используются несколькими REQ. |
| templates/nfr.md | Форма качественного требования: метрика, порог, условия и способ измерения. Помогает заменить неопределённые обещания проверяемым обязательством. |
| templates/overview.md | Структура обзора системы с проблемой, целями, контекстом и границами. Заполняется до подробных правил поведения. |
| templates/question.md | Карточка вопроса с контекстом, вариантами, влиянием и выбранными полями блокировки. Разрешённый вопрос связывается с решением DEC. |
| templates/scenario.json | Машинные метаданные сценария с GIVEN/WHEN, CHECK, ссылками на REQ и DATA. Заготовочные ID заменяются ID конкретной проверки. |
| templates/screen.md | Постановка экрана с действиями, состояниями, ошибками, доступностью и связанными REQ. Макет сопровождается описанием обязательных деталей. |
| templates/spec.md | Заготовка нормативного REQ в формате OpenSpec со сценарием и контрольными метаданными. Используется для детализации обязательства верхнего уровня. |
ux/
| Папка или артефакт | Назначение |
|---|---|
| ux/ | Экранные контракты, макеты и условия устойчивости интерфейса. Поведение, состояния и доступность описываются текстом и связываются с REQ, а изображения поясняют выбранные визуальные детали. |
| ux/screen-contracts.md | Действия и состояния экранов подачи, обработки и чтения ответа со ссылками на REQ. Дальнейшая детализация задаёт поля, тексты, фокус, клавиатурные действия и ошибки. |
| ux/ui-resilience.md | Условия проверки интерфейса при длинном тексте, разных размерах экрана, масштабе и других граничных случаях. Связывает устойчивость UI с наблюдаемым результатом и приёмкой. |