feat(runner): icona nella tray con il numero di sessioni e finestra di dettaglio #10

Merged
claudia merged 1 commit from feat/runner-tray-status into main 2026-09-11 08:51:14 +00:00
Owner

Cosa

Finora, per sapere cosa stesse facendo un runner, bisognava aprire i .jsonl in log_dir. Ora la VM lo dice a colpo d'occhio: un'icona nell'area di notifica con il numero di sessioni attive, e al click una finestra con progetto, ticket, stato e prompt di ognuna.

Come

Worker — internal/status

  • Registry in memoria delle sessioni (progetto, ticket, prompt, stato, ultimo output, turni, costo). Prompt e output troncati, storico delle ultime 10 sessioni chiuse. Nil-safe, così l'agent lo chiama senza guardie.
  • Server HTTP di sola lettura su loopback, porta effimera, token casuale. Indirizzo e token pubblicati in <log_dir>/status.json (0600).
  • Nuovi campi di config: status_addr, status_disabled.

Tray — cmd/tray → agent-tray.exe

  • .exe separato: agent-runner.exe gira come servizio in sessione 0, che non ha desktop né area di notifica.
  • Icona 16/32px disegnata a runtime (ICO 32bpp + font bitmap 3x5) col numero di sessioni. Colore = stato: verde in esecuzione, azzurro aperte ma ferme, grigio nessuna, rosso errore o gateway disconnesso, ! worker non raggiungibile.
  • Click sinistro: finestra WebView2 con il dettaglio; se il runtime manca, ripiega sul browser predefinito. Menu: dettagli, cartella log, esci.
  • Riscopre endpoint e token quando il worker riparte (porta e token cambiano).
  • scripts/build-tray.sh (-H windowsgui) e scripts/install-tray.ps1 (collegamento in Esecuzione automatica, senza diritti di admin).

Scelte

  • Solo sessioni locali, nessuna query al gateway (deciso con Marcello). Per la flotta c'è list_agents.
  • Token anche su loopback: 127.0.0.1 è raggiungibile da qualunque processo della macchina, e lo stato contiene i prompt dei ticket.
  • Niente CGO: fyne.io/systray + jchv/go-webview2, cross-compilabile da Linux come il resto.

Verificato

gofmt pulito, go vet su linux e windows/amd64, build windows/amd64 ok, go test ./... verde (nuovi test: registry, token/loopback del server, encoder ICO, glifi, derivazione dello stato, riscoperta dell'endpoint).

⚠️ Non verificabile in CI: il comportamento GUI su Windows (tray + WebView2 + threading) va provato a mano sulla VM.

## Cosa Finora, per sapere cosa stesse facendo un runner, bisognava aprire i `.jsonl` in `log_dir`. Ora la VM lo dice a colpo d'occhio: un'icona nell'area di notifica con il **numero di sessioni attive**, e al click una finestra con **progetto, ticket, stato e prompt** di ognuna. ## Come **Worker — `internal/status`** - `Registry` in memoria delle sessioni (progetto, ticket, prompt, stato, ultimo output, turni, costo). Prompt e output troncati, storico delle ultime 10 sessioni chiuse. Nil-safe, così l'agent lo chiama senza guardie. - Server HTTP **di sola lettura su loopback**, porta effimera, token casuale. Indirizzo e token pubblicati in `<log_dir>/status.json` (0600). - Nuovi campi di config: `status_addr`, `status_disabled`. **Tray — `cmd/tray` → `agent-tray.exe`** - `.exe` separato: `agent-runner.exe` gira come servizio in **sessione 0**, che non ha desktop né area di notifica. - Icona 16/32px disegnata a runtime (ICO 32bpp + font bitmap 3x5) col numero di sessioni. Colore = stato: verde in esecuzione, azzurro aperte ma ferme, grigio nessuna, rosso errore o gateway disconnesso, `!` worker non raggiungibile. - Click sinistro: finestra **WebView2** con il dettaglio; se il runtime manca, ripiega sul browser predefinito. Menu: dettagli, cartella log, esci. - Riscopre endpoint e token quando il worker riparte (porta e token cambiano). - `scripts/build-tray.sh` (`-H windowsgui`) e `scripts/install-tray.ps1` (collegamento in Esecuzione automatica, senza diritti di admin). ## Scelte - **Solo sessioni locali**, nessuna query al gateway (deciso con Marcello). Per la flotta c'è `list_agents`. - **Token anche su loopback**: `127.0.0.1` è raggiungibile da qualunque processo della macchina, e lo stato contiene i prompt dei ticket. - **Niente CGO**: `fyne.io/systray` + `jchv/go-webview2`, cross-compilabile da Linux come il resto. ## Verificato `gofmt` pulito, `go vet` su linux e windows/amd64, build `windows/amd64` ok, `go test ./...` verde (nuovi test: registry, token/loopback del server, encoder ICO, glifi, derivazione dello stato, riscoperta dell'endpoint). ⚠️ **Non verificabile in CI**: il comportamento GUI su Windows (tray + WebView2 + threading) va provato a mano sulla VM.
Finora l'unico modo di sapere cosa stesse facendo un runner era aprire i
.jsonl in log_dir. Ora la VM lo dice a colpo d'occhio.

Worker (internal/status):
- Registry in memoria delle sessioni: progetto, ticket, prompt, stato,
  ultimo output, turni, costo; prompt e output troncati, storico a 10.
- Server HTTP di sola lettura su loopback (porta effimera) con token
  casuale; indirizzo e token pubblicati in <log_dir>/status.json (0600).
  Il bind e' forzato su 127.0.0.1: lo stato contiene i prompt dei ticket,
  e il token serve lo stesso perche' loopback non e' un confine di
  sicurezza fra processi della stessa macchina.
- Nuovi campi di config status_addr / status_disabled.

Tray (cmd/tray -> agent-tray.exe):
- .exe separato perche' il runner gira come servizio in sessione 0, dove
  non esistono desktop ne' area di notifica.
- Icona 16/32px disegnata a runtime (ICO 32bpp + font bitmap 3x5) col
  numero di sessioni; colore = stato (verde in esecuzione, azzurro ferme,
  grigio nessuna, rosso errore/gateway giu', ! worker assente).
- Click sinistro: finestra WebView2 con il dettaglio; se il runtime manca
  ripiega sul browser. Menu: dettagli, cartella log, esci.
- Riscopre da solo endpoint e token quando il worker riparte.
- Conta solo le sessioni locali (scelta di Marcello): niente query al
  gateway.

scripts/build-tray.sh (-H windowsgui) e scripts/install-tray.ps1
(collegamento in Esecuzione automatica, senza diritti di admin).

Non verificabile da qui: il comportamento GUI su Windows (tray + WebView2)
va provato sulla VM.
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Soltea-org/soltea-agent-gateway!10
No description provided.