spec-feature 1.1.2 → 1.1.4

package/spec/features/metrics/tasks.md

@@ -0,0 +1,31 @@
+# Tasks
+
+**Context:** Подготовить и внедрить модуль метрик для владельца проектов с использованием данных из Supabase (`projects`, `orders`, `order_history`, `order_reminder_logs`, `project_members`), отобразить ключевые показатели эффективности, сроков, нагрузки, финансов и качества.
+
+## Main directions
+### Data & Analytics
+- [ ] Разработать SQL-представления/материализованные представления для основных наборов метрик (project, orders, timing, team, finance, quality, reminders) с учётом фильтров по проекту и периоду.
+- [ ] Настроить обновление и кеширование представлений (либо через Supabase cron/Edge Function), обеспечить выполнение запросов < 3 сек при объёме до 10k заказов.
+- [ ] Подготовить скрипты миграций и документацию по обновлению схемы (описание индексов, требований к данным).
+
+### Backend / API
+- [ ] Реализовать серверный эндпоинт `/api/metrics` (или Edge Function) с параметрами `projectId`, `from`, `to`, который агрегирует данные из представлений и возвращает структуру, описанную в плане.
+- [ ] Добавить валидацию входных параметров и контроль доступа (проверка `user_telegram_id` владельца, доступ только к своим проектам).
+- [ ] Встроить логирование времени выполнения и обработку ошибок с единым форматом ответа.
+
+### Frontend
+- [ ] Создать страницу/виджет дашборда метрик с карточками, графиками и таблицами по разделам (прогресс, воронка, сроки, команда, финансы, ревью, напоминания), используя существующие UI-компоненты.
+- [ ] Настроить навигацию из вкладки «Метрики» на странице редактирования проекта на новую страницу `/projects/:id/metrics` и обеспечить возврат назад.
+- [ ] Реализовать глобальные фильтры периода и проекта, влияющие на все виджеты, и отображать состояния загрузки/ошибок.
+- [ ] Покрыть вычисления форматированием (валюта, проценты, локализованные даты) и подсказками по метрикам.
+
+## Supporting tasks
+- [ ] Documentation: update relevant instructions and descriptions.
+- [ ] Observability: add or clarify metrics, alerts, and/or logging.
+- [ ] Code review and PR: prepare changes for review and accompanying information.
+
+## Definition of Done
+- [ ] All tasks are completed and tested.
+- [ ] Relevant unit/e2e/integration tests pass successfully.
+- [ ] Documentation and operational instructions are updated.
+- [ ] `/spec/core/verify.md` is executed after completing all tasks to verify the task list.

package/spec/features/project-edit/plan.md

@@ -0,0 +1,36 @@
+# Implementation Plan
+
+**Plan:** Реализовать страницу `/projects/new`, повторяющую паттерны создания задачи, подключить её к существующим кнопкам добавления проекта и расширить состояние проектов возможностью добавления новой записи с валидацией данных.
+
+## Data sources / schemas
+
+- Расширить `useProjectsState` (в `composables/useProjectOrders.ts`) или создать отдельный композабл `useProjects` с методом `createProject`, который добавляет объект `Project` в состояние `projects-data`, пересчитывая `completed`/`total` по умолчанию (0 завершено, 0 всего) и создавая уникальный `id`.
+- Определить интерфейс входных данных для проекта (название, описание, ссылка, дата запуска). При необходимости вынести в тип `CreateProjectInput`, чтобы переиспользовать в форме и тестах.
+- Сохранить новые проекты в локальном состоянии, чтобы они были доступны на главной странице и в последующих сессиях во время работы приложения (reactive state).
+
+## Contracts and interfaces
+
+- Создать маршрут `/projects/new` (файл `pages/projects/new.vue`) с `useRoute`/`useRouter` и query-параметром `from` для возврата.
+- Определить публичный метод `createProject` в новом/существующем композабле; метод возвращает созданный `Project` и выбрасывает ошибку при некорректных данных. Обновить потребителей, если потребуется.
+- Настроить обработчики у кнопок «Создать проект» и плавающей кнопки на `/` для перехода через `router.push({ path: '/projects/new', query: { from: route.fullPath } })`.
+- В форме предусмотреть интерфейс валидации: `title` обязательно, `link` — допустимые схемы `http/https`; ошибки отображаются рядом с полями и в нижнем статусе.
+
+## Architecture / Components
+
+- UI: переиспользовать визуальные паттерны из `pages/projects/[id]/orders/new.vue` — тёмный фон, фиксированный футер, sticky header с кнопкой закрытия. Выделить компоненты при необходимости (например, поле ввода), но можно ограничиться копированием стилевых классов с адаптацией текстов.
+- Логика: внутри страницы использовать реактивные refs для полей формы, computed для валидаций, `isSubmitting` для блокировки кнопки. После успешного создания вызвать переход на `from` или `/`.
+- Навигация: при закрытии формы и после успешного сабмита возвращаться на маршрут `from`; если query отсутствует, использовать `/`.
+- Тестирование: дополнить существующие unit-тесты или добавить новые (например, в `tests/useProjectOrders.test.ts`) для метода `createProject` и маршрутизации.
+
+## Risks
+
+- Отсутствие серверной синхронизации может приводить к расхождению данных после перезагрузки — важно задокументировать ограничение.
+- Возможные дубли `id` для проектов при генерации; нужно гарантировать уникальность (например, `project-${timestamp}`) и проверить отсутствие конфликтов в ссылках.
+- Несогласованность стилей при копировании из страницы задач — требуется ручная проверка на мобильных разрешениях.
+- Потенциальные несоответствия расчёта `completed/total` для новых проектов; нужно определить стартовые значения (0 и 0) и не ломать прогресс-бар.
+
+## Assumptions
+
+- Создание проекта не требует выбора задач или исполнителей на этапе создания; список задач и прогресс инициализируются пустыми значениями.
+- Дополнительные поля (аватар, цвет, участники) не нужны в рамках текущей итерации.
+- Переход из других страниц (например, будущей панели проектов) также будет использовать тот же маршрут, поэтому логика `from` универсальна.

package/spec/features/project-edit/spec.md

@@ -0,0 +1,32 @@
+# Создание проекта
+
+**Specification:** Добавить полноэкранную страницу создания проекта, оформленную в том же визуальном стиле и UX-паттернах, что и страница создания задачи (`/projects/[id]/orders/new`). Страница должна открываться по нажатию плавающей кнопки «плюс» и кнопки «Создать проект» в пустом состоянии списка проектов, обеспечивать ввод основных данных проекта и возвращать пользователя к списку после сохранения.
+
+## User Stories
+
+- Как руководитель команды, я хочу нажать на плавающую кнопку «добавить проект» на странице списка и попасть на страницу создания проекта, чтобы быстро зафиксировать новую инициативу.
+- Как проджект-менеджер, я хочу заполнить название, описание и ключевые параметры нового проекта на отдельной странице, чтобы команда сразу увидела его в списке.
+- Как пользователь Telegram Web App, я хочу, чтобы страница создания проекта выглядела и работала так же, как экран создания задачи, чтобы не разбираться в новой навигации и не тратить время на обучение.
+
+## Main scenarios and rules
+
+- Маршрут `GET /projects/new` (Nuxt страница) открывает форму создания проекта в тёмной теме, повторяя структуру шапки, подвала и отступов страницы создания задачи.
+- Кнопки `Создать проект` в пустом состоянии и плавающая кнопка с иконкой «add» на `/` должны перенаправлять на `/projects/new`, передавая параметр `from` для возврата (по умолчанию `/`).
+- Форма содержит обязательное поле «Название проекта» (валидация на непустое значение) и необязательные поля «Описание», «Ссылка на проект» (валидация URL) и «Дата запуска/дедлайн».
+- Отправка формы создаёт запись проекта через существуемый стор/композабл (либо временный мок) и возвращает пользователя на маршрут `from` с показом нового проекта в списке.
+- Ошибки сохранения отображаются в подвале формы, кнопка сабмита блокируется во время отправки или при невалидных данных.
+- При закрытии (иконка «крестик») осуществляется возврат на маршрут `from` без создания проекта.
+
+## Non-functional requirements
+
+- Страница должна корректно отображаться на мобильных устройствах и адаптироваться под WebApp (использование текущих Tailwind классов и паттернов).
+- Навигация и состояние должны быть управляемыми без перезагрузки страницы; переходы выполняются через Nuxt Router.
+- Валидация выполняется на клиенте, сообщения об ошибках локализованы на русском языке.
+- Код оформлен согласно существующим паттернам (Composition API, `<script setup lang="ts">`, композиционные хуки).
+
+## Assumptions
+
+- Создание проекта пока не синхронизируется с API; используется локальный стор `useProjectOrders` или отдельный мок до появления бэкенда.
+- Параметр `from` передаётся строкой и используется только для клиентского редиректа после успешного создания или закрытия формы.
+- Поле «Дата запуска» можно хранить как ISO-дату (`YYYY-MM-DD`) по аналогии с дедлайнами задач; уточнение формата возможно позднее.
+- Если потребуются дополнительные поля (например, ответственный), их добавление будет отдельной задачей.

package/spec/features/project-edit/tasks.md

@@ -0,0 +1,36 @@
+# Orders
+
+**Context:** Реализовать страницу создания проекта в стиле формы создания задачи, добавить навигацию с главной страницы и обеспечить сохранение нового проекта в общем состоянии.
+
+## Main directions
+
+### UI/UX
+
+- [ ] Создать страницу `pages/projects/new.vue` с макетом, повторяющим шапку, футер и поля формы из `orders/new`, адаптировав тексты под создание проекта.
+- [ ] Настроить клиентскую валидацию для полей (обязательное название, проверка URL), показать ошибки рядом с полями и в подвале.
+- [ ] Реализовать сценарии закрытия и возврата на маршрут `from` (через query) с сохранением плавных анимаций и фокус-стилей.
+
+### Состояние и логика
+
+- [ ] Расширить состояние проектов (`useProjectsState` или новый композабл) методом `createProject`, который добавляет проект с начальными значениями прогресса и пустым списком задач.
+- [ ] Обновить тесты/написать новые для проверки `createProject` (уникальный id, корректное добавление, значения completed/total).
+- [ ] Подключить форму к методу `createProject`, обрабатывать состояния загрузки и ошибок, возвращать пользователя на `from` после успешного создания.
+
+### Маршрутизация и интеграция
+
+- [ ] Добавить маршрут `/projects/new` в навигацию: кнопка «Создать проект» из пустого состояния и плавающая кнопка на `/` переходят на новый экран с передачей `from`.
+- [ ] Убедиться, что после создания проект отображается на главной странице без перезагрузки (реактивное состояние).
+- [ ] Обновить консольные заглушки и убедиться, что нет неиспользуемых обработчиков.
+
+## Supporting orders
+
+- [ ] Документация: описать новый маршрут и форму в соответствующем README/спецификационном разделе, если требуется.
+- [ ] Observability: добавить при необходимости `console.info`/`console.error` с контекстом создания проекта.
+- [ ] Code review and PR: подготовить изменения, описание и скриншоты для ревью.
+
+## Definition of Done
+
+- [ ] Все задачи выполнены и протестированы.
+- [ ] Релевантные unit/e2e/integration тесты успешно проходят.
+- [ ] Документация и операционные инструкции обновлены.
+- [ ] `/spec/core/verify.md` выполнен после завершения всех задач для проверки списка.

package/spec/features/review-order/plan.md

@@ -0,0 +1,37 @@
+# Implementation Plan
+
+**Plan:** Реализовать новый экран отправки задачи на проверку и обновить навигацию с карточки задачи. Использовать существующие компоненты интерфейса, обеспечить обработку загрузки фотографий и комментариев, а также визуальное сокращение длинных имен файлов.
+
+## Data sources / schemas
+- Проверить доступные API/сторы для получения деталей задачи (название, статус) и возможности обновления статуса до «ожидает проверки».
+- Уточнить и при необходимости расширить схему данных для хранения вложенных фотографий и комментария (использовать текущий механизм хранения файлов).
+- Убедиться, что фронтенд поддерживает множественные загрузки изображений и ссылки на сохранённые файлы.
+
+## Contracts and interfaces
+- Определить маршрут страницы, например `/orders/[id]/review`, и согласовать параметры навигации из деталей задачи.
+- Обновить контракт действия «Отметить выполненным», чтобы он инициировал переход на новую страницу вместо мгновенного изменения статуса.
+- Согласовать формат передачи файлов и комментария при отправке (например, multipart/form-data или JSON с ссылками на заранее загруженные файлы).
+- Обеспечить отображение ошибок загрузки и сохранения в едином стиле уведомлений.
+
+## Architecture / Components
+- Создать компонент страницы отправки на проверку с шапкой, кнопкой «Назад» и названием задачи (переиспользовать хедер из списка задач).
+- Добавить компонент для загрузки фотографий, поддерживающий обрезку длинных названий (функция форматирования имени файла).
+- Интегрировать текстовое поле комментария и кнопку отправки, используя существующие UI-компоненты.
+- Настроить логику сохранения: загрузка файлов (при необходимости — предварительное сохранение) и отправка запроса изменения статуса.
+- Реализовать переход назад по кнопке, возвращающий пользователя к деталям задачи.
+
+## Risks
+- Возможные ограничения бэкенда по количеству/размеру загружаемых файлов могут привести к ошибкам сохранения.
+- Недоступность повторного использования хедера может потребовать дублирования стилей или временного решения.
+- Некорректная обработка длинных имен файлов может вызвать разметку, выходящую за пределы контейнера.
+
+## Assumptions
+- Бэкенд уже поддерживает состояние задачи «ожидает проверки» и хранение комментариев и медиа.
+- Маршрут и данные задачи доступны через Nuxt-роутер и сторы проекта.
+- В проекте уже есть компонент уведомлений для отображения ошибок/успеха.
+
+## Implementation summary (2025-11-03)
+- Создан подмаршрут `/orders/[id]/review` с отдельной страницей отправки задачи на проверку, использующей базовый хедер и минималистичный интерфейс.
+- Действие «Отметить выполненным» на странице деталей (`pages/orders/[id]/index.vue`) перенаправляет на новый экран вместо мгновенной смены статуса.
+- Добавлен модуль `utils/orderReviewSubmission.ts`, имитирующий загрузку вложений и перевод задачи в статус `pending-review` до интеграции с бэкендом.
+- На клиенте реализовано обрезание длинных имён файлов с троеточием и отзыв предварительных превью при очистке списка вложений.

package/spec/features/review-order/spec.md

@@ -0,0 +1,28 @@
+# Review Order Submission
+
+**Specification:** На странице деталей задачи нужно изменить поведение кнопки «Отметить выполненным», чтобы пользователь переходил на новую страницу для отправки задачи на проверку. На новой странице он может прикрепить фотографии выполненной работы, оставить комментарий и отправить задачу на ревью. Интерфейс должен быть минималистичным: только шапка с кнопкой «Назад», названием задачи и форма для вложений и комментария. Длинные названия файлов необходимо сокращать с добавлением троеточия.
+
+## User Stories
+- Как исполнитель задачи, я нажимаю «Отметить выполненным» на странице деталей и автоматически перехожу на экран отправки на проверку, чтобы завершить работу без поиска нужного раздела.
+- Как исполнитель задачи, я прикрепляю несколько фотографий результата и вижу, что длинные названия файлов корректно обрезаются с троеточием, чтобы интерфейс оставался аккуратным.
+- Как исполнитель задачи, я добавляю текстовый комментарий к выполненной работе и отправляю задачу на проверку, чтобы заказчик получил контекст и подтверждение выполнения.
+
+## Main scenarios and rules
+- При нажатии кнопки «Отметить выполненным» на экране деталей задачи выполняется навигация на новую страницу подтверждения (например, `/orders/{id}/review`).
+- Шапка новой страницы копирует стиль списка задач: кнопка «Назад» возвращает к предыдущему экрану, рядом отображается название задачи.
+- На странице присутствует форма с полем для загрузки одной или нескольких фотографий (при загрузке отображаются названия файлов) и текстовым полем для комментария.
+- Отображаемые названия загруженных файлов должны ограничиваться по длине с добавлением троеточия, сохраняя расширение файла и минимально достаточную часть имени.
+- Страница не содержит дополнительных элементов (кнопок, подсказок, статистики); только элементы, необходимые для отправки на проверку.
+- Должна быть кнопка отправки, которая сохраняет вложения и комментарий и переводит задачу в состояние «ожидает проверки».
+- При ошибках загрузки файлов или сохранения данных пользователь получает стандартные уведомления проекта.
+
+## Non-functional requirements
+- Форма загрузки фотографий поддерживает основные форматы изображений (JPEG, PNG, HEIC) до установленного лимита размера (уточнить при реализации).
+- Обработка загрузок должна использовать существующие механизмы хранения медиа, обеспечивая отзывчивость интерфейса (оптимальная реакция < 2 секунд при стабильном соединении).
+- Страница и элементы управления соответствуют существующей дизайн-системе и адаптивно отображаются на мобильных и десктопных устройствах.
+- Названия файлов обрезаются на клиенте без заметной задержки, чтобы избежать заморозки интерфейса.
+
+## Assumptions
+- Требуется уточнение максимального числа фотографий и их размерного лимита.
+- Не определён процесс уведомления заказчика после отправки на проверку — предполагается, что он уже реализован в бекэнде.
+- Ожидается, что данные о задаче (название, статус) доступны через существующие API/стор.

package/spec/features/review-order/tasks.md

@@ -0,0 +1,26 @@
+# Orders
+
+**Context:** Реализовать страницу отправки задачи на проверку с загрузкой фотографий и комментарием, перенаправляя пользователя с деталей задачи по кнопке «Отметить выполненным», и обеспечить сокращение длинных имен файлов.
+
+## Main directions
+### UI/UX
+- [x] Обновить страницу деталей задачи, чтобы кнопка «Отметить выполненным» перенаправляла на маршрут страницы отправки на проверку.
+- [x] Создать страницу отправки на проверку с шапкой (кнопка «Назад» и название задачи), формой загрузки фотографий, полем комментария и кнопкой отправки.
+- [x] Реализовать клиентскую обрезку длинных названий файлов с добавлением троеточия при отображении списка вложений.
+- [x] Убедиться, что интерфейс не содержит лишних элементов и соответствует дизайн-системе проекта.
+
+### Data flow / интеграция
+- [x] Настроить загрузку изображений и передачу их ссылок/идентификаторов вместе с комментарием в бэкенд.
+- [x] Обновить логику смены статуса задачи на «ожидает проверки» после успешной отправки.
+- [x] Обработать ошибки загрузки и отправки, используя существующий механизм уведомлений.
+
+## Supporting orders
+- [x] Documentation: update relevant instructions and descriptions.
+- [x] Observability: add or clarify metrics, alerts, and/or logging.
+- [x] Code review and PR: prepare changes for review and accompanying information.
+
+## Definition of Done
+- [x] All orders are completed and tested.
+- [x] Relevant unit/e2e/integration tests pass successfully.
+- [x] Documentation and operational instructions are updated.
+- [x] `/spec/core/verify.md` is executed after completing all orders to verify the order list.

package/spec/features/review-order/verify-report.md

@@ -0,0 +1,19 @@
+<!-- SAVE_AS: spec/features/review-order/verify-report.md -->
+
+# Verify Report - review-order
+
+**Date:** 2025-11-03
+**Context:** Проверка выполнения задач по запуску страницы отправки задачи на проверку и обновлению пользовательского пути из деталей задачи.
+
+## Discrepancy log
+
+### 2025-11-03 - Positive results
+
+No discrepancies detected.
+
+#### Fully implemented components:
+
+- ✅ UI-редирект с деталей задачи на страницу отправки на проверку (`pages/orders/[id]/index.vue`).
+- ✅ Страница отправки с загрузкой фотографий, комментарием и валидацией (`pages/orders/[id]/review.vue`).
+- ✅ Клиентская имитация загрузки вложений и смены статуса на «ожидает проверки» (`utils/orderReviewSubmission.ts`).
+- ✅ Обновлён список задач и сопутствующая документация (`spec/features/review-order/orders.md`).

package/spec/features/supabase-init/plan.md

@@ -0,0 +1,89 @@
+# Implementation Plan
+
+**Plan:** Нужно добавить и настроить Supabase в проект на стороне сервера. Добавить env example и тд. Настроить минимально.
+
+## Data sources / schemas
+
+Не требуется — причина: задача только в базовой инициализации Supabase клиента на сервере. Работа с базой данных, создание схем, миграции и индексы выходят за рамки текущей задачи и будут реализованы в последующих фичах.
+
+## Contracts and interfaces
+
+### Переменные окружения
+
+Обязательные переменные для серверной части:
+
+- `SUPABASE_URL` — URL проекта Supabase (например, https://xxx.supabase.co)
+- `SUPABASE_SERVICE_ROLE_KEY` — Service Role Key для серверных операций с полными правами доступа
+
+Опциональные переменные (для будущего использования):
+
+- `SUPABASE_ANON_KEY` — анонимный ключ для публичных операций
+
+### API Supabase клиента
+
+- Серверный клиент будет доступен через Nuxt server utilities (composable или helper)
+- Клиент типа `SupabaseClient` из `@supabase/supabase-js`
+- Клиент инициализируется один раз и переиспользуется
+
+### Формат ошибок
+
+- При отсутствии обязательных переменных: логирование предупреждения при старте
+- При ошибке подключения: стандартные ошибки Supabase клиента
+
+## Architecture / Components
+
+### Структура компонентов
+
+1. **Supabase серверный модуль/plugin**
+   - Создание серверного клиента Supabase при инициализации Nuxt
+   - Использование Nuxt plugins или server utilities для инъекции клиента
+   - Типизация клиента для TypeScript
+
+2. **Переменные окружения**
+   - Файл `.env.example` с примером необходимых переменных
+   - Проверка наличия `.env` в `.gitignore`
+
+3. **Зависимости**
+   - Установка `@supabase/supabase-js` пакета
+   - TypeScript типы уже включены в пакет
+
+### Технический стек
+
+- **Runtime**: Node.js (Nuxt 4 серверная часть)
+- **Библиотека**: `@supabase/supabase-js` — официальный JavaScript клиент Supabase
+- **Интеграция**: Nuxt plugins или server utilities для создания серверного singleton клиента
+
+### Архитектурные решения
+
+- **Singleton паттерн**: клиент создается один раз и переиспользуется
+- **Lazy initialization**: клиент создается только при первом использовании или при старте сервера
+- **Server-only**: клиент доступен только в server-side контексте Nuxt
+
+### Интеграция с существующим кодом
+
+- Интеграция с существующей структурой `server/api/`
+- Возможность использования клиента в server routes и middleware
+- Соответствие паттернам существующего кода (например, `server/api/telegram/validate-init-data.post.ts`)
+
+## Risks
+
+1. **Отсутствие переменных окружения в production**
+   - **Митигация**: проверка наличия переменных при инициализации с логированием ошибок
+
+2. **Утечка Service Role Key в клиентский код**
+   - **Митигация**: использование только в server-side контексте, проверка через TypeScript типы и документация
+
+3. **Конфликт версий пакета `@supabase/supabase-js`**
+   - **Митигация**: использование стабильной версии, обновление с осторожностью
+
+4. **Избыточная сложность при минимальных требованиях**
+   - **Митигация**: строгое следование принципу минимальной настройки, без дополнительных абстракций
+
+## Assumptions
+
+1. Nuxt 4 поддерживает server plugins/utilities для создания серверных singleton сервисов
+2. Проект Supabase уже создан, разработчик имеет доступ к URL и Service Role Key
+3. TypeScript конфигурация проекта совместима с типами из `@supabase/supabase-js`
+4. Минимальная настройка означает только базовое подключение без миграций, схем БД и дополнительных сервисов
+5. `.gitignore` уже настроен и включает `.env` файл (требуется проверка)
+

package/spec/features/supabase-init/spec.md

@@ -0,0 +1,73 @@
+# Supabase Initialization
+
+**Specification:** Нужно добавить и настроить Supabase в проект на стороне сервера. Добавить env example и тд. Настроить минимально.
+
+## User Stories
+
+1. **Как разработчик**, я хочу иметь настроенный Supabase клиент на сервере, чтобы использовать его для работы с базой данных и другими сервисами Supabase в серверных API endpoints.
+
+2. **Как разработчик**, я хочу иметь файл с примером переменных окружения (.env.example), чтобы быстро настроить проект на новой машине или в новом окружении без необходимости искать документацию.
+
+3. **Как разработчик**, я хочу иметь минимальную конфигурацию Supabase, чтобы начать использовать его в проекте без избыточной сложности.
+
+## Main scenarios and rules
+
+### Основные сценарии
+
+1. **Инициализация Supabase клиента на сервере**
+   - Клиент создается один раз при старте серверной части приложения
+   - Клиент доступен в серверных API handlers через Nuxt runtime utilities
+   - Клиент использует переменные окружения для подключения к Supabase
+
+2. **Конфигурация через переменные окружения**
+   - URL Supabase проекта
+   - Service Role Key (для серверных операций с полными правами)
+   - Опционально: анонимный ключ для клиентской стороны (если будет использоваться)
+
+3. **Минимальная настройка**
+   - Только базовые переменные для подключения
+   - Без дополнительных модулей или расширений
+   - Поддержка только серверной части
+
+### Правила
+
+- Все секретные данные хранятся только в переменных окружениях
+- Файл .env.example содержит примеры значений без реальных ключей
+- Файл .env должен быть в .gitignore (проверка наличия)
+- Клиент Supabase инициализируется только на сервере
+
+### Ограничения и ошибки
+
+- Отсутствие обязательных переменных окружения должно логироваться при старте
+- Невалидные учетные данные должны обрабатываться с понятными сообщениями об ошибках
+
+## Non-functional requirements
+
+### Производительность
+
+- Клиент Supabase создается один раз при старте, без пересоздания на каждый запрос
+- Минимальное влияние на время старта приложения
+
+### Безопасность
+
+- Service Role Key не должен попадать в клиентский код
+- Все секретные значения должны быть защищены через переменные окружения
+- Файл .env.example не содержит реальных ключей
+
+### Надежность
+
+- При отсутствии переменных окружения приложение должно информировать разработчика, а не падать молча
+
+### Простота
+
+- Минимальная конфигурация без избыточных настроек
+- Простая интеграция с существующей Nuxt структурой проекта
+
+## Assumptions
+
+1. Проект использует Supabase Cloud (не self-hosted)
+2. Supabase проект уже создан, URL и ключи уже есть у разработчика
+3. Настройка требуется только для серверной части приложения
+4. TypeScript используется в проекте (уже присутствует)
+5. Минимальная настройка означает только базовое подключение, без миграций, без схем и без дополнительных сервисов (Storage, Auth конфигурация и т.д.)
+

package/spec/features/supabase-init/tasks.md

@@ -0,0 +1,51 @@
+# Orders
+
+**Context:** Нужно добавить и настроить Supabase в проект на стороне сервера. Добавить env example и тд. Настроить минимально.
+
+## Main directions
+
+### Установка зависимостей
+
+- [ ] Установить пакет `@supabase/supabase-js` в зависимости проекта. Проверить, что пакет добавлен в `package.json` в секции `dependencies`.
+
+### Конфигурация переменных окружения
+
+- [ ] Создать файл `.env.example` в корне проекта с примерами переменных `SUPABASE_URL` и `SUPABASE_SERVICE_ROLE_KEY` с комментариями о том, где их получить. Проверить, что файл содержит только примеры без реальных ключей.
+
+- [ ] Проверить наличие `.env` в `.gitignore`. Если отсутствует, добавить `.env` в `.gitignore`. Убедиться, что реальные секреты не попадут в репозиторий.
+
+### Инициализация Supabase клиента на сервере
+
+- [ ] Создать серверный plugin или utility для инициализации Supabase клиента. Клиент должен создаваться один раз при старте сервера и быть доступен в server-side контексте. Проверить, что используется `SUPABASE_URL` и `SUPABASE_SERVICE_ROLE_KEY` из переменных окружения.
+
+- [ ] Реализовать проверку наличия обязательных переменных окружения при инициализации. При отсутствии переменных логировать предупреждение. Проверить логирование при отсутствии переменных.
+
+- [ ] Обеспечить доступность клиента в server API routes (например, в `server/api/`). Проверить, что клиент можно использовать в существующих или новых API endpoints.
+
+- [ ] Добавить TypeScript типизацию для Supabase клиента. Проверить, что TypeScript не выдает ошибок при использовании клиента.
+
+### Тестирование
+
+- [ ] Протестировать инициализацию клиента при наличии всех переменных окружения. Проверить, что клиент успешно создается и доступен.
+
+- [ ] Протестировать поведение при отсутствии переменных окружения. Проверить, что приложение логирует предупреждение и не падает с критической ошибкой.
+
+## Supporting orders
+
+- [ ] Документация: добавить комментарии в код о том, как использовать Supabase клиент в серверных API routes. Обновить README.md с инструкциями по настройке переменных окружения из `.env.example`.
+
+- [ ] Observability: обеспечить логирование успешной инициализации Supabase клиента (опционально, для отладки). Добавить логирование ошибок при проблемах с подключением.
+
+- [ ] Code review and PR: подготовить изменения для review. Убедиться, что все файлы соответствуют стандартам проекта и нет линтер ошибок.
+
+## Definition of Done
+
+- [ ] Все задачи выполнены и протестированы.
+- [ ] Переменные окружения настроены и проверены (через `.env.example`).
+- [ ] Supabase клиент инициализируется на сервере и доступен в API routes.
+- [ ] TypeScript типы работают корректно без ошибок.
+- [ ] Логирование работает при отсутствии переменных окружения.
+- [ ] Файл `.env` добавлен в `.gitignore`.
+- [ ] Документация обновлена с инструкциями по настройке.
+- [ ] `/spec/core/verify.md` выполнен после завершения всех задач для проверки списка задач.
+

package/spec/features/task-details/plan.md

@@ -0,0 +1,38 @@
+# Implementation Plan
+
+**Plan:** Реализовать динамическую страницу `/orders/[id]`, отображающую детали задачи на основе мок-данных, с сохранением стиля приложения и подготовкой к замене данных на реальные источники в будущем.
+
+## Data sources / schemas
+
+- Использовать статические мок-данные, определённые прямо в компоненте страницы либо вынесенные в `data` директорию, чтобы имитировать структуру будущего API.
+- Определить интерфейс OrderDetail (id, название, статусы, ответственный, сроки, приоритет, описание, вложения, история) для дальнейшей типизации.
+- Подготовить структуру мок-данных таким образом, чтобы в дальнейшем можно было заменить на API вызов без изменения шаблона.
+
+## Contracts and interfaces
+
+- Динамический маршрут Nuxt `/orders/[id].vue`, принимающий `route.params.id`.
+- Компонент страницы экспортирует объект с макетом и секциями, соответствующими макету (статусные чипы, блоки с иконками, история, кнопки).
+- Предусмотреть интерфейсы/типы для вложений и истории, чтобы обеспечить проверку структуры данных.
+- Тесты проверяют наличие ключевых блоков и отображение основных полей мок-данных.
+
+## Architecture / Components
+
+- Страница создаётся как отдельный файл в `pages/orders/[id].vue` с использованием `<script setup lang="ts">`.
+- Использовать существующую систему Tailwind классов и тему (тёмная/светлая), избегать инлайновых стилей.
+- Вынести повторно используемые UI-фрагменты (например, компонент бейджа статуса) в локальные компоненты или вспомогательные функции при необходимости, но без излишней декомпозиции.
+- В футере добавить кнопку действия (например, "Отметить выполненным") с соответствующими стилями.
+- Использовать Nuxt Layout, если у приложения есть общий layout для страниц задач (проверить текущую структуру; при отсутствии — использовать `<div>` контейнер с нужными классами).
+
+## Risks
+
+- Несоответствие текущему дизайн-гайду, если макет из примера не согласован с приложением.
+- Возможные конфликты с существующей маршрутизацией, если `/orders/[id]` уже занят другой страницей.
+- Перегруженность страницы на мобильных устройствах: важно протестировать адаптивность.
+- Недостаточное покрытие тестами может привести к регрессии при замене мок-данных на реальные.
+
+## Assumptions
+
+- В проекте уже настроен Tailwind и тема, необходимые классы доступны.
+- В Nuxt не требуется дополнительная настройка для динамических маршрутов.
+- Дополнительные глобальные компоненты не нужны; можно использовать стандартные элементы.
+- Дальнейшее подключение API будет выполнено в отдельной задаче.

package/spec/features/task-details/spec.md

@@ -0,0 +1,33 @@
+# Страница деталей задачи
+
+**Specification:** Создать динамическую страницу деталей задачи, открывающуюся при переходе из списка задач по клику на карточку. Страница пока использует мок-данные и отражает ключевую информацию о задаче, статусы, историю, вложения, без серверной логики.
+
+## User Stories
+
+- Как менеджер по работе с задачими, я хочу открывать страницу деталей задачи из списка, чтобы видеть полную информацию по конкретной задаче.
+- Как сотрудник службы поддержки, я хочу видеть на странице основные статусы и пометки по задачи, чтобы быстро ответить клиенту.
+- Как руководитель команды, я хочу просматривать историю изменений по задаче, чтобы отслеживать исполнение и вовлечённых сотрудников.
+
+## Main scenarios and rules
+
+- Переход на страницу выполняется по маршруту с динамическим идентификатором задачи (`/orders/[id]`).
+- При загрузке страницы отображаются мок-данные: статус, сроки, приоритет, ответственный, описание, вложения, история.
+- Данные должны быть структурированы по блокам (шапка, статусные чипы, ключевые сведения, описание, вложения, история, управляющие кнопки).
+- Страница сохраняет визуальный стиль текущего приложения (Tailwind, тёмная тема по умолчанию, соответствующие классы).
+- Адаптивная вёрстка: корректное отображение на мобильных и десктопных разрешениях, основные блоки должны стекаться вертикально.
+- Допускается отображение заглушек и мок-значений, но структура должна предусматривать замену на реальные данные в будущем.
+
+## Non-functional requirements
+
+- Поддержка тёмной темы и общей цветовой палитры приложения.
+- Адаптивность: корректная работа на ширинах от 360px и выше.
+- Компонентность: переиспользование существующих UI-компонентов где возможно (карточки, типографика).
+- Код должен быть покрыт базовыми unit-тестами на рендеринг ключевых блоков (с использованием мок-данных).
+- Страница не должна делать реальных сетевых запросов.
+
+## Assumptions
+
+- На данный момент страница работает полностью на статических мок-данных.
+- Переход из списка задач уже реализован и будет настроен отдельно.
+- Иконки и стили берутся из существующей дизайн-системы (Material Symbols и Tailwind конфигурация проекта).
+- Размеры и точное содержимое блоков могут быть уточнены после демонстрации макета.

package/spec/features/task-details/tasks.md

@@ -0,0 +1,33 @@
+# Orders
+
+**Context:** Реализовать динамическую страницу деталей задачи `/orders/[id]` на мок-данных с адаптивной вёрсткой, соответствующей стилю приложения.
+
+## Main directions
+
+### UI
+
+- [ ] Создать страницу `pages/orders/[id].vue` с разметкой и мок-данными.
+- [ ] Добавить блоки: шапка с навигацией, статусные чипы, ключевые детали (ответственный, сроки, приоритет, проект), описание, вложения, история изменений, кнопка действия.
+- [ ] Обеспечить адаптивность и корректное отображение в тёмной и светлой темах согласно дизайн-системе.
+
+### Data & Typing
+
+- [ ] Определить типы для деталей задачи, вложений и элементов истории.
+- [ ] Настроить мок-данные, отражающие структуру будущих API-ответов.
+
+### Testing
+
+- [ ] Добавить unit-тесты, проверяющие рендеринг ключевых секций и отображение данных по умолчанию.
+
+## Supporting orders
+
+- [ ] Документация: обновить/добавить краткое описание новой страницы в README или отдельном разделе при необходимости.
+- [ ] Наблюдаемость: Not required — reason: статическая мок-страница не использует сервисы и логи.
+- [ ] Code review and PR: подготовить изменения для ревью, оформить summary и тест-план.
+
+## Definition of Done
+
+- [ ] All orders are completed and tested.
+- [ ] Relevant unit/e2e/integration tests pass successfully.
+- [ ] Documentation and operational instructions are updated.
+- [ ] `/spec/core/verify.md` is executed after completing all orders to verify the order list.