ripwire-perf-target

# Performance targeting with ripwire > Nearest neighbours: > • Repo-wide quality/health sweep (not perf-specific) → **ripwire-fresh-eyes** (also uses --hotspots). > • Finding a specific BUG, not a slow path → **ripwire-find-bug**. Trigger: a representative benchmark, flame graph, trace, or profiler has identified a slow operation, file, stack, or symbol and you need to understand where a safe optimization belongs. If you have no measurement yet, create the smallest representative benchmark/profile first; ripwire cannot infer runtime cost from source shape. `<dir>` = repo root. 1. **Pin the measured evidence** — record the workload, baseline, profiler/trace result, and the symbol or subsystem it implicates. Keep the same workload for the after measurement. 2. **Navigate the measured surface** — `ripwire <dir> --for="measured operation or symbol" --detail=3`, then `--callers=SYM`, `--callees=SYM`, or `--around=SYM` as needed. This turns runtime evidence into a bounded source-reading set without pretending the graph measured execution. 3. **Maintenance/change-risk context** — `ripwire <dir> --hotspots` Output: `<hotspots>` ranked by `score = churn × ccx` (churn = git commit frequency over 12mo; ccx = cognitive complexity). The `top=` attribute names the highest-complexity function in each file. High-score files are frequently changed and structurally complex: useful evidence about optimization risk and validation scope, but structural evidence, not run...