embeddevio/awg-dash
1
0
Fork 0
Code Issues 40 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

Эпик: панель состояния VPN-туннеля #9

New Issue
Open
opened 2026-10-18 22:17:09 +03:00 by embeddevio · 2 comments
embeddevio commented 2026-10-18 22:17:09 +03:00
Owner
Copy Link
Copy Source

Эпик для проверки авто-декомпозиции через MCP.

Цель

Дашборд должен показывать состояние VPN-туннеля (awg0) и управлять им.

Acceptance criteria

  • GIVEN открыт дашборд, WHEN туннель поднят, THEN отображается статус и внешний IP
  • GIVEN туннель упал, WHEN открыт дашборд, THEN виден индикатор ошибки

Артефакты

  • OpenAPI spec
  • Скриншот макета
Эпик для проверки авто-декомпозиции через MCP. ## Цель Дашборд должен показывать состояние VPN-туннеля (awg0) и управлять им. ## Acceptance criteria - GIVEN открыт дашборд, WHEN туннель поднят, THEN отображается статус и внешний IP - GIVEN туннель упал, WHEN открыт дашборд, THEN виден индикатор ошибки ## Артефакты - OpenAPI spec - Скриншот макета
embeddevio added the epic label 2026-10-18 22:17:09 +03:00
embeddevio commented 2026-10-18 22:18:01 +03:00
Author
Owner
Copy Link
Copy Source

Декомпозиция эпика #9 (TechLead)

Артефакты, на которые опираемся: OpenAPI spec (создаётся в подзадаче 1), скриншот макета (прикладывает frontend в подзадаче 2).

  1. Backend: REST API статуса туннеля awg0 | owner: backend-engineer | est: 5 | AC: GIVEN интерфейс awg0 существует, WHEN выполняется GET /api/v1/tunnel/status, THEN возвращается JSON {status, peer_endpoint, external_ip, last_handshake_at, error} со схемой, описанной в OpenAPI spec; AND WHEN awg0 отсутствует или down, THEN HTTP 200 c status="down" и заполненным error, без 500.
  2. Frontend: панель состояния и индикатор ошибки | owner: frontend-engineer | est: 5 | AC: GIVEN открыт дашборд, WHEN API отдаёт status="up", THEN отображаются статус, внешний IP и время последнего handshake; AND GIVEN API отдаёт status="down" или запрос упал, THEN виден красный индикатор ошибки с текстом причины и кнопка повторной загрузки.
  3. QA: e2e-проверка сценариев up/down/недоступен-API | owner: qa-engineer | est: 3 | AC: GIVEN стенд с замоканным API, WHEN прогоняется e2e-набор, THEN кейсы «туннель поднят», «туннель упал», «API 5xx/timeout» зелёные и покрытие нового кода ≥70%.
  4. DevOps: healthcheck и деплой обновления | owner: devops | est: 3 | AC: GIVEN новый образ собирается в CI, WHEN выполняется деплой в staging, THEN контейнер проходит readiness-пробу на /api/v1/tunnel/status и smoke-тест отвечает 200 при поднятом туннеле.

Приоритет: P1 (подзадачи 1 и 2), P2 (3 и 4). Зависимости: 2 зависит от 1 (контракт API), 3 зависит от 1 и 2, 4 зависит от 1. Merge в main — только при зелёном CI, покрытии ≥70% и ревью владельца роли; деплой в прод — по отдельному одобрению TechLead. Подзадачи созданы отдельными issue с ссылкой на этот эпик.

## Декомпозиция эпика #9 (TechLead) Артефакты, на которые опираемся: OpenAPI spec (создаётся в подзадаче 1), скриншот макета (прикладывает frontend в подзадаче 2). 1. Backend: REST API статуса туннеля awg0 | owner: backend-engineer | est: 5 | AC: GIVEN интерфейс awg0 существует, WHEN выполняется GET /api/v1/tunnel/status, THEN возвращается JSON {status, peer_endpoint, external_ip, last_handshake_at, error} со схемой, описанной в OpenAPI spec; AND WHEN awg0 отсутствует или down, THEN HTTP 200 c status="down" и заполненным error, без 500. 2. Frontend: панель состояния и индикатор ошибки | owner: frontend-engineer | est: 5 | AC: GIVEN открыт дашборд, WHEN API отдаёт status="up", THEN отображаются статус, внешний IP и время последнего handshake; AND GIVEN API отдаёт status="down" или запрос упал, THEN виден красный индикатор ошибки с текстом причины и кнопка повторной загрузки. 3. QA: e2e-проверка сценариев up/down/недоступен-API | owner: qa-engineer | est: 3 | AC: GIVEN стенд с замоканным API, WHEN прогоняется e2e-набор, THEN кейсы «туннель поднят», «туннель упал», «API 5xx/timeout» зелёные и покрытие нового кода ≥70%. 4. DevOps: healthcheck и деплой обновления | owner: devops | est: 3 | AC: GIVEN новый образ собирается в CI, WHEN выполняется деплой в staging, THEN контейнер проходит readiness-пробу на /api/v1/tunnel/status и smoke-тест отвечает 200 при поднятом туннеле. --- Приоритет: P1 (подзадачи 1 и 2), P2 (3 и 4). Зависимости: 2 зависит от 1 (контракт API), 3 зависит от 1 и 2, 4 зависит от 1. Merge в main — только при зелёном CI, покрытии ≥70% и ревью владельца роли; деплой в прод — по отдельному одобрению TechLead. Подзадачи созданы отдельными issue с ссылкой на этот эпик.
embeddevio commented 2026-10-21 23:25:08 +03:00
Author
Owner
Copy Link
Copy Source

TechLead: эпик поглощён эпиком #15 (полное приложение awg-dash). Маппинг подзадач:

  • #10 (REST API статуса) → #22 (VPN Controller: парсинг/up/down/статус туннеля) и #32 (REST API v1).
  • #11 (UI-панель состояния) → #36 (Dashboard: статус, графики, handshake, аптайм).
  • #12 (E2E up/down/недоступен API) → #41 (интеграционные тесты) + #42 (Playwright E2E).
  • #13 (healthcheck + staging) → #31 (/health, /ready) + #45 (runbook + staging smoke).

Задачи #10–#13 остаются открытыми как исторические — закроем их после того, как соответствующие подзадачи #15 дойдут до Done. Новая работа ведётся по доске эпика #15: status/backlog → status/ready → status/in-progress → status/review.

**TechLead:** эпик поглощён эпиком #15 (полное приложение awg-dash). Маппинг подзадач: - #10 (REST API статуса) → #22 (VPN Controller: парсинг/up/down/статус туннеля) и #32 (REST API v1). - #11 (UI-панель состояния) → #36 (Dashboard: статус, графики, handshake, аптайм). - #12 (E2E up/down/недоступен API) → #41 (интеграционные тесты) + #42 (Playwright E2E). - #13 (healthcheck + staging) → #31 (/health, /ready) + #45 (runbook + staging smoke). Задачи #10–#13 остаются открытыми как исторические — закроем их после того, как соответствующие подзадачи #15 дойдут до Done. Новая работа ведётся по доске эпика #15: status/backlog → status/ready → status/in-progress → status/review.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
backend
Backend related work
 blocker
Blocking issue
 devops
Infra and deployment
 epic
Large feature or project
 frontend
Frontend related work
 hotfix
Urgent hotfix
 qa
Testing and QA
 release
Release request
 status/backlog
Kanban: не начато / бэклог
 status/blocked
Kanban: заблокировано, нужна эскалация
 status/in-progress
Kanban: в работе (есть ветка/PR)
 status/ready
Kanban: готово к работе, есть AC и зависимости
 status/review
Kanban: на ревью/QA
No Label epic
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
embeddevio
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: embeddevio/awg-dash#9
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?