feature-tracelisted

# Feature trace The frontend/backend split means the answer to "where does this number come from" lives in a repo you are not currently in. A trace crosses that boundary once and writes it down, so the next person crosses it by reading. Trace **one concrete instance** — one button, one value, one request. Tracing a feature in general produces an architecture diagram; tracing one instance produces something you can act on. ## The path Follow it in order. At each hop, name the file and line, and state what the data looks like there — because the point at which the shape changes is usually the point you were looking for. **Split the two repos across two subagents.** Hops 1–4 live in the frontend, hops 5–6 in the backend, and they meet at one known value: the method and URL. Give the frontend agent the trigger to start from, and the backend agent that method and URL — then join their reports at the seam. Two repos' worth of file reading in one context is what makes a trace run out of room halfway through, and the join is exactly where the findings are anyway. When the URL is not yet known, run the frontend side first and dispatch the backend side once hop 4 has produced it. **1. The trigger.** The exact element and its handler. Find it by the i18n key or the accessible label rather than by guessing at component names. **2. The component layer.** Which component holds the handler, what it does locally, what it delegates. Note where the loading and error state is held. **3