architect/arh/analysis/2026-02-02-project-structure/DISCUSSION.md

ОБСУЖДЕНИЕ: Структура проекта

Дата: 2026-02-02
Статус: Draft для обсуждения
Проект: lideravto (как пример)

ПРЕДЛОЖЕННАЯ СТРУКТУРА

4 раздела (производственный цикл)

project/
├── data/      ← 1. Источники данных
├── plan/      ← 2. Проектирование и ПМ
├── build/     ← 3. Производство
└── ops/       ← 4. Эксплуатация

МОДЕЛИРОВАНИЕ: lideravto

Текущее состояние проекта

Что есть:
- 13,347 товаров из BAZON
- CS-Cart 4.19.1 установлен
- 3 блока разработки: import ✅, catalog 🔄, seo ⏳
- work.lideravto.ru (dev), lideravto.ru (prod)

Активная работа:
- Разработка каталога
- Планирование SEO
- Развёртывание на prod

ВАРИАНТ 1: Полная фрактальность

Идея: ВСЕ разделы фрактальные (с одинаковой структурой)

lideravto/
├── data/
│   ├── CLAUDE.md
│   ├── planning/
│   ├── dev/
│   ├── testing/
│   └── deploy/
│
├── plan/
│   ├── CLAUDE.md
│   ├── planning/
│   ├── dev/
│   ├── testing/
│   └── deploy/
│
├── build/
│   ├── CLAUDE.md
│   ├── planning/
│   ├── dev/
│   │   ├── import/
│   │   ├── catalog/
│   │   └── seo/
│   ├── testing/
│   └── deploy/
│
└── ops/
    ├── CLAUDE.md
    ├── planning/
    ├── dev/
    ├── testing/
    └── deploy/

Проблемы варианта 1

❌ data/ не нужна фрактальность
- Источники данных не "разрабатываются"
- Нет смысла в planning/dev/testing/ для data/sources/
- data/ = конфигурация, не процесс

❌ plan/ не нужна фрактальность
- Планирование не "тестируется"
- plan/planning/ = рекурсия без смысла
- plan/ = документы, не код

❌ ops/ частично нужна
- ops/deploy/ может быть фрактальным (скрипты)
- ops/monitor/ НЕ нужна фрактальность (конфиги)
- ops/backup/ НЕ нужна (скрипты)

✅ build/ нужна фрактальность
- build/dev/ = фрактальные блоки (import, catalog, seo)
- Каждый блок = planning → dev → testing → deploy

ВАРИАНТ 2: Фрактальность только в build/dev/

Идея: Фрактальность ТОЛЬКО для разработки блоков

lideravto/
│
├── data/              ← КОНФИГУРАЦИЯ (не фрактально)
│   ├── sources/
│   │   ├── bazon.yaml
│   │   └── 1c.yaml
│   ├── storage/
│   │   ├── db-schema.sql
│   │   ├── s3-config.yaml
│   │   └── cache-config.yaml
│   └── infra/
│       └── credentials.md
│
├── plan/              ← ДОКУМЕНТЫ (не фрактально)
│   ├── strategy/
│   │   ├── vision.md
│   │   └── roadmap.md
│   ├── requirements/
│   │   ├── import.md
│   │   ├── catalog.md
│   │   └── seo.md
│   ├── architecture/
│   │   ├── system.md
│   │   └── decisions/
│   └── backlog/
│       └── tasks.yaml
│
├── build/             ← ПРОИЗВОДСТВО
│   ├── setup/         ← не фрактально (конфиги)
│   │   ├── server.sh
│   │   └── cscart-install.sh
│   │
│   ├── dev/           ← ФРАКТАЛЬНО (блоки)
│   │   ├── import/    ← фрактальный блок
│   │   │   ├── CLAUDE.md
│   │   │   ├── planning/
│   │   │   ├── dev/
│   │   │   ├── testing/
│   │   │   └── deploy/
│   │   ├── catalog/   ← фрактальный блок
│   │   └── seo/       ← фрактальный блок
│   │
│   ├── testing/       ← не фрактально (общие тесты)
│   │   ├── e2e/
│   │   └── performance/
│   │
│   └── docs/          ← не фрактально (документация)
│       ├── api/
│       └── guides/
│
└── ops/               ← ОПЕРАЦИИ
    ├── deploy/        ← не фрактально (скрипты)
    │   ├── staging.sh
    │   └── production.sh
    ├── monitor/       ← не фрактально (конфиги)
    │   ├── prometheus.yaml
    │   └── grafana.json
    ├── backup/        ← не фрактально (скрипты)
    │   └── backup.sh
    └── maint/         ← не фрактально (скрипты)
        └── cleanup.sh

Преимущества варианта 2

✅ Простота
- Фрактальность только где нужна (build/dev/)
- Остальное = простые файлы/папки

✅ Понятность
- data/ = конфиги
- plan/ = документы
- build/dev/ = блоки (фрактальные)
- ops/ = скрипты

✅ Масштабируемость
- Легко добавлять блоки в build/dev/
- Не ломается при росте

ВАРИАНТ 3: Гибридная фрактальность

Идея: Фрактальность где процесс, простота где конфигурация

lideravto/
│
├── data/              ← ПРОСТАЯ структура
│   ├── sources/
│   ├── storage/
│   └── infra/
│
├── plan/              ← ПРОСТАЯ структура
│   ├── strategy/
│   ├── requirements/
│   ├── architecture/
│   └── backlog/
│
├── build/
│   ├── setup/         ← ПРОСТАЯ (скрипты)
│   │
│   ├── dev/           ← ФРАКТАЛЬНАЯ (блоки)
│   │   ├── import/    ← микро-проект
│   │   ├── catalog/   ← микро-проект
│   │   └── seo/       ← микро-проект
│   │
│   ├── testing/       ← ПРОСТАЯ (общие тесты)
│   └── docs/          ← ПРОСТАЯ (документы)
│
└── ops/
    ├── deploy/        ← МОЖЕТ БЫТЬ ФРАКТАЛЬНОЙ
    │   ├── staging/
    │   │   ├── planning/    ← план деплоя
    │   │   ├── scripts/     ← скрипты
    │   │   └── rollback/    ← откат
    │   └── production/
    │       ├── planning/
    │       ├── scripts/
    │       └── rollback/
    │
    ├── monitor/       ← ПРОСТАЯ
    ├── backup/        ← ПРОСТАЯ
    └── maint/         ← ПРОСТАЯ

Когда фрактальность?

Критерии для фрактальности:

✅ Нужна фрактальность:
- Есть процесс разработки (планирование → код → тесты → деплой)
- Блок независимый (можно разрабатывать отдельно)
- Есть критерии готовности
- Размер > 2 часов

❌ НЕ нужна фрактальность:
- Только конфигурация (YAML, ENV)
- Только документы (MD)
- Только скрипты (без планирования)
- Размер < 30 минут

ПРАКТИЧЕСКАЯ ПРОВЕРКА: lideravto

Раздел DATA

Что там:

data/
├── sources/
│   └── bazon/
│       ├── url.txt           ← URL CSV
│       └── mapping.yaml      ← маппинг полей
├── storage/
│   ├── db/
│   │   ├── schema.sql        ← схема БД
│   │   └── migrations/       ← миграции
│   └── s3/
│       └── config.yaml       ← конфиг S3
└── infra/
    └── credentials.md        ← доступы

Вопрос: Нужна ли фрактальность?
Ответ: ❌ НЕТ — это конфигурация, не процесс

Раздел PLAN

Что там:

plan/
├── strategy/
│   ├── vision.md             ← видение проекта
│   └── roadmap.md            ← Q1-2026, Q2-2026
├── requirements/
│   ├── import.md             ← FR-1, FR-2 для импорта
│   ├── catalog.md            ← FR для каталога
│   └── seo.md                ← FR для SEO
├── architecture/
│   ├── system.md             ← системная архитектура
│   └── decisions/
│       ├── 001-use-cscart.md
│       └── 002-bazon-import.md
└── backlog/
    └── tasks.yaml            ← очередь задач

Вопрос: Нужна ли фрактальность?
Ответ: ❌ НЕТ — это документы, не код

Раздел BUILD/DEV

Что там:

build/dev/
├── import/                   ← ФРАКТАЛЬНЫЙ БЛОК
│   ├── CLAUDE.md
│   ├── planning/             ← план блока
│   │   ├── requirements.md
│   │   ├── blocks.md         ← 8 подблоков
│   │   └── criteria.md
│   ├── dev/                  ← разработка
│   │   ├── INSTRUCTIONS.md
│   │   └── lider_import/     ← код модуля
│   ├── testing/              ← тесты блока
│   │   └── unit/
│   └── deploy/               ← результат
│       └── README.md
│
├── catalog/                  ← ФРАКТАЛЬНЫЙ БЛОК
│   ├── CLAUDE.md
│   ├── planning/
│   │   ├── blocks.md         ← 4 подблока
│   │   └── criteria.md
│   ├── dev/
│   │   └── INSTRUCTIONS.md
│   ├── testing/
│   └── deploy/
│
└── seo/                      ← ФРАКТАЛЬНЫЙ БЛОК
    └── [аналогично]

Вопрос: Нужна ли фрактальность?
Ответ: ✅ ДА — это разработка блоков (процесс)

Раздел OPS

Что там:

ops/
├── deploy/
│   ├── staging.sh            ← скрипт деплоя
│   └── production.sh         ← скрипт деплоя
├── monitor/
│   ├── prometheus.yaml       ← конфиг
│   └── grafana.json          ← дашборд
├── backup/
│   └── backup.sh             ← скрипт бэкапа
└── maint/
    └── cleanup.sh            ← скрипт очистки

Вопрос: Нужна ли фрактальность?
Ответ: ❌ НЕТ (для lideravto) — простые скрипты

НО: Для большого проекта может быть:

ops/deploy/production/
├── planning/
│   ├── deployment-plan.md    ← план развёртывания
│   └── rollback-plan.md      ← план отката
├── scripts/
│   ├── deploy.sh
│   └── rollback.sh
├── testing/
│   └── smoke-tests.sh        ← дымовые тесты после деплоя
└── monitoring/
    └── check-health.sh       ← проверка здоровья

Вывод: Фрактальность в ops/ — опционально, для сложных деплоев

КОНТЕКСТБЛОК: Обязательное промежуточное звено

Ключевая идея

Для ЛЮБОГО IT проекта:

❌ НЕПРАВИЛЬНО:
Задача → Сразу кодинг

✅ ПРАВИЛЬНО:
Задача → КОНТЕКСТБЛОК → Кодинг

КОНТЕКСТБЛОК — обязательное промежуточное звено между задачей и кодом.

Что такое КОНТЕКСТБЛОК

Определение: Фрактальная структура которая содержит:
1. Контекст — зачем, почему, что за задача
2. Планирование — требования, декомпозиция, решения
3. Разработка — инструкции, код
4. Результат — что получилось

Структура:

контекстблок/
├── CLAUDE.md              ← Описание контекста
├── CACHE.yaml             ← Зависимости
│
├── planning/              ← КОНТЕКСТ + ПЛАНИРОВАНИЕ
│   ├── context.md         ← Зачем? Почему? Что за задача?
│   ├── requirements.md    ← FR-1, FR-2, NFR
│   ├── blocks.md          ← Декомпозиция
│   └── criteria.md        ← Критерии готовности
│
├── dev/                   ← РАЗРАБОТКА
│   ├── INSTRUCTIONS.md    ← Как делать
│   └── src/               ← Код
│
├── testing/               ← ТЕСТИРОВАНИЕ
├── deploy/                ← РЕЗУЛЬТАТ
│
└── [под-контекстблоки]/   ← Вложенные (опционально)
    ├── подблок-1/
    └── подблок-2/

Обязательное правило

ДЛЯ ЛЮБОЙ ЗАДАЧИ:

1. ПОЛУЧИЛИ ЗАДАЧУ
   ↓
2. СОЗДАЛИ КОНТЕКСТБЛОК
   ↓ Даже если мало информации!
3. ЗАПОЛНИЛИ planning/context.md
   ↓ Зачем? Почему? Что делаем?
4. СОБРАЛИ requirements.md
   ↓
5. СОЗДАЛИ декомпозицию blocks.md
   ↓
6. ТОЛЬКО ПОТОМ → dev/INSTRUCTIONS.md
   ↓
7. КОДИНГ

Важно: Даже если информации мало — всё равно создаём контекстблок и заполняем что знаем.

Иерархия контекстблоков

Контекстблок может содержать под-контекстблоки:

build/dev/
└── marketplace/                    ← КОНТЕКСТБЛОК уровня 1
    ├── CLAUDE.md                   ← Контекст: Маркетплейс
    ├── planning/
    │   ├── context.md              ← Зачем маркетплейс?
    │   └── blocks.md               ← 3 подблока: catalog, orders, payments
    │
    ├── catalog/                    ← КОНТЕКСТБЛОК уровня 2
    │   ├── CLAUDE.md
    │   ├── planning/
    │   │   ├── context.md          ← Зачем каталог?
    │   │   └── blocks.md           ← 4 подблока: filters, variations...
    │   ├── dev/
    │   └── deploy/
    │
    ├── orders/                     ← КОНТЕКСТБЛОК уровня 2
    │   ├── CLAUDE.md
    │   ├── planning/
    │   └── dev/
    │
    └── payments/                   ← КОНТЕКСТБЛОК уровня 2
        └── ...

Правило: Контекстблок может порождать под-контекстблоки через декомпозицию.

Минимальный контекстблок

Даже если информации мало:

block/
├── CLAUDE.md
└── planning/
    └── context.md              ← Минимум!

# planning/context.md:
# КОНТЕКСТ

**Задача:** [Что нужно сделать]

**Зачем:** [Почему это нужно]

**Что известно:**
- [Пункт 1]
- [Пункт 2]

**Что НЕ известно:**
- [Вопрос 1]
- [Вопрос 2]

**Следующий шаг:**
- [ ] Собрать requirements
- [ ] Создать декомпозицию

Потом дополняем:
1. requirements.md
2. blocks.md
3. criteria.md
4. dev/INSTRUCTIONS.md

Зачем нужен контекстблок?

Проблема БЕЗ контекстблока:

Получили задачу "Сделай импорт"
    ↓
Начали кодить import.py
    ↓
Через 3 часа: "А откуда данные? А какой формат? А сколько товаров?"
    ↓
Переделываем

Решение С контекстблоком:

Получили задачу "Сделай импорт"
    ↓
Создали контекстблок import/
    ↓
planning/context.md:
  - Зачем: Загрузить 13,347 товаров из BAZON
  - Откуда: CSV URL (см. data/MASTER.md)
  - Как: Штатный Advanced Import CS-Cart
    ↓
planning/requirements.md:
  - FR-1: 3 типа обменов (Full/New/Prices)
  - FR-2: 4-уровневая категоризация
    ↓
planning/blocks.md:
  - 8 блоков (features, normalize, categories...)
    ↓
dev/INSTRUCTIONS.md:
  - Пошаговые инструкции
    ↓
КОД (с полным пониманием контекста)

КОНТЕКСТБЛОК = build/dev/block/

Наши фрактальные блоки УЖЕ являются контекстблоками!

build/dev/import/              ← Это КОНТЕКСТБЛОК
├── CLAUDE.md                  ← Описание контекста
├── CACHE.yaml                 ← Зависимости
├── planning/                  ← КОНТЕКСТ
│   ├── context.md             ← Зачем? Почему? (НОВОЕ!)
│   ├── requirements.md        ← Требования
│   ├── blocks.md              ← Декомпозиция
│   └── criteria.md            ← Критерии
├── dev/                       ← РАЗРАБОТКА
│   ├── INSTRUCTIONS.md
│   └── src/
└── deploy/                    ← РЕЗУЛЬТАТ

Изменение: Добавляем planning/context.md как обязательный файл.

ВЫВОДЫ

1. Контекстблок — обязательное звено

ДЛЯ ЛЮБОЙ IT ЗАДАЧИ:

Задача → КОНТЕКСТБЛОК → Код

Минимальный контекстблок:
- planning/context.md (зачем, почему, что известно)

Полный контекстблок:
- planning/context.md
- planning/requirements.md
- planning/blocks.md
- planning/criteria.md
- dev/INSTRUCTIONS.md
- dev/src/
- testing/
- deploy/

2. Иерархия контекстблоков

Контекстблок может содержать под-контекстблоки:

marketplace/              ← КОНТЕКСТБЛОК (большой)
├── catalog/              ← под-контекстблок
├── orders/               ← под-контекстблок
└── payments/             ← под-контекстблок

Правило: Декомпозиция в blocks.md создаёт под-контекстблоки.

3. Фрактальность = Контекстблоки

Фрактальная структура (planning/dev/testing/deploy) нужна ТОЛЬКО:
- ✅ build/dev/ — КОНТЕКСТБЛОКИ (разработка)
- ✅ ops/deploy/ — сложное развёртывание (опционально)

НЕ нужна:
- ❌ data/ — конфигурация
- ❌ plan/ — документы
- ❌ build/setup/ — скрипты установки
- ❌ ops/monitor/ — конфиги мониторинга
- ❌ ops/backup/ — скрипты бэкапа

4. Правило создания контекстблока

Когда создавать:

ЕСЛИ (IT задача) ТО
  создать контекстблок

ДАЖЕ ЕСЛИ (мало информации) ТО
  всё равно создать (минимальный)

Минимальный контекстблок:

block/
├── CLAUDE.md
└── planning/
    └── context.md        ← Что знаем, что не знаем

Полный контекстблок:

block/
├── CLAUDE.md
├── CACHE.yaml
├── planning/
│   ├── context.md        ← ОБЯЗАТЕЛЬНО
│   ├── requirements.md
│   ├── blocks.md
│   └── criteria.md
├── dev/
├── testing/
└── deploy/

3. Оптимальная структура для lideravto

lideravto/
│
├── data/              ← ПРОСТАЯ (конфигурация)
│   ├── sources/
│   ├── storage/
│   └── infra/
│
├── plan/              ← ПРОСТАЯ (документы)
│   ├── strategy/
│   ├── requirements/
│   ├── architecture/
│   └── backlog/
│
├── build/
│   ├── setup/         ← ПРОСТАЯ (скрипты)
│   ├── dev/           ← ФРАКТАЛЬНАЯ (блоки!)
│   │   ├── import/
│   │   ├── catalog/
│   │   └── seo/
│   ├── testing/       ← ПРОСТАЯ (общие тесты)
│   └── docs/          ← ПРОСТАЯ (документация)
│
└── ops/               ← ПРОСТАЯ (для lideravto)
    ├── deploy/        ← скрипты
    ├── monitor/       ← конфиги
    ├── backup/        ← скрипты
    └── maint/         ← скрипты

ПРОБЛЕМЫ И ВОПРОСЫ

Проблема 1: build/testing/ vs блок/testing/

Вопрос: Где тесты?

Вариант А: В каждом блоке

build/dev/import/testing/    ← тесты импорта
build/dev/catalog/testing/   ← тесты каталога

Вариант Б: Общие тесты

build/testing/
├── unit/                     ← unit-тесты всех блоков
├── integration/              ← интеграционные
└── e2e/                      ← end-to-end

Вариант В: Оба

build/dev/import/testing/     ← unit-тесты блока
build/testing/e2e/            ← e2e всего проекта

Рекомендация: Вариант В (оба)

Проблема 2: build/docs/ vs блок/docs/

Вопрос: Где документация?

Вариант А: В каждом блоке

build/dev/import/deploy/README.md    ← как использовать импорт
build/dev/catalog/deploy/README.md   ← как использовать каталог

Вариант Б: Общая документация

build/docs/
├── api/                              ← API всего проекта
└── guides/
    ├── import-guide.md
    └── catalog-guide.md

Вариант В: Оба

build/dev/import/deploy/README.md     ← документация блока
build/docs/guides/import-guide.md     ← общий guide

Рекомендация: Вариант В (оба)

Проблема 3: cscart/ куда девать?

Текущее:

build/dev/cscart/                     ← CS-Cart приложение

Вопросы:
- Это НЕ блок (приложение)
- Но в build/dev/ только блоки
- Куда переместить?

Варианты:

А) build/app/

build/
├── app/               ← приложения (не блоки)
│   └── cscart/
└── dev/               ← блоки
    ├── import/
    ├── catalog/
    └── seo/

Б) build/platform/

build/
├── platform/          ← платформы (CS-Cart, Drupal...)
│   └── cscart/
└── dev/               ← блоки

В) Оставить в dev/

build/dev/
├── cscart/            ← НЕ блок (помечено в CLAUDE.md)
├── import/            ← блок
├── catalog/           ← блок
└── seo/               ← блок

Рекомендация: Вариант А (build/app/)

ФИНАЛЬНАЯ РЕКОМЕНДАЦИЯ

Структура для lideravto

lideravto/
├── CLAUDE.md
├── PROJECT.md
│
├── data/              ← конфигурация (не фрактально)
│   ├── sources/
│   ├── storage/
│   └── infra/
│
├── plan/              ← документы (не фрактально)
│   ├── strategy/
│   ├── requirements/
│   ├── architecture/
│   └── backlog/
│
├── build/
│   ├── setup/         ← скрипты (не фрактально)
│   ├── app/           ← приложения (не фрактально)
│   │   └── cscart/
│   ├── dev/           ← блоки (ФРАКТАЛЬНО!)
│   │   ├── import/
│   │   ├── catalog/
│   │   └── seo/
│   ├── testing/       ← общие тесты (не фрактально)
│   └── docs/          ← общая документация (не фрактально)
│
└── ops/               ← операции (не фрактально для lideravto)
    ├── deploy/
    ├── monitor/
    ├── backup/
    └── maint/

ВОПРОСЫ ДЛЯ ОБСУЖДЕНИЯ

1. Согласен с правилом фрактальности?

Правило: Фрактальность только для процессов разработки (build/dev/)

Да/Нет/Корректировки?

2. build/app/ для приложений правильно?

Или:
- build/platform/
- build/runtime/
- Оставить в build/dev/ с пометкой

Твой вариант?

3. Тесты и документация в двух местах?

Текущее предложение:
- Тесты блока: блок/testing/
- Общие тесты: build/testing/
- Документация блока: блок/deploy/README.md
- Общая документация: build/docs/

Правильно или упростить?

4. ops/ может быть фрактальной для сложных проектов?

Для lideravto: простая структура (скрипты)
Для enterprise: может быть фрактальная (plan → deploy → monitor)

Добавить вариативность в стандарт?

ОПТИМИЗАЦИЯ КОНТЕКСТА: Типы структур

Проблема: Claude перегружается если загружать всё сразу

Решение: Разделить по типу использования

3 типа структур

ФРАКТАЛЬНАЯ               ИСТОЧНИКИ ПРАВИЛ           КЕШ
build/dev/block/          theory/                    CACHE.yaml
├── planning/             standards/                 ↓
├── dev/                  templates/                 dependencies:
├── testing/              patterns/                    - file1
└── deploy/               ↓                            - file2
↓                         LOCKED, читаются
Полный процесс            при необходимости           Что загрузить
разработки

Тип 1: ФРАКТАЛЬНЫЕ (build/dev/)

Когда: Процесс разработки (планирование → код → тесты → деплой)

Структура:

block/
├── CLAUDE.md           ← Точка входа
├── CACHE.yaml          ← Зависимости (что загрузить)
├── planning/           ← ЧТО делаем
├── dev/                ← КАК делаем
├── testing/            ← Тесты
└── deploy/             ← Результаты

Правило загрузки:
1. Claude читает CLAUDE.md → видит CACHE.yaml
2. CACHE.yaml указывает что загрузить (источники данных, стандарты)
3. Claude загружает только нужное

Пример CACHE.yaml:

dependencies:
  data_sources:
    - ../../data/MASTER.md          # BAZON URL
  standards:
    - architect/standards/FRACTAL_ARCHITECTURE.md
  blocks:
    - ../import/CLAUDE.md           # зависимость от другого блока

Тип 2: ИСТОЧНИКИ ПРАВИЛ (theory/, standards/, templates/)

Когда: Неизменяемые правила, читаются по необходимости

Структура: Простые MD файлы

Правило использования:
- ❌ НЕ загружать при старте
- ✅ Загружать когда триггер (см. CLAUDE.md > ИНДЕКС ТРИГГЕРОВ)
- ✅ Загружать через CACHE.yaml блока

Пример триггера:

Запрос: "создай новый блок"
→ Триггер: "блок" → читай architect/standards/FRACTAL_ARCHITECTURE.md

Пример через CACHE:

# В import/CACHE.yaml
dependencies:
  standards:
    - architect/standards/FRACTAL_ARCHITECTURE.md  # нужен для понимания структуры

Тип 3: КЕШ (CACHE.yaml)

Назначение: Явно указывать что нужно загрузить для работы с блоком

Где: В каждом фрактальном блоке (build/dev/*/CACHE.yaml)

Формат:

# Версия CACHE
version: 1.0.0

# Зависимости (что загрузить)
dependencies:

  # Источники данных
  data_sources:
    - ../../data/MASTER.md

  # Стандарты
  standards:
    - architect/standards/FRACTAL_ARCHITECTURE.md
    - architect/standards/DATABASE_NAMING.md

  # Другие блоки
  blocks:
    - ../import/CLAUDE.md      # зависит от import

  # Инфраструктура
  infra:
    - ../../infra/CLAUDE.md

# Входные данные (что блок ожидает на входе)
inputs:
  bazon_url: "https://baz-on.ru/export/..."
  cscart_path: "/path/to/cscart"
  db_config: {...}

# Выходные данные (что блок производит)
outputs:
  - "lider_setup модуль"
  - "lider_import модуль"
  - "13,347 товаров в БД"

Алгоритм:
1. Claude открывает блок → читает CLAUDE.md
2. CLAUDE.md указывает на CACHE.yaml
3. Claude читает CACHE.yaml
4. Claude загружает только dependencies (не всё подряд)

Тип 4: КОНФИГУРАЦИЯ (data/, plan/)

Когда: Данные и документы (не процессы)

Структура: Простые файлы/папки

Правило:
- ❌ НЕ фрактальные
- ✅ Простая иерархия
- ✅ Загружаются через CACHE.yaml блоков

Пример:

data/
├── sources/
│   └── bazon.yaml          ← конфигурация источника
└── storage/
    └── db-schema.sql       ← схема БД

plan/
├── strategy/
│   └── roadmap.md          ← документ
└── requirements/
    └── import.md           ← документ

Тип 5: СКРИПТЫ (ops/)

Когда: Операции (deploy, backup, monitor)

Структура: Простые скрипты + конфиги

Правило:
- ❌ НЕ фрактальные (для lideravto)
- ✅ Простые .sh/.yaml файлы
- ⚠️ Может быть фрактальной для сложных проектов

Пример:

ops/
├── deploy/
│   └── production.sh       ← скрипт
├── backup/
│   └── backup.sh           ← скрипт
└── monitor/
    └── prometheus.yaml     ← конфиг

ПРАВИЛО ВЫБОРА СТРУКТУРЫ

Алгоритм

1. Есть процесс разработки? (план → код → тесты → деплой)
   → ДА: ФРАКТАЛЬНАЯ (build/dev/)
   → НЕТ: идём дальше

2. Это правило/стандарт? (теория, шаблон, паттерн)
   → ДА: ИСТОЧНИК ПРАВИЛ (theory/, standards/, templates/)
   → НЕТ: идём дальше

3. Это данные или документ?
   → ДА: КОНФИГУРАЦИЯ (data/, plan/)
   → НЕТ: идём дальше

4. Это операция? (deploy, backup, monitor)
   → ДА: СКРИПТЫ (ops/)

Таблица решений

Вопрос Да → Нет →
Процесс разработки? ФРАКТАЛЬНАЯ →
Правило/стандарт? ИСТОЧНИК →
Данные/документ? КОНФИГУРАЦИЯ →
Операция? СКРИПТЫ ?

ПРИМЕНЕНИЕ К lideravto

data/ → КОНФИГУРАЦИЯ

data/
├── MASTER.md              ← конфигурация (BAZON URL)
├── sources/
│   └── bazon.yaml
└── storage/
    └── db-schema.sql

Тип: КОНФИГУРАЦИЯ
Загрузка: Через CACHE.yaml блоков (например import/CACHE.yaml)

plan/ → КОНФИГУРАЦИЯ

plan/
├── strategy/
│   └── roadmap.md         ← документ
└── requirements/
    └── import.md          ← документ

Тип: КОНФИГУРАЦИЯ (документы)
Загрузка: По необходимости (триггер "roadmap" → читать roadmap.md)

build/dev/ → ФРАКТАЛЬНАЯ

build/dev/
├── import/                ← ФРАКТАЛЬНЫЙ блок
│   ├── CLAUDE.md
│   ├── CACHE.yaml         ← зависимости
│   ├── planning/
│   ├── dev/
│   ├── testing/
│   └── deploy/
├── catalog/               ← ФРАКТАЛЬНЫЙ блок
└── seo/                   ← ФРАКТАЛЬНЫЙ блок

Тип: ФРАКТАЛЬНАЯ (процессы разработки)
Загрузка:
1. Claude открывает import/CLAUDE.md
2. Читает import/CACHE.yaml
3. Загружает только dependencies (data/MASTER.md, standards/, ...)

ops/ → СКРИПТЫ

ops/
├── deploy/
│   └── production.sh      ← скрипт
├── backup/
│   └── backup.sh          ← скрипт
└── monitor/
    └── prometheus.yaml    ← конфиг

Тип: СКРИПТЫ
Загрузка: По необходимости (триггер "deploy" → читать production.sh)

architect/ → ИСТОЧНИКИ ПРАВИЛ

architect/
├── theory/               ← LOCKED, читается по триггерам
├── standards/            ← читается через CACHE.yaml
└── templates/            ← читается по триггерам

Тип: ИСТОЧНИКИ ПРАВИЛ
Загрузка:
- Через CACHE.yaml блоков
- По триггерам в CLAUDE.md

ПРЕИМУЩЕСТВА ПОДХОДА

1. Оптимизация контекста

✅ Claude не загружает всё сразу
✅ Загружает только нужное (через CACHE.yaml)
✅ Источники правил — по триггерам

2. Прозрачность

✅ Явные зависимости (CACHE.yaml)
✅ Понятно что откуда берётся
✅ Легко найти правило (по триггеру)

3. Масштабируемость

✅ Новый блок = новый CACHE.yaml
✅ Не ломается при росте проекта
✅ Не перегружает контекст

ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ

Пример 1: Работа с блоком import

Запрос: "открой блок import"

Алгоритм Claude:
1. Читаю import/CLAUDE.md → вижу CACHE.yaml
2. Читаю import/CACHE.yaml → вижу dependencies
3. Загружаю:
- data/MASTER.md (BAZON URL)
- architect/standards/FRACTAL_ARCHITECTURE.md
4. Готов работать с блоком

Не загружаю:
- catalog/CLAUDE.md (не в dependencies)
- seo/CLAUDE.md (не в dependencies)
- plan/roadmap.md (не в dependencies)
- ops/deploy/ (не в dependencies)

Пример 2: Создание нового блока

Запрос: "создай блок payments"

Алгоритм Claude:
1. Триггер "блок" → читаю architect/standards/FRACTAL_ARCHITECTURE.md
2. Создаю структуру по шаблону
3. Создаю CACHE.yaml с зависимостями:
yaml dependencies: standards: - architect/standards/FRACTAL_ARCHITECTURE.md blocks: - ../catalog/CLAUDE.md # платежи зависят от каталога

Пример 3: Применение стандарта

Запрос: "как назвать таблицу в БД?"

Алгоритм Claude:
1. Триггер "таблица" → читаю architect/standards/DATABASE_NAMING.md
2. Применяю правило (app_orders, prj_products)
3. Отвечаю пользователю

Не читаю:
- import/CLAUDE.md
- catalog/CLAUDE.md
- plan/roadmap.md

ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА: Эволюция структуры

4 стадии развития

INCEPTION (идея)
    ↓
MVP (минимальный продукт)
    ↓
GROWTH (рост и развитие)
    ↓
MATURE (зрелый проект)
    ↓
ENTERPRISE (масштаб)

СТАДИЯ 1: INCEPTION (0-1 неделя)

Что есть: Идея, требования, первичный анализ

Структура:

project/
├── CLAUDE.md              ← Описание проекта
├── analysis/              ← Дискуссии и выбор подходов
│   └── YYYY-MM-DD-название/
│       └── DISCUSSION.md  ← Анализ вариантов
└── plan/
    ├── strategy/
    │   └── vision.md      ← Видение
    └── requirements/
        └── initial.md     ← Первичные требования

Пути работы:
1. Создать DISCUSSION.md → анализ вариантов
2. Выработать концепт → создать vision.md
3. Собрать требования → создать requirements/
4. → Переход к MVP

Критерии готовности:
- ✅ Видение сформулировано
- ✅ Требования собраны
- ✅ Технологический стек выбран
- ✅ Архитектурные решения приняты

СТАДИЯ 2: MVP (1-4 недели)

Что есть: Первый работающий прототип

Структура:

project/
├── CLAUDE.md
├── PROJECT.md             ← Описание
│
├── data/                  ← ПОЯВЛЯЕТСЯ
│   └── sources/
│       └── config.yaml    ← Источники данных
│
├── plan/
│   ├── strategy/
│   │   ├── vision.md
│   │   └── roadmap.md     ← Дорожная карта
│   ├── requirements/
│   │   └── mvp.md         ← Требования MVP
│   └── backlog/
│       └── tasks.yaml     ← Очередь задач
│
├── build/
│   ├── setup/             ← Скрипты установки
│   │   └── install.sh
│   ├── dev/               ← ФРАКТАЛЬНЫЕ БЛОКИ
│   │   └── core/          ← Один базовый блок
│   │       ├── CLAUDE.md
│   │       ├── CACHE.yaml
│   │       ├── planning/
│   │       ├── dev/
│   │       └── deploy/
│   └── docs/
│       └── README.md      ← Минимальная документация
│
└── ops/
    ├── deploy/
    │   └── dev.sh         ← Деплой на dev окружение
    └── backup/
        └── backup.sh      ← Простой бэкап

Пути работы:
1. Создать минимальную структуру (data, plan, build, ops)
2. Создать первый блок (build/dev/core/)
3. Реализовать MVP функциональность
4. Настроить dev деплой
5. → Переход к Growth

Критерии готовности:
- ✅ MVP работает
- ✅ Один блок реализован
- ✅ Dev деплой настроен
- ✅ Минимальная документация есть

Что НЕ нужно:
- ❌ Сложная архитектура
- ❌ Множество блоков
- ❌ Production деплой
- ❌ Monitoring

СТАДИЯ 3: GROWTH (2-6 месяцев)

Что есть: Растущий проект, новые фичи, расширение команды

Структура:

project/
├── CLAUDE.md
├── PROJECT.md
├── ROADMAP.md             ← ПОЯВЛЯЕТСЯ
│
├── data/
│   ├── sources/
│   │   ├── api1.yaml
│   │   ├── api2.yaml      ← Множество источников
│   │   └── files/
│   ├── storage/           ← ПОЯВЛЯЕТСЯ
│   │   ├── db/
│   │   │   └── schema.sql
│   │   └── s3/
│   │       └── config.yaml
│   └── infra/
│       └── credentials.md
│
├── plan/
│   ├── strategy/
│   │   ├── vision.md
│   │   ├── roadmap.md     ← Детальный roadmap
│   │   └── okr.md         ← ПОЯВЛЯЕТСЯ (цели)
│   ├── requirements/
│   │   ├── feature-1.md
│   │   ├── feature-2.md   ← По фиче на документ
│   │   └── nfr.md         ← Нефункциональные
│   ├── architecture/      ← ПОЯВЛЯЕТСЯ
│   │   ├── system.md
│   │   └── decisions/
│   │       ├── 001-db.md
│   │       └── 002-api.md
│   └── backlog/
│       ├── features.md
│       ├── bugs.md
│       └── tech-debt.md
│
├── build/
│   ├── setup/
│   │   ├── server.sh
│   │   └── dependencies.sh
│   ├── dev/               ← ФРАКТАЛЬНЫЕ БЛОКИ (3-7 шт)
│   │   ├── auth/          ← Блок аутентификации
│   │   ├── catalog/       ← Блок каталога
│   │   ├── orders/        ← Блок заказов
│   │   ├── payments/      ← Блок платежей
│   │   └── admin/         ← Блок админки
│   ├── testing/           ← ПОЯВЛЯЕТСЯ
│   │   ├── unit/
│   │   ├── integration/
│   │   └── e2e/
│   ├── ci-cd/             ← ПОЯВЛЯЕТСЯ
│   │   └── pipeline.yaml
│   └── docs/
│       ├── api/
│       └── guides/
│
└── ops/
    ├── deploy/
    │   ├── staging.sh     ← ПОЯВЛЯЕТСЯ staging
    │   └── production.sh  ← ПОЯВЛЯЕТСЯ production
    ├── monitor/           ← ПОЯВЛЯЕТСЯ
    │   ├── prometheus.yaml
    │   └── grafana.json
    ├── backup/
    │   └── backup.sh
    └── maint/
        └── cleanup.sh

Пути работы:

Добавление новой фичи:
1. Создать plan/requirements/feature-N.md
2. Создать build/dev/feature-N/ (фрактальный блок)
3. Создать feature-N/CACHE.yaml (зависимости)
4. Реализовать по feature-N/dev/INSTRUCTIONS.md
5. Тесты → build/testing/
6. Деплой на staging → ops/deploy/staging.sh
7. Деплой на production → ops/deploy/production.sh

Рефакторинг существующего блока:
1. Обновить block/planning/ (новые требования)
2. Обновить block/dev/INSTRUCTIONS.md
3. Рефакторинг кода
4. Обновить тесты
5. Деплой

Добавление нового источника данных:
1. Создать data/sources/new-api.yaml
2. Обновить CACHE.yaml блоков которые используют
3. Реализовать коннектор
4. Тестирование

Критерии готовности:
- ✅ 3-7 блоков реализовано
- ✅ Testing настроен
- ✅ CI/CD работает
- ✅ Production деплой есть
- ✅ Monitoring настроен

Что появляется:
- ✅ Детальная архитектура
- ✅ Множество блоков
- ✅ Автоматизация (CI/CD)
- ✅ Staging + Production
- ✅ Monitoring

СТАДИЯ 4: MATURE (6+ месяцев)

Что есть: Зрелый проект, стабильная архитектура, команда

Структура: Полная (как в GROWTH) + оптимизации

Дополнительно:

project/
├── build/
│   ├── app/               ← ПОЯВЛЯЕТСЯ (приложения)
│   │   ├── cscart/        ← Платформы
│   │   └── drupal/
│   ├── dev/               ← 10+ блоков
│   ├── testing/
│   │   └── performance/   ← ПОЯВЛЯЕТСЯ
│   └── docs/
│       ├── api/
│       ├── guides/
│       └── architecture/  ← ПОЯВЛЯЕТСЯ
│
└── ops/
    ├── deploy/
    │   ├── blue-green/    ← ПОЯВЛЯЕТСЯ (advanced)
    │   └── rollback/
    ├── monitor/
    │   ├── alerts/        ← ПОЯВЛЯЕТСЯ
    │   └── dashboards/
    ├── security/          ← ПОЯВЛЯЕТСЯ
    │   ├── ssl/
    │   └── audit/
    └── maint/
        ├── cleanup/
        └── optimization/

Пути работы:

Плановая разработка:
1. Планирование спринта (backlog → sprint)
2. Параллельная работа над блоками
3. Code review + тесты
4. Staging → Production (по графику)
5. Мониторинг + алерты

Инцидент-менеджмент:
1. Алерт → ops/monitor/
2. Анализ → logs + metrics
3. Hotfix → создать блок/hotfix/
4. Deploy → production (через rollback plan)
5. Post-mortem → decisions/

Рефакторинг архитектуры:
1. Создать analysis/YYYY-MM-DD-refactoring/DISCUSSION.md
2. Анализ вариантов
3. ADR → decisions/NNN-refactoring.md
4. План миграции → plan/architecture/migration.md
5. Поэтапная реализация

Критерии готовности:
- ✅ 10+ блоков
- ✅ Performance testing
- ✅ Advanced deployment (blue-green)
- ✅ Security audit
- ✅ Полная документация

СТАДИЯ 5: ENTERPRISE (1+ год)

Что есть: Платформа, множество проектов, большая команда

Структура: Полная + масштабирование

Дополнительно:

project/
├── plan/
│   ├── project/           ← ПОЯВЛЯЕТСЯ
│   │   ├── team.md        ← Команда и роли
│   │   ├── timeline.md
│   │   ├── budget.md
│   │   └── risks.md
│   └── compliance/        ← ПОЯВЛЯЕТСЯ
│       ├── gdpr.md
│       └── security.md
│
├── build/
│   ├── modules/           ← ПОЯВЛЯЕТСЯ (переиспользуемые)
│   │   ├── auth-module/
│   │   └── payment-module/
│   └── dev/               ← 20+ блоков, организованы по доменам
│       ├── core/
│       ├── marketplace/
│       ├── crm/
│       └── analytics/
│
└── ops/
    ├── deploy/
    │   ├── multi-region/  ← ПОЯВЛЯЕТСЯ
    │   ├── canary/
    │   └── feature-flags/
    └── compliance/        ← ПОЯВЛЯЕТСЯ
        └── audit-logs/

Пути работы:

Управление платформой:
1. Roadmap на квартал
2. Приоритизация фич
3. Allocation ресурсов
4. Tracking прогресса

Модульная разработка:
1. Создать переиспользуемый модуль (build/modules/)
2. Использовать в блоках (через CACHE.yaml)
3. Версионирование модулей
4. Обновление зависимостей

Compliance:
1. Audit → ops/compliance/
2. Security review → plan/compliance/
3. Updates → по требованиям
4. Reporting

МАТРИЦА: Стадия × Структура

Элемент Inception MVP Growth Mature Enterprise
data/ — ✅ sources ✅ + storage ✅ полная ✅ полная
plan/strategy/ ✅ vision ✅ + roadmap ✅ + OKR ✅ полная ✅ + compliance
plan/requirements/ ✅ initial ✅ mvp ✅ по фичам ✅ полная ✅ полная
plan/architecture/ — — ✅ появляется ✅ полная ✅ + patterns
plan/project/ — — — — ✅ появляется
build/setup/ — ✅ базовый ✅ полный ✅ полный ✅ полный
build/dev/ — 1 блок 3-7 блоков 10+ блоков 20+ блоков
build/app/ — — — ✅ появляется ✅ полная
build/modules/ — — — — ✅ появляется
build/testing/ — — ✅ появляется ✅ + perf ✅ полная
build/ci-cd/ — — ✅ появляется ✅ полная ✅ полная
ops/deploy/ — ✅ dev ✅ + staging/prod ✅ + blue-green ✅ multi-region
ops/monitor/ — — ✅ появляется ✅ + alerts ✅ полная
ops/security/ — — — ✅ появляется ✅ полная
ops/compliance/ — — — — ✅ появляется

ПРАВИЛА ЭВОЛЮЦИИ

Правило 1: Добавляй постепенно

❌ НЕ создавать всё сразу:

project/
├── data/sources/api/files/services/     ← Пустые папки
├── plan/strategy/requirements/...       ← Пустые папки
├── build/setup/dev/testing/ci-cd/...    ← Пустые папки
└── ops/deploy/monitor/backup/...        ← Пустые папки

✅ Создавать по мере необходимости:

MVP:
project/
├── data/sources/               ← Только это
├── plan/strategy/vision.md     ← Только это
├── build/dev/core/             ← Только это
└── ops/deploy/dev.sh           ← Только это

→ Рост → добавляем по мере роста

Правило 2: Блоки масштабируются

MVP: 1 блок

build/dev/
└── core/                       ← Всё в одном блоке
    ├── planning/
    ├── dev/
    │   ├── auth.py
    │   ├── catalog.py
    │   └── orders.py
    └── deploy/

Growth: Разделение на блоки

build/dev/
├── auth/                       ← Отдельный блок
├── catalog/                    ← Отдельный блок
└── orders/                     ← Отдельный блок

Mature: Организация по доменам

build/dev/
├── core/
│   ├── auth/
│   └── users/
├── marketplace/
│   ├── catalog/
│   ├── orders/
│   └── payments/
└── crm/
    ├── customers/
    └── analytics/

Правило 3: Документация растёт с кодом

Стадия Документация
Inception DISCUSSION.md, vision.md
MVP + README.md, initial requirements
Growth + Architecture, ADR, API docs
Mature + Guides, performance docs
Enterprise + Compliance, team docs, patterns

Правило: Документируй то что есть, не то что будет

Правило 4: Фрактальность опциональна для ops/

MVP-Growth: Простые скрипты

ops/
├── deploy/production.sh        ← Скрипт
├── backup/backup.sh            ← Скрипт
└── monitor/prometheus.yaml     ← Конфиг

Mature-Enterprise: Может быть фрактальной

ops/deploy/production/          ← Фрактальный блок
├── planning/
│   └── deployment-plan.md
├── scripts/
│   ├── deploy.sh
│   └── rollback.sh
├── testing/
│   └── smoke-tests.sh
└── monitoring/
    └── check-health.sh

Критерий: Если деплой требует планирования, тестов и мониторинга → фрактальная структура

ПРИМЕНЕНИЕ К lideravto

Текущая стадия: GROWTH

Что есть:
- 13,347 товаров
- CS-Cart 4.19.1 (приложение)
- 3 блока (import ✅, catalog 🔄, seo ⏳)
- work.lideravto.ru (dev), lideravto.ru (prod)

Что должно быть (по матрице):
- ✅ data/ — есть (BAZON URL)
- ✅ plan/ — частично (roadmap есть, architecture нужна)
- ✅ build/dev/ — есть (3 блока)
- ⚠️ build/app/ — нужна (для cscart/)
- ⏳ build/testing/ — нужна (e2e тесты)
- ⏳ build/ci-cd/ — опционально
- ✅ ops/deploy/ — есть (staging + production)
- ⏳ ops/monitor/ — нужна (базовый мониторинг)
- ✅ ops/backup/ — есть

Что добавить:
1. build/app/ — переместить cscart/ сюда
2. build/testing/ — создать e2e тесты
3. plan/architecture/ — создать system.md + decisions/
4. ops/monitor/ — базовый мониторинг (uptime, errors)

Следующая стадия: Переход к MATURE через 3-6 месяцев

ВЫВОДЫ

1. Структура эволюционирует

❌ НЕ создавать всё сразу
✅ Добавлять по мере роста

2. Фрактальность только для dev/

build/dev/ — всегда фрактальная (блоки)
ops/ — фрактальная только для сложных проектов

3. Каждая стадия имеет критерии

Готов к следующей стадии когда:
- Критерии текущей стадии выполнены
- Появилась необходимость в новых элементах
- Команда/процессы готовы

СЛЕДУЮЩИЙ ШАГ:
1. Утвердить матрицу эволюции
2. Применить к lideravto (добавить недостающие элементы Growth)
3. Создать CACHE.yaml для существующих блоков