Версионирование промтов через git

Поставь версионирование промтов через git для масштаба {{scale}}. Цель: видеть кто, когда и зачем менял промт, и откатить его за секунды.

1. Почему git, а не "в коде"

Промт — это код, который меняет поведение системы. Без версии:

• Не объяснишь регрессию (когда стало хуже?)
• Не откатишь (что было неделю назад?)
• Не сделаешь A/B (нет двух версий рядом)
• Не пройдёшь аудит (кто менял prompt про deletion?)

2. Структура репо

prompts/
  agents/
    code-reviewer/
      v1.md
      v2.md
      CURRENT -> v2.md        # симлинк на активную
      CHANGELOG.md
      tests/                   # эваль-кейсы под этот промт
  templates/
    rag-answer/
      v1.tmpl
      v2.tmpl
  shared/
    safety.md                  # переиспользуемые блоки
    output-formats.md
  schema.json                  # описание метаданных
  README.md

Для <10 промтов — один файл на промт + git history достаточно. Для 10-100 — структура выше + manifest prompts.json. Для 100+ — добавь registry-сервис на ту же файловую структуру + кэш в рантайме.

3. Метаданные промта (frontmatter)

---
id: code-reviewer
version: 2.3.0
status: stable | beta | deprecated
model_target: claude-opus-4
owner: "@alice"
last_eval: 2026-05-10
eval_pass_rate: 0.94
related_tests: ./tests/
changelog: ./CHANGELOG.md
---

SemVer для промтов:

• major — поменялся контракт (формат вывода, schema)
• minor — добавлены capabilities, обратно совместимо
• patch — формулировки, antipatterns, без поведенческих изменений

4. Workflow изменения

feature branch
  └─ редактирование v3.md
  └─ обновление CHANGELOG.md
  └─ локальный eval run
  └─ PR
    ├─ CI: eval vs main
    ├─ CI: lint frontmatter
    ├─ Reviewer: читает diff + смотрит eval-результаты
    └─ merge
       └─ deploy (см. ниже)

Реквайр в PR: ссылка на eval report + объяснение почему менял (не "improve", а "fix #482 false-positive on long files").

5. Подгрузка в рантайм

Три модели:

Для большинства — bundled file. Registry — когда промтов 100+, и нужна смена без редеплоя.

6. Deploy

• Каждый merge в main → новый артефакт (тэг prompts-v2.3.0)
• В рантайме фиксируется конкретная версия (PROMPT_VERSION=2.3.0 в env)
• Не "latest" — иначе регрессия пройдёт незаметно
• В логах рантайма каждый запрос помечен prompt_version (см. телеметрию)

7. Rollback

Контракт: откат за < 60 секунд.

# bundled
git revert <merge-commit>
deploy

# registry
curl -X POST registry/prompts/code-reviewer/activate \
  -d '{"version":"2.2.0"}'

Условия отката:

• Eval показал регрессию
• Production алерт стрелял после релиза
• Жалоба пользователя, attributable к релизу

После rollback — incident note и regression test, иначе откатится ещё раз.

8. A/B и shadow

При больших изменениях:

• Shadow: новая версия принимает 100% трафика, но её ответы не показываются — только сравниваются
• Canary: 5% → 25% → 100% если метрики ок
• A/B: 50/50, по prompt_version в метриках смотрим pass_rate / cost / satisfaction

Это нужно когда eval-набор не покрывает реальное использование.

9. Lint и pre-commit

В hooks:

• Валидный frontmatter (schema.json)
• Заполнен CHANGELOG
• При major bump — bumped и в файлах-потребителях
• Нет TODO / TBD в активной версии
• Длина не превышает токен-бюджет

10. Deprecated

Удалять файлы — теряешь историю. Вместо:

status: deprecated
deprecated_at: 2026-04-01
replaced_by: code-reviewer-v3

Через 2-3 цикла — реально удалить.

Анти-паттерны

• Промт в коде как литерал без id и версии
• "Latest" в рантайме
• Нет eval перед merge — катимся вслепую
• Один merge = много несвязанных правок
• CHANGELOG отсутствует или "improve"
• Откат через "правку файла", не через revert

На выходе

• Структура prompts/ с примером промта v1
• schema.json для frontmatter
• Pre-commit hooks
• CI с eval + lint
• Документ "How we deploy prompts" + "How we rollback"