/fec-code-review

name: fec-code-review
description: Use when the user asks for general frontend code review, PR review, merge-readiness assessment, architecture maintainability, type-safety, rendering/state risks, style consistency, testability gaps, or a cross-cutting review summary. Delegate deep security, accessibility, E2E, or performance investigations to their specialized skills; Chinese triggers include code review, code review, review.

Front-end code review

Purpose

Review the front-end code quality from 8 dimensions including architecture, type safety, accessibility, style consistency, performance and testability, and output a graded review report.

Procedure

1. Read the project facts first: package scripts, frameworks, directory conventions, recent diffs, existing tests and related rules. 2. Find problems based on risk, rather than picking styles based on personal preference; each finding must be able to point to specific files, line numbers, and user impacts. 3. Use five axes to converge conclusions: correctness, maintainability, type/interface, user experience, and verification coverage. 4. Only preliminary screening will be done for deep water areas such as safety, accessibility, E2E, and performance; diversion will be clearly defined when special investigation is needed. 5. During multi-dimensional review, first split according to responsibilities, and then merge similar findings; only one main finding for the same root cause of the same file is retained to avoid repeated noise. 6. List blocking issues first in the report, then recommendations; do not write firm conclusions on issues without evidence.

Multi-dimensional review arrangement

When changes span multiple quality dimensions, organize them according to "main review + special diversion" instead of having all dimensions repeatedly check the same code.

| Dimension | Trigger condition | Diversion boundary | | ------------------- | ---------------------------------------------------- | ------------------------------------ | | TypeScript Projects and Type Contracts | DTOs, generics, public types, type guards, `any`, assertions, tsconfig | In-depth type modeling and TS configuration handed over to the TypeScript process | | State management | State attribution, global store, URL state, derived state, cross-page synchronization | State selection and migration are handed over to the state management special process | | Security | User input, HTML rendering, token, upload, third-party script | Vulnerability level analysis is handed over to the security-specific process | | Accessibility | Pop-up windows, menus, forms, keyboard operations, focus management | WCAG scrutinizes the special accessibility process | | Performance | Large lists, heavy dependencies, repeated requests, long tasks, package sizes | Handle performance evidence and budget to the performance-specific process | | E2E | Key user path, login status, payment, cross-page process | Browser use cases and traces are handed over to E2E special process |

Discover merge rules:

• When the same root cause appears in multiple dimensions, only the highest severity level is retained and the related dimensions are listed in `Dimension`.
• Repeated patterns in multiple places in the same file are merged into one pattern-level discovery, and representative locations are listed.
• Questions with insufficient confidence are placed in Open Questions and will not be upgraded to blocked items.
• Format issues that can be stably captured by automation are handed over to lint/format and are not discovered by human reviewers.

Review dimensions

1. Architecture

• Is the component boundary clear?
• Whether display logic and business logic are separated
• Is there a reusable abstraction?
• Whether there is a God component

2. Type safety

• Whether there is unnecessary `any`
• Is the props type clear?
• Is the return value of hooks/composables stable?
• Whether the API contract has type constraints where feasible

3. Rendering and status

• Is there unnecessary repeated rendering?
• Is the use of key stable?
• Whether the deducible state is stored repeatedly
• Is the local state coupled too deeply?
• Whether the global store only saves client state that is truly shared across borders
• Whether the boundaries between URL state, server state, form state and browser persistence are clear

4. Style

• Whether the magic number is still used when there is already a Token
• Whether the class name is consistent with the warehouse convention
• Is responsive processing clear?
• Are multiple style systems being mixed unnecessarily?

5. Accessibility

• Is the semantic structure reasonable?
• Whether label and aria are used correctly when needed
• Whether to support keyboard operation
• Is the focus management of floating layers and menus correct?

6. Maintainability

• Is the component/page file size reasonable (it should be within **300 lines**; if it exceeds **500 lines** or is too complex, it must be split. See "Component file size" in the shared React/Vue rules)
• Is the naming quality good?
• Is there any repetitive logic that should be extracted
• Whether there is dead code, outdated comments or temporary hacks
• Whether the business status, type, and identification use bare numbers/naked strings (should be aligned with `templates/shared/rules/fec-typescript.md` "Magic Number / Magic String is prohibited")

7. Test

• Is critical test coverage missing?
• Is there a fragile selector or unstable test mode?

8. Security

• No obvious XSS risks (dangerouslySetInnerHTML/v-html must be reviewed)
• No sensitive information hardcoded
• Direct rendering without unvalidated user input

9. Performance and experience evidence

• Whether to introduce heavy dependencies on the first screen, repeated requests, large list rendering or long tasks
• Whether the status of loading, empty, error, disabled, focus, etc. is complete
• Whether the responsive layout has verifiable breakpoints and text