Add durable orchestration and Task Capsule model for Memory Bank

[dapi]

Контекст

По итогам созвона о Code Property Graph и цифровых ролях нужно описать и постепенно внедрить в Memory Bank модель durable orchestration:

• цифровые роли с ограниченными входами, выходами и инструментами;
• декларативные workflow и допустимые handoff-переходы;
• Task Capsule для persisted state конкретной задачи;
• машинно проверяемые handoff-контракты;
• возобновление работы короткими сессиями без зависимости от полного chat context.

Разбор концепции:

• Статья в docs
• Исходный созвон на MyMeet.ai

Цель

Сделать так, чтобы незавершённую задачу можно было безопасно продолжить в новой сессии, на другой машине или другим агентом, прочитав только persisted state задачи и canonical owner-документы.

Целевая модель:

Issue / Task
  → Task Capsule
  → Workflow / stage
  → Digital Role
  → Artifacts + Evidence
  → Handoff Validator
  → next role или диагностируемая ошибка

Почему это Epic, а не одна подзадача

Инициатива затрагивает несколько независимых delivery units:

1. формат и ownership Task Capsule;
2. role contracts и границы автономии;
3. handoff protocol и validator;
4. session continuation;
5. разные минимальные workflow;
6. только после этого — возможный runtime-оркестратор.

Поэтому сначала нужен Epic/umbrella issue, а реализация должна идти отдельными feature/subissues.

Предлагаемые подзадачи

A. Зафиксировать Task Capsule contract

Определить минимальный persisted state:

• task_id;
• route и текущая stage;
• текущая и следующая роль;
• ссылки на canonical artifacts;
• completed/current/next action;
• assumptions;
• open risks;
• evidence log;
• stop conditions;
• причина последнего отклонённого handoff.

Определить, где Capsule живёт для Feature и Epic и кто владеет каждым полем. Не создавать вторую копию требований и статусов.

B. Определить role contract format

Описать входы, выходы, доступные tools/skills, запрещённые изменения, допустимые handoff-переходы и exit criteria для переиспользуемых ролей.

Роль выполняет один шаг, но не владеет workflow и не может обходить routing/lifecycle gates.

C. Спроектировать handoff protocol и validator

Определить проверяемый контракт перехода:

• обязательные артефакты;
• frontmatter/status;
• upstream owner links;
• required evidence;
• соответствие выбранному flow;
• stop conditions.

Ошибка должна иметь структурированную диагностику и next action.

D. Добавить session continuation contract

Сделать так, чтобы новая сессия стартовала по Capsule, canonical owner-документам, continuation priming inputs, ближайшим checks и next action, без обязательного чтения полного transcript.

E. Развести минимальные workflow

Зафиксировать отдельные маршруты для Small Change, Bug Fix, Research, Feature, Epic и Refactoring. Не прогонять все задачи через один длинный pipeline.

F. Сделать файловый прототип оркестрации

Начать без Temporal:

• состояние в feature/epic package и session handoff;
• Git как durable storage;
• воспроизводимая validator-команда;
• registry активных задач только как projection/index.

G. Принять решение о runtime-оркестраторе

После файлового прототипа оценить необходимость Temporal или аналога для retries/timers, external waits, parallel roles, queues и automatic resume.

Не входит в scope

• превращение всех ролей в автономных агентов;
• создание центрального реестра, дублирующего canonical documents;
• внедрение Temporal до проверки файловой модели;
• изменение существующих Feature/Epic lifecycle без отдельного decision record;
• перенос project-specific деталей в generic template/memory-bank/.

Связанные canonical документы

• Task Routing
• Feature Flow
• Epic Flow
• Session Handoff template
• Lifecycle Protocol template
• Memory Bank usage model

Acceptance criteria

• Статья опубликована в docs/ и доступна из README.
• Для Feature и Epic определены Task Capsule и ownership её полей.
• Описан role contract format.
• Описан handoff validator и диагностический output.
• Новая сессия продолжает задачу без полного transcript.
• Минимальные workflow для разных типов задач не смешаны.
• Registry/projector не становится вторым SSoT.
• После файлового прототипа принято отдельное решение о runtime-оркестраторе.

Validation

• rg --files template
• ruby tools/validate-priming-manifests.rb template/memory-bank
• memory-bank-cli lint --scope-root template/memory-bank --entrypoint template/memory-bank/README.md
• memory-bank-cli doctor --profile template
• git diff --check