Maintainability rules

Store repeated string literals in constants or variables to improve maintainability and reduce redundancy.

Detect methods that have an empty body. If a method is empty, ensure that a comment is present explaining why it remains unimplemented.

Detect modifications to built-in prototypes. Modifying built-in objects can lead to compatibility issues and unexpected behavior. Recommend creating helper functions instead.

Before persisting ePHI, encrypt using a data key protected by a Key Management Service (KMS). Use authenticated encryption (AES-256-GCM or equivalent), rotate keys, and store the key id and algorithm with the record.

All static JS/CSS/font/image files MUST use content-hashed filenames (e.g., app.9c1a7b.js) and be served with "Cache-Control: public, max-age=31536000, immutable". HTML and other non-fingerprinted documents MUST be served with "Cache-Control: no-cache" (or equivalent) to enable conditional revalidation.

Ensure close/stop/dispose is called for resources (clients, channels, scopes) using use{} or try/finally; cancel coroutines on shutdown.

Check that finalizers are not left empty. If cleanup is needed, ensure proper resource disposal is implemented instead.

Do not combine mechanical changes (formatting, renames) with behavioral changes. If unavoidable, separate commits and call out which commits are mechanical.

Classes with only private constructors cannot be instantiated outside their own scope, potentially making them dead code.

Detect the use of the 'any' type in TypeScript. Using 'any' disables type checking and can lead to runtime errors. Recommend using specific types or generics instead.

Detect cases of unsafe type assertions. These do not perform runtime checks and can lead to unexpected runtime errors. Recommend using proper type guards instead.

Ensure that `File.deleteOnExit()` is not used, as it can cause memory and resource leaks.

Ensure that the `finalize()` method is not used. Use try-with-resources or explicit cleanup methods instead.

Check for global variable usage (e.g., variables prefixed with `$`). Suggest using instance variables, constants, or dependency injection instead.

Identify global variables that are mutable (e.g., lists, dictionaries). Global mutable state can cause unpredictable behavior. Recommend using local variables or encapsulating state in a class.

Tag records by data_class (PII, telemetry, auth) and enforce retention (e.g., PII ≤ 365 days unless legal hold). Provide scheduled deletion jobs and audit log entries.

Check if modules export mutable variables. Mutable exports can be modified by other modules, leading to unpredictable behavior. Recommend exporting immutable values instead.

Check for empty code blocks (such as `if` or `loop` structures) that do not contain any statements. If an empty block is present, ensure it includes a comment explaining its purpose.

Detect occurrences of the 'with' statement. This construct is banned in strict mode due to unpredictable behavior and makes debugging harder.

Every package must have a package comment, and each exported identifier must have a comment starting with the identifier name and a full-sentence summary.

All public modules, classes, and functions must include a docstring immediately after the definition, using PEP 257 conventions (one-line summary + optional sections like Args, Returns, Raises).

Identify functions that raise exceptions but do not document them in docstrings. Missing exception documentation makes it difficult to understand failure cases. Suggest adding an `:raises` section in the docstring.

When a function is unsafe, may panic, or returns Result, include sections # Safety, # Panics, and/or error conditions in the docs.

On every create/read/update/delete of CHD or tokens, write a structured audit event (who, what, when, result) without full PAN, including only pan_last4. Persist to an append-only/immutable sink. (PCI DSS 4.0 Req. 10)