type: standard
layer: arch
object: project
aspect: lifecycle
form: text
title: "Жизненный цикл проекта"
status: active
version: 1.0.0
date: 2026-04-11
knowledge_level: У1
parent: arch-project-structure.md
deps:
- arch-project-structure.md
- arch-document-system.md
Стандарт описывает универсальный жизненный цикл проекта на платформе: 5 этапов, 15 фаз, ворота между ними, документы по фазам, статусы и специализация по типам проектов.
Жизненный цикл проекта — последовательность этапов от первого импульса до эксплуатации и улучшения.
5 этапов:
ИНИЦИАЦИЯ → ИССЛЕДОВАНИЕ → ПРОЕКТИРОВАНИЕ → ИСПОЛНЕНИЕ → ЭКСПЛУАТАЦИЯ
| Этап | Вопрос | Фазы |
|---|---|---|
| Инициация | Что хотим и зачем? | 0→1 |
| Исследование | Что есть и что нужно? | 2→4 |
| Проектирование | Как будем делать? | 5→6 |
| Исполнение | Делаем и проверяем | 7→12 |
| Эксплуатация | Работает и улучшается | 13→14 |
Принцип: каждый этап завершается воротом (gate) — точкой проверки перед переходом к следующему.
| Фаза | Название | Кто | Что происходит | Выход |
|---|---|---|---|---|
| 0 | ТРИГГЕР | Опер. | Записать первичный импульс | Записанный запрос |
| 0.5 | INTAKE | Опер. | Кто клиент? Что хотят? Ограничения? Передать материалы | MASTER_BRIEF.md |
| 0.7 | AI-РАЗБОР | AI | Анализ всех предоставленных данных. Автозаполнение документов. Предложение списка исследований. → arch-intake-operation.md | Pre-filled docs |
| 1 | ПОНИМАНИЕ | Опер. | Проверить заполненные документы, дополнить, согласовать | BRIEF.md |
Ворота 1→2: Понимаем что хотят?
Фаза 0.7 — операция РАЗБОР. Запускается автоматически при передаче материалов. Может быть вызвана повторно в любой фазе проекта при поступлении новых данных.
| Фаза | Название | Что происходит | Выход |
|---|---|---|---|
| 2 | ИССЛЕДОВАНИЕ | Изучить область, аналоги, данные, ограничения | RESEARCH.md |
| 3 | АНАЛИЗ | Систематизировать, выявить паттерны и риски | ANALYSIS.md |
| 4 | ТРЕБОВАНИЯ | Определить границы, приоритизировать, согласовать | REQUIREMENTS.md |
Ворота 4→5: Требования согласованы?
| Фаза | Название | Что происходит | Выход |
|---|---|---|---|
| 5 | ПРОЕКТИРОВАНИЕ | Варианты → выбор → детализация → декомпозиция | DESIGN.md |
| 6 | ВАЛИДАЦИЯ | Соответствует требованиям? Реализуемо? Утверждено? | VALIDATION.md |
Ворота 6→7: Проект утверждён?
| Фаза | Название | Что происходит | Выход |
|---|---|---|---|
| 7 | ПЛАНИРОВАНИЕ | Задачи, зависимости, ресурсы, контрольные точки | TODO.md |
| 8 | ПОДГОТОВКА | Среда, команда, инструменты | Готовность |
| 9 | РЕАЛИЗАЦИЯ | Выполнение задач, контроль качества, документирование | Артефакт |
| 10 | ТЕСТИРОВАНИЕ | Проверка, граничные случаи, нагрузка, дефекты, исправление | Проверенный артефакт |
| 11 | ВНЕДРЕНИЕ | Среда, откат, деплой, обучение, документация | Работающее решение |
| 12 | ПРИЁМКА | Приёмочные тесты, обратная связь, акт приёмки | ACCEPTANCE.md |
Ворота 12→13: Принято?
| Фаза | Название | Что происходит | Выход |
|---|---|---|---|
| 13 | ЭКСПЛУАТАЦИЯ | Мониторинг, поддержка, сбор обратной связи | METRICS.md |
| 14 | УЛУЧШЕНИЕ | Анализ метрик, идеи, приоритизация → новый цикл | → Фаза 1 |
| Документ | Фаза создания | Фазы обновления | Обязательность |
|---|---|---|---|
| MASTER_BRIEF.md | 0.5 INTAKE | 1 | ✅ обязателен |
| BRIEF.md | 1 Понимание | — | ✅ обязателен |
| RESEARCH.md | 2 Исследование | — | ⭐ рекомендован |
| ANALYSIS.md | 3 Анализ | — | ⭐ рекомендован |
| REQUIREMENTS.md | 4 Требования | 10, 12 | ✅ обязателен |
| DESIGN.md | 5 Проектирование | 9 | ✅ обязателен |
| VALIDATION.md | 6 Валидация | — | по необходимости |
| TODO.md | 7 Планирование | 9, 10 | ✅ обязателен |
| STATUS.md | 7 Планирование | 8–14 | ✅ обязателен |
| RISKS.md | 3 Анализ | 6, 9, 10 | ⭐ рекомендован |
| DECISIONS.md | 5 Проектирование | все | ⭐ рекомендован |
| TEST_PLAN.md | 10 Тестирование | — | по необходимости |
| DEPLOY.md | 11 Внедрение | — | по необходимости |
| ROLLBACK.md | 11 Внедрение | — | по необходимости |
| ACCEPTANCE.md | 12 Приёмка | — | по необходимости |
| METRICS.md | 13 Эксплуатация | 13, 14 | по необходимости |
| CHANGELOG.md | 9 Реализация | 9–14 | по необходимости |
Каждый документ объявляет parent: и deps: в frontmatter и регистрирует себя в индексе родителя.
Подробно: arch-document-linking.md
Статус фиксируется в STATUS.md и index.yaml проекта.
| Статус | Фаза | Описание |
|---|---|---|
draft |
0–1 | Сбор информации |
research |
2–3 | Исследование и анализ |
requirements |
4 | Согласование требований |
design |
5–6 | Проектирование |
approved |
6→7 | Проект утверждён, готов к планированию |
planning |
7 | Планирование |
in_progress |
8–9 | В работе |
testing |
10 | Тестирование |
deploying |
11 | Внедрение |
review |
12 | Приёмка |
production |
13 | В эксплуатации |
improving |
14 | Улучшение |
on_hold |
любая | Приостановлен |
cancelled |
любая | Отменён |
completed |
14 | Завершён |
Статус меняется только при прохождении ворот (gate).
При смене статуса → запись в CHANGELOG.md.
Базовый жизненный цикл универсален. Каждый тип наследует его и расширяет под свою специфику.
| Тип | Префикс | Расширения |
|---|---|---|
| IT-проект | @it | ARCHITECTURE.md, DATA_MODEL.md, API.md, код, тесты, CI/CD |
| Бизнес | @biz | бизнес-план, P&L, юридические документы |
| Исследование | @rd | methodology/, data/, reports/ |
| Операции | @ops | runbook, SLA, incident log |
| Маркетинг | @mkt | brief, creatives/, campaigns/ |
| Личное | @my | свободная структура |
Специализация описывается в отдельном стандарте типа:
arch-project-{тип}-structure.md
IT-проект — двумерная модель:
IT-проект специализируется по двум измерениям:
Измерение 1: ТИП СИСТЕМЫ (что делает) — cms / api / bot / etl / dashboard
Измерение 2: СТЕК (на чём построено) — drupal / fastapi / nextjs / python
Цепочка наследования:
arch-project-lifecycle.md ← базовый ЖЦ (этот документ)
→ arch-project-it-structure.md ← IT специфика
→ projector/templates/@it/stacks/{стек}/ ← шаблоны стека
→ coder/library/{стек}/ ← код стека
Стандарт описания стека: arch-stack-bootstrap.md
Тип может:
- добавить под-фазы (9.1 → 9.1.1 компонент А, 9.1.2 компонент Б)
- добавить документы в список обязательных
- сделать опциональные фазы обязательными
Выполнять строго по порядку:
Шаг 1: Определить тип и место (типология, родитель, имя @{тип}-{имя}/)
Шаг 2: Скопировать шаблон из projector/templates/@{тип}/
Шаг 3: Создать структуру (INDEX.md, AI.md, CLAUDE.md, STATUS.md, LOG.md)
Шаг 4: Заполнить frontmatter AI.md (type, name, description, status: IDEA)
Шаг 5: Глоссарий — изучить тему, предложить термины, если >3 → GLOSSARY.md
Шаг 6: Обновить родителя (INDEX.md родителя + запись в LOG.md)
Санация = применение bootstrap-чеклиста к существующему проекту.
Цель: собрать ценное, лишнее → arh/, восстановить навигацию.
Разведка (L0): читаем все .md, строим карту
↓
Карта документов → показываем оператору
↓
Утверждение списка ← ОПЕРАТОР
↓
По каждому документу:
Читаем → предлагаем объединение → ОПЕРАТОР ✓ → записываем
↓
Всё остальное → arh/ ← ОПЕРАТОР ✓
↓
Битые ссылки → fix → git commit
| Bootstrap | Санация | |
|---|---|---|
| Откуда | С нуля | Существующий проект |
| Контент | Пишем новый | Берём лучшее из существующего |
| Участие оператора | Шаг глоссария | Каждый документ |
| Результат | Чистый проект | Оздоровлённый с историей в arh/ |
ZERO VANILLA WORKING PRODUCTION
───────── ────────────── ───────────── ─────────────
Установлено Голый дистрибутив Версии с кодом Релиз в проде
НЕ работает v0.0.0 v0.1.0+ v1.0.0+
БД нет БД есть Custom модули Стабильно
PATH A — Создание с нуля:
НИЧЕГО → Zero → Vanilla (v0.0.0) → Working (v0.1.0+) → Production (v1.0.0+)
PATH B — Онбординг существующего:
Получение → Анализ → Развёртывание → Онбординг (v1.0.0) → Working (v1.1.0+)
PATH A даёт Vanilla (чистый дистрибутив), PATH B — Working (уже с кодом).
Каждое действие в ходе разработки записывается в DEVLOG.md.
Формат записи:
[YYYY-MM-DD HH:MM] ДЕЙСТВИЕ: описание
Параметр: значение
✓ Результат
→ Статус
Типы действий:
INFRA CHECK ZERO VANILLA SETUP MODULE BACKUP FEATURE FIX DEPLOY ROLLBACK
Правило git: проверил что работает → commit. НЕ раньше.
Один commit = одно логическое изменение.
git commit -m "feat(scope): описание"
git tag v0.x.x # после каждого значимого состояния
Фрактальная архитектура — рекурсивная структура проекта, где каждый уровень является микро-проектом с одинаковой структурой.
ПРОЕКТ = МОДУЛЬ = БЛОК = ПОКОЛЕНИЕ
Одна и та же структура на всех уровнях:
CLAUDE.md + CACHE.yaml + planning/ + dev/ + testing/ + deploy/
Рекурсия:
ПРОЕКТ
dev/
МОДУЛЬ (микро-проект)
dev/
БЛОК (микро2-проект)
dev/
ПОКОЛЕНИЕ (микро3-проект)
Каждый уровень: самодостаточен, тестируем, деплоим, декомпозируем.
Два критерия декомпозиции:
| Критерий | Принцип |
|---|---|
| По смыслу | Каждый уровень — логически завершённая единица с чётким интерфейсом (inputs/outputs) |
| По размеру | Уровень декомпозируется глубже, пока не влезает в контекст Claude (~300 строк кода) |
Критерий остановки: уровень влезает в контекст Claude (~300 строк кода).
микро-проект/
├── CLAUDE.md -- описание, метаданные, интерфейс
├── CACHE.yaml -- входные данные, зависимости
│
├── planning/ -- планирование
│ ├── requirements.md -- требования
│ ├── blocks.md -- декомпозиция на под-блоки
│ └── criteria.md -- критерии готовности
│
├── dev/ -- разработка
│ ├── [под-блоки] -- рекурсия (микро-проекты)
│ └── [код] -- или финальный код (атом)
│
├── testing/ -- тесты
│ ├── unit/
│ ├── integration/
│ └── criteria.md -- результаты тестов
│
└── deploy/ -- результат (финальная сборка)
├── dist/ -- собранный продукт
└── README.md -- как использовать
1. ПРОЕКТ → определить стадии, для dev/ — определить модули
2. МОДУЛЬ → CLAUDE.md, CACHE.yaml, planning/
3. БЛОК → декомпозировать на ПОКОЛЕНИЯ
4. ПОКОЛЕНИЕ (АТОМ) → planning/ + dev/ (код, влезает в контекст)
# CLAUDE.md — интерфейс уровня
block:
name: "..."
type: CODE|DOCS|OPS
inputs: [...] # что требует
outputs: [...] # что производит
# CACHE.yaml — входные данные
dependencies: [...]
inputs: {...}
resolved: {...}
НАЧАТЬ С САМОГО ГЛУБОКОГО УРОВНЯ (атом):
Уровень N (атомарный):
1. Загрузить контекст CLAUDE.md
2. dev/ — реализовать код
3. testing/ — написать и запустить тесты
4. FAILED → вернуться к dev/
5. PASSED → deploy/ собрать результат
Уровень N-1 (использует результаты N):
1. CACHE.yaml → resolved += deploy/ уровня N
2. dev/ — интегрировать под-блоки
3. testing/ — тесты интеграции
4. PASSED → deploy/ собрать результат
Продолжать до КОРНЯ (проект).
Ключевой принцип: Уровень N не знает внутреннее устройство уровня N+1, только использует его deploy/.
ДЛЯ КАЖДОГО УРОВНЯ (снизу вверх):
1. СБОРКА deploy/ — собрать результаты под-уровней
2. ТЕСТИРОВАНИЕ — unit/ + integration/ + criteria.md
3. ВАЛИДАЦИЯ — все тесты PASSED? критерии выполнены?
4. ФИКСАЦИЯ — обновить CLAUDE.md (status: completed)
5. ПОДЪЁМ НА УРОВЕНЬ ВЫШЕ
БИЗНЕС планирует ЧТО → IT реализует КАК
Граница: REQUIREMENTS.md (требования от бизнеса к IT).
BIZ не лезет в код. IT не принимает решений по ассортименту и каналам.
BIZ пишет REQUIREMENTS.md
| ГРАНИЦА 1: BIZ → IT
IT получает требования → пишет DESIGN.md
| ГРАНИЦА 2: IT → Кодер
Кодер получает DESIGN.md + GUIDE.md → пишет код
BIZ → IT:
1. BIZ заполняет REQUIREMENTS.md (что нужно от IT)
2. IT создаёт подпроект @it-{тип}-{имя}/
3. IT пишет DESIGN.md со ссылкой на BIZ/REQUIREMENTS.md
4. IT декомпозирует на модули → GUIDE.md по каждому
IT → Кодер:
1. IT создаёт specs/ с SPEC.yaml + CODE-PROMPT.md для каждого модуля
2. Кодер читает SPEC + CODE-PROMPT → реализует код
3. Кодер отчитывается по критериям готовности
| Кто | Пишет | Формат |
|---|---|---|
| BIZ | BRIEF.md, CONCEPT.md, REQUIREMENTS.md | Markdown |
| IT | DESIGN.md, GUIDE.md, specs/ | Markdown + YAML |
| Кодер | Код в implementation/ | PHP / JS / Python |
| Кто | Что НЕ делает |
|---|---|
| BIZ | НЕ пишет технические решения (платформа, стек) |
| BIZ | НЕ создаёт specs для кодера |
| IT | НЕ определяет цели канала, ЦА, контент-стратегию |
| Кодер | НЕ решает что реализовывать (получает specs) |
IT/DESIGN.md обязательно ссылается на @biz-.../REQUIREMENTS.mdspecs/CODE-PROMPT.md обязательно ссылается на DESIGN.mdspecs/SPEC.yaml содержит version и dependenciesREQUIREMENTS.md (BIZ → IT):
# REQUIREMENTS
## Функциональные
- [ ] Требование 1
## Контентные
- [ ] Тексты для категорий
## Технические ограничения
- Скорость < 2 сек
- Uptime > 99%
DESIGN.md (IT):
# DESIGN
## Входящие требования
[REQUIREMENTS.md](../@biz-.../REQUIREMENTS.md)
## Платформа
{платформа, версия}
## Модули
| Модуль | Назначение | Зависимости |
|--------|-----------|-------------|
CODE-PROMPT.md (IT → Кодер):
# Модуль: {название}
## Контекст
[ссылки на REQUIREMENTS и DESIGN]
## Задача
{что создать}
## Требования
{детальный список с алгоритмами}
## Структура кода
{файлы и что в каждом}
## Критерии готовности
- [ ] критерий 1
- [ ] тесты
BIZ:
- [ ] BRIEF.md заполнен (зачем, для кого)
- [ ] REQUIREMENTS.md содержит конкретные требования (не общие слова)
- [ ] Метрики указаны (конверсия, скорость, uptime)
IT:
- [ ] DESIGN.md ссылается на BIZ/REQUIREMENTS.md
- [ ] specs/ созданы для каждого модуля
- [ ] SPEC.yaml содержит version, dependencies, features
- [ ] CODE-PROMPT.md содержит структуру кода, тесты, критерии готовности
ЗАПРЕЩЕНО:
- Править ядро (core) системы
- Чинить сломанное на месте
- Накручивать workarounds
ПРАВИЛЬНО:
- Откатиться к предыдущей рабочей версии
- Продолжить с чистого состояния
- Искать где именно поломка
1. ПЕРЕД изменением — backup (контрольная точка)
2. ДЕЛАТЬ изменение — одно за раз
3. ЕСЛИ сломалось — СТОП! Откат
4. НИКОГДА не менять ядро CMS
ОДИН ШАГ = ОДНА ПРОВЕРКА
НЕПРАВИЛЬНО:
1. Установить 5 модулей → 2. Изменить конфиг → 3. Деплой → 4. Проверить всё
ПРАВИЛЬНО:
1. Установить модуль 1 → проверка → git commit
2. Установить модуль 2 → проверка → git commit
3. Изменить конфиг → проверка → git commit
1. READ: cat конфиг > backup.conf
2. MODIFY: vim конфиг (локально)
3. TEST: nginx -t (проверка синтаксиса)
4. WRITE: загрузить на сервер
5. CHECK: nginx -t && service nginx reload
6. VERIFY: curl http://site.ru
Для БД:
1. READ: mysqldump db > backup.sql
2. MODIFY: создать миграцию
3. TEST: проверить на локальной копии БД
4. WRITE: применить миграцию на prod
5. CHECK: проверить результат
6. VERIFY: проверить работу сайта
| Действие | Команда |
|---|---|
| Контрольная точка | tar -czf vanilla-$(date +%Y%m%d).tar.gz project/ |
| Откат к Vanilla | tar -xzf vanilla-YYYYMMDD.tar.gz |
| Создать версию | git tag v0.1.0 && git push --tags |
| Проверка nginx | nginx -t |
| Backup БД | mysqldump db_name > backup-$(date +%Y%m%d).sql |