Constitution

Project Constitution

Основной документ конституции — принципы, границы и правила проекта.

⚖️ Конституция проекта SprosOS Seed

Полное название: SprosOS Seed — Demand Operating System
Кодовое имя: sprosos-seed
Первый клиент: EcoYar (ecoyar.ru, ручные ткацкие станки)
Версия конституции: v0.1.0
Дата: 2026-06-11

1. Миссия

SprosOS Seed — платформа управления спросом, которая превращает неструктурированные рыночные сигналы в верифицированные бизнес-возможности через цикл:

Signal → Evidence → JTBD → Offer → Experiment → Measurement → Opportunity → Learning

Платформа даёт бизнесу прозрачность того, почему клиенты покупают, как они принимают решения и какие возможности открываются на основе данных.

2. North Star

Стать международным SaaS, который является стандартом де-факто для evidence-driven product management в производственных и B2B-компаниях.

Ближайшая цель: За 6 месяцев внедрить SprosOS у EcoYar, показав измеримый рост конверсии и сокращение времени вывода новых офферов.

3. Архитектура

  • Modular monolith — bounded contexts внутри одного процесса, с чёткими границами модулей
  • Multi-tenant с первого дня — все сущности имеют tenant_id, архитектура поддерживает изоляцию
  • Multi-project, multi-market, multi-locale — каждая сущность привязана к проекту, рынку и локали
  • Event-driven внутри — bounded contexts общаются через доменные события

4. Источник истины

Единственный источник истины — файлы в репозитории.
Никакие устные договорённости, сообщения в чатах или документы вне репозитория не имеют силы конституционного решения.

В репозитории фиксируется:

  • Архитектура и доменная модель
  • Принятые решения (ADR)
  • Продуктовые артефакты (JTBD, офферы, эксперименты)
  • Процессы и протоколы
  • История изменений

5. 10 архитектурных принципов

  1. Domain-Core Separation — Доменная логика изолирована от инфраструктуры
  2. Change Protocol First — Любое изменение начинается с конституции
  3. Immutability by Design — JTBD, Offer, Experiment — версионированы
  4. Evidence over Opinion — Решения на основе данных, не мнений
  5. Pay for Use — Архитектура не строит для гипотетических сценариев
  6. Traceability — Каждый элемент трассируется от Vision до кода
  7. Convention over Configuration — Явные конфигурации через доменные сущности
  8. Open-Closed Contexts — Bounded contexts открыты для расширения, закрыты для модификации
  9. Tenant Isolation — Данные клиентов строго изолированы
  10. Failure Transparency — Ошибки логируются и трассируются, не замалчиваются

6. Кто принимает решения

РольОбласть решений
Product ArchitectАрхитектура, доменная модель, конституция
Product OwnerПриоритеты, scope, roadmap
Tech LeadТехническая реализация, стек, инструменты
AnalystJTBD-гипотезы, метрики, эксперименты
Команда (консенсус)Изменения, затрагивающие конституцию

Любое изменение конституции требует: (1) ADR, (2) согласование Product Architect, (3) запись в CHANGE_PROTOCOL.md.

7. Цикл разработки

  1. Constitution change — изменение начинается с конституции
  2. ADR — фиксация архитектурного решения
  3. Task card — задача с acceptance criteria
  4. Code — реализация
  5. Tests — покрытие
  6. Review — проверка соответствия конституции
  7. Changelog — запись в историю

Эта конституция — живой документ. Все изменения проходят через CHANGE_PROTOCOL.md (шаг 10).