but-performance-tests

Source excerpt starting at line 1.

1---2name: but-performance-tests3description: Use when creating, changing, running, or debugging shell-based `but` CLI performance scenarios under `crates/but/tests/performance`, including Hyperfine runs, fixture setup, setup-to-test state, and output inspection.4---5 6# `but` CLI performance tests7 8Read [performance framework documentation](../../../crates/but/tests/performance/README.md)9completely before answering questions or changing performance scenarios. Inspect nearby10scenarios and current shared helpers as applicable; README is canonical source for11framework behavior, commands, helper APIs, and debugging options.12 13## Workflow for changes14 151. Confirm requested operation and timing boundary.162. Inspect closest existing scenarios plus `lib.sh` and `run.sh`.173. Add or update only scenario's `setup.sh` and `test.sh` unless shared behavior is18   genuinely required.194. Prefer real, representative GitButler repository state over toy data.205. Keep setup, validation, and ID discovery outside timed operation.216. Reuse documented helpers instead of creating parallel fixture, state, output, or22   timing mechanisms.237. List every scenario in top-level performance README's included-scenario list, and24   update its entry when materially changing scenario.258. Run README's shell validation and short single-scenario benchmark.26 27For usage or debugging questions, answer from current README and scripts. Do not edit28files unless user asks for changes.29 30## Guardrails31 32- Keep changes inside `crates/but/tests/performance/` unless task specifically requests33  related documentation or skill updates.34- Preserve two-file scenario contract.35- Do not add custom timing/statistics code; Hyperfine owns measurement.36- Do not include fixture setup or compilation in measured command.37- Do not run all scenarios when user requests or changes only one.38- Report fixture/setup limitations and unavailable validation explicitly.39