# [DEF:EffortAssess:Report] # @COMPLEXITY: 3 # @PURPOSE: Оценка трудозатрат для репозитория на основе эволюции требований в specs и изменений объёма по git-истории. # @RELATION: DEPENDS_ON -> [Project_Knowledge_Map:Root] # @RELATION: DEPENDS_ON -> [Module:Specs] ## Обзор - Оценка трудозатрат по объёму, представленному в `specs/002`–`specs/027`: **~4 400 человеко-часов**. - Рекомендуемый плановый диапазон: **3 800–5 100 человеко-часов**. - Практическая форма поставки: **ядро команды 5–6 человек** примерно на **4–6 календарных месяцев**, в зависимости от степени параллелизации и объёма уже выполненной части. ## Размер кодовой базы (line of code) По выводу `cloc backend/src frontend/src --exclude-dir=__pycache__,node_modules`: | Язык | Файлов | Blank | Comment | Code | |---|---:|---:|---:|---:| | Python | 231 | 8 931 | 14 681 | 40 641 | | Svelte | 97 | 2 191 | 1 333 | 26 798 | | JavaScript | 77 | 1 321 | 1 909 | 7 852 | | JSON | 3 | 0 | 0 | 3 473 | | TypeScript | 8 | 30 | 137 | 194 | | Markdown | 2 | 5 | 0 | 25 | | HTML | 1 | 0 | 0 | 13 | | CSS | 1 | 0 | 0 | 3 | | SVG | 1 | 0 | 0 | 1 | | **Итого** | **421** | **12 478** | **18 060** | **79 000** | Это подтверждает, что оценка должна учитывать не только требования, но и уже значимый объём реализации в backend и frontend. ## Как получена оценка Оценка опирается на три источника доказательств: 1. **Объём и сложность требований в `specs/`** — поздние спецификации заметно крупнее и сильнее завязаны на интеграции. Примеры: в `017-llm-analysis-plugin` 31 функциональное требование, в `025-clean-release-compliance` — 33, в `027-dataset-llm-orchestration` — 51. 2. **Хронологическая эволюция требований** — проект развивается от базовой настройки веб-интерфейса и исправления UI к консолидации платформы, затем к LLM-сценариям, отчётности, RBAC, enterprise-compliance и многосоставной оркестрации датасетов. 3. **История git, показывающая расширение объёма** — несколько коммитов фиксируют выход за рамки исходной постановки, особенно в части semantic-compliance, миграции на Svelte 5, hardening clean-release, test-contract enforcement и dataset-review. ## Эволюция требований (по времени) | Период | Эволюция объёма | Доказательства | Сигнал по трудозатратам | |---|---|---|---| | Декабрь 2025 | Базовое веб-приложение: настройки, Svelte UI, глобальные стили, запуск, ранний UX задач | `specs/002-app-settings/spec.md`, `005-fix-ui-ws-validation/spec.md`, ранние коммиты `2d8cae5`, `9b7b743` | Умеренные трудозатраты на full-stack старт | | Конец декабря 2025 — январь 2026 | UX миграции углубляется: история задач, логи, запросы пароля, backup/storage, миграция CLI→web, консолидация backend (`superset_tool` удалён), унификация frontend-дизайна и редизайн навигации | `specs/008`, `010`, `012`, `013`, `015` | Объём смещается от полировки UI к платформенному рефакторингу | | Конец января — февраль 2026 | Продукт становится “intelligence-enabled”: валидация/документация LLM dashboard, постоянное логирование задач, унифицированные отчёты, assistant chat, восстановление cross-filter | `specs/017`, `018`, `020`, `021`, `022` | Высокая стоимость интеграции backend, frontend, async-задач, Superset и LLM-провайдеров | | Март 2026 | Появляется enterprise- и governance-слой: clean enterprise delivery, фильтрация профиля пользователя, redesign для clean-release compliance, окна health для dashboard | `specs/023`, `024`, `025`, `026` | Добавляются release engineering, compliance evidence, RBAC, уведомления и policy-driven workflows | | Середина марта 2026 и далее | Оркестрация датасетов становится самым сложным участком продукта: semantic enrichment, уточнения, preview gating, audited SQL Lab launch, совместная работа и сохранение сессий | `specs/027-dataset-llm-orchestration/spec.md` и `plan.md` | Самый рискованный orchestration-сценарий в репозитории | ## Релевантная git-история, показывающая изменение объёма | Коммит | Что изменилось по объёму | Почему это важно для оценки | |---|---|---| | `8406628` | Clean-enterprise выделен в `023-clean-repo-enterprise` с 1 500+ строк новых spec-артефактов | Clean-enterprise стал отдельной программой, а не мелким дополнением | | `de1f044` | Добавлены test contract annotations и tracking покрытия | QA/compliance вышли за пределы обычного feature testing | | `36742cd` | Добавлен Docker admin bootstrap для clean release | Clean-release расширился до deployment/bootstrap операций | | `0083d90` | Frontend переведён на Svelte 5 runes в 60+ файлах | Миграция платформы добавила стоимость репозитория на уровне фронтенда | | `321e0eb` | Жёсткие tiers заменены на adaptive complexity semantics | Процессная и semantic-миграция создала сквозной объём документации и compliance | | `023bacd` | Доставлена и принята автоматическая часть US1 для dataset-review | Подтверждает, что `027` — реальная ветка реализации, а не только спецификация | | `ed3d5f3` | Добавлены clarification engine, preview adapter, batch approvals, RBAC sweep, i18n для `027` | Показывает, что dataset-review вырос в многофазную оркестрацию и hardening | ## Оценка трудозатрат по фазам | Фаза | Включённый объём | Оценка часов | |---|---|---:| | Базовая платформа и миграция web | Specs `002`, `005`, `008`, `010`, `012`, `013`, `015` | 1 000 | | Observability, LLM, отчётность, assistant, cross-filtering | Specs `017`, `018`, `020`, `021`, `022` | 1 450 | | Enterprise clean release, compliance, фильтрация профиля, health windows | Specs `023`, `024`, `025`, `026` | 950 | | Оркестрация датасетов и контролируемое исполнение | Spec `027` | 1 000 | | **Итого** | | **4 400** | ## Оценка трудозатрат по направлениям | Направление | Оценка часов | |---|---:| | Уточнение продукта/spec, архитектура, design review | 360 | | Backend-сервисы, модели, API, persistence, task orchestration | 1 500 | | Frontend-роуты, компоненты, состояние, UX-потоки, i18n | 1 050 | | Внешние интеграции (Superset, Git, LLM-провайдеры, уведомления) | 650 | | QA, contract testing, semantic/test compliance, regression hardening | 600 | | DevOps / упаковка релизов / hardening деплоя | 240 | | **Итого** | **4 400** | ## Рекомендуемый состав команды | Роль | Рекомендуемая загрузка | Примечания | |---|---|---| | Техлид / архитектор | 0,5–1,0 FTE | Владеет cross-feature дизайном, semantic protocol и интеграционными решениями | | Backend-инженеры | 2,0 FTE | Основные API, оркестрация, persistence, compliance, интеграции | | Frontend-инженер | 1,0 FTE | Svelte/SvelteKit, task/report/assistant/dataset UX | | Full-stack инженер | 1,0 FTE | Связывает API, storage, RBAC и end-to-end сценарии | | QA / automation инженер | 1,0 FTE | Contract, API, UI, regression и release validation | | DevOps / release инженер | 0,5 FTE | Offline bundle, Docker/bootstrap, deployment/compliance tooling | | Product/UX/Data SME | 0,5 FTE | Clarification flows, LLM UX, enterprise acceptance decisions | **Рекомендуемое ядро команды:** **5,5–7,0 FTE в смеси ролей**. ## Допущения - Оценка покрывает объём, отражённый в текущей истории `specs/`, а не минимальный MVP. - Существующие FastAPI/Svelte-архитектура, TaskManager, модель авторизации и интеграция с Superset считаются переиспользуемыми, а не переписываемыми с нуля. - Зависимости LLM/провайдеров и Superset доступны для разработки и тестирования. - Semantic-protocol и test-contract compliance считаются обязательной частью поставки, а не опциональной документацией. - Часть функциональности уже реализована, но оценка отражает **полную трудоёмкость проекта, подразумеваемую объёмом репозитория**, включая rework и hardening, на которые указывает git-история. ## Доверие и риски **Доверие:** среднее. **Основные риски, влияющие на диапазон:** 1. **Спецификации описаны неравномерно**; поздние specs (`025`, `027`) заметно тяжелее ранних. 2. **Сквозная semantic/process-работа** существенна и не видна только по product-specs. 3. **Интеграционный риск** высок для Superset, LLM-провайдеров, Git-операций и async task/reporting surfaces. 4. **Объём enterprise-compliance расширялся в ходе реализации**, особенно для clean release и audit evidence. 5. **Оркестрация датасетов остаётся самой неопределённой частью**, потому что `027` объединяет LLM UX, сохранение сессий, provenance, preview gating и audited execution. ## Использованные источники - Specs: `specs/002-app-settings/spec.md`, `005-fix-ui-ws-validation/spec.md`, `008-migration-ui-improvements/spec.md`, `010-refactor-cli-to-web/spec.md`, `012-remove-superset-tool/spec.md`, `013-unify-frontend-css/spec.md`, `015-frontend-nav-redesign/spec.md`, `017-llm-analysis-plugin/spec.md`, `018-task-logging-v2/spec.md`, `020-task-reports-design/spec.md`, `021-llm-project-assistant/spec.md`, `022-sync-id-cross-filters/spec.md`, `023-clean-repo-enterprise/spec.md`, `024-user-dashboard-filter/spec.md`, `025-clean-release-compliance/spec.md`, `026-dashboard-health-windows/spec.md`, `027-dataset-llm-orchestration/spec.md`. - Plans: `specs/021-llm-project-assistant/plan.md`, `specs/025-clean-release-compliance/plan.md`, `specs/027-dataset-llm-orchestration/plan.md`. - Git evidence: коммиты `8406628`, `de1f044`, `36742cd`, `0083d90`, `321e0eb`, `023bacd`, `ed3d5f3`, а также хронологический `git log --reverse -- specs`. # [/DEF:EffortAssess:Report]