Software Development Flow

Software Development Flow implements one complete software change as independently accepted vertical units. It owns the full repository result—production code, tests, coverage, documentation, schemas and types, generated or configuration outputs, compatibility, and integration consequences—rather than splitting one lifecycle across several task workflows.

mcp__moira__start({
  action: "prepare",
  workflowId: "moira/software-development-flow",
  parentExecutionId: "none"
})
mcp__moira__start({ action: "execute", startAttemptId: "<Start attempt ID from prepare>" })

Lifecycle

The flow captures source-grounded requirements and authority, resolves one simple visual preference (disabled, screenshots, or html_report), creates and independently reviews an architecture-aware plan, and then treats that current plan as the sole source of each unit’s visual and user-approval policy. It prepares every unit from the real repository before mutation, implements complete vertical behavior with its tests, and runs producer completion before validation. Once the applicable checks converge, it updates affected permanent documentation before independent unit completeness review. A product defect discovered while documenting returns to implementation and the checks it invalidates.

screenshots captures and actually inspects the required states once. html_report reuses those same accepted images in a self-contained report, uploads it through Moira’s Artifact API, and sends the public URL through the current user’s configured communication channels; it never performs a second screenshot pass. Artifact upload failure blocks the unit. Missing channels or send failure at a reached notification node is non-blocking. Interactive plan, selected-unit, and final approvals receive attention notifications and wait in ordinary directives. Autonomous mode has no human-approval directives. Ending the whole run early is the exception and is not an approval: where a blocker cannot be cleared or a unit cannot close, the flow states what ending it now leaves incomplete and ends only on the user’s explicit confirmation, which autonomous mode never infers for itself.

Findings are classified as product, test/validation, evidence, documentation/projection, invalid criterion, or upstream plan/process defects. Product repair returns through producer completion. Verification-only or gate-local repair reruns only stale evidence. Mixed or invalid causes trigger quality-preserving replan rather than expanding implementation against a broken contract.

Every current-unit producer, validator, reviewer, repair role, checkpoint, and report role resolves its complete approved unit from plans/{{plan_revision}}/plan.md. This active revision remains authoritative after any replan; remembered wording and previous_plan_revision are not execution inputs. Only the five revision writers intentionally read both revisions: they preserve the historical source while writing the already-advanced current plan. Cross-revision final review may use origin-qualified historical evidence, but it does not replace the active plan contract.

When the originating request already authorizes a later caller-owned push, pull request, publication, release, or deployment, SDF records that intent through the session reminder API during intake. The write requires the current workflow-step revision but does not advance that revision or invalidate the presented Step attempt. The reminder is returned under Next requested actions on ordinary completion for both standalone and child runs. It never becomes a development-plan unit, changes vcs_commits_authorized, performs the effect, or grants new authority.

Runtime, browser, visual, integration, performance, and full-suite checks remain conditional on the feature and repository. Permanent documentation closes with its vertical unit. One unified final semantic review checks the complete result against the requirements, including cross-unit documentation; there is no separate documentation-only reconciliation. Finalization covers feature-wide validation, requirements coverage, factual reporting, and authority-bound local VCS reconciliation. A run ends in one of three ways, and each sends a best-effort notification through the configured user channels: it completes; it ends early on the user’s explicit confirmation; or it finishes the development work while local finalization stays blocked, which is reported as such rather than as a complete run.

Notifications

Intake persists the task name with fresh guards before completing. Only an authorized scope change renames it; optional execution_note (up to 120 characters) remains separate.

Configured channels receive English text with the flow/task heading, run link, goal, unit list, current result or blocker, and report links, without images or internal variable names. Revised plans are announced again. Interactive plan, selected-unit and final acceptance messages explain their choices; autonomous runs do not ask for those approvals.

Blocker gates wait for the person in both modes: repair the external condition and retry, or explicitly end the whole run. Blocked finalization additionally offers finishing without the final local commit. An interactive unit closure requests approval to revise the plan; an autonomous closure follows the confirmed cause or asks whether to end the run. Finishing, finishing without the commit and user-confirmed early termination are reported distinctly, with limitations, local commit state and follow-ups; terminal lists show no unit still in progress.

Final and unit HTML reports are self-contained Artifact API publications; URLs use the instance’s HTTP or HTTPS scheme. Missing channels refuse start unless a new prepare explicitly uses skipNotificationCheck: true; notification delivery failure does not stop the run.

Waiting for you

The steps where SDF waits for your decision are marked as waiting for you: confirming the requirements, the plan approval, a unit’s approval, the unit closure, the final acceptance, and the blocker steps (health check, runtime, broad and final checks, finalization). While a run stands on one, the run page and the run’s progress say waiting for you with what you are asked, and the message that asks ends with 🙋 waiting for you. The blocker steps wait for you in autonomous runs too — only you can change the external state or end the run — so they are marked in both modes; an autonomous run decides the unit closure itself and is not shown as waiting there. Where the flow sends its own message before the step, that message is the first notification; confirming the requirements has none, so Moira notifies you itself. If nobody answers for a day, Moira sends one reminder with a link to the run.

Execution progress

The process view follows the recorded route and current node, showing the plan, completed units and current work. Repair or replanning reopens the corresponding stage without invented execution state. Display data never changes routing or authority. See Process view.

When to use it

Use Software Development Flow for repository implementation of any size: its plan and conditional checks scale to the actual change while preserving one complete software lifecycle. Security or privacy boundaries, persistent data or migrations, breaking public contracts, multiple vertical units, unresolved architecture, and complex rollout or recovery require correspondingly stronger units and evidence inside the same flow. Quick Task and Robust Task do not replace a software lifecycle.

The SDF development plan may include explicitly authorized local commits or checkpoints. Push, pull-request creation or merge, publication, release, and deployment are caller or parent-process work and never development-plan units. Starting SDF does not authorize notification, production mutation, or administrative override; every side effect remains bounded by originating authority.

SDF declares no externally writable runtime variables. Agents may inspect its registry through session variables, but visual settings, VCS authority, plan cursors, and every other SDF variable remain read-only through the default-deny runtime policy.