thalarch-performancelisted

# Thalarch Performance Performance work starts with a metric and comparable evidence, not with code that merely looks faster. ## 1. Classify the scenario before measuring For runtime performance establish: - user/business-visible metric; - workload/input distribution; - environment/hardware/runtime; - baseline and target/regression threshold; - correctness constraints that optimization must preserve. For **build/tooling performance**, additionally classify: - local developer loop vs CI; - debug/development vs release/distribution artifact; - cold vs warm vs incremental vs no-op build; - exact command the user actually waits for; - dominant phase/task from logs/profile/build scan; - cache state and whether dependencies/toolchains were already present. Never compare a cold build to a warm build and call the difference an optimization. ## 2. Find the bottleneck Use the strongest available evidence for the stack: - profiler/flame graph; - tracing; - benchmark; - query plan; - allocation/GC profile; - browser/device performance trace; - application metrics; - build scan/profile/task timing; - compiler/build reports; - controlled instrumentation. Do not optimize a guessed bottleneck merely because it is visually obvious in source. If execution is unavailable, state that the diagnosis is **static/log-based** and keep runtime claims `UNVERIFIED`. ## 3. Same-workload rule A performance result is comparable only when the meaningful conditions match. Record the exact base