UNIVERSAL_PROJECT_STRUCTURE.md

Универсальная структура для ЛЮБОГО проекта: IT, бизнес, организация, платформа.

Принципы:
- Масштабируемость (от простого к сложному)
- Универсальность (одинаковые правила для всех типов)
- Производственный цикл (DATA → PLAN → BUILD → OPS)

ЕДИНАЯ СТРУКТУРА: ВСЕ ПРОЕКТЫ = ORG

Принцип: Любой проект = организация (4 уровня)

ORG / TYPE / DIRECTION / SOLUTION

GROUP / ORG / TYPE / DIRECTION / SOLUTION

Правило: Начинаем с ORG → добавляем GROUP только когда проектов становится несколько

ПРИМЕРЫ СТРУКТУР

Одна организация (без группы)

lideravto/                ← ORG
├── PROJECT.md
├── CLAUDE.md
├── README.md
├── biz/                  ← TYPE (business)
│   ├── CLAUDE.md
│   ├── README.md
│   ├── sales/            ← DIRECTION
│   │   └── crm/          ← SOLUTION
│   └── ops/              ← DIRECTION
│       └── warehouse/    ← SOLUTION
├── fin/                  ← TYPE (finance)
│   ├── CLAUDE.md
│   ├── README.md
│   └── accounting/       ← DIRECTION
│       └── 1c/           ← SOLUTION
└── it/                   ← TYPE (IT)
    ├── CLAUDE.md
    ├── CACHE.yaml        ← CACHE только в IT!
    ├── README.md
    ├── data/             ← DATA раздел
    ├── plan/             ← PLAN раздел
    ├── web/              ← DIRECTION
    │   ├── _shared/
    │   ├── cscart/       ← SOLUTION
    │   └── drupal/       ← SOLUTION
    ├── mob/              ← DIRECTION
    │   └── flutter/      ← SOLUTION
    └── api/              ← DIRECTION
        └── fastapi/      ← SOLUTION

Группа организаций

holding/                  ← GROUP
├── GROUP.md              ← описание группы
├── CLAUDE.md             ← контекст группы
├── README.md
│
├── lideravto/            ← ORG #1
│   ├── PROJECT.md
│   ├── CLAUDE.md
│   ├── biz/
│   ├── fin/
│   └── it/
│       ├── CACHE.yaml
│       ├── data/
│       ├── plan/
│       └── web/
│           ├── cscart/
│           └── drupal/
│
└── pirotehnika/          ← ORG #2
    ├── PROJECT.md
    ├── CLAUDE.md
    ├── biz/
    ├── fin/
    └── it/
        ├── CACHE.yaml
        ├── data/
        ├── plan/
        └── web/
            └── opencart/

Простая организация (только IT)

startup-saas/             ← ORG
├── PROJECT.md
├── CLAUDE.md
├── biz/                  ← минимальный (может быть пустой)
│   └── README.md
├── fin/                  ← минимальный (может быть пустой)
│   └── README.md
└── it/                   ← основной фокус
    ├── CACHE.yaml
    ├── data/
    ├── plan/
    ├── web/nextjs/
    ├── mob/flutter/
    └── api/fastapi/

Правило: Даже если проект только IT — структура ORG (с biz/, fin/, it/)

УРОВНИ ИЕРАРХИИ

Уровень 0: GROUP (группа, ОПЦИОНАЛЬНО)

Что: Группа организаций (холдинг, портфолио, экосистема)

⚠️ ВАЖНО: Этот уровень НЕ обязательный! Используется только когда проектов становится несколько.

Файлы:
- GROUP.md — описание группы
- CLAUDE.md — контекст группы
- README.md — обзор

Примеры:
- holding/ — холдинг компаний
- portfolio/ — портфолио агентства
- ecosystem/ — экосистема стартапов

Когда добавлять:
- ✅ Появилась вторая организация
- ✅ Нужно общее управление несколькими ORG
- ✅ Общие ресурсы (инфра, бухгалтерия)
- ✅ Консолидированная отчётность

Когда НЕ нужен:
- ❌ Одна организация (работаем на уровне ORG)
- ❌ "На будущее" (добавляем когда реально нужно)
- ❌ Для красоты структуры (избыточная вложенность)

Уровень 1: ORG (организация)

Что: Корень организации (компания, проект, продукт)

Файлы:
- PROJECT.md — описание организации, бизнес-контекст
- CLAUDE.md — точка входа для AI
- README.md — быстрый старт для людей

Правила:
- Короткое имя (1 слово, латиница)
- Уникальное в GROUP или workspace
- Без пробелов и спецсимволов

Примеры:
- lideravto/ — организация (разборка грузовиков)
- pirotehnika/ — организация (пиротехника)
- startup-saas/ — организация (SaaS продукт)

org-name/
├── PROJECT.md
├── CLAUDE.md
├── README.md
├── biz/              ← может быть пустым
├── fin/              ← может быть пустым
└── it/               ← основной (если IT проект)
    └── CACHE.yaml

Уровень 2: TYPE (тип)

Обязательные типы:
- biz/ — бизнес (продажи, операции, закупки, маркетинг)
- fin/ — финансы (бухгалтерия, налоги, отчёты, платежи)
- it/ — IT (сайты, приложения, API, боты)

Файлы:
- CLAUDE.md — контекст типа (наследует ORG/CLAUDE.md)
- README.md — описание направления
- CACHE.yaml — только для it/!

Правила:
- Короткие имена (2-4 буквы)
- ВСЕ три типа должны быть (даже если пустые)
- Если организация только IT → biz/ и fin/ минимальные (только README.md)

Уровень 3: DIRECTION (направление)

Что: Направление деятельности (канал, технология, процесс)

IT направления:
- web/ — веб-сайты
- mob/ — мобильные приложения
- api/ — API и интеграции
- bot/ — боты (Telegram, WhatsApp)
- desktop/ — десктоп приложения

Бизнес направления:
- sales/ — продажи
- ops/ — операции
- support/ — поддержка
- warehouse/ — склад

Финансы:
- accounting/ — бухгалтерия
- tax/ — налоги
- reporting/ — отчётность

Файлы:
- README.md — описание направления
- _shared/ — общий код/данные (опционально)

Правила:
- Полные имена (читаемые)
- Не обязательно все направления
- Можно добавлять свои

Уровень 4: SOLUTION (решение)

Что: Конкретное решение (продукт, платформа, система)

IT решения:
- cscart/ — CS-Cart магазин
- drupal/ — Drupal сайт
- nextjs/ — Next.js приложение
- flutter/ — Flutter приложение
- fastapi/ — FastAPI сервис

Бизнес решения:
- crm/ — CRM система
- 1c/ — 1С Бухгалтерия
- wms/ — Система управления складом

Файлы:
- PLATFORM.md — описание платформы/решения
- README.md — как использовать
- modules/ — модули/расширения (для IT)
- app/ — установки приложения (для IT)

Правила:
- Имя платформы или тип решения
- Может быть несколько решений в одном направлении
- Каждое решение автономно

IT РЕШЕНИЯ: Детальная структура

Standalone IT проект

my-saas/                    ← PROJECT
├── PROJECT.md
├── CLAUDE.md
├── README.md
├── CACHE.yaml              ← CACHE в корне (IT проект)
│
├── data/                   ← DATA: источники данных
│   ├── sources/            ← внешние API, файлы
│   └── storage/            ← БД, кеш, S3
│
├── plan/                   ← PLAN: проектирование
│   ├── strategy/           ← стратегия, roadmap
│   ├── requirements/       ← требования (FR, NFR)
│   ├── architecture/       ← архитектура, ADR
│   └── backlog/            ← задачи
│
├── web/                    ← DIRECTION: веб
│   └── nextjs/             ← SOLUTION
│       ├── PLATFORM.md
│       ├── README.md
│       ├── modules/        ← модули приложения
│       │   └── auth/
│       │       ├── SPEC.yaml
│       │       ├── CODE-PROMPT.md
│       │       └── src/
│       └── app/            ← установки
│           ├── dev/        ← dev окружение
│           └── prod/       ← production
│
├── testing/                ← тесты
│   ├── unit/
│   ├── integration/
│   └── e2e/
│
├── deploy/                 ← развёртывание
│   ├── staging/
│   └── production/
│
└── docs/                   ← документация
    ├── api/
    └── guides/

Organizational IT (внутри it/)

lideravto/it/               ← TYPE = IT
├── CLAUDE.md
├── CACHE.yaml              ← CACHE только для IT!
├── README.md
│
├── infra/                  ← INFRA: инфраструктура (сервер, БД, домены)
│   ├── server/
│   ├── db/
│   └── domains/
│
├── data/                   ← DATA раздел (общий для IT)
│   ├── sources/
│   └── storage/
│
├── plan/                   ← PLAN раздел (общий для IT)
│   ├── strategy/
│   ├── requirements/
│   └── backlog/
│
├── web/                    ← DIRECTION
│   ├── _shared/            ← общий код для всех сайтов
│   │   ├── images/
│   │   └── scripts/
│   ├── cscart/             ← SOLUTION #1
│   │   ├── PLATFORM.md
│   │   ├── README.md
│   │   ├── modules/
│   │   │   └── lider_import/
│   │   │       ├── SPEC.yaml
│   │   │       ├── CODE-PROMPT.md
│   │   │       └── src/
│   │   └── app/
│   │       ├── work.lideravto.ru/   ← dev установка
│   │       └── lideravto.ru/        ← prod установка
│   └── drupal/             ← SOLUTION #2
│       ├── PLATFORM.md
│       └── app/
│           └── shop.lideravto.ru/
│
├── mob/                    ← DIRECTION
│   └── flutter/
│
├── api/                    ← DIRECTION
│   └── fastapi/
│
├── testing/
├── deploy/
└── docs/

СЕКЦИЯ DATA (источники данных)

data/
├── sources/                ← внешние источники
│   ├── api/                ← API интеграции
│   │   ├── ozon/
│   │   └── 1c/
│   ├── files/              ← файлы (CSV, XML)
│   └── services/           ← внешние сервисы
│
└── storage/                ← хранилища
    ├── db/                 ← БД (схемы, миграции)
    ├── cache/              ← кеш
    ├── s3/                 ← объектное хранилище
    └── files/              ← файловое хранилище

Примеры:
- E-commerce: API поставщиков, БД товаров, S3 изображения
- SaaS: БД пользователей, интеграции CRM
- Организация: 1С, OZON, Bitrix24, Google Sheets

СЕКЦИЯ PLAN (проектирование)

plan/
├── strategy/               ← стратегия
│   ├── vision.md           ← видение
│   ├── roadmap.md          ← дорожная карта
│   └── okr.md              ← цели
│
├── requirements/           ← требования
│   ├── business.md         ← бизнес-требования
│   ├── functional.md       ← функциональные (FR-1...)
│   └── technical.md        ← технические (NFR)
│
├── architecture/           ← архитектура
│   ├── system.md           ← системная
│   ├── data.md             ← данных
│   └── decisions/          ← ADR
│
└── backlog/                ← задачи
    ├── features.md         ← фичи
    ├── bugs.md             ← баги
    └── tech-debt.md        ← технический долг

Минимум (MVP):
- roadmap.md — что делаем
- backlog/ — очередь задач

СЕКЦИЯ BUILD (производство)

Старая структура: build/dev/feature-1/
Новая структура: web/nextjs/modules/auth/

Почему:
- Модули привязаны к решению (platform-specific)
- Каждое решение = своя структура модулей
- Фрактальная архитектура внутри модулей

СЕКЦИЯ OPS (эксплуатация)

testing/                    ← тестирование
├── unit/
├── integration/
└── e2e/

deploy/                     ← развёртывание
├── backup/                 ← резервное копирование
├── maint/                  ← обслуживание (очистка, оптимизация)
├── monitor/                ← мониторинг работы
├── setup/                  ← настройка окружения
├── scripts/                ← скрипты развёртывания
├── staging/                ← тестовое окружение
└── production/             ← продакшн

docs/                       ← документация
├── api/
└── guides/

Причина:
- Разделение забот (testing ≠ deploy ≠ docs)
- Более понятная структура
- OPS = слишком широкое понятие

MODULES (модули решения)

Что: Модуль = функциональный блок внутри решения

modules/auth/
├── SPEC.yaml               ← конфигурация модуля
├── CODE-PROMPT.md          ← сгенерированный промпт
├── src/                    ← исходный код
│   ├── controllers/
│   ├── models/
│   └── views/
├── tests/                  ← тесты модуля
│   ├── unit/
│   └── integration/
└── docs/                   ← документация модуля
    └── README.md

product: nextjs
module: auth
version: 1.0.0

task: "Авторизация пользователей"

data:
  source: "@CACHE#extracted.data.users_db"

constraints:
  platform: "@CACHE#extracted.products.nextjs.constraints"
  security:
    - "Использовать JWT токены"
    - "Хешировать пароли (bcrypt)"

dependencies:
  - "@../api/users#get_user"
  - "@../../mob/flutter/modules/auth#login_screen"

# CODE-PROMPT: auth module

## Задача
Авторизация пользователей

## Данные
- База пользователей: PostgreSQL (users table)
- Endpoint: /api/auth/login

## Ограничения платформы
[автоматически извлечено из CACHE]
- Next.js 14 App Router
- TypeScript strict mode
- React Server Components

## Зависимости
- API: /api/users (get_user)
- Mobile: Flutter auth screen

## Инструкции
[пошаговые инструкции для кодера]

ДЕКОМПОЗИЦИЯ БОЛЬШИХ МОДУЛЕЙ

Правило: Везде где есть код → должен быть CODE-PROMPT

Проблема: Модуль может быть слишком большим для одного промпта

Простой модуль (один промпт)

modules/simple-feature/
├── SPEC.yaml
├── CODE-PROMPT.md          ← один файл, вся задача
└── src/
    └── index.ts

Когда использовать:
- Модуль < 500 строк кода
- Одна чёткая задача
- Нет сложной логики

Средний модуль (подзадачи = файлы)

modules/catalog/
├── SPEC.yaml
├── CODE-PROMPT.md          ← основной (общее описание)
├── CODE-PROMPT-1.md        ← подзадача: controllers
├── CODE-PROMPT-2.md        ← подзадача: models
├── CODE-PROMPT-3.md        ← подзадача: views
└── src/
    ├── controllers/        ← реализация CODE-PROMPT-1
    ├── models/             ← реализация CODE-PROMPT-2
    └── views/              ← реализация CODE-PROMPT-3

# CODE-PROMPT: catalog module

## Общая задача
Модуль каталога товаров

## Архитектура
Модуль состоит из 3 подзадач:
- CODE-PROMPT-1: Controllers (API endpoints)
- CODE-PROMPT-2: Models (данные и валидация)
- CODE-PROMPT-3: Views (шаблоны отображения)

## Общие данные
[данные доступные всем подзадачам]

## Общие ограничения
[ограничения для всего модуля]

## Порядок реализации
1. Сначала CODE-PROMPT-2 (models) — основа
2. Затем CODE-PROMPT-1 (controllers) — логика
3. В конце CODE-PROMPT-3 (views) — интерфейс

# CODE-PROMPT-1: Controllers

## Задача
Создать API endpoints для каталога

## Зависимости
- Требует: CODE-PROMPT-2 (models)
- Используется: CODE-PROMPT-3 (views)

## Инструкции
[конкретные инструкции только для controllers]

Когда использовать:
- Модуль 500-2000 строк
- Чёткое разделение на файлы/папки
- Каждая подзадача = отдельная часть кода

Большой модуль (подзадачи = части одного файла)

modules/import/
├── SPEC.yaml
├── CODE-PROMPT.md          ← основной
├── CODE-PROMPT-1.md        ← нормализация данных
├── CODE-PROMPT-2.md        ← маппинг категорий
├── CODE-PROMPT-3.md        ← создание товаров
├── CODE-PROMPT-4.md        ← обработка фич
└── src/
    └── import.php          ← один большой файл
        ├── [блок 1: normalize]
        ├── [блок 2: categories]
        ├── [блок 3: products]
        └── [блок 4: features]

# CODE-PROMPT: import module

## Общая задача
Импорт товаров из CSV файла в CS-Cart

## Архитектура
Один файл import.php с 4 логическими блоками:
1. normalize() — CODE-PROMPT-1
2. mapCategories() — CODE-PROMPT-2
3. createProducts() — CODE-PROMPT-3
4. processFeatures() — CODE-PROMPT-4

## Поток данных
CSV → normalize() → mapCategories() → createProducts() → processFeatures() → DB

## Общие данные
- Входной файл: BAZON CSV
- База данных: MySQL (cscart_products, cscart_categories)

## Общие ограничения
- PHP 8.0+
- CS-Cart API v4.19
- Batch processing (1000 товаров за раз)

# CODE-PROMPT-1: Normalize data

## Задача
Функция normalize() — очистка и нормализация входных данных

## Входные данные
CSV строка из BAZON файла

## Выходные данные
Массив с нормализованными полями

## Правила нормализации
1. Артикул: trim, uppercase
2. Цена: float, убрать валюту
3. Наличие: boolean (в наличии/нет)

## Код
[инструкции только для функции normalize()]

Когда использовать:
- Один большой файл >2000 строк
- Логические блоки внутри файла
- Сложная последовательность операций
- Legacy код (нельзя разбить на файлы)

Очень большой модуль (группа модулей)

modules/ecommerce/
├── SPEC.yaml
├── CODE-PROMPT.md          ← корневой промпт
├── catalog/
│   ├── CODE-PROMPT.md      ← промпт каталога
│   ├── CODE-PROMPT-1.md
│   ├── CODE-PROMPT-2.md
│   └── src/
├── cart/
│   ├── CODE-PROMPT.md      ← промпт корзины
│   ├── CODE-PROMPT-1.md
│   └── src/
└── checkout/
    ├── CODE-PROMPT.md      ← промпт оформления
    └── src/

# CODE-PROMPT: ecommerce module

## Общая задача
E-commerce модуль (каталог + корзина + оформление)

## Подмодули
1. catalog/ — каталог товаров (CODE-PROMPT.md)
2. cart/ — корзина (CODE-PROMPT.md)
3. checkout/ — оформление заказа (CODE-PROMPT.md)

## Взаимодействие
catalog → cart → checkout

## Общая архитектура
[общие принципы для всех подмодулей]

## Использование
Сначала читай CODE-PROMPT конкретного подмодуля

Когда использовать:
- Модуль = группа связанных модулей
- Каждый подмодуль > 1000 строк
- Можно разрабатывать параллельно
- Общие принципы + специфичная реализация

Правила именования

Уровень	Файл	Назначение
Корневой	`CODE-PROMPT.md`	Общее описание, архитектура
Подзадача	`CODE-PROMPT-1.md`	Первая подзадача
Подзадача	`CODE-PROMPT-2.md`	Вторая подзадача
...	`CODE-PROMPT-N.md`	N-ая подзадача
Подмодуль	`submodule/CODE-PROMPT.md`	Промпт подмодуля

Нумерация:
- По порядку реализации (1 → 2 → 3)
- Или по зависимостям (2 зависит от 1)
- Или по логике (input → process → output)

Связи между промптами

prompts:
  main: CODE-PROMPT.md
  sub:
    - CODE-PROMPT-1.md  # controllers
    - CODE-PROMPT-2.md  # models
    - CODE-PROMPT-3.md  # views

  order:
    - CODE-PROMPT-2     # сначала models
    - CODE-PROMPT-1     # затем controllers
    - CODE-PROMPT-3     # в конце views

  dependencies:
    CODE-PROMPT-1:
      requires:
        - CODE-PROMPT-2
    CODE-PROMPT-3:
      requires:
        - CODE-PROMPT-1
        - CODE-PROMPT-2

dependencies:
  "modules/catalog/CODE-PROMPT-1.md":
    depends_on:
      - "modules/catalog/CODE-PROMPT.md"
      - "modules/catalog/CODE-PROMPT-2.md"
      - "data/MASTER.md"
    rebuild: true

Алгоритм выбора структуры

1. Оцени размер модуля:
   < 500 строк        → CODE-PROMPT.md (один файл)
   500-2000 строк     → CODE-PROMPT.md + CODE-PROMPT-N (по файлам)
   > 2000 строк       → CODE-PROMPT.md + CODE-PROMPT-N (по блокам/файлам)
   > 5000 строк       → Подмодули (каждый со своим CODE-PROMPT)

2. Оцени сложность:
   Простая задача     → CODE-PROMPT.md
   Несколько частей   → CODE-PROMPT-1,2,3
   Много зависимостей → Подмодули

3. Определи декомпозицию:
   - По файлам? (controllers, models, views)
   - По блокам? (normalize, process, save)
   - По функциям? (input, logic, output)
   - По фичам? (catalog, cart, checkout)

Примеры из lideravto

modules/lider_setup/
├── SPEC.yaml
├── CODE-PROMPT.md          ← один файл
└── src/
    └── install.php

modules/lider_import/
├── SPEC.yaml
├── CODE-PROMPT.md          ← общий
├── CODE-PROMPT-1.md        ← normalize
├── CODE-PROMPT-2.md        ← categories
├── CODE-PROMPT-3.md        ← products
├── CODE-PROMPT-4.md        ← features
└── src/
    └── lib/
        ├── normalize.php
        ├── categories.php
        ├── products.php
        └── features.php

modules/catalog/
├── CODE-PROMPT.md          ← корневой
├── filters/
│   ├── CODE-PROMPT.md
│   └── src/
├── variations/
│   ├── CODE-PROMPT.md
│   └── src/
└── search/
    ├── CODE-PROMPT.md
    └── src/

APP (установки приложения)

Что: Рабочие установки приложения (окружения)

# Dev + Prod
app/
├── dev/                    ← development
└── prod/                   ← production

# Мультисайт
app/
├── work.lideravto.ru/      ← dev сайт
├── lideravto.ru/           ← prod сайт #1
└── shop.lideravto.ru/      ← prod сайт #2

Правило:
- Имя = доменное имя (если веб)
- Имя = окружение (dev/staging/prod)
- Всё содержимое — установленное приложение (НЕ исходники)

CACHE.yaml (кеш и зависимости)

Что: Система отслеживания изменений и зависимостей

Правило: CACHE.yaml ТОЛЬКО в it/ типе, НЕ в корне ORG!

version: 1.0
updated: 2026-02-03T10:30:00Z

files:
  PROJECT.md:
    hash: sha256:abc123def456
    modified: 2026-02-01T15:20:00Z
  data/MASTER.md:
    hash: sha256:789ghi012jkl
    modified: 2026-02-03T09:15:00Z

extracted:
  data:
    bazon_url:
      value: "https://baz-on.ru/export/..."
      source: "data/MASTER.md"
      updated: 2026-02-03
    users_db:
      value: "postgresql://localhost/lideravto"
      source: "data/storage/db/config.yaml"
  products:
    cscart:
      version: "4.19.1"
      constraints:
        - "PHP 8.0+"
        - "MySQL 5.7+"
        - "Модули в app/addons/"

dependencies:
  "web/cscart/modules/lider_import/CODE-PROMPT.md":
    depends_on:
      - "data/MASTER.md"
      - "PROJECT.md"
      - "web/cscart/PLATFORM.md"
    rebuild: true

Правила:
- Автообновление при изменении файлов
- Проверка зависимостей перед генерацией CODE-PROMPT
- Ребилд CODE-PROMPT если зависимости изменились

ФАЙЛЫ НА КАЖДОМ УРОВНЕ

PROJECT (уровень 1)

Обязательные:
- PROJECT.md — описание проекта
- CLAUDE.md — контекст для AI
- README.md — быстрый старт

Опциональные:
- ROADMAP.md — дорожная карта
- CHANGELOG.md — история изменений

TYPE (уровень 2, только ORG)

Обязательные:
- CLAUDE.md — контекст типа (extends PROJECT/CLAUDE.md)
- README.md — описание направления

DIRECTION (уровень 3)

Обязательные:
- README.md — описание направления

SOLUTION (уровень 4)

Обязательные:
- PLATFORM.md — описание платформы
- README.md — как использовать

IT решения:
- modules/ — модули приложения
- app/ — установки
- docs/ — документация

Бизнес решения:
- Специфичная структура системы

ПРАВИЛА ПРИМЕНЕНИЯ

Все проекты = ORG структура

Принцип: Любой проект использует ORG структуру (4 уровня)

Обязательно:
- ✅ Три типа: biz/, fin/, it/
- ✅ CACHE.yaml в it/ (если есть код)
- ✅ PROJECT.md, CLAUDE.md, README.md в корне

Полная организация (все типы активны)

Признаки:
- ✅ Бизнес + IT + Финансы
- ✅ Несколько направлений в каждом типе
- ✅ Интеграции между типами

Примеры:
- Интернет-магазин (продажи + сайты + 1С)
- Производство (операции + ERP + мобильное приложение)
- Агентство (проекты + CRM + портфолио)

org-name/
├── biz/              ← полная (sales/, ops/, support/)
├── fin/              ← полная (accounting/, tax/, reporting/)
└── it/               ← полная (web/, mob/, api/)

IT-фокусированная организация

Признаки:
- ✅ Основной фокус = IT продукт
- ✅ Минимальные biz/ и fin/
- ✅ Может расшириться в будущем

Примеры:
- Стартап SaaS
- Мобильное приложение
- API сервис

startup-saas/
├── biz/              ← минимальный (только README.md)
├── fin/              ← минимальный (только README.md)
└── it/               ← основной (web/, mob/, api/)
    ├── CACHE.yaml
    ├── data/
    ├── plan/
    └── ...

Правило: Даже если проект только IT — структура ORG (готовность к росту)

Группа организаций (когда проектов несколько)

⚠️ Не используется по умолчанию! Добавляется только при росте.

Когда добавлять GROUP:
- ✅ Появилась 2-я организация (было: lideravto/ → стало: holding/lideravto/)
- ✅ Несколько организаций под одним управлением
- ✅ Общие ресурсы (инфра, бухгалтерия)
- ✅ Консолидированная отчётность

GROUP / ORG / TYPE / DIRECTION / SOLUTION

# Было: одна ORG
lideravto/

# Стало: GROUP с несколькими ORG
holding/
├── lideravto/
└── pirotehnika/

holding/              ← GROUP (добавлен при появлении 2-го проекта)
├── GROUP.md
├── lideravto/        ← ORG #1 (была корнем)
│   ├── biz/
│   ├── fin/
│   └── it/
└── pirotehnika/      ← ORG #2 (новая)
    ├── biz/
    ├── fin/
    └── it/

Правило: Начинаем с ORG → мигрируем в GROUP когда появляется 2-й проект

МИГРАЦИЯ СУЩЕСТВУЮЩИХ ПРОЕКТОВ

Шаг 1: Оценить проект

Вопросы:
1. Какие типы активны (biz, fin, it)?
2. Сколько IT решений (платформ)?
3. Есть ли несколько организаций? (для GROUP)

Результат:
- По умолчанию → ORG (4 уровня)
- Несколько организаций → мигрируем в GROUP/ORG позже

Шаг 2: Создать структуру

mkdir -p {biz,fin,it}
mkdir -p biz/README.md fin/README.md
mkdir -p it/{data,plan,testing,deploy,docs}
mkdir -p it/{web,mob,api}
touch it/CACHE.yaml

# 1. Создать GROUP корень
mkdir -p holding/

# 2. Переместить существующую ORG
mv lideravto/ holding/

# 3. Добавить новую ORG
mkdir -p holding/pirotehnika/{biz,fin,it}

Шаг 3: Переместить файлы

Старое → Новое

dev/cscart/ → it/web/cscart/
dev/import/ → it/web/cscart/modules/lider_import/
data/ → it/data/
planning/ → it/plan/
deploy/ → it/deploy/

Шаг 4: Обновить документацию

ПРИМЕРЫ ПРОЕКТОВ

Пример 1: IT-стартап (SaaS)

startup-saas/               ORG (4 уровня)
├── PROJECT.md
├── CLAUDE.md
├── README.md
├── biz/                    ← минимальный
│   └── README.md
├── fin/                    ← минимальный
│   └── README.md
└── it/                     ← основной
    ├── CACHE.yaml
    ├── data/
    ├── plan/
    ├── web/nextjs/
    ├── mob/flutter/
    ├── api/fastapi/
    ├── testing/
    └── deploy/

Характеристики:
- Фокус на IT продукте
- Минимальные biz/ и fin/ (готовность к росту)
- Три платформы (Next.js + Flutter + FastAPI)

Пример 2: E-commerce организация

lideravto/                  4 уровня
├── PROJECT.md
├── CLAUDE.md
├── biz/
│   ├── sales/crm/
│   ├── ops/warehouse/
│   └── support/helpdesk/
├── fin/
│   └── accounting/1c/
└── it/
    ├── CACHE.yaml
    ├── data/
    ├── plan/
    ├── web/
    │   ├── cscart/
    │   └── drupal/
    ├── mob/flutter/
    └── api/fastapi/

Характеристики:
- Организация (бизнес + финансы + IT)
- Несколько IT решений (2 сайта + приложение + API)
- Интеграции (1С, CRM, склад)

Пример 3: Агентство

agency/                     ORG (4 уровня)
├── PROJECT.md
├── CLAUDE.md
├── biz/
│   ├── CLAUDE.md
│   ├── sales/bitrix24/
│   └── projects/jira/
├── fin/
│   ├── CLAUDE.md
│   └── accounting/quickbooks/
└── it/
    ├── CLAUDE.md
    ├── CACHE.yaml
    └── web/
        ├── portfolio-site/nextjs/
        ├── client-a/wordpress/
        └── client-b/drupal/

Характеристики:
- Полная организация (biz + fin + it активны)
- Разные платформы для клиентов
- Общая IT инфраструктура

Пример 4: Группа организаций (холдинг)

holding/                    GROUP (5 уровней)
├── GROUP.md
├── CLAUDE.md
├── README.md
│
├── lideravto/              ← ORG #1
│   ├── PROJECT.md
│   ├── CLAUDE.md
│   ├── biz/
│   │   ├── sales/crm/
│   │   └── ops/warehouse/
│   ├── fin/
│   │   └── accounting/1c/
│   └── it/
│       ├── CACHE.yaml
│       ├── data/
│       └── web/
│           ├── cscart/
│           └── drupal/
│
└── pirotehnika/            ← ORG #2
    ├── PROJECT.md
    ├── CLAUDE.md
    ├── biz/
    │   └── sales/crm/
    ├── fin/
    │   └── accounting/1c/
    └── it/
        ├── CACHE.yaml
        ├── data/
        └── web/
            └── opencart/

Характеристики:
- Группа из 2 организаций
- Каждая ORG = полная структура (4 уровня)
- Общее управление на уровне GROUP
- Независимые IT решения

ПРЕИМУЩЕСТВА СТРУКТУРЫ

1. Универсальность

2. Готовность к росту

3. Производственный цикл

4. Модульность

5. Короткие имена

6. Группировка

СВЯЗАННЫЕ СТАНДАРТЫ

ЧЕКЛИСТ ПРИМЕНЕНИЯ

Новый проект (всегда начинаем с ORG)

Добавление GROUP (когда проектов стало несколько)

Миграция существующего

Версия: 2.0.0
Дата: 2026-02-03
Автор: Architect
Статус: Active

СТАНДАРТ: Универсальная структура проекта

Назначение