docs: add per-process priming manifests

[dapi]

Что изменено

• списки priming inputs вынесены из process-документов в отдельные YAML-манифесты;
• process-документы указывают manifest и stage keys, сохраняя lifecycle, gates и stop conditions;
• manifests содержат только пути и bounded masks, без дублирующих пояснений;
• resolved manifest удаляет уже прочитанные paths, поэтому corpus masks не перечитывают process index;
• вложенные Priming Inputs считаются данными и не запускают другой process manifest;
• PRD и ADR creation/update читают полный существующий corpus;
• Feature Bootstrap / Brief обязательно читает весь memory-bank/prd/*.md corpus;
• добавлены YAML-шаблон для project-specific процессов и CI-валидатор schema/paths;
• task-specific Implementation Priming остаётся в implementation plan.

Refs #85. Зависит от #84.

Проверки

• ruby -c tools/validate-priming-manifests.rb
• ruby tools/validate-priming-manifests.rb template/memory-bank
• negative validator smoke test с отсутствующим path
• rg --files template
• memory-bank-cli lint --scope-root template/memory-bank --entrypoint template/memory-bank/README.md
• memory-bank-cli doctor --profile template
• git diff --check

[dapi]

Какие у нас предусмотрены механизмы расширения списка файлов необходимых для рпаймеринга по мере развития memory-bank-а в проекте?

[dapi]

Список не является единым фиксированным перечнем. Он расширяется на трёх уровнях:

1. Каждый flow владеет своим versioned YAML manifest в memory-bank/flows/priming/. При появлении нового устойчиво необходимого документа его добавляют только в релевантный source set и stage соответствующего процесса, а не во все flows.
2. Для групп документов manifest допускает bounded mask. Перед чтением она разворачивается в упорядоченный exact input manifest для конкретной ревизии репозитория; уже прочитанные пути из него исключаются. Поэтому новые документы, попадающие под правило, будут подхвачены на следующем запуске нужной стадии без ручного дублирования.
3. Task-specific implementation/test paths не пытаются угадать в generic manifest: их добавляет task owner. Для Feature отдельный Implementation Priming в плане фиксирует exact список перед первым write.

Изменения в manifests проверяются validate-priming-manifests.rb: schema и все явные пути должны быть валидны. Таким образом, эволюция memory-bank-а требует локального обновления canonical manifest владельца, остаётся reviewable и не превращает priming в чтение всего каталога.

[dapi]

ok

[dapi]

Нет, не всегда. governance.yaml выполняется только когда после routing выбран процесс governance — то есть для работы с governance-ядром Memory Bank.

Обычный flow (Feature, Bug Fix, Incident и т. п.) исполняет только свой manifest; ссылка Priming Inputs, встреченная внутри прочитанного документа, не запускает вложенный manifest автоматически. Это прямо зафиксировано в context-priming contract.

В этом репозитории есть отдельное, более строгое project-level правило в AGENTS.md: перед substantial delivery нужно прочитать Memory Bank README, DNA README и routing. Оно частично пересекается с этим набором, но это не означает, что generic governance.yaml становится universal priming package для любого downstream-проекта.

[dapi]

В текущей версии это как раз не определено надёжно: Feature / PRD / ADR manifests не включают DNA-файлы, а governance.yaml по контракту исполняется только для governance-route. Поэтому предыдущая формулировка создаёт пробел.

Для создания любого governed артефакта общий baseline должен включать пять первоисточников DNA:

• dna/principles.md — базовые правила работы с документацией;
• dna/governance.md — canonical owner, SSoT и derived_from;
• dna/frontmatter.md — обязательная схема и status;
• dna/lifecycle.md — допустимые состояния и правила изменения;
• dna/cross-references.md — навигация и двусторонние ссылки.

dna/README.md — удобная точка входа, но не заменяет эти источники. Следовательно, корректный design — выделить этот набор как universal governance baseline, выполняемый до выбранного process manifest, а не считать governance.yaml универсальным при его нынешнем scope. Это нужно поправить в PR.