Fec code 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 overflow protection

10. Must-check items (blocking merge)

• TypeScript complete type, no any
• No guardless assertions for external input, DTO, and public type boundaries
• No XSS risk
• No sensitive information hardcoded
• Core logic has unit tests

11. Quality items (suggested modifications)

• The size of the component file complies with the agreement (within about 300 lines is preferred; if it exceeds 500 lines or is highly complex, the sub-components/Hooks/Composables/utils have been disassembled)
• No duplicate code (DRY principle)
• No unused imports

12. Normative items (style suggestions)

• clear naming semantics
• comments cover complex logic

Detailed reference

When writing a code review report, load references/report-template.md. Findings must be specific and actionable; don't write general recommendations such as "optimize performance" without pointing out specific code patterns.

Constraints

• Do not write personal style preferences as blocking issues; blocking items must have clear evidence of user impact, runtime risk, security risk, or maintenance cost.
• Don't give conclusions when diff, file location or reproduction clues are missing.
• In-depth security, accessibility, E2E and performance issues are only screened initially; when an evidence chain is needed, they will be diverted to special skills.
• Do not report multiple reports for the same root cause; merge them into one representative finding and list the scope of impact.
• Format issues that are stably covered by automated tools are handed over to lint/format and are not discovered by human reviewers.

Expected Output

• Grading review report (CRITICAL / HIGH / MEDIUM / LOW)
• Each problem is associated with a specific file and line number, with suggestions for repairing it.
• It is not recommended to merge the blocking item (CRITICAL) until it is repaired
• The review report is saved as reports/code-review-YYYY-MM-DD-HHmmss.md
• Multi-dimensional reviews should consolidate duplicate findings and explain which special capabilities have been diverted to
• Label uncertain items with required verification commands or supplementary context, and do not write guesses into facts