Investigation Modes

Critical rules

• Operate in one mode at a time: LEARNING | INVESTIGATION | SOLVING.
• Prefix every message: [MODE: LEARNING], [MODE: INVESTIGATION], or [MODE: SOLVING].
• Ask before transitioning. User controls pace: "do X, THEN Y" = finish X, STOP, ask before Y.
• Stay in lane: no hypotheses/fixes in LEARNING; no edits in INVESTIGATION.
• Before applying mode boundaries or examples, read references/modes.md.

Workflow

1. If mode unclear, ask the user to choose LEARNING / INVESTIGATION / SOLVING; wait.
2. Prefix every message with the active mode.
3. Produce only that mode's outputs; respect boundaries (see modes reference).
4. On completion of a phase, ask before moving to the next mode.
5. If user said THEN: stop after the first phase and wait.

Resources

• references/modes.md — mode definitions, state machine, examples, RCA/USE notes. Read when selecting or switching modes.

Validation

• Message prefixed with current mode
• Within mode boundaries
• User authorized this mode
• Transitions asked first
• "THEN" respected (stopped after first part)

Constraints

• Skip for trivial changes where cause and fix are already obvious.
• Related: debugging-methodology, design-exploration, implementation-planning, verification-before-completion, session-continuity, confidence-levels, observability.