best-practice-guardlisted

# Best-Practice Guard Build a quality decision from the project's actual stack and evidence. Treat a practice as a hypothesis to check, not a universal label such as "secure" or "fast." ## Establish the frame 1. Read the authoritative manifest, lockfile, runtime settings, framework version, supported browsers/devices, and project policies before choosing a check. 2. Write the changed surface, threat or user impact, compatibility baseline, performance budget, and acceptance tests. Keep unrelated polish out of the gate. 3. For each recommendation, record a source: a project rule, versioned vendor documentation, a recognized standard, or a reproducible measurement. Include the source date or version when it affects the result. ## Evaluate six gates Use a small table with `gate`, `question`, `evidence`, `severity`, and `status`: - **Security:** Are trust boundaries, validation, authorization, dependency changes, and sensitive outputs appropriate for this stack and threat model? - **Accessibility:** Can the intended users discover, operate, and understand the changed surface with the project's supported input and assistive tools? - **Compatibility:** Does the behavior fit the declared runtime, browser, device, API, and data-version support matrix? - **Performance:** Does a reproducible measurement stay within the stated budget on a representative fixture? Explain what was not measured. - **Tests:** Do focused tests cover the acceptance path, failure