Module Boundaries & Architecture rules

For changes that affect architecture, data models, external APIs, security posture, deployment topology, or cost (>10%), create an ADR in docs/adr/ using the standard template (Context, Decision, Consequences) and link the PR and issue IDs.

Ensure that factory method injection is used in `@Configuration` classes instead of `@Autowired` field injection.

Identify cases where a module imports itself. Self-imports are usually unintentional and can cause confusion or unnecessary dependencies. Suggest removing them.

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

Provide a single permission check API (e.g., can(user, action, resource)) and reuse it across layers.

When accepting a slice or map from external snippet or returning one, consider copying it. This prevents unintentional modifications to the original data. For example, don't store a slice argument directly if the caller might modify it later; instead, make a copy for internal use.

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

Do not violate the project's architecture boundaries. Examples of violations: Controllers/Views directly querying the database; UI importing infrastructure modules; domain modules importing unrelated domains. If the repo defines boundaries (lint rules, Nx tags, dependency-cruiser, ARCHITECTURE.md), enforce them. When in doubt, route all I/O through the intended service/repository layer and keep domain logic isolated.

Check if the `__all__` list in a module contains titles that are not defined. Listing undefined titles can cause `ImportError` when performing wildcard imports.

Controllers handling multiple concerns become harder to maintain and test. Split responsibilities into separate controllers.

In JS/TS workspaces, imports must use workspace package names (as defined in each package.json and exports) rather than relative paths crossing package boundaries.

Authorize every request by role and resource scope. Policies must default-deny and require explicit allow; privileged roles (admin, auditor) must be rare and reviewed quarterly.

Load and validate environment/config once during startup; inject settings into modules instead of re-reading env.

Ensure that constructor injection is used instead of field injection (`@Autowired` on fields) in Spring components for better testability.

Obtain collaborators via constructor injection (or a DI container) instead of new/service locators in business code.

Keep UI/controllers thin; move domain logic to services or domain objects.

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.

Request dependencies via constructors and register them with the DI container; avoid new-ing services in code.

Maintain a single go.work at the monorepo root listing all local modules via use directives. Forbid go.mod replace directives that point to sibling modules (e.g., ../pkg) in workspace modules.

Ensure `dart:html`, `dart:js`, and `dart:js_util` are only used in Flutter web plugins to prevent runtime errors in non-web environments.

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.

Ensure that titlespace structures are not overly deep. Favor a flat, organized structure to enhance readability and navigation.