Angular Quality Rails
Agent Studio website work should not keep growing as one large content file and a few large components. Angular projects need explicit linting, template checks, SCSS rules, component boundaries and a quality migration plan.
This plan is based on the current website app: Angular 21, Prettier installed, no ESLint or Stylelint scripts yet, one large `site-content.ts`, large `page.component.scss`, and mostly inline templates. The goal is better structure before the site becomes hard to maintain.
Current Website Quality State
The current static Angular website builds, but the structure is starting to show risk. The content source is concentrated in one large file, templates are mostly inline and the styling surface is large enough that linting and component boundaries should become explicit.
Visual evidence as a first-class review surface: screenshots harvested from tasks and grouped by capture time.
- `site-content.ts` is roughly 2,479 lines and carries page data, articles, captures, patterns and navigation source.
- `page.component.ts` is roughly 462 lines and includes multiple layouts in one inline template.
- `page.component.scss` is roughly 925 lines and `app.scss` roughly 505 lines.
- The package has Prettier but no ESLint, Angular template linting or Stylelint scripts yet.
- A static build is currently the main safety check, which catches route and icon failures but not enough style or architecture drift.
Target Quality Bar
The target is a maintainable Angular content site with reusable components, linted TypeScript, linted Angular templates, linted SCSS, predictable content modules and review evidence for visual changes.
- TypeScript linting catches unused code, risky any usage, brittle imports and component complexity.
- Angular template linting checks accessibility, bindings and template structure.
- SCSS/Stylelint catches invalid CSS, duplicate patterns and maintainability issues.
- Content modules keep articles, patterns, product pages and captures easier to inspect.
- Reusable components replace repeated catalog, essay and card rendering logic where it reduces real complexity.
Linting Plan
The first migration task is to add explicit lint commands without changing the website behavior. The second task is to make the checks strict enough that Agent Studio can use them as review evidence.
TS lint
TypeScript and Angular component rules.
Template lint
HTML/template accessibility and binding checks.
SCSS lint
Stylesheet validity, duplication and maintainability checks.
- Add Angular ESLint for TypeScript and Angular template linting.
- Add Stylelint for SCSS with project-appropriate rules and no one-note cosmetic churn.
- Add scripts such as `lint`, `lint:ts`, `lint:templates`, `lint:scss` and keep `build:static` as the route/prerender check.
- Run the first pass in report mode, then create Agent Studio follow-up tasks for violations by category.
- Make lint output part of task evidence before accepting website UI/content changes.
Component and Content Split Plan
The current page renderer is useful but too central. The next quality step is to split by layout and content ownership without inventing unnecessary abstractions.
- Extract catalog, essay, comparison and generic content layouts into focused components.
- Move article, pattern and product content into separate content modules or data files.
- Keep capture data reusable and typed, but avoid one giant content registry when sections keep growing.
- Define component size thresholds and create review tasks when a component crosses them.
- Prefer stable small components over nested card-heavy layouts.
Quality Analysis Plan
Before refactoring, run an explicit analysis so tasks are based on evidence: file sizes, repeated markup, repeated SCSS patterns, missing lint rules, accessibility risks and visual verification gaps.
- Inventory large files, inline templates, repeated cards, repeated layout classes and duplicated text rendering logic.
- Review component responsibilities: what renders layout, what owns content, what owns navigation and what owns proof captures.
- Review SCSS by selector group and identify global styles that should become component styles.
- Review HTML/template accessibility for heading order, link labels, nav depth and mobile drawer behavior.
- Turn each finding into scoped Agent Studio tasks with build/lint evidence.
Migration Sequence
The migration should be incremental. First add checks, then split the riskiest surfaces, then use Agent Studio tasks to repair quality findings one class at a time.
- Step 1: add lint tooling and scripts, keeping behavior unchanged.
- Step 2: run baseline analysis and record findings as Agent Studio tasks.
- Step 3: split the largest renderer/layout pieces into reusable components.
- Step 4: split content into product, patterns, articles and captures modules.
- Step 5: add visual verification for key desktop and mobile routes.
- Step 6: make lint, build and visual checks required evidence for future website tasks.