Code Flow Analysis

Code Flow Analysis

Critical rules

• Trace before implementing non-trivial changes. No abstractions like "the handler" — use file:line.
• Diagrams stay short (5-15 lines). Show fn(args, deps), Result ok/err, workflow steps, error mark.
• Confirm understanding with the user before changing code.
• Red flags: fix without file:line; adding retry/validation/cache without checking upstream; changing internals without callers; assuming Result is ok.
• Before drawing examples or pattern-specific traces, read references/examples.md.

Workflow

1. Trace: entry point, fn(args, deps) chain, error/change location, workflow steps, Result propagation — all with file:line.
2. Draw a concise execution diagram (see examples).
3. Verify: "Here's the flow: [diagram]. Error/change at [file:line] when [condition]. Correct?" Wait for confirmation.
4. Only then implement (feeds debugging-methodology / tdd-workflow).

Resources

• references/examples.md — diagram shape, Result/workflow traces, bug/feature examples, rationalizations. Read before tracing non-trivial flows.

Validation

• Entry and full call chain with file:line
• Result propagation and error/change location marked
• Diagram concise (5-15 lines)
• User confirmed understanding before code changes

Constraints

• Skip for typos, formatting, docs-only.
• Related: debugging-methodology, tdd-workflow, result-types, fn-args-deps, resilience, validation-boundary, confidence-levels.