# Smart Task Management System — Technical Specification ## 1. Project Overview The goal of this project is to build a **smart task management application** that combines traditional task management with AI-assisted planning and Telegram-based task creation. The application must allow users to: - Create and manage tasks. - Add dates, priorities, labels, and statuses. - Organize tasks by labels. - Define dependencies between tasks. - Group related dependent tasks. - View tasks from a global dashboard. - Receive push notifications. - Receive notifications through Telegram. - Create tasks automatically from Telegram messages. - Use AI to generate tasks from natural-language descriptions. - Use AI to create a daily plan through a **Plan My Day** action. The initial technical stack will be: ``` Frontend: React.js Backend: FastAPI Database: PostgreSQL AI Layer: LLM API Notifications: Web Push + Telegram Bot ``` --- # 2. Core Functional Requirements ## 2.1 Task Management A user must be able to create, update, view, and delete tasks. Each task should contain at least: ``` Task ├── ID ├── Title ├── Description ├── Status ├── Priority ├── Due date ├── Due time ├── Labels ├── Creation date ├── Updated date ├── Completed date └── AI-generated flag ``` ### Task statuses Recommended initial statuses: ``` TODO IN_PROGRESS DONE CANCELLED ``` ### Task priorities ``` LOW MEDIUM HIGH URGENT ``` --- # 3. Labels Tasks can have one or more labels. Examples: ``` Work Personal University Administrative Important Interview Project ``` The user should be able to: - Create labels. - Rename labels. - Delete labels. - Assign multiple labels to a task. - Filter tasks by label. - View all tasks belonging to a label. --- # 4. Main Task Views The application should have a global task view. Recommended views: ``` All Tasks Today Upcoming Overdue Completed By Label ``` The user should also be able to filter and sort tasks. Example filters: ``` Priority Status Label Due date Completed / Active ``` Example sorting: ``` Due date Priority Creation date Updated date ``` --- # 5. Task Dependencies Tasks must support dependencies. This means one task may depend on another task being completed. Example: ``` Prepare Job Application │ ├── Update CV │ ├── Write Cover Letter │ └── Submit Application depends on: ├── Update CV └── Write Cover Letter ``` ## Dependency model Example: ``` TaskDependency ├── id ├── task_id ├── depends_on_task_id └── created_at ``` For example: ``` Task B depends on Task A. ``` Database relation: ``` task_id = B depends_on_task_id = A ``` --- # 6. Dependency Rules A task can have: ``` 0 dependencies 1 dependency multiple dependencies ``` The system should determine whether a task is: ``` READY BLOCKED ``` Example: ``` Update CV Status: DONE Write Cover Letter Status: DONE Submit Application Status: TODO Dependencies satisfied: YES ``` The application should visually display dependencies. Example: ``` Submit Application Depends on: ✓ Update CV ✓ Write Cover Letter Status: Ready ``` If dependencies are incomplete: ``` Submit Application Depends on: ✓ Update CV ○ Write Cover Letter Status: Blocked ``` --- # 7. Task Groups Dependent tasks should also be able to belong to a logical group. Example: ``` Group: Apply to Andros Tasks: 1. Research company 2. Update CV 3. Prepare interview 4. Attend interview 5. Send follow-up email ``` Possible entity: ``` TaskGroup ├── id ├── user_id ├── name ├── description ├── created_at └── updated_at ``` Each task can optionally contain: ``` group_id ``` This gives two different concepts: ``` Group Organizes related tasks. Dependency Defines execution order. ``` For example: ``` Group: Job Application Update CV ↓ Write Cover Letter ↓ Submit Application ↓ Prepare Interview ``` --- # 8. AI Task Creation The application should provide an AI-powered task creation interface. The user could enter: ``` Prepare my Andros interview next Monday. It is important and I need to research the company, prepare HR questions and review EPM Board. ``` The AI should return structured data. Example: ``` { "title": "Prepare Andros interview", "description": "Prepare for the upcoming Andros interview.", "priority": "HIGH", "due_date": "2026-10-05", "labels": [ "Interview", "Career" ] } ``` The AI may optionally propose subtasks or grouped tasks. Example: ``` Prepare Andros interview ├── Research Andros ├── Review job description ├── Study EPM Board basics ├── Prepare HR answers └── Prepare questions for recruiter ``` The user should be allowed to review the generated tasks before confirming creation. --- # 9. AI Structured Output The backend should not rely on free-form AI responses. The LLM should return structured JSON. Example schema: ``` { "title": "string", "description": "string", "priority": "LOW | MEDIUM | HIGH | URGENT", "due_date": "YYYY-MM-DD | null", "due_time": "HH:mm | null", "labels": [], "suggested_tasks": [] } ``` FastAPI should validate this response using Pydantic. Example concept: ``` class GeneratedTask(BaseModel): title: str description: str | None priority: Priority due_date: date | None due_time: time | None labels: list[str] ``` --- # 10. Daily Planner One of the main AI features will be: ``` Plan My Day ``` The user presses a button: ``` Plan My Day ``` The application sends relevant tasks to the AI. --- # 11. Data Provided to the Daily Planner The AI planner should receive: ``` Current date Incomplete tasks Today's tasks Overdue tasks Priority Task dependencies Due dates Task groups Optional estimated duration ``` Example input: ``` { "date": "2026-10-04", "tasks": [ { "id": 15, "title": "Prepare interview", "priority": "HIGH", "due_date": "2026-10-05" }, { "id": 19, "title": "Send CV", "priority": "URGENT", "due_date": "2026-10-04" } ] } ``` --- # 12. Daily Planner Output The AI should return an ordered plan. Example: ``` { "date": "2026-10-04", "plan": [ { "task_id": 19, "position": 1, "reason": "Urgent and due today" }, { "task_id": 15, "position": 2, "reason": "High priority and due tomorrow" } ] } ``` Frontend display: ``` Today's Plan 1. Send CV Urgent · Due today 2. Prepare interview High priority · Due tomorrow 3. Review project report Medium priority ``` The AI should prioritize tasks based on factors such as: ``` Urgency Priority Due date Overdue status Dependencies Blocked status ``` Blocked tasks should normally not be scheduled before their dependencies. --- # 13. Daily Plan Storage The generated daily plan should optionally be persisted. Entity: ``` DailyPlan ├── id ├── user_id ├── plan_date ├── created_at └── generated_by_ai ``` Plan items: ``` DailyPlanItem ├── id ├── daily_plan_id ├── task_id ├── position └── ai_reason ``` This allows the user to: ``` Generate plan Modify plan Regenerate plan Review previous plans ``` --- # 14. Dashboard The dashboard should be the application's main page. A recommended layout: ``` ┌──────────────────────────────────────────────┐ │ Dashboard │ ├──────────────────────────────────────────────┤ │ TODAY │ │ 5 tasks │ │ 2 high priority │ │ 1 overdue │ ├──────────────────────────────────────────────┤ │ PLAN MY DAY │ │ │ │ [ Plan My Day with AI ] │ ├──────────────────────────────────────────────┤ │ TODAY'S TASKS │ UPCOMING │ │ │ │ │ ○ Send CV │ ○ Project report │ │ ○ Interview prep │ ○ Meeting │ │ ○ Documentation │ ○ Application │ ├──────────────────────────────────────────────┤ │ BLOCKED TASKS │ │ │ │ Submit application │ │ Waiting for: Update CV │ ├──────────────────────────────────────────────┤ │ LABELS │ │ Work Personal Study Interview │ └──────────────────────────────────────────────┘ ``` --- # 15. Dashboard Information Recommended dashboard widgets: ``` Tasks today Tasks completed today Overdue tasks High-priority tasks Upcoming tasks Blocked tasks Daily AI plan Labels Task groups ``` Keep the first version relatively simple. Avoid complex analytics at the beginning. --- # 16. Notifications The application must support notifications. Initial channels: ``` Browser Push Notifications Telegram Notifications ``` A task can contain one or multiple reminders. Example: ``` Task: Prepare Interview Reminders: - One day before - One hour before ``` --- # 17. Reminder Model ``` Reminder ├── id ├── task_id ├── reminder_datetime ├── notification_channel ├── sent ├── sent_at └── created_at ``` Possible channels: ``` WEB_PUSH TELEGRAM ``` --- # 18. Background Processing Notifications should not depend on an active HTTP request. Use a background task mechanism. Possible architecture: ``` FastAPI │ ├── REST API │ └── Background Worker │ ├── Check reminders ├── Send Telegram notification └── Send push notification ``` Possible tools: ``` Celery + Redis ``` or for a simpler initial implementation: ``` APScheduler ``` A clean production architecture would be: ``` FastAPI PostgreSQL Redis Celery Celery Beat ``` --- # 19. Telegram Integration Telegram has two purposes. ## Purpose 1 — Receive task notifications Example: ``` Reminder Prepare Andros interview Due tomorrow Priority: High ``` ## Purpose 2 — Create tasks from Telegram messages This is one of the major features. --- # 20. Telegram Task Creation Flow User sends the bot: ``` Remind me tomorrow evening to send my CV to the recruiter. This is important. ``` Flow: ``` Telegram │ ▼ Telegram Bot │ ▼ FastAPI webhook │ ▼ AI Task Parser │ ▼ Structured task │ ▼ PostgreSQL ``` Result: ``` Task created Title: Send CV to recruiter Priority: HIGH Due date: Tomorrow Due time: Evening ``` --- # 21. Telegram Confirmation The bot should respond after processing the message. Example: ``` Task created successfully. Send CV to recruiter Due: Tomorrow evening Priority: High Label: Work ``` For ambiguous requests, the bot should ask for clarification instead of guessing important information. Example: ``` User: Remind me to call Ahmed. Bot: When would you like to be reminded? ``` --- # 22. Telegram Bot Commands Recommended initial commands: ``` /start /help /tasks /today /overdue /done ``` Natural language should remain the main interaction method. Example: ``` "Tomorrow remind me to submit the report." ``` No command should be required for task creation. --- # 23. Telegram User Linking The Telegram account must be linked to an application user. Recommended table: ``` TelegramIntegration ├── id ├── user_id ├── telegram_chat_id ├── telegram_username ├── verification_token ├── verified └── created_at ``` A secure linking flow: ``` Web application Settings ↓ Connect Telegram ↓ Generate temporary token Example: ABC123 User opens Telegram Bot /connect ABC123 Backend validates token Telegram account linked ``` Do not identify users solely using Telegram usernames because usernames can change. Use: ``` telegram_user_id telegram_chat_id ``` --- # 24. System Architecture Recommended architecture: ``` ┌─────────────────────┐ │ React.js │ │ Frontend │ └─────────┬───────────┘ │ │ REST API ▼ ┌─────────────────────┐ │ FastAPI │ │ Backend │ └─────────┬───────────┘ │ ┌───────────────────┼────────────────────┐ │ │ │ ▼ ▼ ▼ Task Service AI Service Notification Service │ │ │ │ │ ├── Web Push │ │ │ │ │ └── Telegram │ │ ▼ ▼ PostgreSQL LLM Provider │ ▼ Redis │ ▼ Background Worker ``` --- # 25. Suggested Backend Structure ``` backend/ │ ├── app/ │ │ │ ├── main.py │ │ │ ├── config.py │ │ │ ├── database.py │ │ │ ├── models/ │ │ ├── user.py │ │ ├── task.py │ │ ├── label.py │ │ ├── task_group.py │ │ ├── dependency.py │ │ ├── reminder.py │ │ ├── daily_plan.py │ │ └── telegram.py │ │ │ ├── schemas/ │ │ ├── task.py │ │ ├── label.py │ │ ├── daily_plan.py │ │ └── ai.py │ │ │ ├── api/ │ │ ├── tasks.py │ │ ├── labels.py │ │ ├── groups.py │ │ ├── plans.py │ │ ├── ai.py │ │ └── telegram.py │ │ │ ├── services/ │ │ ├── task_service.py │ │ ├── dependency_service.py │ │ ├── planning_service.py │ │ ├── ai_service.py │ │ ├── telegram_service.py │ │ └── notification_service.py │ │ │ ├── workers/ │ │ └── reminders.py │ │ │ └── core/ │ ├── security.py │ └── exceptions.py │ ├── migrations/ │ ├── tests/ │ ├── requirements.txt └── Dockerfile ``` --- # 26. Suggested Frontend Structure ``` frontend/ │ ├── src/ │ │ │ ├── components/ │ │ ├── TaskCard/ │ │ ├── TaskForm/ │ │ ├── TaskList/ │ │ ├── LabelSelector/ │ │ ├── DependencySelector/ │ │ ├── DailyPlanner/ │ │ └── DashboardCard/ │ │ │ ├── pages/ │ │ ├── Dashboard/ │ │ ├── Tasks/ │ │ ├── Today/ │ │ ├── Labels/ │ │ ├── Groups/ │ │ └── Settings/ │ │ │ ├── services/ │ │ ├── api.js │ │ ├── tasks.js │ │ ├── ai.js │ │ └── telegram.js │ │ │ ├── hooks/ │ │ │ ├── context/ │ │ │ └── App.jsx │ ├── package.json └── Dockerfile ``` --- # 27. Main Database Entities The initial database could contain: ``` users tasks labels task_labels task_groups task_dependencies reminders daily_plans daily_plan_items telegram_integrations ``` --- # 28. Task Database Model Example: ``` tasks ────────────────────────────────── id user_id group_id title description status priority due_date due_time ai_generated created_at updated_at completed_at ``` --- # 29. Labels Relationship Because one task can have several labels: ``` tasks │ │ many-to-many │ task_labels │ │ labels ``` Table: ``` task_labels task_id label_id ``` --- # 30. Dependency Relationship ``` task_dependencies id task_id depends_on_task_id created_at ``` Important validation: ``` Task cannot depend on itself. ``` The backend should also prevent circular dependencies. Invalid example: ``` Task A depends on B Task B depends on C Task C depends on A ``` This creates a cycle and must be rejected. --- # 31. REST API Design Base URL: ``` /api/v1 ``` --- # 32. Task Endpoints ``` GET /tasks POST /tasks GET /tasks/{id} PATCH /tasks/{id} DELETE /tasks/{id} ``` Additional endpoints: ``` GET /tasks/today GET /tasks/upcoming GET /tasks/overdue ``` --- # 33. Label Endpoints ``` GET /labels POST /labels PATCH /labels/{id} DELETE /labels/{id} ``` --- # 34. Group Endpoints ``` GET /groups POST /groups GET /groups/{id} PATCH /groups/{id} DELETE /groups/{id} ``` --- # 35. Dependency Endpoints ``` POST /tasks/{task_id}/dependencies DELETE /tasks/{task_id}/dependencies/{dependency_id} GET /tasks/{task_id}/dependencies ``` --- # 36. AI Endpoints Generate a task: ``` POST /ai/generate-task ``` Example input: ``` { "text": "Tomorrow remind me to submit the report. High priority." } ``` Plan the user's day: ``` POST /ai/plan-day ``` Example: ``` { "date": "2026-10-04" } ``` --- # 37. Daily Plan Endpoints ``` GET /plans/today POST /plans/generate PUT /plans/{id} ``` --- # 38. Telegram Endpoints Webhook: ``` POST /telegram/webhook ``` Link Telegram: ``` POST /telegram/link-token ``` Integration status: ``` GET /telegram/status ``` Disconnect: ``` DELETE /telegram/integration ``` --- # 39. Dashboard Endpoint Instead of making many requests from React, a dedicated endpoint can simplify the dashboard. ``` GET /dashboard ``` Response example: ``` { "today_count": 5, "overdue_count": 2, "high_priority_count": 3, "completed_today": 4, "today_tasks": [], "upcoming_tasks": [], "blocked_tasks": [], "daily_plan": [] } ``` --- # 40. AI Service Architecture Do not place AI logic directly inside FastAPI route handlers. Use: ``` AI Route ↓ AI Service ↓ Prompt Builder ↓ LLM ↓ Structured Output Parser ↓ Pydantic Validation ``` Example: ``` services/ ai_service.py ``` Possible functions: ``` generate_task_from_text() generate_task_breakdown() generate_daily_plan() ``` --- # 41. AI Daily Planning Logic Before calling the LLM, the backend should already filter unnecessary tasks. For example, exclude: ``` DONE CANCELLED ``` And identify: ``` Overdue Due today High priority Blocked Available ``` The AI should mainly decide: ``` Ordering Grouping Suggested focus ``` Do not delegate all business logic to the LLM. For example, dependency validation should remain deterministic backend logic. --- # 42. Recommended Daily Planner Prompt Logic System instructions should communicate rules such as: ``` You are a task planning assistant. Your job is to organize the user's tasks for the selected day. Rules: 1. Prioritize overdue tasks. 2. Consider task priority. 3. Consider due dates. 4. Do not schedule blocked tasks before dependencies. 5. Prefer completing dependency tasks first. 6. Do not create tasks unless necessary. 7. Return only valid structured JSON. ``` --- # 43. Telegram AI Processing Telegram messages should pass through the same AI task parser used by the web application. Avoid building two independent AI implementations. Architecture: ``` Web text │ ├─────────┐ │ │ Telegram │ │ │ └────► Task AI Parser │ ▼ Task Service ``` This keeps the system maintainable. --- # 44. Authentication Users need authentication before storing personal tasks. Recommended authentication: ``` Email + Password JWT Access Token JWT Refresh Token ``` Important endpoints: ``` POST /auth/register POST /auth/login POST /auth/refresh GET /auth/me ``` Passwords must be hashed using a secure hashing algorithm such as: ``` Argon2 ``` or: ``` bcrypt ``` Never store plain-text passwords. --- # 45. Authorization Every database query should be restricted by the current user's ID. For example: ``` GET /tasks/42 ``` must verify: ``` task.user_id == authenticated_user.id ``` A user must never be able to retrieve another user's tasks by changing an ID in the URL. --- # 46. Telegram Security Telegram webhook requests should be validated. Recommended: ``` Telegram webhook secret ``` The application should verify that webhook requests actually originate from the configured Telegram integration. AI-generated content must also be validated before writing to the database. --- # 47. Error Handling API errors should follow a consistent structure. Example: ``` { "error": { "code": "TASK_NOT_FOUND", "message": "The requested task does not exist." } } ``` Other examples: ``` INVALID_DEPENDENCY DEPENDENCY_CYCLE INVALID_TASK_DATE TELEGRAM_NOT_CONNECTED AI_RESPONSE_INVALID ``` --- # 48. Logging Important operations should be logged. Examples: ``` Task creation Task deletion AI generation errors Telegram webhook failures Reminder delivery Authentication failures ``` Do not log: ``` Passwords Authentication tokens Full secret keys ``` --- # 49. Environment Variables Configuration should come from environment variables. Example: ``` DATABASE_URL= JWT_SECRET= OPENAI_API_KEY= TELEGRAM_BOT_TOKEN= TELEGRAM_WEBHOOK_SECRET= REDIS_URL= ``` Never hard-code secrets into the source code. --- # 50. Docker Architecture Recommended development stack: ``` docker-compose.yml services: frontend backend postgres redis worker ``` Architecture: ``` Docker Compose │ ├── React ├── FastAPI ├── PostgreSQL ├── Redis └── Worker ``` --- # 51. Step-by-Step Implementation Plan ## Step 1 — Initialize the Repository Create the main project structure. ``` task-manager/ │ ├── backend/ ├── frontend/ ├── docker-compose.yml ├── .env.example ├── .gitignore └── README.md ``` Initialize Git. --- # Step 2 — Set Up FastAPI Create the FastAPI project. Add: ``` Application configuration Environment variables Database connection API router structure Error handling ``` Verify with a basic endpoint: ``` GET /health ``` Example: ``` { "status": "ok" } ``` --- # Step 3 — Set Up PostgreSQL Configure: ``` PostgreSQL SQLAlchemy Alembic ``` Create the initial migration system. --- # Step 4 — Implement Users Create: ``` User model Registration Login JWT authentication Current-user dependency ``` Verify that authenticated endpoints are protected. --- # Step 5 — Implement Core Task Model Create the `tasks` table. Implement: ``` Create task Read task Update task Delete task ``` Then implement: ``` Today Upcoming Overdue Completed ``` --- # Step 6 — Build React Foundation Create the React application. Add: ``` Routing Authentication state API client Login page Registration page Main layout Navigation sidebar ``` Recommended main navigation: ``` Dashboard Today All Tasks Labels Groups Settings ``` --- # Step 7 — Build Task UI Implement: ``` Task list Task card Create task modal/page Edit task Delete task Complete task Priority display Due date display ``` --- # Step 8 — Implement Labels Backend: ``` Label model Task-label relationship CRUD endpoints Filtering ``` Frontend: ``` Label selector Label page Filter by label ``` --- # Step 9 — Implement Task Groups Backend: ``` TaskGroup model Group CRUD Assign tasks to groups ``` Frontend: ``` Group list Group details Grouped tasks ``` --- # Step 10 — Implement Dependencies Create the dependency table. Implement logic for: ``` Add dependency Remove dependency Check whether task is blocked Prevent self dependency Prevent dependency cycles ``` Frontend should show: ``` Blocked Ready Dependencies Dependent tasks ``` --- # Step 11 — Build Dashboard Create backend endpoint: ``` GET /dashboard ``` Create dashboard components: ``` Today's tasks Overdue Upcoming High priority Blocked Daily plan ``` --- # Step 12 — Integrate AI Provider Create a dedicated AI service. Implement: ``` LLM client Prompt handling Structured output Pydantic validation Error recovery ``` No database writes should happen directly inside the AI provider code. --- # Step 13 — Build AI Task Generation Create endpoint: ``` POST /ai/generate-task ``` Flow: ``` Natural language ↓ LLM ↓ Structured task ↓ User review ↓ Create task ``` Build the frontend action: ``` Create with AI ``` --- # Step 14 — Build AI Daily Planner Create: ``` POST /ai/plan-day ``` Backend should: ``` Load active tasks Determine dependencies Mark blocked tasks Determine overdue tasks Send valid tasks to AI Validate AI response Return ordered daily plan ``` --- # Step 15 — Build Plan My Day Interface Dashboard button: ``` Plan My Day ``` When clicked: ``` Frontend ↓ POST /ai/plan-day ↓ Loading state ↓ Display generated plan ``` Allow the user to: ``` Accept Regenerate Reorder Remove an item ``` --- # Step 16 — Persist Daily Plans Create: ``` daily_plans daily_plan_items ``` Save accepted AI plans. Implement: ``` GET /plans/today ``` --- # Step 17 — Create Telegram Bot Create the Telegram bot using BotFather. Configure: ``` Bot token Webhook endpoint Bot commands ``` Create: ``` POST /telegram/webhook ``` --- # Step 18 — Implement Telegram Account Linking From web settings: ``` Connect Telegram ``` Generate a temporary linking token. User sends: ``` /connect TOKEN ``` Store: ``` user_id telegram_user_id telegram_chat_id ``` --- # Step 19 — Implement Telegram Task Creation When the bot receives regular text: ``` Telegram message ↓ Telegram service ↓ AI task parser ↓ Task data ↓ Task service ↓ Database ``` Bot response: ``` Task created successfully. ``` --- # Step 20 — Implement Reminders Create the reminder model. Users should be able to choose: ``` Web notification Telegram ``` Create the background worker. --- # Step 21 — Implement Telegram Notifications Worker detects reminder. Example: ``` Task reminder found ↓ Get Telegram integration ↓ Telegram API ↓ Send message ``` --- # Step 22 — Implement Web Push Register a service worker in React. Store push subscriptions in the backend. Implement push notification sending. --- # Step 23 — Add Validation and Business Rules Add backend validation for: ``` Invalid dates Dependency cycles Unauthorized tasks Deleted dependencies Invalid Telegram accounts Malformed AI responses ``` --- # Step 24 — Add Tests Backend tests should include: ``` Authentication Task CRUD Task filtering Labels Groups Dependencies Circular dependencies AI JSON parsing Daily planner Telegram webhook Reminder processing ``` AI calls should be mocked during automated tests. --- # Step 25 — Improve Frontend UX Add: ``` Loading states Error messages Empty states Confirmation dialogs Responsive layout Task status indicators Blocked indicators AI generation feedback ``` --- # Step 26 — Containerize the Application Create Dockerfiles for: ``` Frontend Backend Worker ``` Configure Docker Compose for: ``` Frontend Backend PostgreSQL Redis Worker ``` --- # Step 27 — Add Production Configuration Configure: ``` HTTPS CORS Database migrations Production environment variables Logging Telegram webhook URL Redis Background worker ``` --- # 52. Final MVP Scope The first complete version should contain exactly these major features: ``` Authentication Task CRUD Task statuses Priorities Dates Labels Task groups Task dependencies Today view Upcoming view Overdue view Dashboard AI task creation AI Plan My Day Daily plan storage Web notifications Telegram notifications Telegram task creation ``` Features such as team collaboration, complex analytics, calendar synchronization, file storage, Slack integration, and collaborative projects should remain outside the initial scope. --- # 53. Final User Flow A typical usage could look like this: ``` User opens dashboard ↓ Views: 3 tasks today 1 overdue 2 high priority ↓ Clicks: Plan My Day ↓ AI generates: 1. Submit application 2. Prepare interview 3. Review documentation ↓ User completes first task ↓ A dependent task becomes available ↓ Later user sends Telegram message: "Tomorrow remind me to send the final report to my manager." ↓ Telegram Bot ↓ AI parser ↓ Task created automatically ↓ Tomorrow Telegram reminder arrives ``` --- # 54. Core Design Principle The system should separate **deterministic task-management logic** from **AI-assisted decision making**. Use normal backend code for: ``` Authentication Permissions Task storage Dependencies Dates Reminder execution Validation Filtering ``` Use AI for: ``` Understanding natural language Creating structured tasks from text Breaking down descriptions when requested Prioritizing daily work Generating Plan My Day recommendations ``` This architecture keeps the project reliable while still making AI a central and genuinely useful part of the product.