- Do not add private information, secrets, local filesystem paths, PHI, or real patient data to code, docs, tests, fixtures, logs, screenshots, or any other version-controlled file; use placeholders or sanitized examples instead.
- Treat "large code changes" as refactors, behavior changes across multiple functions/modules, or edits affecting multiple call sites.
- After large refactors, run
make benchmarkon the baseline and refactor versions with the sameBENCH_*settings, and report median deltas fortotal,startup,dicom_load, andrender_ui. - Run
cargo fmt --all -- --checkbefore sending the final response. - Run
cargo clippy --all-targets --all-features -- -D warningsbefore sending the final response. - Run
cargo test --all-targets --all-featuresafter large code changes. - For small changes, run
cargo check --all-targets --all-featuresat minimum. - Add or update tests when behavior changes; if tests are not needed, state why in the final response.
- Treat
unsafeas an exception: eachunsafeblock must include a short invariant/safety explanation. - Avoid
unwrap()andexpect()in production paths; allow them in tests with clear messages. - Prefer typed error enums in library-style modules and contextual error propagation in application flows.
- Keep
DESIGN.mdupdated when architecture, module ownership, invariants, or core data flows change. - Consult
RELEASE.mdwhen a change affects release process, versioning, tags, or publishing workflow.