Style & Conventions rules

Base components (a.k.a. presentational, dumb, or pure components) that apply app-specific styling and conventions should all begin with a specific prefix, such as `Base`, `App`, or `V`.

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

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.

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.

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

Ensure that variables are declared as close as possible to their first use to improve readability.

Ensure that each variable is declared separately instead of using multiple declarations in one statement.

Always specify access levels (public, private, protected) when declaring class properties and methods. Don’t use the old `var` keyword for properties. Explicit visibility clarifies intent and prevents unintended access.

Hoist constant Regex/Formatters/Collections into top-level vals or companion objects; avoid recreating in hot paths.

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.

Avoid duplicating runtime schemas and TypeScript types; derive types from constants/functions or declare as const tuples.

Directive shorthands (`:` for `v-bind:`, `@` for `v-on:` and `#` for `v-slot`) should be used always or never.

Use `///` for documentation instead of block comments to improve tooling support and ensure better formatting in generated docs.

Detect occurrences of the Array constructor. It behaves inconsistently depending on arguments. Recommend using array literals [] instead for clarity and predictability.

Ensure that the Object constructor is not used. Object literals are clearer, more predictable, and improve readability.

Ensure that extensions use UpperCamelCase naming conventions (e.g., `MyExtension`). Avoid other casing styles that could reduce readability.

Check that import prefixes use lowercase_with_underscores (e.g., `my_library`), following Dart's style guide.

Ensure that identifiers such as variables and method titles are written in lowerCamelCase (e.g., `myVariable`). Avoid using other naming conventions.

Check that fields and top-level variables are type-annotated explicitly when the type is not obvious from the context. This avoids ambiguity.

For async functions or functions returning Promise, document resolve value, rejection conditions, and usage with await; include @throws or @returns {Promise<Type>}.