git:20260611.9d7f5e4 to git:20260901.387d97a

---

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