ce-probe-perflisted

# Probe Perf **Invocation input:** Target to profile (and optional --type / --against): $ARGUMENTS Measure how a running target *performs* — and where it spends its time. This is the **dynamic** performance tool: it exercises a live instance or binary. For *static*, code-level review of inefficiency, use `/core-engineering:ce-review`'s **Performance lens** (the boundary below). Sister to `/core-engineering:ce-probe-sec` and `/core-engineering:ce-ux-audit`: same evidence-bound finding *discipline* (every finding cited, triaged, escalated — though each tool's finding fields and evidence-state vocabulary differ), same consent-first discipline, same escalate-up chain. **Not a benchmark suite or an SLA certification** — a first cut that surfaces measurements and hotspots as leads; mature load generators and profilers do the deep work where installed. ## Boundary — dynamic vs static - **`/core-engineering:ce-probe-perf`** (this tool) — *dynamic*: measures a running target under real load. - **`/core-engineering:ce-review` Performance lens** — *static*: reads code for structural inefficiency (algorithmic complexity, N+1, unbounded loads) without running it. They mirror security's split (`/core-engineering:ce-probe-sec` dynamic · `/core-engineering:ce-review` Security lens static). A static lens *suspects*; `/core-engineering:ce-probe-perf` *quantifies* and finds what reading can't (real latency under concurrency). Only `/core-engineering:ce-probe-perf` can prove a numeric N