architect/standards/arch-project-structure.md

type: standard
layer: arch
object: project
aspect: structure
form: text
title: "Структура проекта платформы"
status: active
version: 1.0.0
date: 2026-04-11
knowledge_level: У1
parent: arch-filesystem-structure.md

Структура проекта платформы

Стандарт описывает что такое проект в платформе, типологию, структуру папки, жизненный цикл, inbox, процедуру создания и наборы документов по типу.

1. ЧТО ТАКОЕ ПРОЕКТ

Проект — автономная единица работы. Тип проекта кодируется в имени папки: @{тип}-{имя}/.

Четыре категории на верхнем уровне:

project/
  org/    ← коммерческие клиенты
  my/     ← личные проекты
  pub/    ← общественные / некоммерческие
  sys/    ← системные проекты платформы

10 типов проектов (префикс @{тип}):

Тип Назначение
@org Организация / холдинг — верхний уровень компании
@domain Предметная область — объединяет бизнес и IT по теме
@biz Бизнес-направление, продукт
@it IT-система, сайт, приложение
@ops Операции, логистика
@hr HR, найм, команда
@fin Финансы, бюджет
@mkt Маркетинг, реклама
@rd R&D, исследование
@phys Физический объект

Иерархия через вложенность:

org/
  @org-lideravto/              ← компания
    @domain-zapchasti/         ← домен "запчасти"
      @biz-zapchasti/          ← бизнес-документы
      @it-lideravto/           ← IT-документы + общие данные
        @it-lideravto-new/     ← Drupal 11 (стек)
        @it-lideravto-cs/      ← CS-Cart (стек, архив)

sys/
  platform-update/             ← системные: без @ (нет типа клиента)

Когда использовать @domain:

Когда одна предметная область имеет одновременно:
- бизнес-документы (@biz) — стратегия, рынок, требования
- IT-документы с общими данными (@it) — модель данных, каталог
- несколько IT-систем на разных стеках

@domain-{имя}/
  @biz-{имя}/          ← что продаём, зачем, кому
  @it-{имя}/           ← как устроено технически (общее)
    data/              ← общие данные (CSV, справочники)
    design/            ← общая IT-архитектура
    @it-{имя}-{стек}/         ← реализация на стеке (текущая)
    @it-{имя}-{стек}-v2/      ← следующая версия того же стека

Именование IT-проектов внутри IT-домена:

Формула: @it-{проект}-{стек} или @it-{проект}-{стек}-v{N}

Пример Значение
@it-lideravto-drupal сайт lideravto на Drupal (текущая версия)
@it-lideravto-drupal-v2 следующая версия на Drupal
@it-lideravto-cscart старый сайт на CS-Cart
@it-pirotehnika-drupal сайт pirotehnika на Drupal

Правило версий: версия добавляется только при параллельном существовании двух реализаций на одном стеке. Если стек один — версия не нужна.

Системные проекты (sys/) отличаются результатом: их артефакты после завершения переходят в arch/ или system/ — пополняют платформу.

2. СТРУКТУРА ПАПКИ

@{тип}-{имя}/
├── AI.md              ← контекст проекта для AI
├── CLAUDE.md          ← AI.md + Claude-специфичное
├── README.md          ← AI.md + объяснения для людей
├── INDEX.md           ← оглавление проекта
│
├── inbox/             ← сырые материалы от оператора
│
├── management/        ← управление (обязательно)
│   ├── STATUS.md
│   ├── LOG.md
│   └── TODO.md
│
├── design/            ← проектирование
│   ├── BRIEF.md
│   ├── CONCEPT.md
│   └── REQUIREMENTS.md
│
├── research/          ← исследования (по необходимости)
├── analysis/          ← аналитика (по необходимости)
├── practice/          ← накопленный опыт (по необходимости)
│
└── {домен}/           ← рабочие папки (@it, @biz, data...)

Обязательный минимум:

AI.md + CLAUDE.md + README.md
management/STATUS.md
management/LOG.md

Правило папки:

1 файл  → файл в корне проекта      research.md
2+ файла → создать папку            research/
                                      competitors.md
                                      market-2026.md

Применяется ко всем рабочим документам: research, analysis, practice и другим.

Папки создаются по необходимости, не заранее. Только management/ обязательна с первого дня.

3. ЖИЗНЕННЫЙ ЦИКЛ

init → active → completed → archived
Статус Что означает
init Создан, настраивается
active В работе
on-hold Приостановлен временно
completed Цель достигнута
cancelled Отменён
archived Перенесён в архив

Фиксируется в management/STATUS.md.

Архивация:

project/sys/platform-update/                      ← активный
project/sys/archive/2026-04/platform-update/      ← архив

Системный проект завершается особо:

completed → артефакты → arch/ или system/library/ → archived

4. INBOX

@{тип}-{имя}/
  inbox/           ← сырые материалы от оператора
    запись.md
    скрин.png
    старый_бриф.docx

Что делает платформа с inbox:
- Читает всё что там лежит
- Извлекает данные → заполняет design/BRIEF.md, design/REQUIREMENTS.md, design/CONCEPT.md
- Если данных достаточно — создаёт недостающие документы
- Что не удалось разложить → оставляет с пометкой "требует внимания"

Правило: inbox/ очищается после обработки — материалы либо разложены, либо архивированы в archive/inbox/.

5. СОЗДАНИЕ ПРОЕКТА (BOOTSTRAP)

Шаг 1. Определить тип и имя
  → выбрать @{тип} из 9 вариантов
  → slug: латиница, дефисы, lowercase

Шаг 2. Скопировать шаблон
  cp -r architect/templates/@{тип}/ project/{категория}/@{тип}-{имя}/

Шаг 3. Заполнить плейсхолдеры
  {ИМЯ}        → полное название
  {имя}        → slug
  {тип}        → тип из таблицы §1
  {YYYY-MM-DD} → дата создания

Шаг 4. Обработать inbox (если есть материалы)
  → положить сырые материалы в inbox/
  → AI читает и заполняет BRIEF, REQUIREMENTS, CONCEPT

Шаг 5. Проверить минимум
  ✅ AI.md + CLAUDE.md + README.md заполнены
  ✅ management/STATUS.md: статус = init
  ✅ management/LOG.md: первая запись с датой

Шаг 6. Добавить в INDEX.md родителя

6. ДОКУМЕНТЫ ПО ТИПУ ПРОЕКТА

Каждый тип имеет свой набор документов в design/ и порядок создания:

Тип Порядок создания документов
@biz BRIEF → CONCEPT → REQUIREMENTS
@it BRIEF → DESIGN → REQUIREMENTS → README → LAUNCH
@ops BRIEF → REQUIREMENTS → GUIDE → PROCESSES
@hr BRIEF → REQUIREMENTS → GUIDE
@fin BRIEF → REQUIREMENTS → GUIDE
@mkt BRIEF → CONCEPT → REQUIREMENTS → ANALYTICS
@rd BRIEF → REQUIREMENTS → DESIGN → GUIDE
@phys BRIEF → REQUIREMENTS → GUIDE → LAUNCH
@org STRUCTURE → PROCESSES → GLOSSARY

Принцип: BRIEF всегда первый — без понимания задачи нет смысла в остальных.

IT-проекты — стековые документы поверх @it:

Стек Дополнительные документы
Drupal INSTALL.md, modules/
Python / FastAPI API.md, DEPLOY.md
CS-Cart CATALOG.md, IMPORT.md

Рабочие документы (создаются по мере накопления):

Папка / файл Когда создавать
research нужно изучить внешнее (конкурент, API, рынок)
analysis накопились данные → нужны выводы
practice есть повторяющийся опыт, который стоит зафиксировать

СВЯЗАННЫЕ ДОКУМЕНТЫ

Родитель:
- arch-filesystem-structure.md — файловая система платформы

Прямые потомки (child):
- arch-project-lifecycle.md — жизненный цикл проекта (15 фаз)

Связанные:
- arch-document-system.md — типы и уровни документов
- arch-rebuild-operation.md — операция ПЕРЕСБОРКА