> ## Documentation Index
> Fetch the complete documentation index at: https://docs.internal.sevencanyon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Frontend AI ruleset

> Enforceable rules for AI agents working in the Angular frontend

Machine-readable rules for AI assistants and agents working in the **Angular** frontend.
These are the enforceable form of the
[frontend coding standards](/development/frontend/coding-standards) and the shared
[AI manifesto](/development/ai/manifesto). Each rule has a stable ID so it can be cited in
review.

```yaml theme={null}
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.

<Info>
  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.
</Info>

## 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](/development/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.

<Note>
  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.
</Note>