Software Development Flow

Software Development Flow реализует одно полное программное изменение как независимо принимаемые вертикальные units. Он владеет всем результатом репозитория — production code, тестами, coverage, документацией, schemas/types, generated/config outputs, compatibility и integration consequences — вместо разделения одного lifecycle между несколькими task workflows.

mcp__moira__start({
  action: "prepare",
  workflowId: "moira/software-development-flow",
  parentExecutionId: "none"
})
mcp__moira__start({ action: "execute", startAttemptId: "<ID попытки запуска из prepare>" })

Lifecycle

Flow фиксирует source-grounded требования и полномочия, определяет одну простую visual preference (disabled, screenshots или html_report), создаёт и независимо проверяет architecture-aware план, после чего именно текущий план становится единственным источником visual и user-approval policy каждого unit. Flow готовит каждый unit по реальному репозиторию до мутации, реализует полное вертикальное поведение и запускает fresh producer completion до deterministic validation и independent semantic review. Документация и тесты являются частью production, а не поздней уборкой.

Каждый execution также показывает постоянно видимое представление процесса из пятнадцати блоков: Intake, Project health, Plan and plan review, Plan approval and activation, Implement a unit, Unit validation gates, Broad validation and documentation, Independent completeness review, Unit review with the user, Checkpoint and advance, Feature-wide validation, Final review and report, Replan, Finalize и Stopped. Каждая нода принадлежит одному блоку, каждая связь, выходящая из блока, подписана, а каждый возврат объясняет причину и условие выхода, поэтому переходы, циклы и блоки-хабы выводятся из исполняемого графа. Активный блок следует за текущей primary workflow node, поэтому repair, replan и обычный multi-unit loop из checkpoint снова открывают соответствующий ранний блок без отдельных status variables. Та же shared model формирует PNG для существующих авторизованных user notifications для plan/report/approval/completion; stopped notification остаётся текстовым, потому что у досрочно завершённого запуска нет одной правдивой фазы. Progress не меняет routing SDF или его границы полномочий.

Стабильные inactive labels остаются короткими. Пока текущей является точная implementation, validation, independent review, repair или checkpoint node, её active-only label добавляет авторитетные unit, total и iteration для этой роли. Plan/replan nodes не используют stale unit counters.

screenshots один раз снимает и действительно просматривает необходимые состояния. html_report переиспользует эти же принятые изображения в self-contained отчёте, загружает его через Moira Artifact API и отправляет публичный URL через настроенные каналы связи текущего пользователя; второй screenshot pass не выполняется. Сбой Artifact upload блокирует unit. Отсутствие настроенных каналов или ошибка отправки в достигнутой notification node не блокируют работу. Interactive approval плана, выбранных units и финального результата получает attention notification и ждёт решения в обычной директиве. В autonomous mode human-approval directives отсутствуют. Исключение — досрочное завершение всего запуска, и это не approval: когда блокер не снимается или unit не может быть закрыт, flow сообщает, что именно останется незавершённым, и завершает запуск только по явному подтверждению пользователя, которое autonomous mode никогда не выводит сам.

Findings классифицируются как product, test/validation, evidence, documentation/projection, invalid criterion или upstream plan/process defects. Product repair возвращается через producer completion. Verification-only и gate-local repair повторяют только устаревшие evidence. Mixed или invalid causes приводят к quality-preserving replan, а не к расширению реализации по сломанному контракту.

Каждый producer, validator, reviewer, repair role, checkpoint и report role текущего unit получает полный утверждённый unit из plans/{{plan_revision}}/plan.md. Эта активная ревизия остаётся источником истины после любого replan; запомненная формулировка и previous_plan_revision не являются входами исполнения. Только пять revision writers намеренно читают обе ревизии: они сохраняют исторический источник и записывают уже увеличенную текущую ревизию. Финальное cross-revision review может использовать исторические evidence с явным указанием ревизии происхождения, но не заменяет ими контракт активного плана.

Если исходный запрос уже разрешает последующий caller-owned push, pull request, publication, release или deployment, SDF во время intake сохраняет это намерение через session reminder API текущего execution. Запись требует текущую ревизию шага workflow, но не увеличивает её и не делает предъявленную попытку шага недействительной. При обычном завершении standalone и child запусков reminder возвращается в Next requested actions. Он не становится unit плана разработки, не меняет vcs_commits_authorized, не выполняет действие и не даёт новых полномочий.

Runtime, browser, visual, integration, performance и full-suite checks остаются условными для конкретной фичи и репозитория. Permanent documentation закрывается вместе со своим vertical unit; финальная reconciliation продолжает проверять cross-unit truth и независимо ревьюит только изменённую либо ранее не покрытую документацию. Финальный suffix включает feature-wide validation, semantic review, requirements coverage, factual report и локальную VCS reconciliation в пределах полномочий. Запуск завершается одним из трёх способов, и каждый отправляет best-effort уведомление через настроенные каналы пользователя: он завершается полностью; он завершается досрочно по явному подтверждению пользователя; либо разработка доведена до конца, а локальная финализация осталась заблокированной — и это сообщается именно так, а не как полностью завершённый запуск.

Когда использовать

Используйте Software Development Flow для реализации в репозитории любого размера: его план и условные проверки масштабируются под фактическое изменение, сохраняя единый полный software lifecycle. Границы security/privacy, постоянные данные и migrations, breaking public contracts, несколько vertical units, неразрешённая архитектура и сложный rollout/recovery требуют более сильных units и evidence внутри этого же flow. Quick Task и Robust Task не заменяют software lifecycle.

Development-plan SDF может включать явно разрешённые локальные commits или checkpoints. Push, создание или merge pull request, publication, release и deployment являются работой caller или parent process и никогда не становятся development-plan units. Запуск SDF не разрешает notification, production mutation или administrative override; любой side effect остаётся ограничен originating authority.

SDF не объявляет externally writable runtime variables. Агент может просматривать registry через session variables, но visual settings, VCS authority, plan cursors и все остальные переменные SDF остаются read-only благодаря default-deny runtime policy.