Every Mesrai rule, in one place

Throw and catch the most specific exception type available; avoid catching or throwing System.Exception unless rethrowing.

When using a WaitGroup to synchronize goroutines, call Add() before launching each goroutine and ensure each goroutine calls Done() exactly once. Finally, call Wait() to block until all goroutines have called Done(). Misordering Add/Done or mismatched calls will cause issues.

Wrap per-item work in try/catch, collect failures, and continue when appropriate; never let one failure abort the entire batch by default.

Use try-with-resources for Closeable/AutoCloseable objects to guarantee deterministic cleanup.

Prefer TryParse-style APIs for user/IO input instead of Parse, and validate culture/format where applicable.

When callbacks/validations are not required, prefer a single UPDATE statement via update_all over iterating records and calling update.

Wrap IDisposable resources in using/await using to ensure deterministic disposal.

Ensure `dart:html`, `dart:js`, and `dart:js_util` are only used in Flutter web plugins to prevent runtime errors in non-web environments.

Make utility classes non-instantiable by providing a private constructor or marking them as `abstract`.

Never trust data received from users, forms or requests. Always validate the expected format (e.g., numbers, emails) and sanitize/remove unexpected characters or content using appropriate techniques (filter_var, filter_input, etc.).

After decoding, assert required keys and types before use; reject unexpected shapes.

Use isset()/array_key_exists() or null coalescing (??) before reading array keys that may be absent.

If a PR changes redirect/header configuration (e.g., middleware redirects, CDN headers, security headers), validate it against the active edge rules to avoid conflicts. - If a Cloudflare MCP is available: fetch active rules and detect potential redirect loops, duplicate rules, or header conflicts. - Otherwise: require the author to link the relevant Cloudflare rules/screenshots in the PR description.

At process start, validate required configuration keys and fail fast with a clear message if any are missing or malformed.

If the PR references a ticket (e.g., 'Refs: ABC-123' or a Linear/Jira/Asana/ClickUp/Trello link), verify the diff covers each Acceptance Criterion. - If a ticketing MCP is available: fetch the ticket and list AC → code/tests mapping. - If no MCP is available or the ticket is inaccessible: ask the author to paste the Acceptance Criteria in the PR description. Flag any missing criteria, unhandled edge cases, or partial implementations before human review.

Validate and sanitize all request bodies and search params on the server using a schema (e.g., zod). Reject invalid payloads with proper status.

When a PR changes dependency manifests (e.g., package.json, yarn.lock, requirements.txt, composer.json), check for known vulnerabilities and risky packages. - If an OSV/SCA MCP is available: query it for the new package versions and flag recent CVEs. - Otherwise: require evidence (audit output, advisory links) in the PR description. Also flag suspicious packages (typosquats, low-maintenance critical libs, unexpected transitive jumps) and require lockfile updates.

Ensure that value types (structs) implement `IEquatable<T>` for efficient equality comparisons, avoiding boxing and reflection.

Enable content versioning and long-lived caching via ResourceChain with VersionResourceResolver and set Cache-Control to public, max-age=31536000 for static locations; keep HTML templates non-immutable.

If a PR changes an API endpoint/controller/route, assess current production health before adding heavier logic. - If a monitoring MCP is available (Datadog/Grafana): query current p95 latency and error rate for that endpoint. - If the endpoint is already degraded, warn against adding heavy queries, blocking I/O, or complex synchronous logic; require performance evidence or a safe rollout plan. To enable this check, the PR should reference the endpoint path (e.g., `POST /api/payments`) or the controller/action name.

Run blocking I/O and CPU-intensive work inside withContext(Dispatchers.IO) or Dispatchers.Default respectively. Never block the main thread.

Use try/catch (or Uri.tryParse with validation) around Uri.parse to guard against FormatException and invalid inputs.

PR titles must follow the pattern: <scope>: <concise change summary>. Keep it under 72 characters and avoid vague words like 'stuff' or 'minor tweaks'.

For any handler that reads or writes ePHI, write an append-only audit record with user id, patient id, action (READ_PHI/WRITE_PHI), purpose-of-use, timestamp, and request id. Prevent deletion or mutation of audit entries.