solution-complexity-audit

# Solution Complexity Audit Used in the post-implementation audit stage after std/brute are available. You must provide structured evidence; verbal claims are not sufficient. ## Execution Order Call tools in this order and record the results: 1. `solution_analyze`: estimate std time/space complexity and record worst/average risks. 2. `solution_audit_std`: verify whether `claimed_complexity` conflicts with estimated complexity and constraints. 3. `solution_audit_brute`: confirm brute is suitable as a stress oracle and derive `n_max` and `trials`. ## Required Checks - Whether std has `high_tle_risk` or obvious boundary flaws. - Whether brute truly serves as a conservative correctness oracle rather than the same class of implementation as std. - Whether complexity conclusions match statement constraints (especially `n_max` and total scale). - Whether executable `stress_profiles` recommendations are produced. ## Output Format - `decision`: `go` / `no_go` - `findings`: structured issue list (including severity) - `recommended_stress_params`: recommended stress parameters ## Failure Handling - If high-risk items exist, fix the algorithm or constraints first, then rerun the full audit chain. - Do not skip this audit and proceed directly to final test generation. ## Decision Rules - `go`: no unresolved `critical` findings, `high_tle_risk` is `false` or `low`, and stress parameters are explicit and executable. - `no_go`: any unresolved `critical` finding, or brute is not a trustworthy stress oracle.