Maintainability rules

Do not put complex logic or long-running tasks in package `init()` functions. Keep `init()` minimal (if you use it at all), such as simple registration of types or default variable initialization. Perform real setup in explicit functions (like in `main` or a setup function called by main).

Ensure that console statements are removed in production code. Console logs can expose sensitive data and impact performance.

Detect the use of default exports. Named exports provide better clarity, maintainability, and prevent issues when refactoring.

Ensure that classes with only static members are converted to top-level functions or extensions. Avoid unnecessary class instantiation.

Flag usages marked as @deprecated (via JSDoc or types) and propose the documented alternative when available.

Treat function inputs as immutable; copy before mutation (e.g., dict.copy(), list(x)).

Do not use global (package-level) variables for mutable state whenever possible. Instead, encapsulate state in structs or pass it as parameters. If you must use a global variable (for configuration or caching), protect it with mutexes if concurrent access is possible and document its usage.

Ensure that arrays do not contain non-numeric properties. This practice can lead to unexpected behavior. Use Maps or Objects instead.

Do not use global variables to share data across your program. Prefer passing values as function parameters or using configuration objects. Limiting variable scope makes code more predictable and less prone to side effects.

Methods returning values that are never used introduce unnecessary complexity. Remove such return values to improve clarity.

Check for the use of getters and setters. These can introduce unexpected side effects and have limited compiler support. Recommend using regular methods unless required by a framework.

Use Directory.Packages.props at the repo root to declare PackageVersion entries. Workspace .csproj files must reference packages without embedding Version attributes.

Route all analytics events through a single service/helper instead of calling the SDK directly from widgets and blocs.

Define configuration values in one place (env/config file/const class) and reference them; avoid scattering magic strings.

Generate cache/Redis keys through a single utility with clear namespaces and versioning.

In the root Cargo.toml, define [workspace] members and manage shared versions under [workspace.dependencies]. Member Cargo.toml files must not pin versions for crates declared centrally.

Define shared string literals (route names, keys, claim types) as constants/enums in a single place.

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.

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

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

Run a scheduled job that deletes telemetry after 30 days and anonymizes PII after the retention window; log deletions with data_class and count.

Replace magic strings with constants or enums sealed classes; keep them in a single source of truth.

Create theme-like constants (radii, gaps, durations) and reuse across widgets.

If the PR introduces or expands usage of deprecated libraries/patterns the team is migrating away from (e.g., Moment.js, React Class Components), block and suggest the modern replacement. If the repo includes a migration guide (e.g., `docs/migration.md`, `CONTRIBUTING.md`, `docs/adr/*`), follow it and propose the equivalent snippet. If no guide exists, use an available web/search MCP to propose a safe, modern alternative and ask for confirmation of project standards.