Что должно входить в баг-репорт для плавающего (непостоянного) дефекта?

А, слушай, вот эта хуйня с плавающими багами — это отдельный вид искусства, блядь. Как поймать призрака, который материализуется только когда у тебя полная луна и ты забыл зарядить мышь. Ну, поехали, объясняю, как надо на коленке выцарапывать репорт, чтобы разработчик не послал тебя нахуй с криком «НЕ ВОСПРОИЗВОДИТСЯ!».

Первое, ебать, — заголовок. Не «Чё-то не работает», а сразу в лоб, как кирпичом. Пример: [Intermittent] Кнопка 'Отправить' иногда игнорирует клик, если тыкать в неё как ошалелый. Сразу понятно, о чём речь и что баг — тот ещё шлюхос.

Второе — шаги. Тут надо расписать всё, как для дебила, который только что проснулся. «1. Открыл приложение. 2. Ввёл данные А, Б, В именно в такой последовательности. 3. Быстро, блядь, пять раз кликнул по кнопке, пока анимация не закончилась». Если не указать «быстро» или «пока анимация идёт» — нихуя не воспроизведётся, и будешь потом сидеть и бздеть.

Третье — что получил vs что ожидал. Ожидал — отправка формы один раз. Получил — форма игнорит все пять кликов, а потом, через три секунды, улетает в никуда. Пиздец, а не логика.

А вот теперь, сука, главное — частота. Это святое. Не «иногда», а «в 3 случаях из 10» или «~30%». Если скажешь «иногда», тебе в ответ «иногда — это не баг, это фича, иди нахуй». Чёткий процент — это уже данные, а не пук в лужу.

Контекст — наше всё. Опиши, в каких дебрях эта хрень вылезает. «ОС: Windows 11, но на Mac тоже видел. Браузер: Chrome 128, но в Safari тоже плавает. Сеть: 3G или когда Wi-Fi тупит. Данные: когда в поле комментария впихнул 2000 символов с эмодзи». Без этого — как искать иголку в стоге сена, который ещё и горит.

Артефакты — твои лучшие друзья. Скриншот — хорошо. Видео — вообще огонь. Но самое сокровенное — логи, ёпта! Открой F12, вкладка Console или Network, и как попадёшь на этот баг — выцепи всё, что там наваяло. Особенно эти красные ошибки, они как маячки в аду.

**Частота:** Примерно каждый четвёртый запрос (~25%) к `/api/v1/process`.
**Условия:** Когда шлёшь ему данные больше 1 МБ, да ещё и с символами `&` и `<` внутри.
**Лог ошибки (из консоли или серверный):**
```json
{
  "timestamp": "2025-01-27T10:05:32Z",
  "level": "ERROR",
  "message": "NullPointerException in ProcessorService line 142",
  "requestId": "req_abc123"
}

Наблюдение: Заметил, что перед тем как всё ебнулось, запрос висит больше 2 секунд. Может, таймаут какой?

И последний пункт — **наблюдения**. Это когда ты уже начал подозревать систему во всём. «Багу нравится появляться с утра, после того как приложение всю ночь простояло». Или «исчезает, если почистить кеш, но потом, через N действий, возвращается». Это как профиль маньяка — помогает поймать.

Короче, суть в чём: чтобы победить плавающий баг, нужно превратить его из призрака в осязаемую, вонючую проблему. С цифрами, логами и чёткими шагами. Тогда у разработчика будет шанс его воспроизвести, а не просто пожать плечами и сказать «работает у меня». Удачи, ебать мои старые костыли, эта охота — та ещё нервотрёпка.