Every Mesrai rule, in one place

Validate collection bounds and query results before indexing; prefer FirstOrDefault/SingleOrDefault with null checks.

Use `npm ci` for reproducible installs in build stages; in runtime, run `npm prune --omit=dev` or install with `--omit=dev`.

Annotate fields/props to explicitly control persistence and serialization (e.g., transient/ignored fields).

Define a discriminated union or error class hierarchy and use user-defined type guards before handling specific cases.

If a single-stage image must build native deps, remove compilers/headers after install and clear package caches in the same layer.

When removing or decommissioning a feature, ensure the associated feature flag is also removed from: - application code paths, - config/registry files (e.g., flags.ts, config.json), and - analytics/feature flag tools (if applicable). If a PostHog (or similar) MCP is available, verify the flag is disabled/removed and not referenced elsewhere. Otherwise, require a repo-wide search evidence in the PR.

Ensure that multiple loops over the same collection are combined into a single loop to improve efficiency.

Whenever a build system is available to concatenate files, each component should be in its own file.

Component names in JS/JSX should always be PascalCase, though they may be kebab-case inside strings for simpler applications that only use global component registration through `app.component`.

In most projects, component names should always be PascalCase in Single-File Components and string templates - but kebab-case in in-DOM templates.

Component options (like `name`, `props`, `data`, `computed`, `methods`, lifecycle hooks, etc.) should be ordered consistently according to a predefined sequence.

If the repo defines a Definition of Done (e.g., `DOD.md`, `CONTRIBUTING.md`), ensure the PR meets it. To enable this check, reference the file path in the PR or ask to review it explicitly. Confirm bureaucratic requirements (docs, tests, design approval, rollout plan) are satisfied or explicitly marked as not applicable.

Deduplicate near-identical Dockerfiles by sharing a common base stage (multi-stage) and varying only service-specific steps via build args/targets.

Extract reusable SQL fragments/builders for commonly repeated WHERE/ORDER clauses.

Avoid maintaining multiple equivalent validators for the same shape; centralize checks in a single function/schema.

Provide a single updater that applies deltas/patches to messages rather than multiple ad-hoc updaters.

Merge near-duplicate methods into a single parameterized method or strategy.

Replace repeated set/get config calls with data-driven loops or loaders from a single schema/source.

Detect the use of 'continue' inside loops. This practice can make control flow harder to follow. Recommend restructuring the loop for better readability.

Configure CookiePolicyOptions to enforce SameSite=Lax or Strict, HttpOnly, and Secure for all auth cookies.

For PHP-served assets, emit the precise Content-Type (e.g., text/css; charset=utf-8, application/javascript, font/woff2) and set immutable caching for hashed files; never apply immutable caching to HTML.

Factor shared before_actions/filters/error handling into ApplicationController or a base controller.

Avoid prop drilling translation functions/objects; expose shared accessors (e.g., a global translation service or context API).

When configuring processors outside the EEA, annotate the config with transfer_mechanism (e.g., SCCs) and link to the signed SCC document; prevent enablement without this metadata. (GDPR Art. 46)