CI/CD Pipeline

✅  Все тесты прошли (phpunit / pytest / jest)
✅  Code review выполнен (не обязательно внешний — хватает self-review)
✅  Нет конфликтов в базе (миграции применились в dev)
✅  Ресурсы проверены: bash /opt/scripts/check_resources.sh → GREEN

✅  Функциональное тестирование на staging завершено
✅  Оператор явно сказал "работает, деплоим"
✅  Бэкап prod выполнен (С2 BACKUP)
✅  Rollback-план готов (docker tag backup-YYYYMMDD)
✅  Время деплоя: рабочее время или по согласованию

❌  В пятницу вечером (нет поддержки на выходных)
❌  Без бэкапа БД
❌  Без явного "да" оператора
❌  Если staging не прошёл тесты

# 1. проверить ресурсы
bash /opt/scripts/check_resources.sh   # GREEN

# 2. pull + build
git pull origin dev
docker compose build --no-cache app

# 3. тесты
docker compose run --rm app vendor/bin/phpunit

# 4. запуск
docker compose up -d

# 5. проверка
curl -s -o /dev/null -w "%{http_code}" http://localhost:{port}/

# 1. бэкап текущего состояния
docker tag {service}:latest {service}:backup-$(date +%Y%m%d)
pg_dumpall -U postgres | gzip > "$DATASPACE/backups/db/$(date +%Y%m%d_%H%M)_pre-deploy.sql.gz"

# 2. merge main → staging
git checkout staging && git merge main

# 3. деплой
docker compose pull
docker compose up -d --force-recreate

# 4. миграции
docker compose exec app drush updb -y   # для Drupal
# или: alembic upgrade head             # для Python

# 5. тесты
docker compose run --rm app vendor/bin/phpunit

# 6. проверка
curl -s -o /dev/null -w "%{http_code}" https://staging.{домен}/

# 0. СТОП — получить явное "да" оператора

# 1. полный бэкап
pg_dumpall -U postgres | gzip > "$DATASPACE/backups/db/$(date +%Y%m%d_%H%M)_pre-prod.sql.gz"
docker tag {service}:latest {service}:backup-$(date +%Y%m%d)

# 2. техническое обслуживание
# (опционально: nginx 503 на время деплоя)

# 3. деплой (аналогично staging)
...

# 4. smoke-tests
curl -s -o /dev/null -w "%{http_code}" https://{домен}/
curl -s -o /dev/null -w "%{http_code}" https://{домен}/health

# 5. снять обслуживание
# 6. мониторинг 15 минут

1. СТОП обычного потока
2. Создать ветку: git checkout -b hotfix/{описание}
3. Исправить + минимальный тест
4. Оператор: явное "да, деплоим хотфикс, понимаю риск"
5. Бэкап prod (обязательно)
6. Деплой напрямую в prod (L4)
7. Merge обратно в main и dev
8. Документировать инцидент в system/monitor/alerts/

# откат Docker
docker compose down
docker tag {service}:backup-YYYYMMDD {service}:latest
docker compose up -d

# откат базы (если миграции применялись)
# alembic downgrade -1
# drush sqlc < backup.sql (для Drupal)

# проверка
curl -s -o /dev/null -w "%{http_code}" https://{домен}/

ПРОЕКТИРОВАНИЕ → CACHE.yaml → SPEC.yaml → CODE-PROMPT.md → КОДИРОВАНИЕ

project/
├── CACHE.yaml              ← Глобальный кеш (хеши, данные, граф зависимостей)
├── PROJECT.md
├── data/
├── standards/
└── solutions/
    └── website/src/module/
        ├── SPEC.yaml       ← Конфигурация модуля
        ├── CODE-PROMPT.md  ← Готовый промпт для кодера (генерируется)
        ├── prompts/        ← Блоки (если >500 строк)
        └── src/

task: "Импорт товаров из BAZON"
estimate: "3.5 часа"

data:
  source: "@CACHE#extracted.data.bazon_url"
  format: "@CACHE#extracted.data.bazon_format"

constraints:
  platform: "@CACHE#extracted.standards.cs_cart.constraints"
  module:
    - "Не использовать глобальные переменные"

dependencies:
  - "@../catalog/API.md#get_category"

instructions:
  - "Создать lib/normalize.php"
  - "Создать lib/categories.php"

check:
  - "SELECT COUNT(*) FROM cscart_products = 13347"

# Агрегация проекта в CACHE
claude aggregate-project

# Сборка промпта из SPEC + CACHE
claude build-prompt solutions/website/src/import/

# Разбиение большого промпта на блоки
claude split-prompt solutions/website/src/import/

# Проверка актуальности (хеши изменились?)
claude check-cache

# Пересборка устаревших промптов
claude rebuild-stale

# .git/hooks/pre-commit
#!/bin/bash
claude check-cache || claude rebuild-stale

У0 (Идея)      — theory/, concept/     — LOCKED, редко меняется
У1 (Стандарты)  — standards/            — Редко меняется
У2 (Паттерны)   — patterns/             — По мере накопления
У3 (Шаблоны)    — templates/            — Готовые заготовки
У4 (Инстансы)   — {project}/            — Конкретные реализации

1. ТРИГГЕР — новая сущность, существенное изменение, запрос оператора
2. ОПРЕДЕЛИТЬ ТИП — уровень (У0-У4), формат (md/yaml), место
3. СОЗДАТЬ/ОБНОВИТЬ — использовать шаблон, заполнить обязательные поля
4. ПРОВЕРИТЬ — версия указана, ссылки работают, нет дублирования
5. ИНТЕГРИРОВАТЬ — добавить в индекс, обновить ссылки, commit

1. ПОДГОТОВКА    → Проверить синтаксис локально      → СТОП: файлы готовы?
2. ЗАГРУЗКА      → Загрузить файлы на сервер          → СТОП: сайт работает?
3. АКТИВАЦИЯ     → Активировать модуль                → СТОП: сайт работает?
4. ТЕСТ МИНИМАЛЬНЫЙ → Проверить базовую функцию       → СТОП: работает?
5. ТЕСТ ПОЛНЫЙ   → Проверить на реальных данных       → СТОП: работает?
6. ГОТОВО

projects/{project}/site/@{domain}/CHANGELOG.md

## YYYY-MM-DD HH:MM

### Действие
- Что сделано
- Какие файлы затронуты
- Результат (ОК / ОШИБКА)

### Откат (если нужен)
- Команды для отката

/.tickets/
├── open/               ← Открытые
├── in_progress/        ← В работе
├── resolved/           ← Решённые
└── closed/             ← Закрытые

# {ТИП}-{NNN}: Краткое название

**Статус:** OPEN
**Приоритет:** P1 (IMPORTANT)
**Создан:** YYYY-MM-DD
**Автор:** Кто создал
**Область:** Где проблема (путь/модуль)

## ПРОБЛЕМА
Описание проблемы или идеи.

## ТЕКУЩЕЕ СОСТОЯНИЕ
Как сейчас работает.

## ПРЕДЛАГАЕМОЕ РЕШЕНИЕ
Как предлагается решить.

## КРИТЕРИИ ПРИЁМКИ
- [ ] Критерий 1
- [ ] Критерий 2

тикет: bug P0 Сессии не сохраняются при сбое
тикет: idea P3 Добавить голосовой интерфейс

Создать файл в /.tickets/open/ → Заполнить по шаблону → Присвоить ID
↓ (взятие в работу)
Переместить в in_progress/ → Обновить статус → Добавить дату начала
↓ (завершение)
Переместить в resolved/ → Заполнить результат
↓ (после проверки)
Переместить в closed/

WORKSPACE (git):
projects/org/{project}/deploy/
├── README.md              ← что за сервер, как подключаться
├── _backups/              ← бэкапы файлов ДО изменения
│   └── 2026-03-14_module.php
└── {путь от корня сайта}/ ← зеркало файлов сервера

DATASPACE (S3):
projects/{project}/backups/
└── 2026-03-14_db.sql      ← дампы БД

1. ЗЕРКАЛО — скопировать с сервера в deploy/
   scp user@server:/path/to/file projects/org/{proj}/deploy/path/to/file

2. БЭКАП — сохранить копию
   cp deploy/path/file deploy/_backups/YYYY-MM-DD_file

3. ИЗМЕНИТЬ — правим файл в зеркале (в workspace)

4. ДЕПЛОЙ — отправить на сервер
   scp deploy/path/file user@server:/path/to/file

5. КОММИТ
   git add deploy/ && git commit -m "deploy({project}): что изменили"

1. ДАМП — на сервере
   mysqldump -u user -p db_name > /tmp/YYYY-MM-DD_db.sql

2. СКАЧАТЬ в dataspace
   scp user@server:/tmp/YYYY-MM-DD_db.sql $DATASPACE/projects/{proj}/backups/

3. МИГРАЦИЯ — выполнить SQL на сервере

4. ПРОВЕРИТЬ — убедиться что всё работает

~/work.lideravto.ru/
├── .scripts/                      ← Скрытая папка (НЕТ веб-доступа)
│   ├── golden_cscart_419.tar.gz   ← Золотой бэкап файлов
│   ├── golden_database.sql.gz     ← Золотой бэкап БД
│   ├── restore_golden.sh          ← Быстрое восстановление (1-2 мин)
│   ├── create_golden.sh           ← Создание золотого бэкапа
│   ├── check_installation.php
│   └── clean_database.php
├── admin.php
└── index.php

# 1. Создать скрытую папку на хостинге
ssh user@host
mkdir -p ~/work.lideravto.ru/.scripts
chmod 700 ~/work.lideravto.ru/.scripts

# 2. Загрузить скрипты
scp check_installation.php user@host:~/work.lideravto.ru/.scripts/

# 3. Заменить credentials (PLACEHOLDER → реальные из .credentials.md)

# 4. Установить права
chmod 700 ~/work.lideravto.ru/.scripts/*.php

# 5. Проверить безопасность
curl http://domain.ru/.scripts/check_installation.php
# Ожидаем: 403 Forbidden или 404 Not Found

// WORKSPACE (в git): placeholder
$DB_PASS = getenv('DB_PASS') ?: 'CHANGE_ME';

// ХОСТИНГ (не в git): реальные значения допустимы
$DB_PASS = '8jR*Y!eB0r%G';

# Создание (один раз после чистой установки)
./.scripts/create_golden.sh

# Восстановление (для экспериментов)
./.scripts/restore_golden.sh

bash <(curl -s http://91.218.142.168/files/ИМЯ_СКРИПТА.sh)

#!/bin/bash
# REMOTE SCRIPT STANDARD v1.0
# Запуск: bash <(curl -s http://91.218.142.168/files/ИМЯ.sh)
# Результат: http://91.218.142.168/files/ИМЯ.log

SERVER="http://share.0kt.ru"
LOGNAME="ИМЯ.log"
OUT=""

log() { OUT+="$1\n"; echo "$1"; }

# --- Основная логика ---
log "=== Заголовок — $(date) ==="
log "Host: $(hostname)"

# ... действия и сбор данных через log() ...

# --- Отправить результат на сервер ---
printf "%b" "$OUT" | curl -s -X POST "${SERVER}/push/${LOGNAME}" \
    -H "Content-Type: text/plain" \
    --data-binary @- > /dev/null

echo "Лог: http://91.218.142.168/files/${LOGNAME}"

# Следить за логом в реальном времени
bash /opt/scripts/watch_remote.sh chrome_fix.log

# Посмотреть последний результат
cat /var/www/html/files/chrome_fix.log

/var/www/html/files/   ← скрипты и логи (публичный доступ)
/opt/scripts/          ← серверные утилиты (watch_remote.sh)