# PRD.md

1. Введение

Этот документ описывает требования к продукту для мобильного приложения по управлению задачами. Основная цель — предоставить пользователям простой и эффективный инструмент для управления ежедневными задачами, их организации по категориям, получения своевременных напоминаний и отслеживания своей продуктивности. Приложение призвано решить распространенную проблему забывания задач, предлагая централизованную платформу с функциями уведомлений.

2. Цели

* Разработать удобное мобильное приложение для управления задачами. * Позволить пользователям создавать, просматривать, редактировать и удалять задачи. * Обеспечить возможность организации задач с помощью папок или категорий. * Реализовать функциональность сроков выполнения с push-уведомлениями. * Предоставлять пользователям базовую статистику по завершению задач. * Обеспечить сохранение данных и их синхронизацию между сессиями пользователя (изначально предполагается одно устройство, но с расчетом на возможную облачную синхронизацию в будущем).

3. Целевая аудитория

Люди, которым нужна помощь в организации личных или рабочих задач, студенты, управляющие учебными заданиями, или любой, кто ищет простой цифровой инструмент для повышения продуктивности и запоминания задач. Ожидается, что пользователи будут уверенно пользоваться стандартными мобильными приложениями.

4. Объем работ

**Входит в объем работ:** * Создание учетной записи и вход пользователя (локально или через простую пару email/пароль). * CRUD-операции для задач (Создание, Чтение, Обновление, Удаление). * CRUD-операции для папок (Создание, Чтение, Обновление, Удаление). * Назначение задач папкам. * Установка дат и времени выполнения для задач. * Локальные push-уведомления для напоминаний о задачах на основе сроков выполнения. * Отметка задач как выполненных/невыполненных. * Просмотр задач списком (все, по папке, по сроку выполнения — сегодня/предстоящие). * Отображение простого еженедельного счетчика выполненных задач. **Не входит в объем работ:** * Облачная синхронизация между несколькими устройствами. * Расширенные функции для совместной работы (общий доступ к задачам/папкам). * Повторяющиеся задачи. * Подзадачи. * Уровни приоритета, кроме сроков выполнения. * Расширенная отчетность или аналитика, кроме еженедельного счетчика. * Интеграция с календарем. * Веб- или десктопные версии.

5. Пользовательские истории

* **US001:** Как пользователь, я хочу создать учетную запись или войти в систему, чтобы мои задачи были надежно сохранены. * **US002:** Как пользователь, я хочу добавить новую задачу с названием, необязательным описанием и необязательным сроком выполнения, чтобы я мог зафиксировать то, что нужно сделать. * **US003:** Как пользователь, я хочу видеть список всех моих задач, чтобы понимать, что мне нужно сделать. * **US004:** Как пользователь, я хочу отметить задачу как выполненную, чтобы отслеживать свой прогресс. * **US005:** Как пользователь, я хочу отредактировать существующую задачу (название, описание, срок, папку), чтобы я мог обновить ее детали. * **US006:** Как пользователь, я хочу удалить задачу, которая мне больше не нужна. * **US007:** Как пользователь, я хочу создавать папки (например, «Работа», «Дом»), чтобы я мог классифицировать свои задачи. * **US008:** Как пользователь, я хочу назначить задачу определенной папке при ее создании или редактировании. * **US009:** Как пользователь, я хочу просматривать задачи, отфильтрованные по определенной папке. * **US010:** Как пользователь, я хочу получать push-уведомление на свой телефон, когда наступает дата/время выполнения задачи, чтобы не забыть о ней. * **US011:** Как пользователь, я хочу видеть простой счетчик того, сколько задач я выполнил за текущую неделю, чтобы я мог оценить свою продуктивность. * **US012:** Как пользователь, я хочу управлять своими папками (переименовывать, удалять).

6. Функциональные требования

* **FR001: Аутентификация пользователя:** * Система должна позволять пользователям регистрироваться с помощью email и пароля. * Система должна позволять зарегистрированным пользователям входить в систему. * Сессия пользователя должна сохраняться локально. * **FR002: Создание задачи:** * Система должна предоставлять интерфейс для создания новой задачи. * Обязательное поле: Название задачи (строка, макс. 255 символов). * Необязательные поля: Описание (текст), Срок выполнения (Дата и время), ID папки (ссылка). * Новые задачи по умолчанию имеют статус «невыполнена». * **FR003: Просмотр задач:** * Система должна отображать список задач. * По умолчанию должны отображаться невыполненные задачи, возможно, отсортированные по сроку выполнения. * Пользователи должны иметь возможность фильтровать задачи по папкам. * Пользователи должны иметь возможность просматривать выполненные задачи (возможно, в отдельном разделе или через фильтр). * Элементы списка задач должны отображать название, срок выполнения (если установлен) и связанную папку (если установлена). * **FR004: Обновление задачи:** * Система должна позволять пользователям изменять название, описание, срок выполнения и папку существующей задачи. * Система должна позволять пользователям переключать статус выполнения задачи (выполнена/невыполнена). * **FR005: Удаление задачи:** * Система должна позволять пользователям безвозвратно удалять задачу. Следует предусмотреть диалоговое окно для подтверждения. * **FR006: Управление папками:** * Система должна позволять пользователям создавать именованные папки. * Система должна позволять пользователям переименовывать существующие папки. * Система должна позволять пользователям удалять папки. При удалении папки необходимо обработать связанные задачи (например, отвязать их или запросить действие у пользователя). По умолчанию: Отвязать задачи от удаленной папки. * **FR007: Уведомления:** * Система должна планировать локальное push-уведомление для задач с установленными датой и временем выполнения. * Уведомление должно срабатывать в указанное время. * Содержимое уведомления должно включать название задачи. * Нажатие на уведомление в идеале должно открывать приложение, возможно, с выделением соответствующей задачи. * **FR008: Статистика:** * Система должна рассчитывать и отображать общее количество задач, отмеченных как выполненные в течение текущей календарной недели (например, с понедельника по воскресенье или с воскресенья по субботу). * Эта статистика должна отображаться в специальном разделе или на панели.

7. Нефункциональные требования

* **NFR001: Платформа:** Приложение должно работать на мобильных платформах iOS и Android. * **NFR002: Производительность:** Интерфейс приложения должен быть отзывчивым. Загрузка и фильтрация списка задач должны быть почти мгновенными при типичных объемах данных пользователя (< 1000 задач). * **NFR003: Удобство использования:** Приложение должно иметь чистый, интуитивно понятный и простой пользовательский интерфейс, подходящий для нетехнических пользователей. Основные действия (добавить задачу, просмотреть список, отметить как выполненную) должны быть легкодоступны. * **NFR004: Надежность:** Данные о задачах должны сохраняться локально на устройстве. Уведомления должны срабатывать надежно, даже если приложение не находится на переднем плане. * **NFR005: Хранилище:** Для хранения данных пользователя (задачи, папки) должно использоваться локальное хранилище (например, SQLite, Realm или специфичное для платформы). * **NFR006: Безопасность:** Если используется аутентификация по email/паролю, пароли должны храниться в безопасном (хэшированном) виде. Локальные данные должны храниться в изолированном хранилище приложения. * **NFR007: Поддерживаемость:** Код должен соответствовать стандартным соглашениям и архитектурным паттернам выбранного технологического стека для облегчения будущих обновлений.

8. Модель данных

* **User (Пользователь):** `user_id` (PK), `email`, `password_hash`, `created_at` * **Folder (Папка):** `folder_id` (PK), `user_id` (FK), `name` (строка, уникальное для пользователя), `created_at` * **Task (Задача):** `task_id` (PK), `user_id` (FK), `folder_id` (FK, может быть null), `title` (строка, не null), `description` (текст, может быть null), `due_date` (datetime, может быть null), `is_completed` (boolean, по умолчанию: false), `created_at` (datetime), `completed_at` (datetime, может быть null)

9. Критерии выпуска

* Все определенные пользовательские истории (US001-US012) реализованы и прошли тестирование. * Основная функциональность (CRUD задач/папок, уведомления, статистика) работает надежно на целевых платформах. * В ходе тестирования не выявлено критических или серьезных ошибок. * Приложение соответствует базовым нефункциональным требованиям к производительности и удобству использования.   # frontend_guidelines.md

1. Обзор

Этот документ содержит руководство по frontend-разработке для мобильного приложения по управлению задачами. Целевые платформы — iOS и Android. Для эффективности рекомендуется использовать кроссплатформенный фреймворк, такой как React Native или Flutter, но нативная разработка также является возможным вариантом. Руководство предполагает кроссплатформенный подход с использованием Flutter и пакета Provider/Riverpod для управления состоянием, но принципы могут быть адаптированы.

2. Архитектура UI

* **Паттерн:** Model-View-ViewModel (MVVM) или аналогичный паттерн управления состоянием, такой как BLoC/Cubit (Flutter) или Provider/Riverpod (Flutter). * **Model:** Представляет структуры данных (Задача, Папка). Находится на уровне данных. * **View:** Представляет компоненты UI (Экраны, Виджеты). Предпочтительны виджеты без состояния (stateless), которые реагируют на изменения состояния от ViewModel/Provider. * **ViewModel/Provider/Bloc:** Управляет состоянием для View, обрабатывает взаимодействия с пользователем, получает данные из репозиториев и предоставляет потоки/уведомители для прослушивания View. * **Разделение ответственности (Separation of Concerns):** Логика UI должна быть строго отделена от бизнес-логики и логики доступа к данным. ViewModel/Provider не должны содержать платформо-зависимый код UI.

3. Библиотека компонентов и стили

* **Инструментарий UI:** Используйте стандартные виджеты, предоставляемые выбранным фреймворком (например, виджеты Material или Cupertino во Flutter, основные компоненты в React Native). * **Согласованность:** Поддерживайте единый визуальный стиль во всем приложении. Определите основную цветовую палитру, типографику (размеры шрифтов, насыщенность) и правила отступов в центральном файле темы (`theme.dart` во Flutter). * **Ключевые компоненты:** * `TaskListScreen`: Отображает список задач, включает опции фильтрации/сортировки. * `TaskListItem`: Виджет, представляющий одну задачу в списке (показывает название, срок, флажок, индикатор папки). * `TaskDetailScreen`: Отображает полную информацию о задаче, позволяет редактировать. * `TaskEditForm`: Форма для создания/редактирования задач (поля ввода для названия, описания, выбор даты, выбор папки). * `FolderListScreen`: Отображает список папок, позволяет управлять ими (добавлять, переименовывать, удалять). * `FolderListItem`: Виджет, представляющий одну папку. * `StatsScreen`: Отображает еженедельный счетчик выполненных задач. * `AuthScreen`: Обрабатывает формы входа/регистрации пользователя. * `AppLayout/Scaffold`: Единая панель приложения, навигация (например, нижняя навигационная панель или боковое меню). * **Адаптивность:** Хотя приложение в первую очередь ориентировано на телефоны, убедитесь, что макеты разумно адаптируются к разным размерам экрана и ориентациям, где это применимо (например, с помощью `LayoutBuilder`, `MediaQuery` во Flutter).

4. Управление состоянием

* **Стратегия:** Используйте централизованное решение для управления состоянием (например, Provider, Riverpod, BLoC/Cubit для Flutter; Context API/Redux/Zustand для React Native; ViewModel/LiveData/StateFlow для нативного Android; SwiftUI State/Combine для нативного iOS). * **Область видимости:** Состояние должно иметь соответствующую область видимости (например, глобальное состояние для аутентификации пользователя, состояние на уровне экрана для элементов управления UI, состояние на уровне фичи для данных задач/папок). * **Неизменяемость (Immutability):** По возможности предпочитайте неизменяемые обновления состояния, чтобы упростить управление им и повысить предсказуемость. * **Поток данных:** Поддерживайте однонаправленный поток данных (например, UI инициирует действие -> ViewModel/Provider обновляет состояние -> UI перестраивается на основе нового состояния).

5. Маршрутизация и навигация

* **Стратегия:** Реализуйте четкую систему навигации. Используйте специализированный пакет для маршрутизации (например, `Navigator 2.0` или `go_router` для Flutter, `React Navigation` для React Native). * **Маршруты:** Определите именованные маршруты для всех основных экранов: * `/auth` * `/taskList` (домашний экран) * `/taskDetail/{taskId}` * `/taskEdit/{taskId}` (или `/taskAdd`) * `/folders` * `/stats` * **Переходы:** Используйте стандартные платформенные переходы, если только кастомные анимации не добавляют значительной ценности.

6. Паттерны проектирования

* **Паттерн Репозиторий:** Абстрагируйте логику доступа к данным за интерфейсами репозиториев. ViewModel/Provider взаимодействуют с репозиториями, а не напрямую с источниками данных (локальная БД, API). * **Внедрение зависимостей (Dependency Injection):** Используйте DI (например, `get_it` или встроенные возможности Provider/Riverpod во Flutter) для предоставления зависимостей, таких как репозитории, сервисы (например, NotificationService), в ViewModel/Provider. * **Паттерн Наблюдатель (Observer):** Решения для управления состоянием обычно реализуют этот паттерн (например, `ChangeNotifierProvider`, `StreamProvider`, `BlocBuilder` во Flutter), чтобы View могли реагировать на изменения состояния.

7. Ресурсы (Assets)

* Оптимизируйте изображения и иконки для мобильного использования. * По возможности используйте векторные иконки (например, Material Icons, FontAwesome) для масштабируемости. * Четко управляйте ресурсами в структуре проекта (например, `assets/images`, `assets/icons`).

8. Обработка ошибок

* Отображайте удобные для пользователя сообщения об ошибках для распространенных проблем (например, неверный ввод, сбой сохранения данных). * Используйте механизмы, такие как Snackbar, диалоговые окна или встроенный текст ошибок. * Логируйте подробные ошибки для целей отладки.   # backend_structure.md

1. Обзор

Этот документ описывает структуру серверной части (backend) для мобильного приложения по управлению задачами. Учитывая требования (ориентация на одного пользователя, базовые функции, мобильная платформа), настоятельно рекомендуется использовать Backend-as-a-Service (BaaS), такой как Firebase или Supabase, для обработки аутентификации, базы данных и, возможно, уведомлений с минимальным количеством кастомного кода. В качестве альтернативы, если требуется кастомный backend, будет достаточно простого REST API, созданного на легком фреймворке (например, Node.js/Express, Python/Flask, Go/Gin), подключенного к реляционной базе данных (например, PostgreSQL, SQLite). Этот документ в основном описывает структуру, предполагающую подход **BaaS (Firebase/Supabase)**, с акцентом на модели данных и взаимодействии основной логики. Если бы создавался кастомный backend, конечные точки API точно соответствовали бы описанным функциям.

2. Архитектура

* **Тип:** Backend-as-a-Service (BaaS) - например, Firebase Firestore/Realtime Database или Supabase (PostgreSQL). * **Ключевые сервисы:** * **Аутентификация:** Управляется BaaS (Firebase Auth, Supabase Auth) - обрабатывает регистрацию по email/паролю, вход, управление сессиями. * **База данных:** Управляется BaaS (Firestore, Supabase DB) - хранит данные пользователя, задачи и папки. Возможности реального времени полезны для обновлений UI. * **Облачные функции/Edge Functions (Опционально):** Для серверной логики, если потребуется (например, сложная валидация, агрегация данных, не подходящая для клиентской стороны). Для основной описанной функциональности не требуется. * **Push-уведомления:** Хотя указаны локальные уведомления, BaaS мог бы облегчить будущие облачные уведомления, если это потребуется (например, Firebase Cloud Messaging). Для исключительно локальных уведомлений это обрабатывается на стороне клиента.

3. Схема базы данных

* **Тип базы данных:** NoSQL (как Firestore) или реляционная (как PostgreSQL через Supabase). Схема ниже для ясности предполагает реляционную модель, но адаптируема к коллекциям/документам NoSQL. * **Таблицы/Коллекции:** * **`users`** * `user_id` (PK, String/UUID - часто управляется BaaS Auth) * `email` (String, Unique) * `created_at` (Timestamp) * *(Хэш пароля управляется сервисом BaaS Auth)* * **`folders`** * `folder_id` (PK, UUID) * `user_id` (FK, ссылается на `users.user_id`, индексируется) * `name` (String, Not Null) * `created_at` (Timestamp) * *(Ограничение: `user_id` + `name` должны быть уникальными)* * **`tasks`** * `task_id` (PK, UUID) * `user_id` (FK, ссылается на `users.user_id`, индексируется) * `folder_id` (FK, ссылается на `folders.folder_id`, Nullable) * `title` (String, Not Null, макс. 255 символов) * `description` (Text, Nullable) * `due_date` (Timestamp, Nullable, индексируется) * `is_completed` (Boolean, по умолчанию: `false`, индексируется) * `created_at` (Timestamp) * `completed_at` (Timestamp, Nullable) * *(Рекомендуются индексы для `user_id`, `due_date`, `is_completed` для эффективных запросов)* * **Отношения:** * Один Пользователь имеет много Папок. * Один Пользователь имеет много Задач. * Одна Папка может содержать много Задач (или Задача имеет одну необязательную Папку).

4. Процесс аутентификации

1. **Регистрация:** * Клиент собирает email/пароль. * Клиент вызывает сервис BaaS Auth (`createUserWithEmailAndPassword`). * При успехе BaaS создает запись пользователя и возвращает информацию о нем (включая `user_id`). * Клиент может дополнительно создать соответствующий документ в коллекции `users`, если требуются дополнительные данные профиля, помимо предоставляемых Auth. 2. **Вход:** * Клиент собирает email/пароль. * Клиент вызывает сервис BaaS Auth (`signInWithEmailAndPassword`). * При успехе BaaS возвращает информацию о пользователе и устанавливает сессию (например, JWT-токен). * Клиент безопасно сохраняет информацию о сессии и использует ее для последующих запросов. 3. **Управление сессией:** * SDK от BaaS обычно автоматически обрабатывают обновление токенов и сохранение сессии. * Правила доступа к базе данных должны быть настроены так, чтобы пользователи могли получать доступ только к своим собственным данным (правила на основе `user_id`).

5. Бизнес-логика и доступ к данным

* **Расположение:** В основном находится на уровне данных мобильного приложения (Репозитории), взаимодействуя напрямую с SDK BaaS. * **Валидация данных:** Базовая валидация (например, обязательные поля, ограничения длины) должна происходить на стороне клиента перед отправкой данных в BaaS. Более критическая валидация может быть обеспечена с помощью Правил безопасности базы данных (например, проверка соответствия `user_id` аутентифицированному пользователю). * **Запросы к базе данных (Примеры):** * Получить невыполненные задачи пользователя: `SELECT * FROM tasks WHERE user_id = ? AND is_completed = false ORDER BY due_date ASC` * Получить задачи в определенной папке: `SELECT * FROM tasks WHERE user_id = ? AND folder_id = ?` * Получить папки пользователя: `SELECT * FROM folders WHERE user_id = ? ORDER BY name ASC` * Подсчитать выполненные задачи за неделю: `SELECT COUNT(*) FROM tasks WHERE user_id = ? AND is_completed = true AND completed_at >= start_of_week AND completed_at <= end_of_week` (Расчет диапазона дат выполняется на клиенте или через функцию БД, если доступно). * **Правила безопасности (Критически важно для BaaS):** * Определите правила в консоли BaaS (например, Firestore Security Rules, Supabase Row Level Security Policies). * Убедитесь, что пользователи могут читать/писать только свои собственные задачи и папки (сопоставление `request.auth.uid == resource.data.user_id`). * По возможности валидируйте типы данных и обязательные поля в правилах.

6. Конечные точки API (Концептуально - обрабатываются SDK BaaS)

Если бы создавался кастомный REST API, конечные точки соответствовали бы CRUD-операциям: * `POST /auth/register` * `POST /auth/login` * `GET /tasks?folderId={id}&completed={bool}&sortBy=dueDate` * `POST /tasks` (Тело: { title, description?, dueDate?, folderId? }) * `GET /tasks/{taskId}` * `PUT /tasks/{taskId}` (Тело: поля для обновления) * `DELETE /tasks/{taskId}` * `GET /folders` * `POST /folders` (Тело: { name }) * `PUT /folders/{folderId}` (Тело: { name }) * `DELETE /folders/{folderId}` * `GET /stats/weekly-completed` **Примечание:** С BaaS эти операции выполняются с помощью предоставляемых SDK методов (например, `firestore.collection('tasks').add(...)`, `supabase.from('tasks').select('*').eq('user_id', userId)`).   # app_flow.md

1. Обзор

Этот документ описывает основные пользовательские сценарии, переходы состояний и механизмы обработки ошибок в мобильном приложении по управлению задачами.

2. Пользовательские сценарии

2.1. Сценарий онбординга и аутентификации

1. **Запуск приложения:** * **Состояние:** Инициализация. * **Действие:** Проверить наличие существующей валидной сессии пользователя (например, сохраненный токен/информация о сессии). * **Переход:** * Если сессия валидна -> Переход к основному сценарию приложения (Список задач). * Если сессии нет -> Переход к Экрану аутентификации. 2. **Экран аутентификации (Вход/Регистрация):** * **Состояние:** Ожидание аутентификации. * **Действие пользователя (Вход):** Вводит email/пароль, нажимает «Войти». * **Действие:** Вызвать сервис аутентификации (`signInWithEmailAndPassword`). * **Переход:** * При успехе -> Сохранить сессию, перейти к основному сценарию приложения (Список задач). * При неудаче (неверные учетные данные, сетевая ошибка) -> Показать сообщение об ошибке на Экране аутентификации. * **Действие пользователя (Регистрация):** Нажимает «Зарегистрироваться», вводит email/пароль, нажимает «Зарегистрироваться». * **Действие:** Вызвать сервис аутентификации (`createUserWithEmailAndPassword`). * **Переход:** * При успехе -> Сохранить сессию, перейти к основному сценарию приложения (Список задач). * При неудаче (email уже существует, слабый пароль, сетевая ошибка) -> Показать сообщение об ошибке на Экране аутентификации.

2.2. Основной сценарий управления задачами

1. **Просмотр списка задач:** * **Состояние:** Отображение Экрана списка задач (По умолчанию: невыполненные задачи, отсортированные по сроку). * **Действие:** Получить задачи для вошедшего пользователя из Репозитория/BaaS. Прослушивать обновления в реальном времени, если применимо. * **Действие пользователя (Добавить задачу):** Нажимает кнопку «Добавить задачу». * **Переход:** Перейти на Экран добавления/редактирования задачи (в режиме «Добавление»). * **Действие пользователя (Нажать на задачу):** Нажимает на элемент задачи в списке. * **Переход:** Перейти на Экран деталей задачи (передав `taskId`). * **Действие пользователя (Отметить как выполненную):** Нажимает на флажок у элемента задачи. * **Действие:** Обновить статус задачи (`is_completed = true`, установить `completed_at`) через Репозиторий/BaaS. * **Переход:** UI обновляется (задача может переместиться/изменить вид). Неявно обновить еженедельный счетчик статистики. * **Действие пользователя (Фильтровать/Сортировать):** Использует элементы управления фильтрацией (например, выбор папки, просмотр выполненных). * **Действие:** Повторно получить/отфильтровать задачи по выбранным критериям. * **Переход:** Список задач обновляется на месте. * **Действие пользователя (Навигация):** Нажимает на элемент навигации (например, вкладку/иконку Папки, вкладку/иконку Статистика). * **Переход:** Перейти на Экран списка папок или Экран статистики. 2. **Добавление/Редактирование задачи:** * **Состояние:** Отображение Экрана добавления/редактирования задачи (заполнен данными задачи, если редактирование). * **Действие пользователя (Ввод данных):** Вводит/изменяет название, описание, выбирает срок (через выбор даты/времени), выбирает папку (через выпадающий список/модальное окно). * **Действие пользователя (Сохранить):** Нажимает кнопку «Сохранить». * **Действие:** Выполнить валидацию на стороне клиента (например, название не пустое). * **Действие:** Вызвать Репозиторий/BaaS для создания или обновления задачи. * **Переход:** * При успехе -> Вернуться на Экран списка задач (список должен обновиться). * При неудаче (ошибка валидации, сетевая ошибка) -> Показать сообщение об ошибке на Экране добавления/редактирования. * **Действие пользователя (Отмена/Назад):** Нажимает «Отмена» или навигацию назад. * **Переход:** Вернуться на предыдущий экран (Список задач или Детали) без сохранения изменений (запросить подтверждение, если были внесены изменения). 3. **Просмотр деталей задачи:** * **Состояние:** Отображение Экрана деталей задачи с данными для конкретного `taskId`. * **Действие:** Получить полные детали задачи из Репозитория/BaaS. * **Действие пользователя (Редактировать):** Нажимает кнопку «Редактировать». * **Переход:** Перейти на Экран добавления/редактирования задачи (в режиме «Редактирование», передав `taskId`). * **Действие пользователя (Удалить):** Нажимает кнопку «Удалить». * **Действие:** Показать диалог подтверждения. * **Действие (Подтвердить удаление):** Вызвать Репозиторий/BaaS для удаления задачи. * **Переход:** Вернуться на Экран списка задач (список должен обновиться). * **Действие пользователя (Отметить выполненной/невыполненной):** Нажимает переключатель/флажок. * **Действие:** Обновить статус задачи через Репозиторий/BaaS. * **Переход:** UI обновляется на месте. Вернуться на Список задач или остаться на детальном просмотре с отражением изменений.

2.3. Сценарий управления папками

1. **Просмотр списка папок:** * **Состояние:** Отображение Экрана списка папок. * **Действие:** Получить папки для вошедшего пользователя из Репозитория/BaaS. * **Действие пользователя (Добавить папку):** Нажимает кнопку/иконку «Добавить папку». * **Действие:** Показать диалог/поле ввода для имени новой папки. * **Действие (Сохранить новую):** Вызвать Репозиторий/BaaS для создания папки. Обработать возможные конфликты имен. * **Переход:** Список папок обновляется. Показать сообщение об успехе/ошибке. * **Действие пользователя (Выбрать папку):** Нажимает на элемент папки. * **Переход:** Перейти на Экран списка задач, отфильтрованный по выбранной папке. * **Действие пользователя (Редактировать папку):** Нажимает иконку «Редактировать» у элемента папки. * **Действие:** Показать диалог/поле ввода, предварительно заполненное текущим именем папки. * **Действие (Сохранить изменения):** Вызвать Репозиторий/BaaS для обновления имени папки. Обработать возможные конфликты имен. * **Переход:** Список папок обновляется. Показать сообщение об успехе/ошибке. * **Действие пользователя (Удалить папку):** Нажимает иконку «Удалить» у элемента папки. * **Действие:** Показать диалог подтверждения (упомянув обработку задач - например, «Задачи в этой папке будут отвязаны»). * **Действие (Подтвердить удаление):** Вызвать Репозиторий/BaaS для удаления папки. Обновить связанные задачи (`folder_id = null`). * **Переход:** Список папок обновляется.

2.4. Сценарий просмотра статистики

1. **Просмотр экрана статистики:** * **Состояние:** Отображение Экрана статистики. * **Действие:** Получить из Репозитория/BaaS задачи, выполненные в течение текущей недели (на основе метки времени `completed_at`). Рассчитать количество. * **Переход:** Отобразить рассчитанное количество (например, «На этой неделе Вы выполнили X задач!»).

3. Переходы состояний (Сводка)

* **`Инициализация`** -> (`Аутентифицирован`) -> `СписокЗадач` * **`Инициализация`** -> (`Не аутентифицирован`) -> `Аутентификация` * **`Аутентификация`** -> (`Успешный вход/регистрация`) -> `СписокЗадач` * **`Аутентификация`** -> (`Неудачный вход/регистрация`) -> `Аутентификация` (с ошибкой) * **`СписокЗадач`** -> (`Нажать Добавить`) -> `Добавление/РедактированиеЗадачи` * **`СписокЗадач`** -> (`Нажать Задачу`) -> `ДеталиЗадачи` * **`СписокЗадач`** -> (`Перейти к Папкам`) -> `СписокПапок` * **`СписокЗадач`** -> (`Перейти к Статистике`) -> `Статистика` * **`Добавление/РедактированиеЗадачи`** -> (`Успешное сохранение`) -> `СписокЗадач` * **`Добавление/РедактированиеЗадачи`** -> (`Неудачное сохранение`) -> `Добавление/РедактированиеЗадачи` (с ошибкой) * **`Добавление/РедактированиеЗадачи`** -> (`Отмена/Назад`) -> `СписокЗадач` / `ДеталиЗадачи` * **`ДеталиЗадачи`** -> (`Нажать Редактировать`) -> `Добавление/РедактированиеЗадачи` * **`ДеталиЗадачи`** -> (`Успешное удаление`) -> `СписокЗадач` * **`СписокПапок`** -> (`Выбрать Папку`) -> `СписокЗадач` (отфильтрованный) * **`СписокПапок`** -> (`Назад`) -> `СписокЗадач` (или предыдущий экран)

4. Обработка ошибок и крайние случаи

* **Сетевые ошибки:** Отображать ненавязчивый индикатор (например, Snackbar) при сбое операций BaaS из-за проблем с сетью. Позволять пользователю повторить действия, где это уместно. Кэшировать данные локально для офлайн-просмотра, если возможно (хотя редактирование в офлайн-режиме может быть отключено). * **Ошибки аутентификации:** Предоставлять четкую обратную связь на экране аутентификации (например, «Неверный email или пароль», «Email уже существует»). * **Ошибки валидации:** Отображать встроенные ошибки в формах (например, «Название не может быть пустым») перед попыткой сохранения. * **Конфликты синхронизации данных (Менее вероятно при фокусе на BaaS/одном устройстве):** Если бы была добавлена облачная синхронизация, реализовать стратегию разрешения конфликтов (например, «побеждает последняя запись»). * **Разрешения на уведомления:** Запрашивать у пользователя разрешения на уведомления в подходящее время (например, когда он впервые устанавливает срок выполнения). Корректно обрабатывать случаи, когда разрешение отклонено (информировать пользователя, что уведомления работать не будут). * **Удаление папки:** Четко сообщать о влиянии на задачи в удаляемой папке. Убедиться, что задачи корректно обновляются (например, `folder_id` устанавливается в null). * **Пустые состояния:** Предоставлять информативные сообщения, когда списки пусты (например, «Задач пока нет. Нажмите '+', чтобы добавить!», «Папки не созданы.»).   # tech_stack.md

1. Обзор

Этот документ описывает рекомендуемый технологический стек для создания мобильного приложения по управлению задачами, нацеленного на платформы iOS и Android. Выбор технологий сделан с приоритетом на скорость разработки, простоту использования для основных функций (аутентификация, БД, уведомления) и поддерживаемость.

2. Целевая платформа

* **Основная:** Мобильная (iOS и Android)

3. Фронтенд (Мобильное приложение)

* **Рекомендуемый фреймворк:** **Flutter** * **Обоснование:** Позволяет создавать нативно компилируемые приложения для мобильных устройств из единой кодовой базы. Предлагает отличную производительность, богатую библиотеку виджетов (Material и Cupertino), сильную поддержку сообщества и хорошую интеграцию с Firebase. Горячая перезагрузка (Hot Reload) значительно ускоряет разработку. * **Альтернативы:** * **React Native:** Еще один сильный кроссплатформенный вариант, особенно если у команды разработчиков есть опыт работы с React. Использует JavaScript/TypeScript. * **Нативный iOS (Swift/SwiftUI) и Нативный Android (Kotlin/Jetpack Compose):** Обеспечивает наилучшую интеграцию с платформой и производительность, но требует отдельных кодовых баз и усилий по разработке. Подходит, если первостепенное значение имеют специфичные для платформы функции или если существуют отдельные нативные команды. * **Язык (если Flutter):** Dart * **Управление состоянием (если Flutter):** **Riverpod** или **Provider** * **Обоснование:** Предоставляют гибкие и масштабируемые способы управления состоянием приложения, облегчая внедрение зависимостей и разделение ответственности (паттерны MVVM/BLoC). Riverpod в целом считается более современным и безопасным на этапе компиляции. * **Маршрутизация (если Flutter):** **go_router** или Flutter Navigator 2.0 API * **Обоснование:** Обеспечивает надежную, декларативную навигацию и возможности глубоких ссылок (deep linking). `go_router` упрощает использование Navigator 2.0. * **Локальные уведомления:** Пакет **flutter_local_notifications** * **Обоснование:** Популярный и хорошо поддерживаемый плагин для планирования и отображения локальных уведомлений как на iOS, так и на Android.

4. Бэкенд

* **Рекомендуемый тип бэкенда:** **Backend-as-a-Service (BaaS)** * **Конкретная рекомендация BaaS:** **Firebase** * **Обоснование:** Предлагает полный набор тесно интегрированных сервисов, хорошо подходящих для мобильных приложений. Простая настройка и щедрый бесплатный тариф. * **Аутентификация:** Firebase Authentication (обрабатывает вход по email/паролю, потенциально социальные логины в будущем). * **База данных:** Firestore (NoSQL, реальное время, масштабируемая, хорошие возможности запросов, поддержка офлайн-режима) или Realtime Database (более простая структура JSON, очень низкая задержка). Firestore обычно предпочтительнее для более сложных структур данных и запросов. * **Облачные функции (Опционально):** Для любой серверной логики, если потребуется в будущем. * **Альтернативы:** * **Supabase:** Альтернатива Firebase с открытым исходным кодом, предоставляющая базу данных PostgreSQL, аутентификацию, Edge Functions и подписки в реальном времени. Отличный выбор, если предпочтительна реляционная структура данных или требуется открытый исходный код. * **AWS Amplify:** Комплексное предложение BaaS от AWS. * **Кастомный бэкенд:** (Node.js/Express, Python/Flask/Django, Go/Gin и т.д. с PostgreSQL/MySQL/MongoDB). Больше контроля, но значительно выше накладные расходы на разработку и обслуживание для масштаба этого проекта. Не рекомендуется, если нет особых потребностей.

5. База данных

* **Рекомендация (если Firebase):** **Firestore** * **Обоснование:** Гибкая NoSQL документо-ориентированная база данных, обновления в реальном времени, офлайн-сохранение, надежные правила безопасности, автоматическое масштабирование. Хорошо подходит для предложенной модели данных. * **Рекомендация (если Supabase):** **PostgreSQL** * **Обоснование:** Мощная реляционная база данных, предоставляемая Supabase, позволяет использовать структурированные данные, ограничения и SQL-запросы. * **Рекомендация (если кастомный бэкенд):** **PostgreSQL** или **SQLite** (если планируется строго локальное использование без синхронизации) * **Обоснование:** PostgreSQL — это надежная реляционная база данных с открытым исходным кодом. SQLite основана на файлах и подходит для чисто локального хранения данных в приложении.

6. Хостинг

* **Неприменимо (если используется BaaS):** Поставщик BaaS сам занимается хостингом бэкенда. * **Если кастомный бэкенд:** * **Platform-as-a-Service (PaaS):** Heroku, Google Cloud Run, AWS Elastic Beanstalk. (Простое развертывание и масштабирование). * **Бессерверные функции:** AWS Lambda, Google Cloud Functions, Azure Functions. (Экономично для логики, управляемой событиями). * **Виртуальный частный сервер (VPS):** DigitalOcean, Linode, AWS EC2. (Больше контроля, больше накладных расходов на управление).

7. Сторонние сервисы

* **Локальные уведомления:** Обрабатываются пакетом на стороне клиента (например, `flutter_local_notifications`). * **(Опционально) Аналитика:** Firebase Analytics, Google Analytics for Mobile Apps (для понимания вовлеченности пользователей, если потребуется позже). * **(Опционально) Отчеты о сбоях:** Firebase Crashlytics, Sentry (для мониторинга стабильности приложения).

8. Инструменты разработки

* **IDE:** VS Code (отличная поддержка Flutter/Dart) или Android Studio / IntelliJ IDEA. * **Система контроля версий:** Git (с использованием платформ, таких как GitHub, GitLab, Bitbucket). * **Менеджер пакетов:** Pub (Dart/Flutter), npm/yarn (React Native). * **Дизайн:** Figma, Sketch, Adobe XD (для макетов и прототипов UI).

9. Сводная таблица

| Категория | Рекомендация | Обоснование | Альтернативы | | :--- | :--- | :--- | :--- | | **Платформа** | Мобильная (iOS, Android) | Требование пользователя | - | | **Фреймворк Frontend** | Flutter | Единая кодовая база, нативная производительность, быстрая разработка | React Native, Нативный Swift/Kotlin | | **Управление состоянием** | Riverpod / Provider (Flutter) | Масштабируемое управление состоянием, DI | BLoC/Cubit, Redux, Zustand, Context API | | **Бэкенд** | BaaS (Firebase) | Интегрированные Auth/DB, быстрая настройка, масштабируемость | Supabase, AWS Amplify, Кастомный бэкенд | | **База данных** | Firestore (через Firebase) | Реальное время, гибкость NoSQL, офлайн-режим, безопасность | Realtime DB (Firebase), PostgreSQL (Supabase) | | **Уведомления** | `flutter_local_notifications` | Кроссплатформенное планирование локальных уведомлений | Специфичные для платформы API | | **Контроль версий** | Git / GitHub | Стандарт для управления исходным кодом | GitLab, Bitbucket | | **IDE** | VS Code | Отличная кроссплатформенная поддержка и поддержка Flutter | Android Studio, IntelliJ, Xcode |   # file_structure.md

1. Обзор

Этот документ описывает рекомендуемую структуру файлов для мобильного приложения по управлению задачами, предполагая использование **Flutter** и паттерна управления состоянием **Riverpod/Provider** с паттерном **Репозиторий** для доступа к данным. Эта структура способствует разделению ответственности, поддерживаемости и масштабируемости.

2. Структура корневого каталога

task_manager_app/
├── android/ # Файлы нативного проекта Android
├── ios/ # Файлы нативного проекта iOS
├── lib/ # Основной код приложения на Dart
│ ├── main.dart # Точка входа в приложение, инициализация Firebase, настройка провайдеров
│ ├── app.dart # Корневой виджет приложения (MaterialApp/CupertinoApp), тема, маршрутизация
│ │
│ ├── core/ # Основные утилиты, константы, базовые классы
│ │ ├── constants/ # Константы для всего приложения (строки, числа, ключи)
│ │ │ └── app_constants.dart
│ │ ├── error/ # Классы обработки ошибок (Failure, Exceptions)
│ │ │ ├── exceptions.dart
│ │ │ └── failure.dart
│ │ ├── navigation/ # Конфигурация маршрутизации (например, настройка go_router)
│ │ │ └── app_router.dart
│ │ ├── theme/ # Данные темы приложения
│ │ │ └── app_theme.dart
│ │ ├── usecases/ # Базовый класс для use case (опционально)
│ │ │ └── usecase.dart
│ │ └── utils/ # Вспомогательные функции (форматтеры дат, валидаторы)
│ │ └── date_formatter.dart
│ │
│ ├── data/ # Слой данных: модели, источники, репозитории
│ │ ├── datasources/ # Источники данных (локальная БД, удаленный API/BaaS)
│ │ │ ├── local/ # Локальное хранилище данных (например, sqflite, hive, shared_prefs)
│ │ │ │ └── task_local_datasource.dart
│ │ │ └── remote/ # Взаимодействие с удаленными данными (например, вызовы Firebase SDK)
│ │ │ ├── firebase_auth_service.dart
│ │ │ ├── firestore_folder_service.dart
│ │ │ └── firestore_task_service.dart
│ │ ├── models/ # Модели данных (простые объекты Dart)
│ │ │ ├── folder_model.dart
│ │ │ └── task_model.dart
│ │ └── repositories/ # Реализации репозиториев (абстрагирующие источники данных)
│ │ ├── auth_repository_impl.dart
│ │ ├── folder_repository_impl.dart
│ │ └── task_repository_impl.dart
│ │
│ ├── domain/ # Доменный слой: сущности, интерфейсы репозиториев, use cases
│ │ ├── entities/ # Ключевые бизнес-объекты (независимые от слоя данных)
│ │ │ ├── folder.dart
│ │ │ └── task.dart
│ │ ├── repositories/ # Абстрактные интерфейсы репозиториев
│ │ │ ├── auth_repository.dart
│ │ │ ├── folder_repository.dart
│ │ │ └── task_repository.dart
│ │ └── usecases/ # Единицы бизнес-логики (интеракторы)
│ │ ├── auth/
│ │ │ ├── login_user.dart
│ │ │ └── register_user.dart
│ │ ├── folders/
│ │ │ ├── add_folder.dart
│ │ │ ├── delete_folder.dart
│ │ │ ├── get_folders.dart
│ │ │ └── update_folder.dart
│ │ └── tasks/
│ │ ├── add_task.dart
│ │ ├── delete_task.dart
│ │ ├── get_tasks.dart
│ │ ├── get_weekly_completed_count.dart
│ │ └── update_task.dart
│ │
│ ├── presentation/ # Слой представления: UI (Виджеты/Экраны), Управление состоянием (Провайдеры/ViewModel/Bloc)
│ │ ├── providers/ # Логика управления состоянием (Riverpod Providers, ChangeNotifiers, BLoC)
│ │ │ ├── auth_provider.dart
│ │ │ ├── folder_provider.dart
│ │ │ ├── stats_provider.dart
│ │ │ └── task_provider.dart
│ │ ├── screens/ # Представления верхнего уровня для каждого маршрута/фичи
│ │ │ ├── auth/
│ │ │ │ └── auth_screen.dart
│ │ │ ├── folders/
│ │ │ │ └── folder_list_screen.dart
│ │ │ ├── stats/
│ │ │ │ └── stats_screen.dart
│ │ │ └── tasks/
│ │ │ ├── task_add_edit_screen.dart
│ │ │ ├── task_detail_screen.dart
│ │ │ └── task_list_screen.dart
│ │ └── widgets/ # Переиспользуемые компоненты UI, общие для экранов
│ │ ├── common/ # Очень общие виджеты (кнопки, поля ввода, загрузчики)
│ │ │ └── loading_indicator.dart
│ │ ├── folders/ # Виджеты, специфичные для функционала папок
│ │ │ └── folder_list_item.dart
│ │ └── tasks/ # Виджеты, специфичные для функционала задач
│ │ ├── task_list_item.dart
│ │ └── task_form.dart
│ │
│ └── services/ # Интеграции с внешними сервисами
│ └── notification_service.dart # Обертка для плагина локальных уведомлений
│
├── test/ # Модульные, виджет- и интеграционные тесты
│ ├── core/
│ ├── data/
│ ├── domain/
│ └── presentation/
│
├── pubspec.yaml # Зависимости и метаданные проекта
├── pubspec.lock # Зафиксированные версии зависимостей
├── README.md # Описание проекта
└── .gitignore # Файлы/папки, игнорируемые Git

3. Описание слоев

* **`lib/`**: Содержит весь код приложения на Dart. * **`lib/core/`**: Фундаментальный код, используемый на нескольких слоях. Включает константы, базовые классы, вспомогательные функции, определения для обработки ошибок, тему и настройку навигации. Не зависит от других слоев, за исключением возможной зависимости от `domain` для базовых use cases. * **`lib/data/`**: Отвечает за получение и хранение данных. Содержит реализации источников данных (как общаться с Firebase, локальной БД), модели данных (часто с логикой сериализации) и конкретные реализации репозиториев, которые выполняют контракты, определенные в слое `domain`. Зависит от `core` и `domain` (для интерфейсов). * **`lib/domain/`**: Слой основной бизнес-логики. Содержит чистые бизнес-сущности, абстрактные интерфейсы репозиториев (определяющие, *какие* операции с данными необходимы, а не *как* их выполнять) и use cases (интеракторы), которые организуют поток данных между представлением и репозиториями. Должен быть независимым от `data` и `presentation`. Зависит только от `core` (опционально). * **`lib/presentation/`**: Слой UI. Содержит экраны (виджеты, представляющие полные представления), более мелкие переиспользуемые виджеты и логику управления состоянием (Провайдеры, ViewModel, BLoC). Отвечает за отображение данных и обработку пользовательского ввода. Зависит от `domain` (для вызова use cases) и `core`. * **`lib/services/`**: Обертки или обработчики для внешних сервисов, таких как уведомления, аналитика и т.д. Часто используются слоями `presentation` или `data` через внедрение зависимостей. Зависит от `core`. * **`test/`**: Содержит все автоматизированные тесты, повторяя структуру каталога `lib/`.

4. Ключевые файлы

* **`lib/main.dart`**: Инициализирует приложение, настраивает внедрение зависимостей (при необходимости), инициализирует Firebase/BaaS и запускает главный виджет приложения. * **`lib/app.dart`**: Определяет корневой `MaterialApp` или `CupertinoApp`, настраивает тему и маршрутизатор. * **`lib/core/navigation/app_router.dart`**: Настраивает все маршруты приложения с использованием выбранного пакета маршрутизации (например, `go_router`). * **`lib/core/theme/app_theme.dart`**: Определяет цвета, типографику и другие константы стиля UI. * **`pubspec.yaml`**: Определяет все зависимости проекта (Flutter SDK, пакеты, такие как `firebase_core`, `cloud_firestore`, `firebase_auth`, `flutter_riverpod`, `go_router`, `flutter_local_notifications` и т.д.). Эта структура обеспечивает четкое разделение, которое помогает управлять сложностью, тестировать компоненты в изоляции и адаптироваться к изменениям.   # trigger_prompt.md

Промпт для генерации ИИ-кода

**Цель:** Сгенерируй исходный код для мобильного приложения по управлению задачами с использованием Flutter и Firebase (Firestore и Auth). **Целевая платформа:** iOS и Android. **Основные требования:** 1. **Технологический стек:** * Фронтенд: Flutter (последняя стабильная версия) * Язык: Dart * Управление состоянием: Riverpod * Бэкенд: Firebase (Authentication, Firestore) * Маршрутизация: `go_router` * Локальные уведомления: `flutter_local_notifications` * Архитектура: Следуй принципам MVVM/Clean Architecture (разделенные слои Presentation, Domain, Data). 2. **Структура файлов:** Реализуй следующую структуру: ``` lib/ ├── core/ (constants, error, navigation, theme, utils) ├── data/ (datasources/remote, models, repositories_impl) ├── domain/ (entities, repositories, usecases) ├── presentation/ (providers, screens, widgets) ├── services/ (notification_service.dart) ├── main.dart └── app.dart ``` *(Обратись к `file_structure.md` для детальной разбивки)* 3. **Настройка Firebase:** * Предполагай, что проект Firebase уже предварительно настроен. * Инициализируй Firebase в `main.dart`. * Используй `firebase_auth` для регистрации и входа по email/паролю. * Используй `cloud_firestore` для хранения данных. 4. **Схема базы данных (Коллекции Firestore):** * `users`: (В основном управляется Firebase Auth, возможно, документ на пользователя для данных профиля, если потребуется) * `folders`: Поля: `userId` (string, FK), `name` (string), `createdAt` (timestamp). Обеспечь уникальность `name` для каждого `userId`. * `tasks`: Поля: `userId` (string, FK), `folderId` (string, nullable), `title` (string), `description` (string, nullable), `dueDate` (timestamp, nullable), `isCompleted` (bool), `createdAt` (timestamp), `completedAt` (timestamp, nullable). Проиндексируй соответствующие поля (`userId`, `isCompleted`, `dueDate`). 5. **Аутентификация:** * Реализуй `AuthScreen` с формами для входа и регистрации по email/паролю. * Используй провайдеры Riverpod (`auth_provider.dart`) для управления состоянием аутентификации (вошел/вышел, ID пользователя). * Реализуй интерфейс `AuthRepository` (domain) и `AuthRepositoryImpl` (data), взаимодействующий с `FirebaseAuth`. * Реализуй use cases `LoginUser` и `RegisterUser` (domain). * Перенаправляй пользователей на `TaskListScreen` после успешного входа/регистрации, в противном случае показывай ошибки на `AuthScreen`. * Обеспечь сохранение состояния входа. 6. **Функционал управления задачами:** * Реализуй интерфейс `TaskRepository` и `TaskRepositoryImpl`, используя Firestore. * Реализуй use cases: `AddTask`, `UpdateTask`, `DeleteTask`, `GetTasks` (с фильтрацией по статусу выполнения, folderId, сортировкой по `dueDate`). * Реализуй `TaskListScreen`: Отображай задачи (используй `StreamProvider` для обновлений из Firestore в реальном времени). Позволяй отмечать задачи как выполненные через флажок прямо в элементе списка (виджет `TaskListItem`). Включи FloatingActionButton для перехода на `TaskAddEditScreen`. Разреши фильтрацию (например, через выпадающий список или вкладки). * Реализуй `TaskAddEditScreen`: Форма (виджет `TaskForm`) для создания/редактирования задач (название, описание, выбор даты, выпадающий список для выбора папки, заполненный папками пользователя). Используй провайдер Riverpod (`task_provider.dart`) для управления состоянием формы и взаимодействия с use cases. * Реализуй `TaskDetailScreen` (опционально, или объедини просмотр/редактирование): Отображай полные детали задачи. Разреши переход в режим редактирования. 7. **Функционал управления папками:** * Реализуй интерфейс `FolderRepository` и `FolderRepositoryImpl`, используя Firestore. * Реализуй use cases: `AddFolder`, `UpdateFolder`, `DeleteFolder`, `GetFolders`. * Реализуй `FolderListScreen`: Отображай папки пользователя (виджет `FolderListItem`). Позволяй добавлять, переименовывать, удалять папки (с подтверждением). Нажатие на папку должно переводить на `TaskListScreen`, отфильтрованный по этой папке. Используй провайдер Riverpod (`folder_provider.dart`). * При удалении папки обновляй связанные задачи, устанавливая их `folderId` в null. 8. **Уведомления:** * Реализуй сервис-обертку `NotificationService` вокруг `flutter_local_notifications`. * Когда задача с `dueDate` создается или обновляется, запланируй локальное уведомление с помощью сервиса, которое сработает в указанное время. Включи название задачи в уведомление. * Обработай запрос разрешений на уведомления. 9. **Статистика:** * Реализуй `StatsScreen`: Отображай простой текстовый виджет, показывающий количество задач, выполненных за текущую неделю. * Реализуй use case `GetWeeklyCompletedCount`, взаимодействующий с `TaskRepository` (запрашивай задачи, где `isCompleted` равно true и `completedAt` попадает в текущую неделю). Используй провайдер Riverpod (`stats_provider.dart`). 10. **UI/UX:** * Используй компоненты Material Design. * Реализуй базовую навигацию с помощью `go_router` между экранами Auth, TaskList, TaskAddEdit, FolderList и Stats. Рассмотри использование `BottomNavigationBar` или `Drawer` для основной навигации. * Предоставляй обратную связь пользователю для действий (индикаторы загрузки, snackbar'ы для сообщений об успехе/ошибке). * Реализуй пустые состояния для списков задач и папок. * Обеспечь базовую валидацию форм (например, название задачи обязательно). 11. **Качество кода:** * Следуй лучшим практикам Dart/Flutter. * Используй Riverpod для внедрения зависимостей и управления состоянием. * Разделяй ответственности в соответствии с определенными слоями (Presentation, Domain, Data). * Добавляй комментарии там, где это необходимо. * Приоритезируй читабельность и поддерживаемость. **Сгенерируй код Flutter на основе этих спецификаций.**