Разбор входящих багов

Что это за сервис

Панель разбора входящих багов для дежурного инженера, тимлидов и руководителя разработки. Она собирает сообщения об ошибках из разных каналов в одну очередь, присваивает серьёзность и владельца и следит, чтобы критичное не лежало без движения.

Без неё баги приходят в чаты, GitHub Issues и обращения поддержки, и никто не знает, какие уже приняты в работу. Дежурный начинает смену с пятнадцатиминутной реконструкции того, что осталось от прошлой. Критичный баг часами ждёт, пока «кто-нибудь возьмёт», а о нарушенном сроке узнают, когда он уже прошёл: пороги серьёзности записаны в вики, которую никто не открывает.

Что он делает

Сводит баги в одну очередь. У каждой записи один статус, серьёзность и владелец, независимо от того, откуда пришло сообщение.
Назначает ответственного по правилам. Новый баг уходит владельцу компонента или текущему дежурному, а не ждёт ручного распределения.
Отсчитывает сроки по серьёзности. Для каждого уровня задан срок решения, панель показывает остаток времени и заранее подсвечивает приближение к нарушению.
Показывает дежурному его срез. Смена начинается с отфильтрованного списка открытых багов по серьёзности, а не с прокрутки чата.
Хранит историю бага. Смены статуса, переназначения и комментарии фиксируются с временем и автором и нужны для разбора после инцидента.

Нюансы и особенности

Панель поверх трекера, а не вместо него. Если команда уже работает в Jira, YouTrack или GitHub Issues и трекер закрывает разбор, отдельное приложение не нужно. Панель на Filament оправдана, когда баги приходят из нескольких источников, нужны свои правила назначения и сроков или связь с данными продукта. Задачи на исправление при этом можно создавать обратно в трекере.
Критерии серьёзности конкретны. «Критичный» означает потерю денег или данных, а не «менеджер сказал, что срочно». Критерии показывают прямо в форме, иначе серьёзность постепенно завышают все.
Без владельца баг не живёт. Автоназначение по карте компонентов не даёт записи висеть без ответственного дольше нескольких минут. Карта компонентов — отдельный справочник, который ведут владельцы.
Старые баги закрывают осознанно. Записи без движения две недели и больше попадают в еженедельный список на чистку: закрыть, понизить или вернуть в работу.
Дубли отсекают до сохранения. При создании бага панель ищет похожие по компоненту и заголовку и предлагает связать с существующим, а поле «Связанные баги» хранит связи.
Связь с релизами. Поле «Появился в релизе» и «Исправлен в релизе» позволяет проследить, какой деплой принёс ошибку, и не спорить об этом на разборе.
Импорт вместо пустой доски. Текущие баги загружают из CSV или через API трекера. Начинать с пустой панели значит вести два списка параллельно.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному: каждый шаг даёт проверяемый результат.

1. Данные и модели

Создай модели и миграции для разбора багов: Component (название, владелец,
команда), Bug (заголовок, описание, источник, компонент, серьёзность,
статус, исполнитель, срок решения, релиз появления и релиз исправления,
внешний id), BugActivity (баг, действие, старое и новое значение, автор,
время), связь «многие ко многим» для связанных багов. Добавь фабрики
с реалистичными данными.

2. Очередь и карточка бага

Сгенерируй Filament-ресурс для Bug. В таблице покажи серьёзность, статус,
компонент, исполнителя и остаток времени до срока; добавь фильтры
по серьёзности, компоненту, исполнителю и вкладки «Мои», «Без владельца»,
«Близко к нарушению». В карточке выведи историю BugActivity и связанные баги.
При создании показывай похожие открытые баги того же компонента.

3. Сроки и назначение

Добавь в конфиг сроки решения по серьёзности (например, критичный — 4 часа,
высокий — сутки, средний — неделя). При создании бага выставляй срок
и назначай владельца компонента или текущего дежурного. Каждое
переназначение пиши в журнал с предыдущим исполнителем.

Проверьте, что смена серьёзности пересчитывает срок и это видно в истории.

4. Импорт и напоминания

Добавь импорт багов из CSV и фоновую синхронизацию с GitHub Issues по API
с сохранением внешнего id, чтобы повторный импорт не создавал дубли.
Сделай задачу по расписанию, которая уведомляет исполнителя и тимлида,
когда до срока осталось меньше 20% времени, и собирает список багов
без движения 14 дней.

5. Роли и сводка

Настрой роли: инженер видит свои баги и очередь без владельца, тимлид —
баги своей команды, руководитель — всё. Ограничение действует в таблицах,
виджетах и экспорте. Добавь виджеты открытых багов по серьёзности и доли
нарушенных сроков за месяц.

Войдите под инженером и убедитесь, что баги других команд не видны ни в очереди, ни в виджетах, ни в выгрузке.