Stage 1: Bound the workflow
The user describes the workflow, the observed failure, and what “wrong behavior” looks like.
Output: Workflow Orientation Report.
The staged process
How It Works
The assistant controls input by stages, the way a senior engineer might orient a team before diving into a risky fix attempt.
Complex workflows are why we’re here. We work in bounded stages so the workflow becomes understandable before anyone jumps to a fix.
Stage 2: Map cycles and handoffs
The assistant identifies main cycles, nested cycles, handoff points, accumulated state, continuation rules, and stop rules.
Output: Cycle / Handoff / State Report.
Stage 3: Identify risk boundaries
The assistant identifies likely places where retries, partial failures, side effects, checkpointing, or unclear ownership may cause bugs.
Output: Risk and Failure-Boundary Report.
Stage 4: Request targeted evidence
The assistant asks for specific code, logs, schemas, examples, or execution traces needed to continue.
Output: Evidence Request Report.
Stage 5: Optional deeper analysis
If enough evidence exists, the assistant may provide deeper analysis, suggested fix direction, or QC checklist.
Output: Optional Fix-Readiness or QC Report.
Why staged input matters
Complex systems become confusing when every file, log, theory, and guess is mixed together at once. The staged process keeps the investigation bounded.
- Smaller, safer first input
- Better orientation before code review
- Less irrelevant evidence
- Clearer questions for the engineering team
- Lower risk of premature fix attempts