@lamemind/loom-deck 0.31.0 → 0.33.0

package/README.md

@@ -2,28 +2,19 @@
 
 Deck TUI (Ink) **per-progetto** della famiglia [loom](https://github.com/lamemind/loom-works).
 
-Legge il `tasks.md` del progetto e, con un tasto (poi un click), **spawna** una tab
-[Ptyxis](https://gitlab.gnome.org/chergert/ptyxis) che avvia una sessione Claude Code
-già bound alla task via `LOOM_TASK`.
+Legge il `tasks.md` del progetto e, con un tasto (poi un click), **spawna** una tab [Ptyxis](https://gitlab.gnome.org/chergert/ptyxis) che avvia una sessione Claude Code già bound alla task via `LOOM_TASK`.
 
 ```
 ↑↓ scegli la task  →  ⏎  →  tab CC di fianco  →  LOOM_TASK bound
 ```
 
-`⏎` apre il **detail** della task — task file scrollabile più una barra azioni —
-e da lì si sceglie con quale prompt entrare; `^K`/`^P`/`^R` restano acceleratori
-per chi lo sa già (vedi [I cinque modi di entrare in una
-task](#i-cinque-modi-di-entrare-in-una-task)).
+`⏎` apre il **detail** della task — task file scrollabile più una barra azioni — e da lì si sceglie con quale prompt entrare; `^K`/`^P`/`^R` restano acceleratori per chi lo sa già (vedi [I cinque modi di entrare in una task](#i-cinque-modi-di-entrare-in-una-task)).
 
-Entrambi i prefissi del contratto loom entrano in lista: **`T`** (code task) e
-**`D`** (doc task). Il trattamento è identico ovunque tranne che su `^R`, dove il
-prompt dispatcha sulla skill di esecuzione della rispettiva famiglia.
+Entrambi i prefissi del contratto loom entrano in lista: **`T`** (code task) e **`D`** (doc task). Il trattamento è identico ovunque tranne che su `^R`, dove il prompt dispatcha sulla skill di esecuzione della rispettiva famiglia.
 
 ## Ruolo nella famiglia loom
 
-`loom-deck` è un **client** con runtime proprio (TUI Ink) che **consuma** il contratto
-definito da `loom-works-plugin` (formato `tasks.md`, variabile `LOOM_TASK`) — non lo
-ridefinisce. Divisione dei ruoli con Compass:
+`loom-deck` è un **client** con runtime proprio (TUI Ink) che **consuma** il contratto definito da `loom-works-plugin` (formato `tasks.md`, variabile `LOOM_TASK`) — non lo ridefinisce. Divisione dei ruoli con Compass:
 
 | | scope | ruolo | domanda |
 |---|---|---|---|
@@ -32,8 +23,7 @@ ridefinisce. Divisione dei ruoli con Compass:
 
 ## Architettura di processo
 
-Il deck è **UN processo Node**: spawna ma **non contiene** le sessioni CC — le possiede
-Ptyxis. Chiudere il deck non uccide le sessioni. La tab nasce nella window *attiva*
+Il deck è **UN processo Node**: spawna ma **non contiene** le sessioni CC — le possiede Ptyxis. Chiudere il deck non uccide le sessioni. La tab nasce nella window *attiva*
 (quella col focus = il deck) → desktop isolation "gratis".
 
 ## Stato
@@ -50,13 +40,13 @@ Bootstrap + spike ① + **TUI ③** funzionante (legge `tasks.md`, `⏎` apre il
 
 ## Standard shortcut
 
-Regola unica, senza eccezioni — pensata per reggere l'aggiunta di nuove azioni
-senza collisioni:
+Regola unica, senza eccezioni — pensata per reggere l'aggiunta di nuove azioni senza collisioni:
 
 | Tasto | Semantica | Note |
 |---|---|---|
 | `↑` `↓` | naviga nella lista | |
-| `←` `→` `tab` | cambia pane | |
+| `tab` | cambia pane | l'unico tasto che sposta il focus |
+| `←` `→` | cambia **vista** del pane a fuoco | ciclico; il catalogo è l'header stesso |
 | `⏎` | azione primaria del pane | Tasks → apre il **detail** della task selezionata · Sessions → riprende (`claude --resume`) la sessione selezionata |
 | **MAIUSCOLA** | **apre un modale** | cattura tutti i tasti; `esc` annulla, non esce |
 | minuscola | azione immediata, one-shot | |
@@ -64,12 +54,7 @@ senza collisioni:
 | `1`…`9` | voce `launch` n-esima del progetto | da `.claude/loom-works.json` |
 | `q` `esc` | esce dal deck | in un modale `esc` annulla soltanto |
 
-`CTRL` è il terzo livello, aggiunto quando è arrivata la ricerca. Serve perché
-un modale con **campi di testo** mangia ogni lettera nuda: là dentro nessun
-comando può essere una lettera semplice. `CTRL+X` e `x` nudo condividono lo
-stesso `input` e si distinguono solo per `key.ctrl`, quindi in modalità normale
-il ramo `CTRL` è valutato **per primo** e chiude l'intera classe — senza,
-`CTRL+F` cadrebbe nel ramo `f` e forkerebbe una sessione invece di cercare.
+`CTRL` è il terzo livello, aggiunto quando è arrivata la ricerca. Serve perché un modale con **campi di testo** mangia ogni lettera nuda: là dentro nessun comando può essere una lettera semplice. `CTRL+X` e `x` nudo condividono lo stesso `input` e si distinguono solo per `key.ctrl`, quindi in modalità normale il ramo `CTRL` è valutato **per primo** e chiude l'intera classe — senza, `CTRL+F` cadrebbe nel ramo `f` e forkerebbe una sessione invece di cercare.
 
 Assegnazioni correnti:
 
@@ -97,39 +82,20 @@ Il footer è **due righe con due nature diverse**:
 t 💻 · c 🤖 · 1 📝 codium · 2 ☕ idea
 ```
 
-- **tasti** — cosa puoi fare *qui e ora*. Solo le voci attive: quelle contestuali
-  compaiono quando il pane a fuoco le rende possibili e altrimenti spariscono,
+- **tasti** — cosa puoi fare *qui e ora*. Solo le voci attive: quelle contestuali compaiono quando il pane a fuoco le rende possibili e altrimenti spariscono,
   invece di mostrarsi inerti. Fuori navigazione (`↑↓` `←→`), uscita (`q`) e
-  indicatore `focus:` — le prime due sono universali in qualunque TUI, il pane a
-  fuoco si vede già dall'evidenziazione.
-- **surface** — *dove* puoi aprire qualcosa: prima le due built-in (`t`/`c`), poi
-  le voci `launch` del progetto. Stanno insieme perché hanno la stessa natura —
-  fire-once, `cwd` = project root, nessuno stato — e differiscono solo per essere
-  universali invece che custom.
-
-L'indice da solo è opaco (le `launch` sono custom per-progetto, senza una lettera
-fissa per app), quindi la riga espone la mappa e non il conteggio. Se non entrano
-in larghezza, si ferma a voci intere e mostra il contatore di quelle fuori riga —
-mai un troncamento silenzioso; le celle delle due built-in sono riservate a monte,
-o le voci sfonderebbero il box di quel tanto. Il cap a `9` è imposto dai
-tasti-cifra, non dallo schema: un progetto può dichiarare più di 9 voci, quelle
-oltre la nona sono configurate ma non raggiungibili (e la riga lo dice).
-
-Le emoji sono quelle del menu compass. Per il terminale compass usa 🖥️, che nel
-frame Ink non sopravvive: `sanitize` lo sostituisce perché VTE lo disegna largo 1
-mentre `string-width` ne conta 2 (invariante ① di `src/width.ts`) — 💻 è il
-gemello concorde.
-
-`t` e `c` sono gemelle: entrambe aprono una surface del cappello nella stessa
-finestra Ptyxis, senza passare da un modale. `c` (minuscola, azione) e `C`
-(maiuscola, modale create-task) restano distinte per la regola sopra — così come
-`f` (fork) e `F` (filtri).
+  indicatore `focus:` — le prime due sono universali in qualunque TUI, il pane a fuoco si vede già dall'evidenziazione.
+- **surface** — *dove* puoi aprire qualcosa: prima le due built-in (`t`/`c`), poi le voci `launch` del progetto. Stanno insieme perché hanno la stessa natura — fire-once, `cwd` = project root, nessuno stato — e differiscono solo per essere universali invece che custom.
+
+L'indice da solo è opaco (le `launch` sono custom per-progetto, senza una lettera fissa per app), quindi la riga espone la mappa e non il conteggio. Se non entrano in larghezza, si ferma a voci intere e mostra il contatore di quelle fuori riga — mai un troncamento silenzioso; le celle delle due built-in sono riservate a monte, o le voci sfonderebbero il box di quel tanto. Il cap a `9` è imposto dai tasti-cifra, non dallo schema: un progetto può dichiarare più di 9 voci, quelle oltre la nona sono configurate ma non raggiungibili (e la riga lo dice).
+
+Le emoji sono quelle del menu compass. Per il terminale compass usa 🖥️, che nel frame Ink non sopravvive: `sanitize` lo sostituisce perché VTE lo disegna largo 1 mentre `string-width` ne conta 2 (invariante ① di `src/width.ts`) — 💻 è il gemello concorde.
+
+`t` e `c` sono gemelle: entrambe aprono una surface del cappello nella stessa finestra Ptyxis, senza passare da un modale. `c` (minuscola, azione) e `C` (maiuscola, modale create-task) restano distinte per la regola sopra — così come `f` (fork) e `F` (filtri).
 
 ### I cinque modi di entrare in una task
 
-Sulla task selezionata (focus sul pane Tasks) si apre una sessione **bound**:
-`LOOM_TASK` iniettata, `sessionId` pinnato, binding scritto nel sidecar. Fra i
-modi cambia **solo il prompt iniziale**.
+Sulla task selezionata (focus sul pane Tasks) si apre una sessione **bound**: `LOOM_TASK` iniettata, `sessionId` pinnato, binding scritto nel sidecar. Fra i modi cambia **solo il prompt iniziale**.
 
 | Azione (detail) | Tasto diretto | Prompt |
 |---|---|---|
@@ -139,18 +105,11 @@ modi cambia **solo il prompt iniziale**.
 | `run` | `^R` | `/loom-works:run-task <id>`, oppure `/loom-works:run-doc <id>` se l'id è una `D` |
 | `checkpoint` | — | `/loom-works:checkpoint-task <id>` |
 
-Il prompt iniziale è la scelta di **chi apre**, non una proprietà della task: lo
-stesso task file si apre per leggerne lo stato, per congelarne le decisioni, per
-eseguirlo o per entrarci a mani nude — e l'azione scelta *è* quell'intento.
+Il prompt iniziale è la scelta di **chi apre**, non una proprietà della task: lo stesso task file si apre per leggerne lo stato, per congelarne le decisioni, per eseguirlo o per entrarci a mani nude — e l'azione scelta *è* quell'intento.
 
-Le due superfici sono complementari, non alternative. `⏎` apre il **detail** e lì
-si legge la Description *mentre* si decide: è il caso normale, perché la domanda
-«quale azione?» quasi sempre si risponde leggendo la task. I tre `CTRL` saltano
-il passaggio per chi lo sa già. Dentro il detail sono inerti — i bottoni sono lì.
+Le due superfici sono complementari, non alternative. `⏎` apre il **detail** e lì si legge la Description *mentre* si decide: è il caso normale, perché la domanda «quale azione?» quasi sempre si risponde leggendo la task. I tre `CTRL` saltano il passaggio per chi lo sa già. Dentro il detail sono inerti — i bottoni sono lì.
 
-Col focus sul pane Sessions né `⏎` né i `CTRL` spawnano: l'oggetto dell'azione è
-la task selezionata, e senza quel pane a fuoco non ce n'è una (il deck lo dice
-nella riga di nota, invece di aprire qualcosa a caso).
+Col focus sul pane Sessions né `⏎` né i `CTRL` spawnano: l'oggetto dell'azione è la task selezionata, e senza quel pane a fuoco non ce n'è una (il deck lo dice nella riga di nota, invece di aprire qualcosa a caso).
 
 ### `⏎` — il detail della task
 
@@ -159,43 +118,25 @@ Overlay fullscreen a due zone: il **task file per intero**, scrollabile
 navigabile con `←→`, con `open` a fuoco all'apertura. `⏎` esegue l'azione
 selezionata e chiude; `esc` chiude lasciando la lista con la stessa selezione.
 
-Le azioni non sono un catalogo nuovo: chiamano lo **stesso** percorso di spawn
-dei tasti diretti. Una superficie in più, zero percorsi di spawn in più.
+Le azioni non sono un catalogo nuovo: chiamano lo **stesso** percorso di spawn dei tasti diretti. Una superficie in più, zero percorsi di spawn in più.
 
-Sono bottoni affiancati e non voci di un menu verticale perché è la forma che
-sopravvive all'arrivo del mouse: un rettangolo ha già coordinate e area
-cliccabile, una lista di voci andrebbe rifatta.
+Sono bottoni affiancati e non voci di un menu verticale perché è la forma che sopravvive all'arrivo del mouse: un rettangolo ha già coordinate e area cliccabile, una lista di voci andrebbe rifatta.
 
-Dentro il detail `←→` non cambia più pane — il ramo `useInput` della modalità
-chiude prima di arrivare a quello di default. Ink non ha focus-trap: la cattura
-**è** l'ordine dei rami.
+Dentro il detail `←→` cicla i bottoni invece di cambiare la vista del pane — il
+ramo `useInput` della modalità chiude prima di arrivare a quello di default. Ink non ha focus-trap: la cattura **è** l'ordine dei rami, e cambiare cosa fa un tasto fuori dal detail non tocca cosa fa dentro.
 
-Il catalogo dei prompt vive in `scripts/deck-run`, non nella TUI: è il primitive
-UI-agnostico, il deck gli passa un **simbolo** (`--prompt-kind`) e non una
-stringa. Così il testo sta in un posto solo, e con lui il suo vincolo di quoting
-— il prompt viaggia dentro apici singoli in `bash -lc`, quindi non può contenerne.
+Il catalogo dei prompt vive in `scripts/deck-run`, non nella TUI: è il primitive UI-agnostico, il deck gli passa un **simbolo** (`--prompt-kind`) e non una stringa. Così il testo sta in un posto solo, e con lui il suo vincolo di quoting — il prompt viaggia dentro apici singoli in `bash -lc`, quindi non può contenerne.
 
 ### `f` — forkare una conversazione
 
-Il fork rama la sessione selezionata: `claude --resume <origine> --fork-session`
-apre un **sessionId nuovo** con il transcript copiato, lasciando l'origine
-intatta. Serve quando vuoi ripartire da un certo stato senza perdere il ramo
-originale — e siccome i due id sono distinti, non esistono mai due processi che
-scrivono lo stesso file (il vincolo *single-writer* dello store di Claude Code).
+Il fork rama la sessione selezionata: `claude --resume <origine> --fork-session` apre un **sessionId nuovo** con il transcript copiato, lasciando l'origine intatta. Serve quando vuoi ripartire da un certo stato senza perdere il ramo originale — e siccome i due id sono distinti, non esistono mai due processi che scrivono lo stesso file (il vincolo *single-writer* dello store di Claude Code).
 
 Il nuovo id lo genera il deck e lo pinna con `--session-id`, per due ragioni:
 
-- il ramo **eredita la task** dell'origine (senza id noto in anticipo il fork
-  di una sessione scoped comparirebbe come spot);
-- il **lineage** finisce nel sidecar `.claude/loom/session-tasks.jsonl` come
-  campo `forkOf`. Serve perché il transcript del fork **non nomina** la sessione
-  d'origine da nessuna parte: è una copia verbatim (stessi uuid dei messaggi) e
-  `parentUuid` incatena i messaggi dentro un transcript, non le sessioni fra
-  loro. Senza quel record un ramo sarebbe una riga gemella dell'originale, di
-  cui eredita anche il titolo.
+- il ramo **eredita la task** dell'origine (senza id noto in anticipo il fork di una sessione scoped comparirebbe come spot);
+- il **lineage** finisce nel sidecar `.claude/loom/session-tasks.jsonl` come campo `forkOf`. Serve perché il transcript del fork **non nomina** la sessione d'origine da nessuna parte: è una copia verbatim (stessi uuid dei messaggi) e `parentUuid` incatena i messaggi dentro un transcript, non le sessioni fra loro. Senza quel record un ramo sarebbe una riga gemella dell'originale, di cui eredita anche il titolo.
 
-Un ramo si riconosce dal marker `⑂` nella lista e dalla riga `⑂ da <id>` nel
-pannello di dettaglio; la sua tab Ptyxis titola `<label> · <task> · fork`.
+Un ramo si riconosce dal marker `⑂` nella lista e dalla riga `⑂ da <id>` nel pannello di dettaglio; la sua tab Ptyxis titola `<label> · <task> · fork`.
 
 > **Nota di migrazione (0.6.0)**: `c` → **`C`** per creare una task, e le voci
 > `codium`/`idea` non hanno più una lettera dedicata (erano `C`/`I` hardcoded):
@@ -203,20 +144,14 @@ pannello di dettaglio; la sua tab Ptyxis titola `<label> · <task> · fork`.
 
 ### `^F` — cercare dentro le conversazioni
 
-Il navigator trova una conversazione per **metadati** (titolo, data, turni). `^F`
-la trova per **contenuto**: «l'IA me l'ha detto 150k di testo fa, ricordo mezza
-parola». Claude Code non ha un find-in-conversation, ma i transcript sono tutti
-su disco e il deck li legge già.
+Il navigator trova una conversazione per **metadati** (titolo, data, turni). `^F` la trova per **contenuto**: «l'IA me l'ha detto 150k di testo fa, ricordo mezza parola». Claude Code non ha un find-in-conversation, ma i transcript sono tutti su disco e il deck li legge già.
 
 Due campi, `tab` per passare dall'uno all'altro:
 
-- **hash** — prefisso del `sessionId` (gli 8 char della statusline bastano),
-  restringe a una conversazione. Vuoto = **tutte** quelle del progetto.
-- **chiave** — il termine cercato. La ricerca è **eager**: si aggiorna a ogni
-  carattere, da 3 in su.
+- **hash** — prefisso del `sessionId` (gli 8 char della statusline bastano), restringe a una conversazione. Vuoto = **tutte** quelle del progetto.
+- **chiave** — il termine cercato. La ricerca è **eager**: si aggiorna a ogni carattere, da 3 in su.
 
-Sei toggle, tutti su `CTRL` perché i campi di testo occupano le lettere nude.
-Lo stato si legge da `[x]`/`[ ]`, non dal solo colore:
+Sei toggle, tutti su `CTRL` perché i campi di testo occupano le lettere nude. Lo stato si legge da `[x]`/`[ ]`, non dal solo colore:
 
 | Tasto | Toggle | Default |
 |---|---|---|
@@ -227,42 +162,21 @@ Lo stato si legge da `[x]`/`[ ]`, non dal solo colore:
 | `^T` | cerca nei **tool** (`tool_use` / `tool_result`) | off |
 | `^U` | cerca nei prompt **umani** | off |
 
-Non esiste un toggle *thinking*: quei blocchi sono persistiti **senza testo**
-(il transcript porta la sola firma crittografica), quindi sarebbe una casella
-che non può mai produrre un risultato.
+Non esiste un toggle *thinking*: quei blocchi sono persistiti **senza testo** (il transcript porta la sola firma crittografica), quindi sarebbe una casella che non può mai produrre un risultato.
 
-Con l'hash vuoto la lista è **raggruppata per conversazione**; `⏎` è contestuale
-alla riga selezionata — su una riga-conversazione **riprende** la sessione
-(come dal pane Sessions), su una riga-occorrenza apre il **reader**. La selezione
-parte dalla prima *occorrenza*, non dalla riga di gruppo: quella è un segnaposto
-di navigazione, raggiungibile con le frecce ma non una destinazione.
+Con l'hash vuoto la lista è **raggruppata per conversazione**; `⏎` è contestuale alla riga selezionata — su una riga-conversazione **riprende** la sessione (come dal pane Sessions), su una riga-occorrenza apre il **reader**. La selezione parte dalla prima *occorrenza*, non dalla riga di gruppo: quella è un segnaposto di navigazione, raggiungibile con le frecce ma non una destinazione.
 
-L'estratto attorno al match **si allarga col terminale**: a 190 colonne sono
-~170 caratteri di contesto, non i 50 di un valore fisso — ed è il contesto la
-ragione per cui si legge la riga invece di aprire il reader.
+L'estratto attorno al match **si allarga col terminale**: a 190 colonne sono ~170 caratteri di contesto, non i 50 di un valore fisso — ed è il contesto la ragione per cui si legge la riga invece di aprire il reader.
 
-Sotto la lista, un **pannello di anteprima** mostra il contesto attorno
-all'occorrenza selezionata e si aggiorna navigando con le frecce. Prende solo le
-righe che la lista non usa: con pochi risultati riempie il terminale, con molti
-sparisce e la lista se le riprende — quando c'è tanto da scorrere la priorità è
-vedere più occorrenze, il contesto è il premio per una ricerca già stretta.
+Sotto la lista, un **pannello di anteprima** mostra il contesto attorno all'occorrenza selezionata e si aggiorna navigando con le frecce. Prende solo le righe che la lista non usa: con pochi risultati riempie il terminale, con molti sparisce e la lista se le riprende — quando c'è tanto da scorrere la priorità è vedere più occorrenze, il contesto è il premio per una ricerca già stretta.
 
 Il reader mostra il messaggio intero, aperto già **posizionato sull'occorrenza**
 col match evidenziato: `↑↓` riga, `PgUp`/`PgDn` pagina, `g`/`G` estremi, `esc`
-torna alla lista senza perdere query, toggle e selezione. (Gli estremi stanno su
-lettera e non su `Home`/`End` perché Ink non espone quei due tasti: arrivano
-indistinguibili da qualunque tasto ignoto.)
+torna alla lista senza perdere query, toggle e selezione. (Gli estremi stanno su lettera e non su `Home`/`End` perché Ink non espone quei due tasti: arrivano indistinguibili da qualunque tasto ignoto.)
 
-I toggle e la query sono **volatili**: sopravvivono alla chiusura del modale,
-non al riavvio del deck — comporre una ricerca non tocca il disco.
+I toggle e la query sono **volatili**: sopravvivono alla chiusura del modale, non al riavvio del deck — comporre una ricerca non tocca il disco.
 
-**Come fa a essere istantanea.** I corpi dei messaggi restano in RAM dentro la
-cache mtime-keyed che il deck usa già per la lista sessioni: quei file venivano
-comunque deserializzati per turni e titoli, e i corpi buttati. Trattenerli non
-aggiunge I/O, aggiunge memoria — e ne aggiunge poca, perché un JSONL è per l'85%
-overhead (misurato su un progetto reale: 57 MB su disco = 9,8 MB di testo
-cercabile). Cercarci dentro costa 1-9 ms; un prefiltro `grep` sugli stessi file
-ne costerebbe 26, perché rileggerebbe il volume pieno a ogni battuta.
+**Come fa a essere istantanea.** I corpi dei messaggi restano in RAM dentro la cache mtime-keyed che il deck usa già per la lista sessioni: quei file venivano comunque deserializzati per turni e titoli, e i corpi buttati. Trattenerli non aggiunge I/O, aggiunge memoria — e ne aggiunge poca, perché un JSONL è per l'85% overhead (misurato su un progetto reale: 57 MB su disco = 9,8 MB di testo cercabile). Cercarci dentro costa 1-9 ms; un prefiltro `grep` sugli stessi file ne costerebbe 26, perché rileggerebbe il volume pieno a ogni battuta.
 
 ## Vista: filtri e ordinamenti
 
@@ -279,26 +193,44 @@ p  priorità     s  stato     i  id
 Partendo da catena vuota, digitare `ppi` produce `[pri ↓, id ↑]`. Il ciclo parte
 sempre **dallo stato corrente**, che il modale mostra dal vivo mentre digiti.
 
-Sull'**id** il confronto è numerico (`T9` prima di `T10`, non lessicografico) e i
-due prefissi sono blocchi distinti — le `D` in coda alle `T`: i counter `T` e `D`
-sono separati nel contratto loom, quindi `T01` e `D01` non sono confrontabili
-come numeri soli.
-A parità su tutte le chiavi decide sempre l'`id` (confronto **numerico**: `T9`
+Sull'**id** il confronto è numerico (`T9` prima di `T10`, non lessicografico) e i due prefissi sono blocchi distinti — le `D` in coda alle `T`: i counter `T` e `D` sono separati nel contratto loom, quindi `T01` e `D01` non sono confrontabili come numeri soli. A parità su tutte le chiavi decide sempre l'`id` (confronto **numerico**: `T9`
 prima di `T10`) → l'ordine è deterministico, mai instabile fra un refresh e l'altro.
 
 **`F` — filtri.** Un toggle per ogni priorità e per ogni stato, componibili in AND.
 `↑↓` cambia riga, `←→` scorre i valori, `spazio` mostra/nasconde.
 
-In entrambi i modali la lista si aggiorna **dal vivo**; `⏎` conferma, `esc`
-ripristina la vista com'era all'apertura.
+In entrambi i modali la lista si aggiorna **dal vivo**; `⏎` conferma, `esc` ripristina la vista com'era all'apertura.
 
-Con un filtro attivo l'header dichiara sempre quanto sta nascondendo
-(`Tasks (9/25) · 16 nascoste`): il deck non finge mai una lista completa.
+Con un filtro attivo l'header dichiara sempre quanto sta nascondendo (`Tasks (9/25) · 16 nascoste`): il deck non finge mai una lista completa.
 
-**Persistenza.** La vista non si salva da sola — sperimentare non sporca nulla.
-`w` la scrive in `.claude/loom/deck-view.json` (macchina-locale, da gitignorare)
+**Persistenza.** La vista non si salva da sola — sperimentare non sporca nulla. `w` la scrive in `.claude/loom/deck-view.json` (macchina-locale, da gitignorare)
 e al riavvio viene ripristinata. File assente o corrotto → default puliti.
 
+## L'header è un selettore di vista
+
+Ogni segmento dell'header nomina un sottoinsieme che il deck sa già calcolare.
+`←`/`→` lo rendono **raggiungibile**: la voce attiva si evidenzia in video
+inverso e la lista sotto mostra quel sottoinsieme.
+
+```
+Tasks (20/78) · 58 nascoste · 23 archiviabili · ↑7 · ↓9
+Sessions · tutte (317) · ●2 vive · 📌4 · +213 più vecchie · ↑7 · ↓9
+```
+
+| Pane | Viste |
+|---|---|
+| Tasks | `Tasks (n/N)` (filtri applicati) · `N nascoste` (il complemento esatto di quei filtri) · `N archiviabili` (Done oltre `archivableDays`, cieca ai filtri) |
+| Sessions | `{parent} (N)` · `●N vive` · `📌N` · `+N più vecchie` (le contestuali che il cap `maxContext` tronca) |
+
+- **Il catalogo è fisso**, anche a contatore 0 (la voce si mostra dim). Un catalogo che si accorcia sposta le voci sotto le dita, e la vista corrente può svanire mentre la guardi — togliere un filtro mentre sei su `nascoste`.
+- **`↑N` `↓N` non sono viste**: contano elementi fuori finestra per altezza del
+  terminale, cioè una posizione, non un insieme. Restano in coda, non selezionabili.
+- **Due assi ortogonali**: il pane task sceglie il *parent* delle conversazioni (`≡ tutte` / `○ spot` / una task), l'header sceglie *quale sottoinsieme* di quel parent. Cambiare parent non azzera la vista, che si ricalcola dentro il nuovo.
+- **`F` è inerte fuori dalla vista `Tasks`** e lo dice con una nota: su `nascoste` riapplicare i filtri non ha senso, `archiviabili` è cieca per scelta.
+- **La vista è volatile**: non entra in `deck-view.json`, il deck riapre sempre sulla voce 1. Un filtro salvato lo si è scelto; una vista non-default riaperta a freddo si leggerebbe come la lista intera.
+- **Cambiare vista riporta la selezione in cima**, righe meta comprese: nessuna regola di mantenimento, nessun tentativo di ritrovare l'elemento precedente.
+- Su un terminale stretto **la voce attiva è servita per prima** dal budget di larghezza: sparisce un contatore, mai la voce che dice dove sei.
+
 ## Installazione
 
 ```bash
@@ -310,9 +242,7 @@ npx @lamemind/loom-deck
 ## Requisiti runtime
 
 - **Node.js ≥ 18** (dichiarato in `engines`).
-- **[Ptyxis](https://gitlab.gnome.org/chergert/ptyxis)** (terminale GNOME) — **dipendenza
-  di runtime, non risolvibile da npm**. Lo spawn di una tab (`scripts/deck-run`) invoca il
-  binario `ptyxis`: l'**install riesce anche senza**, ma al momento dello spawn il comando
+- **[Ptyxis](https://gitlab.gnome.org/chergert/ptyxis)** (terminale GNOME) — **dipendenza di runtime, non risolvibile da npm**. Lo spawn di una tab (`scripts/deck-run`) invoca il binario `ptyxis`: l'**install riesce anche senza**, ma al momento dello spawn il comando
   fallisce (gestito: handler `error` → la TUI resta viva, mostra la nota). Senza una GUI
   GNOME con Ptyxis installato, il deck naviga i task ma **non apre sessioni**.
 - **[Claude Code](https://claude.com/claude-code)** nel `PATH` — la tab spawnata avvia `claude`.
@@ -325,19 +255,9 @@ scripts/deck-run T18
 scripts/deck-run T18 --prompt-kind none|recap|preflight|run|checkpoint
 ```
 
-Apre una tab Ptyxis nella window attiva con `LOOM_TASK=T18 claude 'recap stato task T18'`.
-Il prompt iniziale è il terzo asse dello spawn, ortogonale al binding task
-(`<TaskID>` vs `--no-task`) e alla continuità (nuova vs `--resume`/`--fork`):
-senza flag resta `recap`, `none` apre la sessione bound **senza** alcun prompt.
-`LOOM_DECK_ENTER_PROMPT` (placeholder `{TASK}`) resta un override che vince sul
-kind — tranne su `none`, che è una richiesta esplicita di non averne.
-
-La tab porta anche `PTYXIS_PROFILE` forzata al profilo bindato al progetto nel
-registry (`bindings/claude`), letto da dconf: è la chiave con cui loom-compass
-associa a un progetto lo stato annunciato dagli hook (running/ask/done). Una tab
-`ptyxis --tab` nuda erediterebbe il profilo di default, e l'annuncio finirebbe
-keyed su un UUID che nessun progetto dichiara — pallino fermo su idle, senza
-alcun errore visibile. Override o disattivazione via `LOOM_DECK_STATE_PROFILE`
+Apre una tab Ptyxis nella window attiva con `LOOM_TASK=T18 claude 'recap stato task T18'`. Il prompt iniziale è il terzo asse dello spawn, ortogonale al binding task (`<TaskID>` vs `--no-task`) e alla continuità (nuova vs `--resume`/`--fork`): senza flag resta `recap`, `none` apre la sessione bound **senza** alcun prompt. `LOOM_DECK_ENTER_PROMPT` (placeholder `{TASK}`) resta un override che vince sul kind — tranne su `none`, che è una richiesta esplicita di non averne.
+
+La tab porta anche `PTYXIS_PROFILE` forzata al profilo bindato al progetto nel registry (`bindings/claude`), letto da dconf: è la chiave con cui loom-compass associa a un progetto lo stato annunciato dagli hook (running/ask/done). Una tab `ptyxis --tab` nuda erediterebbe il profilo di default, e l'annuncio finirebbe keyed su un UUID che nessun progetto dichiara — pallino fermo su idle, senza alcun errore visibile. Override o disattivazione via `LOOM_DECK_STATE_PROFILE`
 (settata a vuoto → nessun annuncio); progetto non registrato → nessun prefisso.
 
 ## Sviluppo (TUI Ink)
@@ -349,12 +269,9 @@ npm run build    # tsc → dist/
 npm test         # node:test sul core vista (src/view.ts), senza Ink né terminale
 ```
 
-Il core di filtri e ordinamenti (`src/view.ts`) è **puro**: nessun import da Ink o
-React, nessun I/O. È il motivo per cui è testabile con `node:test` su array
-fixture, mentre la TUI resta un guscio sottile che lo consuma.
+Il core di filtri e ordinamenti (`src/view.ts`) è **puro**: nessun import da Ink o React, nessun I/O. È il motivo per cui è testabile con `node:test` su array fixture, mentre la TUI resta un guscio sottile che lo consuma.
 
-Il deck cerca `tasks.md` in `$PWD/${LOOM_DECK_DOCS_ROOT:-docs}/tasks.md`. Progetti
-con docs-root non-standard esportano la variabile, es. `LOOM_DECK_DOCS_ROOT=runtime`.
+Il deck cerca `tasks.md` in `$PWD/${LOOM_DECK_DOCS_ROOT:-docs}/tasks.md`. Progetti con docs-root non-standard esportano la variabile, es. `LOOM_DECK_DOCS_ROOT=runtime`.
 
 La lista si **auto-aggiorna** quando `tasks.md` cambia sotto (poll su `mtime`, ~1.5s):
 crei/checkpoint una task da un'altra sessione → il deck la riflette senza riavvio.

package/dist/archivable.js

@@ -106,17 +106,23 @@ async function gitOut(args, cwd) {
     }
 }
 /**
- * Quante fra le task Done passate sono oltre soglia. Le indeterminate (nessuno
+ * Quali fra le task Done passate sono oltre soglia. Le indeterminate (nessuno
  * dei tre gradini risolve) e le righe orfane (Done in tasks.md ma task file
- * assente) NON entrano nel conteggio: il deck non chiama "vecchia" una task di
- * cui non sa l'età.
+ * assente) NON entrano: il deck non chiama "vecchia" una task di cui non sa
+ * l'età.
  *
  * Riceve gli id già filtrati sul glifo Done invece della lista completa: lo
  * scan resta così proporzionale al vecchiume, non alla lunghezza della lista.
+ *
+ * T100 — ritorna gli ID e non più il solo conteggio: `archiviabili` è diventata
+ * una vista navigabile del pane task, e il numero da solo non basta più a
+ * disegnarne le righe. Il contatore dell'header è la lunghezza della lista, così
+ * ciò che si conta e ciò che si mostra restano lo stesso insieme per
+ * costruzione.
  */
-export async function countArchivable(doneIds, opts) {
+export async function archivableIds(doneIds, opts) {
     const now = opts.now ?? Date.now();
-    let n = 0;
+    const out = [];
     for (const id of doneIds) {
         const taskFile = findTaskFile(opts.tasksDir, id);
         if (!taskFile)
@@ -133,7 +139,7 @@ export async function countArchivable(doneIds, opts) {
             continue;
         const age = ageDays(iso, now);
         if (age !== null && age >= opts.days)
-            n++;
+            out.push(id);
     }
-    return n;
+    return out;
 }