build

Devora Build

User input

$ARGUMENTS

1. Run devora status --json, devora govern status --json, devora govern drift --json, devora change requirement status --json, and devora quality status --json. Verify that every Governance scope recorded by the active Change is current and complete, its captured company policies and exceptions still match, selected Skills remain active, and the requirement baseline is confirmed with no source drift; resolve blockers before Build. Then run devora change setup build --json. Read change.md, optional tasks.md, relevant project context and Skills, the generated validation matrix, and the real target files.
2. Verify that material technical and business controls from Design can be honored. If implementation evidence invalidates a decision or a material source changes, register the new evidence, return to Design, resolve the clarification, and reconfirm the baseline before continuing Build.
3. Implement in dependency order and stay within allowed paths. Never modify protected paths or broaden scope to clean up a legacy exception. Pre-existing baseline work is input, not this Change's output.
4. Run devora change audit --json during implementation. Resolve unexpected or protected-path changes before proceeding. If the user genuinely expands scope, use devora change expand --reason <reason>; it preserves the original baseline.
5. Execute every required governance and type-policy validation. Prefer devora quality run <id> --command <quoted-command> --timeout <seconds> --provider <runner> --environment <environment> --target <code-path> --json for bounded local commands so complete output is retained automatically; classify a non-zero result as blocked only with concrete environment evidence. Record manual and external evidence explicitly with devora change validate <id> --result <result> --execution <automatic|manual|external> --provider <tool-or-reviewer> --target <code-path> --risk <scope/finding> --control <scope/control> --evidence <observation> --artifact <report-or-url> --command <command> --environment <environment> --json, omitting fields that do not apply. Use blocked or not_run for unavailable environments—never passed. External passed/failed results require a provider, and local report references must exist. The evidence package is generated automatically.
6. Keep change.md and tasks current with behavior, deviations, residual risk, and recovery details. For a cross-repository Change, register the producer/consumers and write a versioned devora change contract; keep it proposed until parties confirm it. Add a handoff only for an independently operating consumer.
7. Run devora change complete build --json; it rejects stale Skills, scope violations, and failed, blocked, or pending required checks. A high-risk Change is not complete merely because unit tests pass. Otherwise leave Build active with one exact resume action.