Frontend Code Review Policy

Speed of iteration over perfection - Frontend development is inherently iterative. It is often better to ship something and then iterate on it than trying to get it perfect from the get go.

Not all changes are equal - CSS changes shouldn't require review. With the advent of LLM's, a lot of NextJS code feels solved as well.

Review Requirements by Change Type

CSS/HTML-only changes: No review required

Pure styling changes (margins, colors, fonts, layouts)
HTML structure changes without logic
Exception: Changes to key components (e.g. StoryCard, IndexContent)
Developer is responsible for visual QA before merging

Very Small Component logic changes: No review required

Changes to the frontend tests
Piping some variable around in order to display it (e.g. adding a date)
Adding/modifying some simple logic
One-line bug fixes
Developer is responsible for visual QA and LLM-core review before merging

Component logic changes: Relaxed review requirements (see below)

Data transformation and display logic
Any React or NextJS component change that follows standard React/NextJS best practices
- Adding hooks
- State management changes
- Event handlers and user interactions (useEffect)
- Props and type definitions
- etc.

Critical paths: Regular review requirements

Authentication/authorization flows
Payment or checkout flows (in the future)
Data mutations that affect other users
Any code in common or backend (i.e. the change is not purely a frontend change)

Relaxed Review Requirements

Before requesting a review, the submitter is expected to have ask an LLM to review the code and find any code smells, bugs, things that might bite us later on, gotchas, or design problems, and address them. This process should be repeated until the LLM is satisfied.
Review should be up for a day to give others a chance to respond
Code can be pushed if either of these two conditions is met:
1. Approval from another UpTrust dev
2. 24 hours + passing the LLM review