Style & Conventions rules

Use `is!` instead of `!is` for type checking to prevent confusion and ensure consistent behavior.

Replace any/unknown with inferred generics, unions, or precise interfaces when the shape is known.

Ensure that all literal values passed to constructors of `@immutable` classes are marked as `const` to prevent unnecessary object creation.

Ensure that constants are declared with the `final` keyword to prevent modification.

Ensure that immutable instance fields are marked as `readonly`, and compile-time constants are marked as `const`.

For applications, styles in a top-level `App` component and in layout components may be global, but all other components should always be scoped. This can be achieved through CSS modules, class-based strategies like BEM, or the `scoped` attribute in Single-File Components.

In committed code, prop definitions should always be as detailed as possible, specifying at least type(s).

Ensure that Java records are used for immutable data structures instead of manually implementing immutable classes.

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

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

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

All public types and members must have XML documentation comments with <summary>, <param>, <returns> (if non-void), and <exception> when thrown.

Annotate function parameters and return types; use TypedDict/Protocol/Dataclass/Pydantic where appropriate.

Check for occurrences of var declarations. Using var leads to function scoping issues. Recommend using const for immutable values and let for mutable ones.

Ensure that strict equality (===) is used instead of loose equality (==). Loose equality can lead to unexpected type coercion and logical errors.

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

Identify lambda functions that are too complex. Lambdas should be simple and concise. If a lambda contains multiple expressions, recommend converting it to a titled function for better readability.

Never use a pointer to an interface type. Pass interfaces as values, since an interface already provides reference semantics to the underlying data.

Do not use pointers to slice or map types. Slices and maps are already reference types that point to underlying data, so they can be passed by value and still allow modifications to the contents.

Check if the method, variable, or class title contains redundant context (e.g., using 'carDrive()' when 'drive()' would suffice). Ensure the title is concise and avoids repetition of surrounding context.

Check if semicolons are used at the end of statements in Python code. Semicolons are unnecessary and may cause readability issues or errors when multiple statements are placed on one line. Recommend using new lines instead.

Detect unnecessary semicolons at the end of statements. Ruby does not require semicolons, so they should be removed unless multiple statements exist on the same line.

Detect occurrences of the comma operator in expressions. The comma operator can make code harder to read and debug, as it executes multiple expressions but only returns the value of the last one.

Ensure that imports are explicitly listed and avoid using wildcard imports (`import package.*;`).