trace-the-flow

Trace the flow

Walking one operation from end to end.

Why this exists

repo-recon tells you where things are. It does not tell you what actually happens, and in a layered enterprise system those are very different questions. The call path for "customer places an order" typically crosses eight files, two process boundaries, a transaction, a message queue, and three error handlers — none of which is visible from any single file.

The specific danger this skill addresses is plausible reconstruction. Reading a controller and a service, it's easy to assemble a mental model that is coherent, confident, and wrong — because the actual dispatch goes through a framework-configured interceptor, or an event listener registered in XML, or a strategy selected by a config value. That model then becomes the basis for a change, and the change breaks something invisible.

A trace with a citation at every hop is the antidote. Where you can't establish a hop, the trace says so rather than bridging the gap with a reasonable guess.

When this applies

• Before changing anything on a request path you haven't walked
• "What happens when a customer does X?"
• Behavior you can't explain from reading one file
• Debugging where the symptom and the cause are in different components
• Understanding an integration before modifying it

When it doesn't

• You need breadth, not depth — run repo-recon
• The system is small enough to read outright
• You need the data model rather than the control flow — that's data-archaeology
• You need to know why the code is shaped this way — that's git-archaeology

Prerequisites

• .fde/02-system-map.md — you need to know the entry points before following one
• Ideally .fde/01-environment.md — being able to run the flow turns [inferred] hops into [confirmed] ones cheaply

Procedure

1. Pick exactly one operation, named in business terms

Not "the OrderController" — "a customer places an order with a saved card."