Code Generations Manager

Appearance

System Monitoringu i Integracji Webhook ​

Przegląd ​

System monitoringu zapewnia ciągłą widoczność postępu zadań poprzez okresowe statusy, event-based notyfikacje oraz integrację z Mattermost. Wszystkie komunikaty przechodzą przez n8n webhook do Mattermost.

Task Status Monitor ​

Automatyczne Okresowe Statusowanie ​

System automatycznie monitoruje wszystkie zadania w trakcie wykonywania i wysyła okresowe statusy do Mattermost.

Workflow:

task_status_monitor.yaml (DAGU workflow)
  ↓ uruchamia co 5 minut
task_status_monitor.sh
  ↓ skanuje tasks/in_progress/
  ↓ dla każdego taska:
     - sprawdza czy minęło X min od ostatniego statusu
     - czyta recent logs i current subtask
     - generuje status przez lekki model AI (Haiku)
     - wysyła przez send_webhook.sh
  ↓
n8n webhook
  ↓
Mattermost notification

Konfiguracja per Task ​

Każdy task ma swoją konfigurację monitoringu w sekcji monitoring w task.json:

json
{
  "task_id": "DEV-7315",
  "monitoring": {
    "status_update_interval_minutes": 5,    // co ile minut wysyłać status
    "status_ai_provider": "claude",         // provider do generowania statusów
    "status_ai_model": "haiku",             // model do generowania statusów (lekki)
    "last_status_update": null              // timestamp ostatniego statusu (auto)
  }
}

Fallback do Globalnej Konfiguracji ​

Jeśli sekcja monitoring nie istnieje w task.json, system używa wartości z .env:

bash
# Domyślny interwał między statusami (w minutach)
STATUS_UPDATE_INTERVAL_MINUTES=5

# Domyślny provider i model do generowania statusów
STATUS_AI_PROVIDER=claude
STATUS_AI_MODEL=haiku

# URL webhooka
N8N_WEBHOOK_URL=https://n8n.sembot.ovh/webhook/

Hierarchia Konfiguracji ​

  1. task.json → monitoring.status_update_interval_minutes (najwyższy priorytet)
  2. .env → STATUS_UPDATE_INTERVAL_MINUTES (fallback)
  3. Hardcoded default: 5 minut

Automatyczne Zarządzanie Statusem ​

System automatycznie:

  • ✅ Tworzy sekcję monitoring w task.json przy pierwszym statusie (jeśli nie istnieje)
  • ✅ Aktualizuje last_status_update po każdym wysłanym statusie
  • ✅ Używa task-specific konfiguracji (interwał, provider, model)

Przykład task.json po wysłaniu statusu:

json
{
  "task_id": "DEV-7315",
  "status": "in_progress",
  "monitoring": {
    "status_update_interval_minutes": 5,
    "status_ai_provider": "claude",
    "status_ai_model": "haiku",
    "last_status_update": "2025-12-31T10:30:00Z"  // ← automatycznie aktualizowane
  }
}

Generowanie Statusów przez AI ​

Lekki model (Claude Haiku) analizuje:

  • Aktualny subtask (z którego priority i jaki task)
  • Recent logs (ostatnie 30 linii)
  • Task title i worker type

Generuje zwięzłe podsumowanie (2-3 zdania) odpowiednie na Mattermost.

Fallback: Jeśli AI niedostępne, używany jest prosty status z metadanych.

Webhook Notifications ​

Typy Notyfikacji ​

System wysyła trzy główne typy webhooków:

  1. Okresowe statusy tasków - automatyczne co X minut
  2. Event-based notifications - w ważnych momentach (start, koniec, błędy)
  3. Response notifications - potwierdzenia komend użytkownika

Struktura Webhook Payload ​

1. Task Status Update (Okresowy) ​

json
{
  "event_type": "task_status_update",
  "timestamp": "2025-12-31T10:30:00Z",
  "task_id": "DEV-7315",
  "title": "Settings UI Unification",
  "status": "in_progress",
  "current_work": "P1: frontend_abc123 - Implement Settings Menu",
  "message": "Currently implementing the settings menu component with new icon visibility logic. Build completed successfully, working on component integration.",
  "worker_type": "sembot_frontend"
}

2. Task Lifecycle Events ​

json
// Task Started
{
  "event_type": "task_started",
  "task_id": "DEV-7315",
  "title": "Settings UI Unification",
  "worker_type": "sembot_frontend",
  "started_at": "2025-12-31T09:00:00Z"
}

// Task Completed
{
  "event_type": "task_completed",
  "task_id": "DEV-7315",
  "title": "Settings UI Unification",
  "status": "success",
  "completed_at": "2025-12-31T15:00:00Z",
  "verification_status": "READY FOR REVIEW"
}

// Task Failed
{
  "event_type": "task_failed",
  "task_id": "DEV-7315",
  "title": "Settings UI Unification",
  "error": "Build failed with 2 compilation errors",
  "failed_at": "2025-12-31T12:00:00Z",
  "priority_level": "P1"
}

3. Follow-up Task Created ​

json
{
  "event_type": "task_followup_created",
  "original_task_id": "DEV-7315",
  "followup_task_id": "DEV-7315-FIX-1",
  "severity": "critical",
  "issues_count": 4,
  "summary": "Build failed with 2 compilation errors. Visual verification found 1 critical bug..."
}

4. Task Reopened ​

json
{
  "event_type": "task_reopened",
  "task_id": "DEV-7315",
  "additional_instructions": "dodaj jeszcze dark mode do settings",
  "reopened_at": "2025-01-01T14:30:00Z",
  "reopened_count": 1,
  "status": "success"
}

5. Task Interrupted ​

json
{
  "event_type": "task_interrupted",
  "task_id": "DEV-7315",
  "interrupt_id": "interrupt_1735742100_12345",
  "priority": "urgent",
  "message": "zweryfikuj build",
  "created_at": "2025-01-01T14:35:00Z",
  "status": "success"
}

6. Error Response ​

json
{
  "event_type": "task_reopened" | "task_interrupted" | "...",
  "task_id": "DEV-7315",
  "status": "error",
  "error": "Task DEV-7315 not found in done/"
}

Komponenty Webhook System ​

  • dags/scripts/send_webhook.sh - Helper do wysyłki webhooków z retry logic
  • N8N_WEBHOOK_URL - Konfiguracja URL z .env
  • Retry logic - 3 próby z exponential backoff

Integracja z Mattermost ​

Komenda Format ​

Użytkownik może wydawać komendy bezpośrednio na kanale Mattermost:

Przykłady:

DEV-7315 dodaj jeszcze dark mode do settings
DEV-7315 PILNE: najpierw zweryfikuj czy build działa
jak skończysz wydaj mi na dev6

Workflow Przetwarzania Komend z Mattermost ​

Mattermost (User)
  ↓ "DEV-7315 dodaj dark mode"
n8n Webhook Receiver
  ↓ parsuje komendę
  ↓ rozpoznaje typ (reopen/interrupt/user_command)
  ↓ tworzy JSON w tasks/control_commands/ lub tasks/in_progress/{TASK_ID}/mattermost_commands/
  ↓
DAGU Workflow (task_control_receiver.yaml lub notification_mattermost_receiver.yaml)
  ↓ uruchamia co minutę
  ↓ wykrywa nowe pliki JSON
  ↓
process_task_control_commands.sh lub process_mattermost_commands.sh
  ↓ przetwarza komendy
  ├─→ reopen_task.sh (dla DONE tasks)
  ├─→ create_task_interrupt.sh (dla IN_PROGRESS tasks)
  └─→ create_user_command_subtask.sh (dla user commands)
  ↓
send_webhook.sh
  ↓ wysyła potwierdzenie
  ↓
n8n → Mattermost (potwierdzenie dla użytkownika)

User Commands przez Mattermost ​

Struktura katalogów:

tasks/in_progress/{TASK_ID}/mattermost_commands/

Struktura JSON dla komendy z Mattermost:

json
{
  "command_id": "mattermost_cmd_1234567890",
  "task_id": "example_task_2_team_mode",
  "user": "jan.kowalski",
  "channel": "dev-team",
  "priority": "P0",
  "command": "wydaj na dev6",
  "raw_message": "jak skończysz wydaj mi na dev6",
  "timestamp": "2025-12-21T10:30:00Z"
}

Implementacja:

  • Dedykowany DAG workflow: notification_mattermost_receiver.yaml
  • Działa co 1 minutę (szybsza reakcja)
  • Przetwarza wszystkie pliki JSON z mattermost_commands/ katalogów
  • Automatyczne wykrywanie typu komendy (deploy, test, fix) na podstawie słów kluczowych
  • Automatycznie tworzone są subtaski z kontekstem użytkownika i kanału
  • Po przetworzeniu plik JSON jest usuwany
  • Wysyłana jest notyfikacja webhook do n8n

Typy User Commands ​

command_type:

  • test_and_fix - uruchom testy i napraw błędy
  • run_script - wykonaj dowolny skrypt shell
  • deploy - wydaj na serwer
  • custom - dowolna komenda AI

Przykład JSON user command:

json
{
  "command_id": "user_cmd_1234567890",
  "task_id": "example_task_2_team_mode",
  "priority": "P1",
  "command_type": "test_and_fix",
  "description": "Uruchom wszystkie testy i napraw błędy",
  "params": {
    "test_command": "npm test",
    "auto_fix": true,
    "max_iterations": 5
  },
  "created_at": "2025-12-21T10:30:00Z"
}

Health Check System ​

Automatyczne Health Check ​

System wysyła health check co 5 minut aby potwierdzić, że watchdog żyje i czeka na zadania.

Workflow:

watchdog.yaml (DAGU)
  ↓ co 5 minut
health_check.sh
  ↓ sprawdza status systemów
  ↓ generuje payload
  ↓
send_webhook.sh
  ↓
n8n → Mattermost (jeśli problem wykryty)

Health Check Payload:

json
{
  "event_type": "system_health_check",
  "timestamp": "2025-12-31T10:35:00Z",
  "status": "healthy",
  "watchdog_running": true,
  "queues": {
    "sembot_frontend_1": { "active_tasks": 2, "status": "healthy" },
    "sembot_frontend_2": { "active_tasks": 1, "status": "healthy" },
    "sembot_backend_1": { "active_tasks": 0, "status": "idle" },
    "sembot_qa_1": { "active_tasks": 1, "status": "healthy" }
  },
  "pending_tasks": 5,
  "failed_tasks": 0
}

Poziomy statusu:

  • healthy - wszystko działa prawidłowo
  • degraded - niektóre kolejki mają problemy
  • unhealthy - krytyczne problemy

Mechanizm Przerwania i Potwierdzeń ​

User Approval Request ​

System może poprosić użytkownika o potwierdzenie w bardzo istotnych momentach.

Workflow:

Subtask (potrzebuje potwierdzenia)
  ↓
send_webhook.sh
  ↓ event_type: "approval_request"
  ↓
n8n → Mattermost (notyfikacja użytkownika)
  ↓
Użytkownik odpowiada na Mattermost
  ↓
n8n parsuje odpowiedź
  ↓ tworzy JSON w tasks/in_progress/{TASK_ID}/approvals/
  ↓
Subtask nasłuchuje pliku approval
  ↓ czyta odpowiedź (approved/rejected)
  ↓ kontynuuje lub przerywa

Approval Request Payload:

json
{
  "event_type": "approval_request",
  "task_id": "DEV-7315",
  "approval_id": "approval_1735742100_12345",
  "question": "Deploy to production server? This will affect live users.",
  "options": ["approve", "reject"],
  "timeout_minutes": 10,
  "created_at": "2025-12-31T14:00:00Z"
}

Approval Response (z Mattermost przez n8n):

json
{
  "approval_id": "approval_1735742100_12345",
  "task_id": "DEV-7315",
  "response": "approve",
  "user": "jan.kowalski",
  "timestamp": "2025-12-31T14:05:00Z"
}

Timeout Handling ​

Jeśli użytkownik nie odpowie w czasie ai.approval_request_wait_minutes (domyślnie 10 minut):

Jeśli możliwe kontynuowanie bez odpowiedzi:

  • System kontynuuje z domyślną akcją
  • Wysyła webhook z informacją o timeout i podjętej decyzji

Jeśli niemożliwe kontynuowanie:

  • Przerywa subtask
  • Oznacza status zadania jako requires_approval
  • Wysyła webhook z informacją o zatrzymaniu

n8n Workflow Integration ​

Główne Workflows w n8n ​

1. Webhook Receiver (główny endpoint) ​

URL: https://n8n.sembot.ovh/webhook/

Funkcje:

  • Odbiera wszystkie webhooks z DAGU
  • Routuje wydarzenia do odpowiednich kanałów Mattermost
  • Parsuje komendy użytkownika z Mattermost
  • Formatuje wiadomości na czytelne notyfikacje

2. Mattermost Command Parser ​

Funkcje:

  • Nasłuchuje wiadomości na kanałach Mattermost
  • Wykrywa komendy typu {TASK_ID} {COMMAND}
  • Parsuje priority (PILNE → urgent, etc.)
  • Tworzy JSON w odpowiednich katalogach (control_commands/, mattermost_commands/)

Wykrywane wzorce:

DEV-7315 {COMMAND}           → komenda dla konkretnego taska
PILNE: {COMMAND}             → priorytet urgent
{TASK_ID} dodaj {FEATURE}    → reopen command
{TASK_ID} PILNE: {COMMAND}   → interrupt urgent

3. Message Formatter ​

Funkcje:

  • Formatuje webhook payload na czytelne wiadomości Mattermost
  • Dodaje emoji indicators (✅, ❌, ⚠️, 🔄, etc.)
  • Grupuje notyfikacje (np. health check tylko gdy problem)
  • Linkuje do tasków w JIRA (jeśli issue.url dostępne)

Przykład formatowania:

📊 Task Status Update
**DEV-7315** - Settings UI Unification

🔧 Current Work: P1: frontend_abc123 - Implement Settings Menu

Currently implementing the settings menu component with new icon visibility logic.
Build completed successfully, working on component integration.

Worker: sembot_frontend_1
⏱️ 10:30:00

Komponenty Systemu ​

DAGU Workflows ​

  • task_status_monitor.yaml - Periodic status updates (*/5 * * * *)
  • task_control_receiver.yaml - Reopen/Interrupt commands (* * * * *)
  • notification_mattermost_receiver.yaml - Mattermost user commands (* * * * *)
  • watchdog.yaml - Health check (*/5 * * * *)

Bash Scripts ​

  • dags/scripts/task_status_monitor.sh - Generowanie statusów tasków
  • dags/scripts/process_task_control_commands.sh - Dispatcher control commands
  • dags/scripts/process_mattermost_commands.sh - Dispatcher Mattermost commands
  • dags/scripts/send_webhook.sh - Helper do wysyłki webhooków z retry
  • dags/scripts/health_check.sh - System health check

Claude Code Plugins ​

  • plugins/plugin-orkiestrator/commands/status_update.md - Generowanie statusów przez AI

Monitoring i Debugging ​

Sprawdzanie Pending Commands ​

bash
# Kontrolne komendy (reopen/interrupt)
ls tasks/control_commands/

# User commands z Mattermost
ls tasks/in_progress/*/mattermost_commands/

# Approval requests
ls tasks/in_progress/*/approvals/

# Error files
ls tasks/control_commands/*.error

Logi DAGU ​

bash
# Status monitor logs
cat ~/.dagu/logs/task_status_monitor/*/task_status_monitor.log

# Control receiver logs
cat ~/.dagu/logs/task_control_receiver/*/task_control_receiver.log

# Mattermost receiver logs
cat ~/.dagu/logs/notification_mattermost_receiver/*/notification_mattermost_receiver.log

# Watchdog logs
cat ~/.dagu/logs/watchdog/*/watchdog.log

Webhook Debugging ​

bash
# Test webhook manually
curl -X POST https://n8n.sembot.ovh/webhook/ \
  -H "Content-Type: application/json" \
  -d '{
    "event_type": "task_status_update",
    "task_id": "TEST-123",
    "message": "Test message"
  }'

Best Practices ​

1. Status Update Frequency ​

Zalecenia:

  • Development tasks: 5 minut (domyślnie)
  • Critical tasks: 2-3 minuty
  • Long-running tasks: 10-15 minut
  • Background tasks: 30 minut

2. Webhook Retry Logic ​

System automatycznie ponawia nieudane webhooks:

  • 3 próby z exponential backoff (1s, 5s, 15s)
  • Logi nieudanych webhooków w DAGU logs
  • Alert do Mattermost po 3 nieudanych próbach

3. Command Processing Priority ​

Kolejność przetwarzania:

  1. Urgent interrupts (natychmiast)
  2. Approval responses (w ciągu 1 minuty)
  3. Reopen commands (w ciągu 1 minuty)
  4. User commands (w ciągu 1-5 minut)

4. Notification Grouping ​

n8n grupuje notyfikacje aby uniknąć spamu:

  • Status updates: max 1 na task na 5 minut
  • Health checks: tylko gdy zmiana statusu
  • Multiple events: agregowane w single message

Error Handling ​

Webhook Failures ​

Retry Logic w send_webhook.sh:

bash
for i in {1..3}; do
  if curl -X POST "$N8N_WEBHOOK_URL" -d "$PAYLOAD"; then
    break
  fi
  sleep $((i * 5))
done

Alert po niepowodzeniu:

json
{
  "event_type": "webhook_delivery_failed",
  "original_event": "task_status_update",
  "task_id": "DEV-7315",
  "attempts": 3,
  "error": "Connection timeout"
}

Invalid Commands ​

Nieprawidłowe JSON:

  • Plik przenoszony do .error
  • Webhook z informacją o błędzie
  • User notyfikowany na Mattermost

Missing Fields:

  • Validation przed przetworzeniem
  • Plik przenoszony do .error
  • Log szczegółowy w DAGU

Task Not Found:

  • Sprawdzenie czy task istnieje w odpowiednim katalogu
  • Error webhook do n8n
  • User notyfikowany na Mattermost

Changelog ​

v2.0 - Advanced Integration ​

  • ✅ Task Status Monitor z AI-generated messages
  • ✅ Mattermost bi-directional integration
  • ✅ User commands i approval system
  • ✅ Health check monitoring
  • ✅ Webhook retry logic

v1.0 - Basic Notifications ​

  • ✅ Podstawowe webhooks (start, done, failed)
  • ✅ n8n integration
  • ✅ Simple Mattermost notifications