Files
prod/.cursor/rules/release-notes-template.md
Andrey 8e595bf7f2 chore: remove outdated monitoring documentation files
- Deleted FIX_PROMLEMS.md and MONITORING_AUTH.md as they contained obsolete information regarding Prometheus and Alertmanager configurations.
- This cleanup helps streamline the documentation and focuses on current setup practices.
2026-01-25 19:02:46 +03:00

6.1 KiB
Raw Blame History

Инструкция по оформлению Release Notes

Назначение

Этот документ описывает структуру и формат для создания файлов Release Notes (например, docs/RELEASE_NOTES_DEV-XX.md).

Структура документа

1. Заголовок

# Release Notes: [название-ветки]

2. Обзор

Краткий абзац (1-2 предложения), описывающий:

  • Количество коммитов в ветке
  • Основные направления изменений

Формат:

## Обзор
Ветка [название] содержит [N] коммитов с ключевыми улучшениями: [краткое перечисление основных изменений].

3. Ключевые изменения

Основной раздел с пронумерованными подразделами для каждого значимого изменения.

Структура каждого подраздела:

### [Номер]. [Название изменения]

**Коммит:** `[hash]`

**Что сделано:**
- [Краткое описание изменения 1]
- [Краткое описание изменения 2]
- [Краткое описание изменения 3]

Правила:

  • Каждое изменение = отдельный подраздел
  • Название должно быть кратким и понятным
  • В разделе "Что сделано" используй маркированные списки
  • НЕ перечисляй затронутые файлы
  • НЕ указывай статистику строк кода
  • Фокусируйся на сути изменений, а не на технических деталях
  • Разделяй подразделы горизонтальной линией ---

4. Основные достижения

Раздел с чекбоксами, подводящий итоги релиза.

Формат:

## 🎯 Основные достижения

✅ [Достижение 1]  
✅ [Достижение 2]  
✅ [Достижение 3]  

Правила:

  • Используй эмодзи для каждого достижения
  • Каждое достижение на отдельной строке
  • Краткие формулировки (3-5 слов)
  • Фокусируйся на ключевых фичах и улучшениях

5. Временная шкала разработки

Раздел с информацией о сроках разработки.

Формат:

## 📅 Временная шкала разработки

**Последние изменения:** [дата]  
**Основная разработка:** [период]  
**Предыдущие улучшения:** [контекст предыдущих веток/изменений]

**Хронология коммитов:**
- `[hash]` - [дата и время] - [краткое описание]
- `[hash]` - [дата и время] - [краткое описание]

Правила:

  • Используй реальные даты из коммитов
  • Формат даты: "DD месяц YYYY" (например, "25 января 2026")
  • Для времени используй формат "HH:MM"
  • Хронология должна быть в хронологическом порядке (от старых к новым)

Стиль написания

Общие правила:

  • Краткость: Фокусируйся на сути, избегай избыточных деталей
  • Ясность: Используй простые и понятные формулировки
  • Структурированность: Информация должна быть легко читаемой и сканируемой
  • Без технических деталей: Не перечисляй файлы, классы, методы (только если это ключевая фича)
  • Без статистики: Не указывай количество строк кода, файлов и т.д.

Язык:

  • Используй прошедшее время для описания изменений ("Добавлена", "Реализована", "Обновлена")
  • Избегай технического жаргона, если это не необходимо
  • Используй активный залог

Эмодзи:

  • 🔥 для раздела "Ключевые изменения"
  • 🎯 для раздела "Основные достижения"
  • 📅 для раздела "Временная шкала разработки"
  • для чекбоксов достижений

Пример использования

При создании Release Notes для новой ветки:

  1. Получи список коммитов: git log [base-branch]..[target-branch] --oneline
  2. Для каждого значимого коммита создай подраздел в "Ключевые изменения"
  3. Собери основные достижения в раздел "Основные достижения"
  4. Добавь временную шкалу с реальными датами коммитов
  5. Проверь, что документ следует структуре и стилю

Важные замечания

  • НЕ включай информацию о коммитах, которые уже были в базовой ветке (master/main)
  • НЕ перечисляй все файлы, которые были изменены
  • НЕ указывай статистику строк кода
  • Фокусируйся на функциональных изменениях, а не на технических деталях реализации
  • Используй реальные даты из коммитов, а не предполагаемые