Keep Angular Website Changes Reviewable
Run the configured TypeScript, template and SCSS checks, then inspect the rendered pages affected by a change.
This website separates route content from shared rendering components. The workflow below helps maintain that separation as content, styles and layouts change.
Use the Existing Content Modules and Checks
Route content lives in src/app/content/. Shared components render it. The project scripts check TypeScript, Angular templates, SCSS and content structure, and produce a static build.
Screenshots grouped by capture time and project. Source labels remain visible, including mocked. A screenshot alone does not establish that a test passed.
- Keep text edits in the responsible content module.
- Check all affected routes when a shared renderer changes.
- Record the commands and results for the current source revision.
Inspect What Automated Checks Cannot Decide
Configured lint rules can identify certain source problems. They do not establish that a page reads well, is easy to navigate or looks correct at every viewport. Review those aspects in the rendered website.
- Keep responsibilities clear between content, navigation and rendering.
- Check headings, link names, focus behavior and mobile navigation.
- Review both language versions after a shared layout change.
Run Checks and Address Their Findings
Use the configured commands and read their output. Distinguish existing failures from problems introduced by the change; do not record an unfinished command as passed.
The combined project workflow is npm run check. Keep a concrete follow-up for any unresolved failure.
npm run lint:tsnpm run lint:templatesnpm run lint:scssnpm run validate:contentnpm run build:staticChange the Component That Owns the Behavior
Before changing rendering behavior, identify the shared component and the routes that depend on it. Split a component when a distinct responsibility or repeated structure justifies it.
- Preserve section IDs, route paths and typed content fields.
- Keep screenshot metadata reusable and distinguish captures from diagrams.
- Use file size as a reason to inspect, not as a verdict.
Base Refactoring Tasks on Specific Problems
Look for repeated markup, unclear responsibilities, conflicting selectors or inaccessible controls. Describe the affected behavior and a way to verify the improvement before starting a refactor.
Make One Coherent Change
Record the source revision and baseline results. Fix one identified problem, run the relevant checks and inspect the affected desktop and mobile routes. Attach the diff and check results to the task.