Продукт: AI Business Copilot (PNL_PLATFORM)

Единая точка возврата: видение, принципы, границы MVP, фазы, карта кода, два контура данных, бэклог-шаблон.

• Техпроцесс: dev-flow.md
• Правила репозитория / референс UI: ../AGENTS.md
• Мотивация / юнит-экономика (owner-friendly): motivation-operating-memo.md · motivation-development-plan.md · демо UI: /motivation-demo
• P&L cockpit (свод B + время C, календарный FY): pnl-cockpit-ui-spec.md · прототип ряда месяцев: /pnl-cockpit
• Штатка + оргструктура + P&L (roles/use-cases): prd/staffing-org-pnl.md

---

1. Видение продукта

Веб-приложение — симулятор бизнес-модели и управленческих сценариев для CEO / собственника сервисной IT-компании со смешанной моделью (внедрение CRM, кастомная разработка, сопровождение, лицензии, продукты, внутренняя инфраструктура). Это не ERP, не замена бухучёта и не клон Excel.

Пользователь должен:

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

UX-цель: ощущение executive simulation workspace / decision cockpit, а не бухгалтерской панели или generic admin.

Для кого в первую очередь: CEO / собственник гибридной сервисной IT-компании; при расширении — CFO / топ-менеджмент (явно не целимся в полевой HRM/CRM в MVP).

Источник бизнес-логики: реальные таблицы и формулы владельца — логику извлекаем в доменную модель и движок приложения; таблицы в перспективе — источник сырых данных после маппинга, а не исполнитель формул.

---

2. Контекст бизнеса (домен)

• Несколько уровней экономики: собственник → CEO → топ → руководители юнитов → команды.
• Несколько юнитов/направлений (Enterprise, SMB, разработка, продукты, поддержка, инфраструктура и т.д.).
• Разные типы выручки с разной маржинальностью, внутренние передачи, бонусы, распределение прибыли, воронка продаж, зависимость от headcount и утилизации.

2.1. Собственник и CEO; модель vs фактический P&L

• Собственник и CEO — разные роли в модели и в мотивации. У CEO — своя система мотивации и KPI (наёмный/операционный лидер компании). Логика вознаграждения собственника (дивиденды, доля прибыли, long-term и т.д.) не смешивается с «зарплатой CEO» без явного продуктового решения.
• Текущий главный фокус продукта: сценарная управленческая модель (plan / what-if), которая бьётся на всех уровнях (юниты, роли, трансферты, компенсации, агрегат компании), масштабируется без поломки инвариантов и остаётся администрируемой и честной по стимулам.
• Фактический P&L (опора на реальные данные, закрытие периода, сверка) планируется как отдельный раздел приложения: отдельный контур смысла от экрана симуляции, чтобы не смешивать decision-support и учётный/фактический срез. Связь между контурами — общие определения метрик и перенос логики там, где это осознанно.

---

3. Принципы разработки

1. Сначала детерминированная логика — явные формулы и допущения; AI не внутри финансового ядра.
2. Domain-driven — сущности бизнеса первичны; не проектировать UI вокруг колонок Excel.
3. Разделение слоёв: доменные типы → calculation engine → состояние сценария → импорт/персистенция → UI. Нет бизнес-формул внутри React-компонентов.
4. Визуальная ясность важнее бухгалтерской полноты на ранних этапах.
5. Scenario-first — ценность только если параметры меняются и результат пересчитывается сразу.
6. Маленькие итерации — MVP, затем наращивание; не строить платформу «на вырост» без доказанного ядра.
7. AI (фаза позже) — объяснения, инсайты, подсказки сценариев поверх стабильных чисел из движка. В репозитории уже есть ранний прототип объяснений для контура Workspace+Sheets ([src/app/api/ai/explain/route.ts](../src/app/api/ai/explain/route.ts)) — это не финансовое ядро.

---

4. Границы MVP (что входит / что нет)

В MVP фокус на четырёх возможностях:

1. Описание бизнес-модели (юниты, роли, headcount, потоки выручки, расходы, допущения, бонусные правила — в объёме, достаточном для пересчёта).
2. Сценарное моделирование (изменение параметров → мгновенный результат).
3. Визуальная карта бизнеса (интерактивный граф).
4. Дашборд KPI и сравнение сценариев.

Сознательно не делаем в ранних версиях: полноценный ERP/HRM/CRM/payroll, копирование всех формул Excel 1:1, микросервисы, тяжёлый multi-tenant, ML-прогнозирование, AI внутри расчёта P&L.

---

5. Критерии успеха MVP

MVP считается успешным, если можно:

• описать компанию как систему (структура + экономика);
• увидеть движение денег и ключевые KPI;
• смоделировать структурные и параметрические изменения;
• сравнить сценарии;
• находить рычаги и утечки маржи (через числа и визуализацию, без «магии» модели);
• использовать это как опору для решений CEO.

---

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

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

В Prisma уже описаны таблицы **CeoCompany, CeoBusinessUnit, …** ([prisma/schema.prisma](../prisma/schema.prisma)) как задел под персистентность целевой доменной модели — CEO Simulator на них пока не завязан.

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

Направление унификации (без обязательства срока): один целевой DomainModel (как в [domain/types.ts](../src/features/ceo-simulator/domain/types.ts)) + адаптеры: mock, xlsx, импорт из Workspace/Google. Два движка — сливать только осознанно, после явного решения.

flowchart TB
  subgraph ceo_client [CEO_Simulator_Client]
    Zustand[useScenarioStore]
    Mock[mock_baseData]
    Engine1[calculateScenario]
    UI[Dashboard_Map_Charts]
    Zustand --> Engine1
    Mock --> Zustand
    Engine1 --> UI
  end

  subgraph workspace_server [Workspace_Sheets_Flow]
    PrismaWS[Prisma_Workspace_models]
    Engine2[calculateMvpMetrics_runScenario]
    Sheets[Google_Sheets_sync]
    PrismaWS --> Engine2
    Sheets --> PrismaWS
  end

  subgraph prisma_ceo [Prisma_Ceo_tables]
    CeoTables[CeoCompany_CeoBusinessUnit]
  end

  prisma_ceo -.->|not_wired_to_client_yet| ceo_client
  workspace_server -->|different_granularity| ceo_client

---

7. Модули продукта и статус в репо

---

8. Стратегия данных (этапы)

---

9. Фазы разработки (продуктовый roadmap)

Актуальный сквозной роадмап, текущий фокус владельца и задачи для агентов: platform-roadmap-agent-todo.md — при необходимости опережает таблицу ниже (например, приоритет мотивации юнитов vs симулятор).

---

10. Стек

---

11. Контур Workspace + главная (кратко)

Для полноты карты продукта:

• Workspace изолирует данные: сотрудники, компенсации, выручка по месяцу, utilization, сценарии с изменениями removeEmployee | changeCompensationRule | changeAvgSellingRate.
• Пользовательский путь: Интеграции → Источники данных → Сценарии → опционально AI chat с опорой на метрики этого контура.
• Подробности схемы БД: [prisma/schema.prisma](../prisma/schema.prisma).

---

12. Бэклог (шаблон)

Формат: идея → зачем → критерий готовности → приоритет P0–P3.

Идеи без приоритета (inbox): добавлять сюда свободным списком.

---

13. ADR-lite (решения и допущения)

---

14. Стратегия (бизнес) — заполняет владелец

---

Документ обновляй по мере решений; для правок по смыслу можно дать агенту текст «что изменить в разделе N».