docs(04): capture phase context

This commit is contained in:
Pierre Martin
2026-03-23 20:31:54 +01:00
parent 5b7c9c5157
commit 719d389d01

View File

@@ -0,0 +1,91 @@
# Phase 4: Notifications et i3bar - Context
**Gathered:** 2026-03-24
**Status:** Ready for planning
<domain>
## Phase Boundary
Notifications desktop (dunst) quand une session passe de Working à Needs Input, mode focus avec timer pour supprimer temporairement les notifications, et widget i3bar affichant le statut des sessions en temps réel.
</domain>
<decisions>
## Implementation Decisions
### Notifications dunst
- **D-01:** Notifier uniquement sur transition Working → Needs Input. Pas de notif pour Idle → Needs Input ou Working → Idle.
- **D-02:** Pas de debounce en v1. Un event hook = une transition = une notification (si pas en mode focus).
- **D-03:** Envoyer les notifications via `notify-send` (ou esiqveland/notify D-Bus). Claude décide l'approche.
### Mode focus
- **D-04:** Timer uniquement : `vmux focus 30` (30 min). Se désactive automatiquement après la durée. Pas de toggle on/off sans durée.
- **D-05:** Le mode focus supprime les notifications dunst. Le widget i3bar reste visible.
### Widget i3bar
- **D-06:** Format liste courte : `vmux: auth[!] portal[W] neia[I]`. Les noms sont le dernier segment du cwd ou le label si défini. `[!]` = Needs Input, `[W]` = Working, `[I]` = Idle.
- **D-07:** Quand aucune session n'attend : `vmux: all working (3)`.
- **D-08:** Couleurs selon urgence : rouge si ≥1 session attend, vert sinon.
### Claude's Discretion
- Protocole i3bar (i3status-rs, i3blocks, ou script custom)
- Implémentation des notifications (notify-send vs D-Bus natif)
- Fréquence de rafraîchissement du widget i3bar
- Stockage du timer focus (en mémoire dans le daemon, persisté ou non)
</decisions>
<canonical_refs>
## Canonical References
**Downstream agents MUST read these before planning or implementing.**
### Existing codebase (Phases 1-3)
- `daemon.go` — Daemon struct avec poll loop, hook server, handlers. Les notifications se déclenchent dans la transition d'état.
- `protocol.go` — SessionInfo avec WaitType. Le widget i3bar consomme la liste des sessions.
- `hook.go` — processHookEvent, UpdateFromHook. Point d'intégration pour les notifications.
- `display.go` — DisplaySessionInfos. Pattern pour le formatage.
- `main.go` — CLI dispatch. Ajouter `vmux focus <minutes>` et potentiellement `vmux i3bar`.
</canonical_refs>
<code_context>
## Existing Code Insights
### Reusable Assets
- `SessionRegistry.List()` — retourne toutes les sessions actives, utilisable pour le widget i3bar
- `processHookEvent` dans hook.go — point d'intégration pour déclencher les notifications
- `Daemon.handleConnection` — pattern pour ajouter de nouvelles actions (focus)
### Established Patterns
- Sous-commandes CLI via switch dans main.go
- Request/Response JSON sur Unix socket
- Goroutines daemon (acceptLoop, pollLoop, hookServerLoop)
### Integration Points
- hook.go `processHookEvent` ou `UpdateFromHook` — déclencher la notif après un changement Working → Needs Input
- daemon.go — ajouter le state focus (timer) et le handler focus
- main.go — ajouter les sous-commandes `focus` et `i3bar`
</code_context>
<specifics>
## Specific Ideas
- Le widget i3bar peut être un script que i3blocks/i3bar appelle périodiquement. Le script query le daemon via le socket Unix et formate la sortie.
- Le mode focus est un timer dans le daemon : timestamp d'expiration. Si `time.Now()` < expiration, pas de notification.
- Les noms courts dans le widget i3bar : label si défini, sinon dernier segment du cwd (ex: `/home/pierre/Code/vibe/vmux``vmux`).
</specifics>
<deferred>
## Deferred Ideas
None — discussion stayed within phase scope
</deferred>
---
*Phase: 04-notifications-et-i3bar*
*Context gathered: 2026-03-24*