Summary
Workflow repair methodology is the cross-cutting rule for turning failures into state. A failure should become an issue, pause, retry candidate, command result, or review task depending on what can be safely automated.
Reader Question
How do failures become issues, cases, retry policies, command state, DAG repair, and operator-visible recovery?
Methodology
The platform first classifies failure. Business ambiguity becomes an issue or review task. Retryable execution failure can become a DAG repair attempt. Manual blockers pause automation until an operator resolves context. External commands record payloads and responses so retry decisions are idempotent.
Workflow services provide cases, issues, events, locks, commands, reviews, and read models. DAG repair services add task-level policy, context extraction, retry, resume, and auto-resume behavior.
Boundaries
Jobs should record or delegate failure state. Review surfaces expose repair. Services own state transitions. Exceptions remain for unrecoverable system or programmer errors, not ordinary business ambiguity.
Tradeoffs
Repair methodology introduces explicit state even when a simple retry might work. That is the cost of auditability and resumability across long-running operational workflows.