performance-investigation
Diagnose performance before changing code. Cover CPU, RAM, GPU/Neural Engine, disk, network, battery, thermals, and perceived responsiveness before claiming that a performance fix is complete.
Procedure
- Read the target performance docs and relevant private/public validation constraints.
- Reproduce in the user-relevant mode when feasible.
- Instrument before optimizing: traces, profiler samples, render logs, CPU/RAM, network, polling, timers, and host diagnostics as applicable.
- Exercise realistic heavy workflows: large sessions, long scrolls, attachments, search, panels, terminals, browser/sidebar, composer, and streaming state.
- Correlate observed UI behavior with measurements.
- Classify causes as confirmed, probable, discarded, or not physically validated.
Required final report
Report these states separately:
- Hypotheses: the suspected causes before measurement.
- Static guard: code reading, static checks, and guard results.
- Compile/build: whether the affected code still builds or type-checks.
- Measurement taken: the trace, profile, runtime log, approved baseline, or
equivalent capture used as evidence.
- Confirmed cause: only causes proven by the cited measurement.
- Probable cause: likely causes when evidence is incomplete.
- Discarded causes: suspects checked and ruled out.
No measurement, no performance validated. If no real measurement was taken and
cited, close as partial validation, blocked, or EXTERNAL PENDING, not as
performance validated.
Constraints
- Do not optimize from code inspection alone unless reproduction is impossible and the limitation is reported.
- Do not send real prompts or use paid services for performance work without approval.
- Keep validation partial if the real mode could not be exercised.
1---2name: performance-investigation3description: Investigate latency, freezes, memory growth, hitches, dropped frames, or perceived slowness with reproduction and instrumentation before optimizing.4---56# performance-investigation78Diagnose performance before changing code. Cover CPU, RAM, GPU/Neural Engine, disk, network, battery, thermals, and perceived responsiveness before claiming that a performance fix is complete.910## Procedure11121. Read the target performance docs and relevant private/public validation constraints.132. Reproduce in the user-relevant mode when feasible.143. Instrument before optimizing: traces, profiler samples, render logs, CPU/RAM, network, polling, timers, and host diagnostics as applicable.154. Exercise realistic heavy workflows: large sessions, long scrolls, attachments, search, panels, terminals, browser/sidebar, composer, and streaming state.165. Correlate observed UI behavior with measurements.176. Classify causes as confirmed, probable, discarded, or not physically validated.1819## Required final report2021Report these states separately:2223- Hypotheses: the suspected causes before measurement.24- Static guard: code reading, static checks, and guard results.25- Compile/build: whether the affected code still builds or type-checks.26- Measurement taken: the trace, profile, runtime log, approved baseline, or27 equivalent capture used as evidence.28- Confirmed cause: only causes proven by the cited measurement.29- Probable cause: likely causes when evidence is incomplete.30- Discarded causes: suspects checked and ruled out.3132No measurement, no performance validated. If no real measurement was taken and33cited, close as partial validation, blocked, or `EXTERNAL PENDING`, not as34performance validated.3536## Constraints3738- Do not optimize from code inspection alone unless reproduction is impossible and the limitation is reported.39- Do not send real prompts or use paid services for performance work without approval.40- Keep validation partial if the real mode could not be exercised.
clawic