---
title: Разбор входящих багов
description: "Панель на Laravel + Filament: единая очередь багов из разных каналов, критерии серьёзности, автоназначение, сроки реакции и история каждого бага."
---

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

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

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

## Что он делает

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Похожие сценарии

- [Журнал деплоев по окружениям](https://wpcraft.ru/kb/stacks/filament/use-cases/engineering/deployment-tracker.md) — какой релиз принёс или исправил баг.
- [Учёт регрессий QA](https://wpcraft.ru/kb/stacks/filament/use-cases/engineering/qa-regression-tracker.md) — ошибки, найденные тестами, а не пользователями.
- [Обращения поддержки](https://wpcraft.ru/kb/stacks/filament/use-cases/customer-support/ticket-dashboard.md) — откуда приходит часть сообщений о багах.

## Материалы и источники

- [Refine: Bug Triage Panel](https://refine.dev/use-cases/engineering/bug-triage-panel/)
- [Filament 4.x: ресурсы](https://filamentphp.com/docs/4.x/resources/overview)
- [Filament 4.x: фильтры таблиц](https://filamentphp.com/docs/4.x/tables/filters/overview)
- [Filament 4.x: импорт](https://filamentphp.com/docs/4.x/actions/import)
- [Filament 4.x: уведомления](https://filamentphp.com/docs/4.x/notifications/overview)