Stephan D
10a278c65a
Integrate themed login/signup, EN/RU localization, shared dummy providers, verification recovery screens and named URL routes. Store frontend guidelines, workflow skills, validation and delivery documentation. Related to #2, #3, #5 and #6.
57 lines
2.6 KiB
Markdown
57 lines
2.6 KiB
Markdown
---
|
|
name: review-frontend-change
|
|
description: Review, fix, and validate the complete Sendico frontend contribution for a task. Use before reporting completion whenever Dart or Flutter code under frontend/ was added or modified, or when the user requests a frontend implementation review.
|
|
---
|
|
|
|
# Review Frontend Change
|
|
|
|
## Establish the review scope
|
|
|
|
1. Read the repository root `AGENTS.md` and `frontend/AGENTS.md` completely.
|
|
2. Inspect repository status and the full frontend diff attributable to the
|
|
current task, including uncommitted and committed changes against the task's
|
|
base.
|
|
3. Separate unrelated pre-existing work from the task contribution. Preserve
|
|
it and do not include it in review fixes.
|
|
4. Identify every changed Dart file and each affected Flutter package before
|
|
validation.
|
|
|
|
## Review and fix the contribution
|
|
|
|
1. Apply every quality requirement in `frontend/AGENTS.md` to the entire task
|
|
diff, not only the most recently edited file.
|
|
2. Verify the established DTO-to-mapper-to-service-to-model-to-provider flow and
|
|
ensure widgets do not absorb transport, I/O, or state-orchestration work.
|
|
3. Search for reusable DTOs, models, providers, widgets, and utilities before
|
|
accepting new representations.
|
|
4. Review widget structure, file cohesion, lifecycle behavior, asynchronous
|
|
races, notification scope, accessibility, responsive behavior, and import
|
|
header layout.
|
|
5. Review loading, empty, success, and error states together with nullability,
|
|
navigation, user-visible failures, edge cases, and focused test coverage.
|
|
6. Fix every in-scope issue found, then re-read the resulting complete frontend
|
|
diff. Repeat until no task-caused finding remains.
|
|
|
|
Do not weaken lints, suppress failures, or modify unrelated user work to make
|
|
validation pass.
|
|
|
|
## Validate
|
|
|
|
1. Run `dart format --output=none --set-exit-if-changed` for every changed Dart
|
|
file.
|
|
2. Run `flutter analyze` from every affected frontend package directory.
|
|
3. Run `make test-frontend` from the repository root.
|
|
4. Select and run every applicable security command from the change-scoped
|
|
security completion requirements in the root `AGENTS.md`.
|
|
|
|
All commands must succeed before reporting the frontend task as complete. If a
|
|
command fails, determine whether the task caused it and fix in-scope failures.
|
|
Report an external or environmental blocker with the exact command and failure;
|
|
never represent blocked validation as successful.
|
|
|
|
## Report the result
|
|
|
|
Summarize the reviewed frontend scope, material fixes made during review, tests
|
|
added or updated, affected packages, and the outcome of every required command.
|
|
Call out relevant accessibility, behavior, contract, or rollout implications.
|