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 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](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
## Refactoring Boundary

A general review may flag maintainability evidence, but dedicated smell diagnosis or a behavior-preserving refactoring plan owns deeper structural analysis. Review should not silently execute structural changes; it can recommend diagnosis/planning when a finding needs systematic transformation.