Жизненный цикл проекта — процессы

1. Тип проекта → PROJECT_TYPOLOGY.md §3
2. Место в иерархии → где родитель?
3. Имя папки: @{тип}-{имя}/

# Шаблоны: architect/templates/@{тип}/
cp -r architect/templates/@biz/ projects/org/@biz-{имя}/

@{тип}-{имя}/
├── INDEX.md        ← навигация: что где лежит
├── AI.md           ← контекст для любого AI
├── CLAUDE.md       ← инструкции для Claude
├── STATUS.md       ← стадия: IDEA, что делаем, следующий шаг
├── LOG.md          ← первая запись: инициализация
├── [файлы по типу] ← матрица в PROJECT_DOCUMENTS.md §4
└── arh/

type: biz          # тип из TYPOLOGY
name: ...
description: ...   # 1-2 абзаца: что это, зачем
status: IDEA
key_files:
  - INDEX.md
  - STATUS.md

1. Изучить тему проекта (бизнес, предметная область, технологии)
2. Предложить пользователю список основных терминов с определениями
3. Обсудить, скорректировать
4. Если терминов >3 → записать в GLOSSARY.md
5. При появлении новых терминов — предлагать добавить

- Добавить ссылку в INDEX.md родительского проекта
- Добавить запись в LOG.md: "YYYY-MM-DD — Создан проект @{name}"

Разведка (L0): читаем все .md, строим карту
    ↓
Карта документов → показываем оператору
    ↓
Утверждение списка ← ОПЕРАТОР
    ↓
По каждому документу:
  Читаем существующие → предлагаем объединение → ОПЕРАТОР ✓ → записываем
    ↓
Всё остальное → arh/ ← ОПЕРАТОР ✓
    ↓
Битые ссылки → fix
    ↓
git commit -m "chore({project}): sanation — docs list, merge, arh/"

ZERO         VANILLA           WORKING          PRODUCTION
─────────    ──────────────    ─────────────    ─────────────
Установлено  Голый дистрибутив Версии с кодом  Релиз в проде
НЕ работает  v0.0.0            v0.1.0+          v1.0.0+
БД нет       БД есть           Custom модули    Стабильно

НИЧЕГО → Zero → Vanilla (v0.0.0) → Working (v0.1.0+) → Production (v1.0.0+)

Получение → Анализ → Развёртывание → Онбординг (v1.0.0) → Working (v1.1.0+)

# Диск
df -h                   # минимум 10GB свободно

# PHP
php -v                  # 8.1+ (рекомендуется 8.4)

# БД
mysql --version         # MySQL 8.0+ или MariaDB 10.6+

# Веб-сервер
nginx -v                # nginx 1.20+

# Composer
composer --version      # 2.x

cd ~/
composer create-project drupal/recommended-project new.site.ru
cd new.site.ru

git init
git add .
git commit -m "Zero: Drupal 11.3.3 deployed"

# Создать БД
mysql -u root -p
CREATE DATABASE site_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site_user'@'localhost' IDENTIFIED BY 'SecurePass123';
GRANT ALL PRIVILEGES ON site_db.* TO 'site_user'@'localhost';
FLUSH PRIVILEGES;

# Установить CMS
php core/scripts/drupal install standard \
  --db-url=mysql://site_user:SecurePass123@localhost/site_db \
  --site-name="New Site" \
  --account-name=admin \
  --account-pass=Admin123!

# Включить ТОЛЬКО модули из коробки
drush en locale -y

# Проверить
curl -I http://new.site.ru/    # HTTP/1.1 200 OK
drush pml --status=enabled --no-core | wc -l  # 1 (только locale)

# Зафиксировать
git tag v0.0.0

# .credentials.md — НЕ в git, добавить в .gitignore
# .project-config.md — в git (параметры без паролей)
echo ".credentials.md" >> .gitignore

cd ~/
tar -czf "vanilla-$(date +%Y%m%d-%H%M%S).tar.gz" new.site.ru/
mysqldump -u site_user -pSecurePass123 site_db | \
  gzip > "vanilla-db-$(date +%Y%m%d-%H%M%S).sql.gz"

v0.0.0 = Vanilla (голый дистрибутив) — контрольная точка
v0.1.0 = Первая фича
v0.x.x = Разработка (не в проде)
v1.0.0 = Релиз в production
v1.0.1 = Баг-фикс (PATCH)
v1.1.0 = Новая фича (MINOR)
v2.0.0 = Breaking change (MAJOR)

DEV        → разработка
STAGING    → точная копия prod, финальные тесты
PRODUCTION → боевой

DEV        → разработка + ВСЕ тесты
PRODUCTION → релиз + мониторинг

Миграция:
site.ru (LEGACY)    → archive.site.ru
new.site.ru (NEXT)  → site.ru

1. DEV: код → тесты → git commit → push develop
2. STAGING: merge develop → deploy → тесты stage.site.ru
3. PRODUCTION: merge staging → deploy → мониторинг

1. DEV: код → ВСЕ тесты → git commit → push main
2. PRODUCTION: deploy → мониторинг → hotfix при необходимости

1. СДЕЛАТЬ одно изменение
2. ПРОВЕРИТЬ что работает
3. ЗАПИСАТЬ в DEVLOG.md
4. GIT COMMIT
5. Следующее изменение

1. READ — прочитать текущее состояние
2. BACKUP — сохранить копию
3. MODIFY — изменить конкретное место
4. VERIFY — проверить результат
5. COMMIT или ROLLBACK

[YYYY-MM-DD HH:MM] ДЕЙСТВИЕ: описание
  Параметр: значение
  ✓ Результат
  → Статус

git commit -m "Feature: описание"
git tag v0.x.x

# L1: Модули
tar -czf "arh/modules-$(date +%Y%m%d-%H%M%S).tar.gz" modules/

# L2: БД
mysqldump -u user -p db_name | gzip > "arh/sql/db-$(date +%Y%m%d-%H%M%S).sql.gz"

# L3: Vanilla
tar -czf "backups/vanilla/vanilla-$(date +%Y%m%d-%H%M%S).tar.gz" site.ru/
mysqldump -u user -p db_name | gzip > "backups/vanilla/vanilla-db-$(date +%Y%m%d-%H%M%S).sql.gz"

□ Backup создан (L1+L2)
□ Тесты пройдены (на DEV/STAGING)
□ Git tag поставлен
□ DEVLOG заполнен
□ План rollback готов

# Откат файлов
tar -xzf arh/modules/modules-before-deploy-*.tar.gz -C modules/

# Откат БД
gunzip -c arh/sql/db-before-deploy-*.sql.gz | mysql -u user -ppass db_name

# Проверка
curl -I http://site.ru/

ФАЗА 1: СОЗДАНИЕ СТРУКТУРЫ     ← один раз
ФАЗА 2: РАЗРАБОТКА (dev/)      ← активная работа
ФАЗА 3: ТЕСТИРОВАНИЕ (test/)   ← проверка
ФАЗА 4: PRODUCTION (prod/)     ← релиз
ФАЗА 5: ЭКСПЛУАТАЦИЯ           ← использование
ФАЗА 6: ОБНОВЛЕНИЕ             ← новая версия (цикл)
ФАЗА 7: АРХИВИРОВАНИЕ          ← вывод из эксплуатации

# Обновить версию: X.Y.Z-dev -> X.Y.Z-rc1
cp -r modules/dev/my_module/ modules/test/my_module-vX.Y.Z-rc1/

# Обновить версию: X.Y.Z-rc1 -> X.Y.Z
bash /opt/scripts/backup.sh    # ОБЯЗАТЕЛЬНО
cp -r modules/test/my_module-vX.Y.Z-rc1/ modules/prod/my_module-vX.Y.Z/

# Исправить в dev/
vim modules/dev/my_module/func.php
# Обновить версию: X.Y.Z -> X.Y.Z+1

# Можно пропустить test/ если критично
cp -r modules/dev/my_module/ modules/prod/my_module-vX.Y.Z+1/

1. ЗАДАЧА — оператор формулирует
2. АНАЛИЗ — кодер читает существующий код, планирует
3. РЕАЛИЗАЦИЯ — код по стандартам, минимальные изменения
4. ПРОВЕРКА — тесты, ручная проверка, демонстрация
5. ФИКСАЦИЯ — git add, git commit, обновление документации

feat: новая функциональность
fix: исправление ошибки
refactor: рефакторинг
docs: документация

ФАЗА 0: INTAKE      — сбор входных данных (2-4 ч)
ФАЗА 1: ПОЧЕМУ      — проблема (4-8 ч)
ФАЗА 2: ЗАЧЕМ       — видение (4-6 ч)
ФАЗА 3: ЧТО         — решение (6-10 ч)
ФАЗА 4: КТО         — команда (2-4 ч)
ФАЗА 5: КАК         — архитектура (8-16 ч)
ФАЗА 6-8: ЧЕМ/ГДЕ/КОГДА — параллельно (8-12 ч)
ФАЗА 9: СКОЛЬКО      — ресурсы (4-6 ч)
ФАЗА 10: СТАРТ       — разработка

git tag rehab-YYYY-MM-start

git commit -m "rehab: create missing files"

git mv old/path.md new/path.md

# Обновить все ссылки во всём репозитории
find /opt/claude-workspace -name "*.md" -exec sed -i 's|old/path|new/path|g' {} +

# Проверить: ноль вхождений старого пути
grep -rn 'old/path' --include="*.md" | wc -l  # должно быть 0

git commit -m "rehab: migrate [описание]"

✅ Ноль ссылок на старые пути
✅ Все файлы из PLAN.md имеют статус ✅
✅ Каждая папка-аспект имеет README.md
✅ git log --follow показывает историю для перенесённых файлов

git tag rehab-YYYY-MM-end
mv tmp/PLAN.md architect/arh/rehab-YYYY-MM-plan.md

#!/bin/bash
PATTERN=${1:-"ваш паттерн"}
grep -rn "$PATTERN" /opt/claude-workspace --include="*.md" | grep -v "^Binary" | sort

#!/bin/bash
ERRORS=0
while IFS= read -r file; do
  while IFS= read -r link; do
    target=$(dirname "$file")/$link
    if [ ! -f "$target" ]; then
      echo "BROKEN: $file -> $link"
      ERRORS=$((ERRORS + 1))
    fi
  done < <(grep -oP '\[.*?\]\(\K[^)]+(?=\))' "$file" | grep -v '^http' | grep '\.md')
done < <(find /opt/claude-workspace/architect -name "*.md" | grep -v arh/ | grep -v tmp/)
echo "Total broken links: $ERRORS"

ПРОЕКТОР (агент) → использует → ПРОЕКТ-ПРОЦЕССОР (движок)

PROCESS(task, context):
  [0]   CONTEXT_CHECK(task)           → path, risk_level
  [0.5] MATCHER(task)                 → template | null
  if ATOMIC(task):
    [2]   SYNTHESIZE(task, context)   → CODE-PROMPT.md
    [3]   EXECUTE(CODE-PROMPT)        → result
    return result

  [1]   DECOMPOSE(task)               → subtasks[]
  [1.5] CLARIFY(subtasks)             → verified_subtasks[]

  for each subtask:
    if ATOMIC: SYNTHESIZE + EXECUTE
    else: PROCESS(subtask, INHERIT(context, subtask))   ← РЕКУРСИЯ

  INTEGRATE(results[]) → deploy/
  PASS_3(deploy/, risk_level)
  PASS_4(deploy/)
  return deploy/

[0]   CONTEXT_CHECK     — проверить размер и сложность
[0.5] MATCHER           — найти шаблон (БЫСТРЫЙ / МЕДЛЕННЫЙ ПУТЬ)
[1]   ДЕКОМПОЗИТОР      — разбить на дерево атомов
[1.5] УТОЧНЕНИЕ         — верификация полноты параметров
[2]   СИНТЕЗАТОР        — собрать контекст для каждого атома
[3]   ЭКЗЕКУТОР         — исполнить атомы
      INTEGRATE         — собрать результаты
      PASS 3            — полное тестирование
      PASS 4            — финализация (HARDEN)

Точное совпадение (100%)    → БЫСТРЫЙ ПУТЬ: шаблон → ЭКЗЕКУТОР
Частичное (>=70%)           → БЫСТРЫЙ + дополнить
Нет совпадения (<70%)       → МЕДЛЕННЫЙ ПУТЬ: полный цикл + сохранить шаблон

depth > 7  → WARN: проверить декомпозицию
depth > 12 → STOP: пересмотреть задачу, ESCALATE оператору