Техническое задание: gntodo

Персональный менеджер задач для повседневных дел и личных проектов.

1. Общие сведения

1.1. Назначение

Продвинутый личный таск-менеджер. Ключевая идея — минимальный трением ввод: задача закидывается в систему в одну строку, без выбора проекта, тегов и приоритета. Система сама делает предварительную детализацию, а пользователь позже утверждает или правит её при разборе.

1.2. Пользователи

• Один пользователь (владелец).
• Авторизация — через централизованный SSO-сервер auth.gnexus.space с клиентской библиотекой gnexus-gauth (см. 6.4).
• Косвенные «пользователи» — ИИ-агенты, действующие от имени владельца через MCP.

1.3. Развёртывание

• Собственный сервер (VPS), доступ из интернета.
• HTTPS, реальный домен.
• Данные хранятся только на своём сервере.

2. Сценарии использования

Сценарий А — веб-интерфейс (основной). Разбор стека входящих, детализация и утверждение задач, работа с проектами, планирование, просмотр дерева задач.

Сценарий Б — ИИ-агент через MCP. Агент от имени пользователя добавляет задачи (например, из переписки или диалога с LLM). Большинство AI-задач выполняется на стороне агента; сервер предоставляет MCP-интерфейс к данным.

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

3.1. Быстрый захват задач (стек входящих)

• Задача создаётся одним текстом (заголовок). Выбор проекта, тегов, приоритета — не обязателен и не предлагается принудительно при вводе.
• Такие «сырые» задачи попадают в стек входящих (raw) и ожидают детализации.
• Стек — отдельное представление с количеством входящих, видимое с главного экрана.

3.2. Автоматическая предварительная детализация

При попадании задачи в стек система самостоятельно предлагает черновые метаданные:

• теги — выбираются из существующего справочника тегов;
• проект или категорию;
• возможно, приоритет.

Требования:

• Это не окончательная детализация — промахи ожидаемы и нормальны.
• При разборе задачи в стеке доступны варианты:
  1. «Да, всё верно» — принять предложенные метаданные одним действием;
  2. отредактировать — изменить предложенное вручную, затем утвердить.
• Задача считается утверждённой (approved) только после явного действия пользователя.
• Механизм предсказания — см. 3.10 и раздел открытых вопросов.

3.3. Содержание и редактирование задачи

• Описание задачи — Markdown (редактирование с форматированием).
• Вложения — изображения, в том числе вставка из буфера обмена (Ctrl+V прямо в редактор).
• Отображение Markdown в описании (просмотр и редактирование).

3.4. Статусы, дедлайны, прогнозы, бюджет

Тип задачи: каждая задача имеет тип — разовая или регулярная (повторяющаяся; см. 3.5).

Статусы выполнения:

• Статус cancelled и deferred — обратимы: задача может быть возвращена в to_do.
• Удаление — отдельное явное действие, не статус.
• Детализационный жизненный цикл (raw → approved) — отдельная плоскость, не статус выполнения: «сырая» задача из стека получает статус только после утверждения.

Дедлайны — двух видов:

• строгий: «сделать до конкретной даты»;
• нестрогий: «сделать в течение недели / месяца / года» — не привязан к конкретному дню, задаётся периодом.

Прогнозирование времени выполнения — система оценивает длительность задачи (на основе истории завершённых задач; алгоритм уточняется).

Бюджет — опциональный, на задачу; есть не у каждой задачи:

• задаётся пользователем вручную (деньги и/или время);
• рядом с бюджетом отображается оценка затрат по задаче, чтобы сразу видеть: задачу можно взять в работу или на неё не хватает денег.

3.5. Регулярные задачи

• Отдельный тип задачи — регулярная (повторяющаяся) в противовес разовой.
• Повторение создаёт новую задачу по правилу после выполнения/истечения предыдущей.
• Точный набор правил повторения (ежедневно/еженедельно/интервалы) — уточняется.

3.6. Представления задач

• Дерево задач: подзадачи — ветви дерева, произвольная вложенность.
• Классический вид: список с фильтрами (проект, тег, статус, приоритет).
• Переключение представлений; дерево — основной, список — опциональный.

3.7. Проекты

• Статус актуальности проекта (активен / приостановлен / закрыт).
• Приоритет проекта.
• Заметка к проекту: Markdown-поле для ссылок на ресурсы проекта и прочего контекста.

3.8. Режим выбора («3 варианта»)

Анти-прокрастинационный режим: пользователь указывает доступное время (например, «3 часа»), система предлагает 3 варианта задач, подходящих под это время; пользователь выбирает один и выполняет сразу.

• Выбор кандидатов учитывает: прогнозируемую длительность ≤ доступного времени, приоритеты, статус актуальности проектов.
• Варианты должны быть осмысленно разными (не три дубликата).
• После выбора — прямой переход к выполнению задачи (отметка начала, быстрый доступ к описанию).

3.9. MCP-интерфейс

• Собственный MCP-сервер как часть backend.
• Инструменты (первичный набор, расширяется):
  • create_task — добавить задачу (достаточно текста; метаданные опциональны);
  • update_task, complete_task;
  • list_tasks / search_tasks — фильтры по проекту, тегу, статусу;
  • get_task — полное описание с вложениями.
• Аутентификация агентов — через SSO-механизм (токен, выданный централизованной системой; детали после предоставления данных SSO).
• Агент действует от имени пользователя; отдельной мультитенантности нет.

3.10. Локальные AI-функции

• Автодетализация (3.2) выполняется маленькой LLM, запущенной локально через Ollama:
  • модель и параметры — конфигурацией приложения, без зашивки в код;
  • LLM классифицирует текст задачи: предлагает теги из справочника, проект/категорию, приоритет;
  • результат — черновые метаданные для утверждения (3.2), не окончательное решение.
• Все вызовы LLM — на собственном сервере, данные не покидают VPS.
• Спекулярные LLM-сценарии вне метаданных — не в скоупе: большинство ИИ-задач выполняют внешние агенты через MCP (3.9).

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

Внешние зависимости проекта (не форкать, обновлять через пакетный менеджер):

• gnexus-ui-kit — часто обновляется, использовать только публичный API кита;
• gnexus-gauth — клиентская библиотека SSO.

5. Модель данных (черновик)

Task
  id, title, description (markdown)
  task_type         one_time | recurring          — тип задачи: разовая / регулярная
  status            to_do | in_progress | done | cancelled | deferred
  detail_state      raw | approved                — плоскость детализации (стека)
  parent_task_id    nullable  — дерево подзадач
  project_id        nullable
  tag_ids           []
  priority          nullable  (заполняется автодетализацией / вручную)
  deadline          nullable  — дедлайн:
                        strict  { date }                  — «до конкретной даты»
                        soft    { period: week|month|year } — «в течение периода»
  recurrence        nullable  — правило повторения (для task_type = recurring)
  time_estimate     nullable  — прогноз времени (система)
  budget            nullable  — ручной бюджет (деньги и/или время), опционален
  estimated_cost    nullable  — оценка затрат по задаче (сравнивается с бюджетом)
  actual_time       nullable  — фактические затраты (для обучения прогноза)
  created_at, approved_at, done_at

Project
  id, name
  relevance_status  active | paused | archived   — статус актуальности
  priority
  note              markdown — ссылки на ресурсы, контекст

Tag           — справочник тегов
Attachment    — файлы задач (изображения), task_id, mime

История завершённых задач (фактическое время) — источник для прогнозирования длительности.

6. Архитектура (черновик)

┌─────────────┐     ┌────────────────────── VPS (docker-compose) ─────────────┐
│  Web SPA    │────▶│  API (FastAPI) ──▶ PostgreSQL                           │
│  Vue 3 +    │     │       │                                                 │
│  gnexus-    │     │       ├──▶ Сервис автодетализации ──▶ Ollama (модель    │
│  ui-kit     │     │       │      — LLM, модель из конфига)                  │
└─────────────┘     │       ├──▶ Хранилище вложений (файлы)                   │
                    │       └──▶ MCP-сервер (для ИИ-агентов)                  │
                    └─────────────────────────────────────────────────────────┘
                                     ▲ SSO auth.gnexus.space (клиент gnexus-gauth)

• API и MCP-сервер — одно Python-приложение (общая бизнес-логика).
• Вложения — файлы на диске VPS + метаданные в БД.

7. Этапы разработки (предложение)

Порядок M4/M5 может меняться — MCP можно поднять раньше ради ИИ-сценария.

8. Открытые вопросы

1. Правила повторения: минимальный набор (ежедневно / еженедельно / N дней / месяц) — уточнить при проектировании.
2. Прогнозирование времени: только по истории похожих задач, или с учётом явных факторов (теги, тип)?
3. Оценка затрат к бюджету: откуда берётся оценка затрат — из прогноза времени, вручную, или нужен учёт «доступных средств»?
4. Оффлайн-режим в PWA: нужен ли, или всегда онлайн?
5. Модель для Ollama: какая конкретно модель и параметры (в конфиг, но нужно выбрать для проверки M2).
6. Практическое различие cancelled / deferred: определения зафиксированы (3.4), но поведение в интерфейсе почти одинаковое — скрыть из активных списков и оставить доступным для возврата. Уточнить при проектировании представлений, нужны ли оба статуса или их поведение сольётся.