docs: систематизировать требования и трассировку до кода в Feature Flow

[dapi]

Контекст

В Feature Flow уже есть REQ-*, MET-*, CON-*, EC-*, SC-*, CHK-* и другие идентификаторы, но не зафиксированы:

• минимальный набор основных видов требований с точки зрения системной инженерии;
• граница между функциональными требованиями, качественными/нефункциональными требованиями, ограничениями, интерфейсными, эксплуатационными, safety/security и regulatory requirements;
• правила классификации требования и его размещения по уровням brief.md, design.md, implementation-plan.md и upstream-документам;
• обязательность требований для разных типов delivery-unit;
• единая связь требования с verification/validation method и evidence;
• необходимость пересмотра существующих мнемокодов и обратная совместимость со старыми пакетами.

Цель

Сделать типы требований явными, проверяемыми и трассируемыми в процессе feature delivery, не превращая каждый feature package в избыточную форму.

Что исследовать и решить

1. Зафиксировать компактную taxonomy основных видов требований на базе системной инженерии.
2. Определить canonical owner для каждого вида требования:
   • stakeholder/product;
   • system/feature;
   • functional;
   • performance/quality;
   • interface/data;
   • safety/security;
   • operational;
   • regulatory/compliance;
   • constraints;
   • verification/acceptance.
3. Определить, какие виды обязательны всегда, а какие включаются по trigger/risk profile.
4. Проверить текущие идентификаторы Feature Flow (REQ-*, MET-*, CON-*, EC-*, SC-*, CHK-*, EVID-*, solution IDs) на:
   • полноту;
   • пересечения и неоднозначность;
   • соответствие ownership boundaries;
   • удобство трассировки;
   • необходимость переименования, разделения или добавления мнемокодов.
5. Решить, должны ли нефункциональные требования оставаться в MET-*/CON-*/EC-* или получить отдельную явную taxonomy.
6. Определить минимальные поля требования: формулировка, rationale/source, priority, owner, measurable threshold, verification method, acceptance/evidence reference.
7. Обновить при необходимости:
   • flows/feature.md;
   • flows/templates/feature/brief.md;
   • flows/templates/feature/design.md;
   • flows/templates/feature/implementation-plan.md;
   • flows/feature-artifact-catalog.md;
   • testing/validation guidance;
   • priming manifests и lint/doctor checks, если потребуется машинная проверка.
8. Описать миграцию существующих feature packages и правило для новых пакетов.

Критерии готовности

• В canonical documentation есть taxonomy требований и определения терминов.
• Для каждого типа указаны owner, допустимый артефакт и verification/validation method.
• Есть компактная матрица классификации с примерами и anti-examples.
• Зафиксировано решение по сохранению или изменению текущих mnemonic IDs.
• brief.md позволяет связать каждый обязательный requirement с acceptance scenario, check и evidence.
• Для нефункциональных требований определены measurable criteria и способ проверки.
• Обязательные и conditional requirement classes отражены в соответствующих lifecycle gates.
• Existing feature packages не получают silent breaking change; описан migration/backward-compatibility path.
• Пройдены релевантные repository checks: priming manifests validation, template lint, doctor и git diff --check.

Не входит

• Реализация прикладной функциональности.
• Создание полноценного отдельного requirements-management продукта или базы данных.
• Обязательное добавление отдельного документа для каждого вида требований.
• Переписывание всех существующих feature packages без отдельного migration scope.

Вопросы для решения

• Нужны ли отдельные ID для FR-* и NFR-*, или текущие problem-space IDs достаточно выразительны?
• Где проходит граница между requirement, constraint, design invariant и acceptance criterion?
• Должна ли validation profile определять обязательные requirement classes автоматически?
• Как проверять наличие requirement classes без превращения lint в domain-specific rules engine?

[dapi]

Review: что нужно усилить

Исходная задача хорошая, но без дополнительных критериев можно получить только словарь мнемокодов и traceability до CHK-*, не до delivered code. Для заявленной цели добавлены следующие обязательные результаты.

1. Покрытие видов требований

Нужна не просто taxonomy, а applicability matrix минимум с колонками:

• requirement class и точное определение;
• уровень: stakeholder/product, system, feature, subsystem/component;
• canonical owner и допустимый артефакт;
• mandatory / conditional / not applicable;
• trigger включения;
• measurable statement / threshold, если применимо;
• verification или validation method;
• required evidence;
• пример и anti-example.

Минимальный baseline должен покрывать: stakeholder/product, functional, performance, quality attributes, interface, data, security, safety, regulatory/compliance, operational, compatibility, deployment/rollout, constraints и verification/acceptance. Для каждого класса должно быть явно указано, почему он применим или не применим.

2. Трассировка до кода

Нужен обязательный trace chain:

upstream source → requirement ID → acceptance/exit criterion → selected solution/contract → exact implementation path + symbol/config → implementation step → test/check → evidence → review/CI result

Трассировка до кода должна использовать конкретные repository-relative paths и symbols/sections, а не только названия модулей, glob или общие категории. Для runtime/config/infrastructure changes нужно также указывать deployment/config surface.

3. Двусторонняя полнота

Проверка должна быть в обе стороны:

• каждый applicable requirement имеет implementation target, verification и evidence;
• каждый изменённый implementation/test surface имеет canonical requirement или явно зафиксированную supporting/necessary change;
• нет orphan requirements, dangling references, duplicate canonical owners и accepted design facts без realization target;
• derived/support documents не могут незаметно вводить новые требования.

4. Граница requirement/design/acceptance

Нужно явно закрепить distinction между requirement, goal/metric, assumption, constraint, design decision, invariant, contract, acceptance criterion и evidence. Иначе новые мнемокоды только увеличат неоднозначность.

5. Машинно проверяемый минимум

Рассмотреть lint/doctor checks для:

• уникальности и формата IDs;
• разрешимости ссылок и owner-а каждого ID;
• покрытия каждого applicable requirement acceptance/check/evidence/code target цепочкой;
• отсутствия dangling/orphan trace links;
• согласованности requirement class с validation profile;
• наличия exact paths/symbols в execution grounding.

Проверка может быть минимальной и структурной; не нужен полноценный requirements-management engine.

Рекомендуемое усиление Definition of Done

• Есть applicability matrix с baseline requirement classes, triggers и N/A rationale.
• Каждый applicable requirement имеет source, owner, priority, measurable wording, verification method и evidence contract.
• Есть canonical traceability matrix от upstream source до exact code/config path, test и CI evidence.
• Трассировка проверяется в обе стороны и выявляет orphan/dangling links.
• Для каждого изменённого code/test/config surface есть requirement или явная supporting rationale.
• Есть минимум по одному worked example для user-facing, contract/integration и infrastructure/operations feature.
• Lint/doctor или другой repository-approved check проверяет структурный traceability minimum.
• Миграция существующих feature packages сохраняет traceability без silent gaps.

Отдельно: не стоит делать все классы обязательными для каждой feature. Максимальное покрытие достигается обязательной applicability decision для каждого класса, а не заполнением нерелевантных разделов.

[dapi]

Delivery checkpoint: the complete documentation change and local validation evidence are prepared in the GH-98 worktree, but this run is in the restricted delivery profile (detached HEAD and no .git write capability). Commit, push, branch creation, and PR creation cannot be performed here. Resume this same run in a full-delivery profile with Git write capability; the remaining steps are non-author Plan Ready artifact review, commit/push on codex/gh-98, PR creation, and the required issue label update.