jMerta Frontend Change Review
Review only unless the user separately authorizes fixes. Do not post comments or change pull-request state.
Review flow
- Establish the base, changed lines, intended user outcome, owning application, and affected routes or states.
- Read repository instructions and trace imports to the actual client, component, hook, primitive, endpoint, mock, and test definitions.
- Trace changed data from input and identity through request, decoding, cache, state, rendering, interaction, and error recovery.
- Compare with the same application's current patterns. Do not transplant another application's similarly named API or component contract.
- Exclude untouched debt, style preferences, and hypothetical failures. Report only reachable regressions introduced, worsened, or materially touched by the diff with confidence of at least 80/100.
- Anchor each finding to a changed location and provide mechanism, evidence, smallest safe direction, and exact validation.
Use evidence in this order: changed code and full rendered or data call chain, protecting tests, repository instructions, then other documentation.
Select references
- Read references/data-flow.md when the diff touches clients, auth, cache keys, decoding, pagination, normalization, server/client boundaries, or demo data.
- Read references/ui-interaction.md when it touches components, copy, localization, accessibility, responsive layout, overlays, navigation, focus, or visual evidence.
- Read both only when the changed behavior crosses both concerns.
Core decision boundaries
- Use the owning application's real client, auth, error, and component contracts.
- Include every input that changes a result in its cache key, including active account or tenant scope when identity can switch.
- Treat external JSON as untrusted until narrowed or mapped at a deliberate boundary.
- Preserve pagination totals and numbering across empty and later pages.
- Keep demos, previews, and mock applications isolated from production auth, backend, and external state unless explicitly designed otherwise.
- Reuse actual component APIs and shared primitives instead of inventing props from a similarly named component.
- Keep visible copy aligned with the active localization system and check every consumer of shared keys.
- Check semantic controls, accessible names, keyboard and focus behavior, disabled states, touch targets, overflow, loading, empty, error, and recovery states when the diff can affect them.
- Require screenshots or recordings only for material visual or interaction changes, not for copy-only or nonvisual logic.
Findings
P0: credible authorization, tenant, payment, secret, personal-data, or permanent data-loss path.P1: user-visible behavior, contract, cache isolation, navigation, or rollout failure.P2: bounded regression or missing validation with a concrete path.- Omit style-only suggestions without a reachable changed failure unless requested.
Use blocked only when the diff or a critical contract cannot be evaluated.
Output
Verdict: clean | findings | blocked
Reviewed: [changed surfaces and traced data/rendered path]
Findings:
[P1][confidence 94] Title — changed/path:line
Mechanism: [reachable user failure]
Evidence: [definition, endpoint, test, or contract]
Direction: [smallest safe correction]
Validation: [exact check or visual scenario]
Verified non-findings: [important traps rejected]
Verification needed: [at most two below-threshold items]