devflow-loop

devflow-loop

Run the active flow end-to-end without leaving the session. The Stop-Hook (DF-405) holds you in until the backend's flowGate service confirms every condition is green. Discipline-tokens are emitted explicitly per state, and knowledge-resolution is callable in review (DF-408) so the pending_drafts_resolved gate never traps you in a catch-22.

This command is the orchestrator. It does NOT replace the per-state skills (devflow-planning, devflow-executing, devflow-reviewing, …) — it sequences them.

Foundation it relies on

• DF-405 — Stop-Hook returns exit 2 + precise stderr-reinject if you try to end the session in a non-wait state. This makes the loop self-correcting.
• DF-323 — pre-flow-update-self-approval.js hook surfaces required-skills automatically on every flow_update attempt.
• DF-408 — KNOWLEDGE_RESOLUTION_TOOLS (knowledge_draft_accept/reject, knowledge_check_resolve, intent_resolve) callable in approval + review. No backward-transition workaround needed.
• pipelineOrchestrator.HARDCODED_REQUIRED_SKILLS — single source of truth for which discipline-tokens each transition needs.

Argument Resolution

• $1 is optional flowId. Resolve:
  • Starts with DF- → use as-is
  • Purely numeric (e.g. 214) → prefix DF- (DF-214)
  • Otherwise → pass through (assume full flow id like 1779181904709-l4pfwtyvu)
  • If missing → read .devflow-active in the repo root and use its flowId field
• --max-iterations N → integer, default 40
• --verify "<shell-cmd>" → shell command to run before review. Its stdout/stderr is captured into testingInstructions field. If absent, use the project's verify script if it exists in package.json, otherwise skip and note in testingInstructions that verification was manual.

Iron Laws

• Only use real MCP tools. devflow_init, flow_get, flow_update, devflow_token_emit, devflow_tokens_list, knowledge_check_flow, knowledge_check_resolve, knowledge_draft_create, knowledge_draft_accept, knowledge_draft_reject, task_create, task_update, task_list, planning_context, wiki_get_briefing, pending_work, flow_upload. Never invent tool names.
• No "should work" claims. Every acceptance criterion gets evidence from the --verify command's actual output. Capture stdout verbatim into testingInstructions.
• Never hand-fabricate tokens. All discipline-tokens come from devflow_token_emit({flowId, skillName, evidence}). The backend signs them; the unsigned token is returned once.
• Respect the gate. A 409 response carries gate.failures[] with named conditions (e.g. plan-required, tasks-required, agent-summary, testing-instructions, adr-compliance-clean, pr-state-consistent). Fix the named field, then retry the SAME transition. Never invent fields the gate didn't mention.
• Stop-Hook does the policing. You cannot legitimately end the session in idea / planning / ready / in_progress. If you think you're done, transition forward — the Stop-Hook will reject premature exit otherwise (DEVFLOW_STOP_HOOK_SOFT=1 is the only override and is gated).