Skip to main content
Machine-readable rules for AI assistants and agents working in the Angular frontend. These are the enforceable form of the frontend coding standards and the shared AI manifesto. Each rule has a stable ID so it can be cited in review. 
ruleset-id: 7days-frontend
applies-to: angular-frontend
language: TypeScript
framework: Angular
id-scheme: FE-<AREA>-NN
derived-from: /development/frontend/coding-standards

​
Rule IDs

Rules use category-scoped IDs: FE-<AREA>-NN, where <AREA> is the (stable, uppercase) section code below and NN is a zero-padded number within that area — for example FE-TS-01.
  • To add a rule, take the next free number in the relevant area (a third TypeScript rule is FE-TS-03), so each section grows independently and the ID always tells you the category.
  • IDs are stable. Never renumber an existing rule or reuse the ID of a retired one — mark a dropped rule as retired instead.
Several frontend standards are still being written (marked TODO in the coding standards). Where a rule is not yet fixed, an agent must ask a human rather than invent a convention — see FE-TODO-01.

​
Project structure

  • FE-STRUCT-01 — Group code by feature, not by type. Keep a feature’s components, services, and models together.

​
Components

  • FE-COMP-01 — Prefer standalone components and the modern Angular APIs. Do not scaffold new NgModule-based components unless an existing area requires it.
  • FE-COMP-02 — Keep components presentational where possible; move logic into services. A component that fetches, transforms, and renders is doing too much.

​
TypeScript & linting

  • FE-TS-01 — Code must pass ESLint + Prettier; CI fails on violations. Do not disable rules inline (// eslint-disable) to get a change through — fix the cause.
  • FE-TS-02 — strict mode is on in tsconfig. Avoid any — use precise types, generics, or unknown with narrowing. Never add any (or as any) to silence the compiler.

​
State & RxJS

  • FE-STATE-01 — Always clean up subscriptions: use the async pipe, takeUntilDestroyed, or an explicit unsubscribe. Never leave an open subscription that outlives its component.

​
Testing

  • FE-TEST-01 — Write unit tests with Jasmine/Karma (or Jest) for logic-bearing services and components. As on the backend, non-trivial logic ships with tests.

​
Styling

  • FE-STYLE-01 — Follow the project’s existing styling approach and naming; match the surrounding component’s conventions rather than introducing a new pattern.

​
When a standard is undefined

  • FE-TODO-01 — Where the frontend coding standards still say TODO (folder structure, inputs/outputs and change-detection conventions, state-management approach, SCSS/design-token conventions, coverage expectations), do not guess a convention. Match the existing code, and flag the ambiguity for a human to resolve.
As the frontend standards are filled in, promote each resolved decision into a concrete rule here in the same pull request, so this ruleset grows alongside the human docs.