brse-impact-tracelisted

# BrSE Impact Trace ## Overview Ground impact and feasibility answers in the actual codebase before reporting to a customer or PM. **Core principle:** No claim about impact without a file path. Memory and ticket text are not evidence. ## When To Use - Customer or PM asks "Does change X affect Y?" - Dev asks whether a proposed change touches shared middleware, permission, or auth. - BrSE must answer a feasibility question that depends on current architecture, not assumed architecture. - A spec says one thing and source behavior may say another. ## When NOT To Use - Question is purely about business policy, not code (use `brse-requirement-clarifier`). - Customer wants a high-level estimate before any source is available — say so, do not invent. - The repository is not accessible from this session — declare the limitation, do not guess. ## Workflow 1. Start from the user-facing entry point: URL, screen, menu, button, API, batch command, task ID, or spec section. 2. Find the closest local source first. Prefer repo-local files over remote GitHub unless the user explicitly asks for remote. 3. Trace in this order when applicable: - UI route/component - state/store/context - API client/request - backend route/controller/service - permission/auth/session logic - model/schema/migration/seed/init data - batch/job/queue/log side effects 4. Record exact evidence with file paths and line numbers when possible. 5. Separate confirmed facts from likely impact and