Deliver localized auth app with verification and go_router

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.

.agents/skills/manage-gitea-task/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: manage-gitea-task
+description: Create, update, or prepare Sendico Gitea tasks and implementation branches with the required body, metadata, branch naming, issue association, and verification. Use when Codex creates a Gitea issue or task, corrects its labels, assignee, or project, or begins code work that requires a task branch.
+---
+
+# Manage Gitea Task
+
+## Establish scope
+
+1. Read the repository root `AGENTS.md`.
+2. Resolve the target owner and repository from authoritative repository
+   context. Do not infer ambiguous values.
+3. Determine whether the request only manages a task or also starts code work.
+4. Before any tracker mutation, resolve the required existing labels, assignee,
+   and project. Ask the user for any value that authoritative data cannot
+   establish.
+
+## Create or update the task
+
+1. Use a concise, outcome-oriented title.
+2. Write a self-contained body with these exact sections:
+
+   - `### Goal`: state the concrete outcome, why it is needed, and its value.
+   - `### Approach`: describe the intended direction, likely components, known
+     constraints, and boundaries without inventing decisions.
+   - `### Acceptance criteria`: provide a checklist of observable, testable
+     completion outcomes, including relevant edge cases and validation.
+   - `### Notes`: record contracts, compatibility, migrations, dependencies,
+     rollout, configuration, security, observability, risks, open questions,
+     exclusions, and authoritative links when relevant. Write
+     `None identified` when no significant notes apply.
+
+3. Prefer the configured Gitea connector for issue operations. If it cannot
+   assign a project or attach a branch, use the authenticated Gitea REST API.
+4. Resolve the project ID from authoritative Gitea data. If no project-list
+   endpoint is available, inspect the `projects` fields on existing issues in
+   the required project. Never infer an ID from its name.
+5. When creating an issue through
+   `POST /api/v1/repos/<owner>/<repo>/issues`, include `labels`, `assignees`, and
+   `projects: [<project-id>]` in the request.
+6. When correcting project assignment through
+   `PATCH /api/v1/repos/<owner>/<repo>/issues/<number>`, send the complete
+   intended `projects` list because it replaces the existing assignment.
+7. Verify the response contains the intended project, labels, assignee, title,
+   and body before proceeding.
+
+Never print, log, store in repository files, or expose API tokens or Git
+credentials.
+
+## Prepare a code-change branch
+
+Skip this section when the task does not require repository changes.
+
+1. Resolve the numeric task number and the specific primary module before
+   changing code.
+2. Form the short branch name as `<module>-<task-number>` with a lowercase
+   kebab-case module. Do not use `codex/`, `#`, task text, or an avoidably generic
+   module name.
+3. Create or select the branch only after the task exists.
+4. Push the branch to the Gitea repository before changing repository files.
+5. Attach the branch by setting the issue `ref` to the exact short name. Prefer
+   the connector; otherwise send `{"ref": "<module>-<task-number>"}` through
+   the issue PATCH endpoint.
+6. Verify the response contains the exact short `ref` and the required project,
+   labels, and assignee. Stop before code changes if any value is empty or
+   mismatched.
+
+## Report the result
+
+Report the task number and URL, resolved metadata, and attached branch when
+applicable. Identify any unresolved metadata or external blocker precisely; do
+not claim the task is ready when verification did not succeed.

.agents/skills/review-frontend-change/SKILL.md

@@ -0,0 +1,56 @@
+---
+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.