@lamemind/loom-deck 0.66.1 → 0.68.0

package/README.md

@@ -74,7 +74,7 @@ Regola unica, senza eccezioni — pensata per reggere l'aggiunta di nuove azioni
 | `⏎` | 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 | |
-| `CTRL`+lettera | idiomi universali, toggle dentro i modali di testo, varianti di un'azione | `^F` = find, come ovunque · `^K`/`^P`/`^R` = spawn con un altro prompt · `^G`/`^O` = genera/apri il project status · `^U` = update del gitlink |
+| `CTRL`+lettera | idiomi universali, toggle dentro i modali di testo, varianti di un'azione | `^F` = find, come ovunque · `^K`/`^P`/`^R` = spawn con un altro prompt · `^G`/`^O` = genera/apri il project status · `^U` = update del gitlink · `^S` = pagina delle azioni di spawn |
 | `1`…`9` | voce `launch` n-esima del progetto | da `.claude/loom-works.json` |
 | `esc` | chiude l'overlay aperto | in modalità normale è inerte: **nessuna lettera chiude il deck** |
 | `^C` `^C` | chiude il deck | la prima pressione avverte in riga di stato, la seconda entro **5 secondi** esce; passata la finestra si riparte dall'avviso. Da dentro un modale il primo `^C` riporta alla lista — l'avviso vive nella riga di stato, che le schermate a pieno frame non disegnano |
@@ -95,6 +95,7 @@ Assegnazioni correnti:
 | modale | `⏎` | **detail** della task selezionata: task file scrollabile + area di compilazione a quattro righe |
 | modale | `CANC` | **elimina** — la task selezionata; su una riga meta della vista `archiviabili`, l'intero insieme |
 | modale | `^O` | apre il **project status** in cache (viewer fullscreen) |
+| modale | `^S` | **azioni di spawn**: la tabella di tutto ciò che il deck apre, con titolo/modello/prompt configurabili per progetto |
 | immediata | `^G` | **genera** il project status (skill headless, dura minuti) |
 | immediata | `^U` | **bumpa il gitlink** dei submodule idonei (solo su un progetto con `.gitmodules`) |
 | immediata | `^K` | spawna la task selezionata col prompt di **recap** |
@@ -109,7 +110,7 @@ Assegnazioni correnti:
 Il footer è **due righe con due nature diverse**:
 
 ```
-⏎ detail · ^K/^P/^R spawn · ^G genera status · ^O apri status · ^U bumpa gitlink · ^F cerca · C nuova · E edit · S sort · F filtri · w salva
+⏎ detail · ^K/^P/^R spawn · ^G genera status · ^O apri status · ^U bumpa gitlink · ^S azioni · ^F cerca · C nuova · E edit · S sort · F filtri · w salva
 t 💻 · c 🤖 · 1 📝 codium · 2 ☕ idea
 ```
 
@@ -161,42 +162,57 @@ Da qui la forma della conferma: nomina il bersaglio (quante e quali ID, troncand
 
 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 |
+| Azione (detail) | Tasto diretto | Prompt di default |
 |---|---|---|
 | `open` | — | nessuno — il contesto lo carica l'hook `SessionStart`, il primo messaggio lo scrivi tu |
-| `status` | `^K` | `recap stato task <id>` — prompt diretto, nessuna skill |
+| `status` | `^K` | `/loom-works:recap-status <id>`, che dal detail si specializza in `-task` o `-epic` |
 | `preflight` | `^P` | `/loom-works:preflight-task <id>` |
-| `run` | `^R` | `/loom-works:run-task <id>`, oppure `/loom-works:run-doc <id>` se l'id è una `D` |
+| `run` | `^R` | `/loom-works:run-task <id>` |
 | `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.
 
+Sono **default**, non costanti: titolo, modello e prompt di ognuna di queste azioni si riscrivono dalla pagina `^S` e si salvano nel progetto (§`^S` — le azioni di spawn sotto).
+
 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).
 
 ### `⏎` — il detail della task
 
-Overlay fullscreen a due zone: il **task file per intero**, scrollabile con `PgUp`/`PgDn`, e sotto un'**area di compilazione** a quattro righe — i quattro parametri con cui la sessione sta per nascere.
+Overlay fullscreen a due zone: il **task file per intero**, scrollabile con `PgUp`/`PgDn`, e sotto un'**area di compilazione** a cinque righe — i parametri con cui la sessione sta per nascere.
 
 | Riga | Cosa | Come si cambia |
 |---|---|---|
 | `azione` | `open` `preflight` `run` `status` `checkpoint` | `←→`, oppure l'iniziale: `o` `p` `r` `s` `c` |
 | `prompt` | il testo che riceverà la sessione | si scrive; parte pre-riempito dall'azione scelta |
 | `modello` | `fable` `opus` `sonnet` `haiku` | `←→` |
-| `titolo` | il nome della conversazione, in lista e nella tab | si scrive |
+| `titolo` | il nome della conversazione, in lista e nella tab | si scrive; parte pre-riempito col template dell'azione, reso su questa task |
+| `priorità` | la conversazione nasce già marcata | `←→` |
 
-`↑↓` spostano il fuoco fra le righe, `⏎` spawna coi quattro valori correnti, `esc` chiude lasciando la lista con la stessa selezione. Le righe di testo ricevono i caratteri **solo quando sono in fuoco**: su `azione` una lettera che non è un'iniziale resta inerte invece di finire in un campo.
+`↑↓` spostano il fuoco fra le righe, `⏎` spawna coi valori correnti, `esc` chiude lasciando la lista con la stessa selezione. Le righe di testo ricevono i caratteri **solo quando sono in fuoco**: su `azione` una lettera che non è un'iniziale resta inerte invece di finire in un campo.
 
 `↑↓` sono quindi una risorsa contesa, e vanno al fuoco: la lettura del task file resta su `PgUp`/`PgDn`, cioè una granularità sola invece di due. È il prezzo di avere `↑↓` nel loro significato di sempre su una schermata che ospita insieme un documento e dei campi.
 
-**Il campo `prompt` è quello che parte davvero**, non un'anteprima: modificarlo cambia il messaggio che la sessione riceve. Cambiare azione lo riscrive col default della nuova — col fuoco per riga il cambio accidentale non esiste (`←→` toccano l'azione solo dalla sua riga), quindi non c'è nessuna modifica da proteggere.
+**I tre campi mostrano quello che parte davvero**, non un'anteprima: modificarli cambia il comando. Cambiare azione li riscrive coi default della nuova — col fuoco per riga il cambio accidentale non esiste (`←→` toccano l'azione solo dalla sua riga), quindi non c'è nessuna modifica da proteggere. Un campo titolo svuotato a mano significa **nessuna nota**: il default è già a schermo, quindi non c'è nessun fallback invisibile da far scattare.
 
 La grammatica delle righe è la **stessa** del modale edit (`SHIFT+E`) e sta in `src/fields.ts`: descrittore delle righe, fuoco, caret, `^A`/`^E`/`^D`/`^U`. Finché era scritta due volte andava tenuta allineata a mano a ogni tasto aggiunto. `Home`/`End` non ci sono e non possono esserci: `useInput` non le espone — verificato su otto sequenze diverse, arrivano tutte come input vuoto senza flag — da cui `^A`/`^E`.
 
 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.
 
-Il **testo** dei prompt vive in `scripts/prompt-catalog`, un file dati sibling di `deck-run` che entrambi leggono a runtime: il deck per pre-riempire il campo, `deck-run` per comporre il comando in-tab. Come codice posseduto da un lato solo il deck avrebbe dovuto riscriverlo per mostrarlo, e le due copie divergerebbero alla prima voce aggiunta da una parte sola. Un prompt modificato a mano viaggia poi letterale (`--prompt`), perché a quel punto nessun `--prompt-kind` lo descrive più.
+Il **testo** dei prompt vive in `scripts/prompt-catalog`, un file dati sibling di `deck-run` che entrambi leggono a runtime: il deck per pre-riempire il campo, `deck-run` per comporre il comando in-tab quando lo si invoca a mano. Come codice posseduto da un lato solo il deck avrebbe dovuto riscriverlo per mostrarlo, e le due copie divergerebbero alla prima voce aggiunta da una parte sola. Dal deck il prompt viaggia comunque **letterale** (`--prompt`), su ogni percorso: la risoluzione — default cablato, riga del catalogo dati, override di progetto — sta tutta da questo lato, e un simbolo non saprebbe più descrivere il testo che ne esce.
+
+### `^S` — le azioni di spawn
+
+Una pagina fullscreen con **una riga per ogni cosa che il deck sa aprire** e quattro colonne: funzione, titolo, modello, prompt. Le ultime tre si modificano, e `w` scrive il blocco `spawn` di `.claude/loom-works.json` — committato, quindi la configurazione viaggia col repo.
+
+Due livelli: `↑↓` scorrono la tabella, `⏎` apre sotto di essa l'area di compilazione della riga selezionata (la stessa grammatica del detail), `⏎` conferma in memoria, `esc` annulla. `CANC` toglie l'override di una riga e la riporta al default; comporre non tocca il disco finché non si preme `w`.
+
+Le celle portano il **template grezzo**, coi buchi ancora dentro — `📐 {slug}`, `📏 {path}` — e l'area mostra accanto l'esempio reso: un valore già interpolato si modificherebbe a partire da un esempio, e ogni modifica cancellerebbe il buco senza dirlo. Una riga con almeno un override si marca con `◆`.
+
+Non tutte le celle esistono per tutte le righe, e quelle che non esistono **dicono perché** invece di restare vuote: la sessione nuda non pinna un `sessionId` e quindi non ha un titolo, il project status gira headless e non apre nessuna tab, il prompt del drain è una funzione della natura del file inbox. Resume e fork non hanno una riga affatto — il loro modello è ereditato dalla conversazione d'origine, non una preferenza.
+
+Un file assente, illeggibile o con una voce sbagliata non rompe niente: il deck parte sui default e lo dice in riga di stato, una voce alla volta.
 
 ### `f` — forkare una conversazione
 

package/dist/actions.js

@@ -15,16 +15,19 @@
 // `test/modes-smoke.test.ts` (`seleziona una task`, `terminale su`, `deck-run`,
 // `nessun push`, `eliminare N task?`, `scartate`): si copiano verbatim, non si
 // migliorano di passaggio.
-import { useMemo, useRef } from 'react';
+import { useRef } from 'react';
 import { randomUUID } from 'node:crypto';
-import { loadPromptCatalog, modelFor } from './prompt-catalog.js';
+import { taskSlug } from './tasks.js';
 import { appendNote, appendPin, appendPriority, appendSessionRecord, appendTaskBinding, } from './task-index.js';
 import { neighborId } from './session-list.js';
 import { cut, cutMiddle } from './width.js';
 import { saveView, viewFilePath } from './view-store.js';
-import { onInTabCommand, runLaunch, spawnClaudeEmpty, spawnBare, spawnDeck, spawnDeckFork, spawnDeckResume, spawnTerminal, fallbackTitle, DECK_RUN, MODEL_DEFAULT, } from './spawn.js';
+import { onInTabCommand, runLaunch, spawnClaudeEmpty, spawnBare, spawnDeck, spawnDeckFork, spawnDeckResume, spawnTerminal, DECK_RUN, } from './spawn.js';
+import { resolveSpawnId } from './spawn-config.js';
 import { useTaskOps } from './task-ops.js';
-export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNote, }) {
+import { inboxWords } from './inbox.js';
+import { wrapWords } from './wrap-scan.js';
+export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, overrides, catalog, setNote, }) {
     // La riga di stato di OGNI spawn di sessione Claude: il comando esatto, come
     // lo si scriverebbe in bash, invece di una parafrasi.
     //
@@ -58,9 +61,6 @@ export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNo
     // prima dell'exec), ed è anche il comando da ripetere a mano per vedere
     // l'errore. Il salto fra le due dura i millisecondi che `deck-run` impiega a
     // comporre.
-    // T152 — stessa fonte del detail (sheet.ts): un file di sei righe accanto al
-    // codice, letto una volta per vita del deck.
-    const catalog = useMemo(() => loadPromptCatalog(), []);
     const spawnSeq = useRef(0);
     function noteSpawn(spawned) {
         noteCommand(spawned.cmd);
@@ -74,6 +74,35 @@ export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNo
                 noteCommand(inTab);
         });
     }
+    /**
+     * T161 — la TERNA di un'azione: default del deck ← override di progetto, coi
+     * buchi già riempiti.
+     *
+     * Un punto solo. Prima di questa task ogni sede di chiamata sceglieva da sé —
+     * `MODEL_DEFAULT` dentro `drainInbox`, `'sonnet'` dentro `unwrapPath`,
+     * `modelFor(catalog, kind)` dentro `spawnTaskSession`, `PROJECT_STATUS_MODEL`
+     * dentro `spawnProjectStatus` — e nessuna delle quattro poteva essere
+     * indirizzata da una configurazione, perché non esisteva un nome con cui
+     * nominarla.
+     */
+    function spawnDefaults(id, holes = {}) {
+        return resolveSpawnId(id, overrides, catalog, holes);
+    }
+    /** I buchi di un'azione su task. Lo slug viene dal NOME del task file, non
+     *  dalla descrizione di `tasks.md`: il nome è già dentro l'alfabeto di
+     *  `_sane_note` per costruzione — minuscolo, separato da trattini, senza
+     *  punteggiatura — mentre la descrizione porta apostrofi e `/` che la riduzione
+     *  toglie senza sostituto, saldando le parole. Task file assente → slug vuoto,
+     *  e il titolo si spegne invece di ridursi al solo prefisso. */
+    function taskHoles(id) {
+        return { TASK: id, slug: taskSlug(tasksDir, id) };
+    }
+    /** La terna di un'azione SU UNA TASK, per chi ha in mano l'id e non i buchi:
+     *  il detail. Derivare i buchi dal chiamante sarebbe la seconda copia della
+     *  regola, e diverge il giorno che un template ne guadagna uno terzo. */
+    function spawnTaskDefaults(id, taskId) {
+        return spawnDefaults(id, taskHoles(taskId));
+    }
     // T66 — la guardia dello spawn bound, con due chiamanti: gli acceleratori
     // della lista e l'apertura del detail. Le tre uscite sono le stesse (pane
     // sbagliato, riga meta, task sparita), e duplicarle vorrebbe dire tenerne
@@ -114,9 +143,9 @@ export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNo
     // nomi diversi per la stessa conversazione. Vale anche sugli acceleratori
     // della lista (^K/^P/^R), che passano di qui con `spawnNote` sul proprio
     // default '' (P1 preflight) — nascono quindi titolati anche loro.
-    function spawnForTask(id, kind, modelKind, spawnNote = '', prompt, priority = false) {
+    function spawnForTask(id, modelKind, spawnNote = '', prompt = '', priority = false) {
         const sid = randomUUID();
-        const note = spawnNote || fallbackTitle(tasksDir, id, kind) || '';
+        const note = spawnNote;
         appendTaskBinding(cwd, sid, id);
         if (note)
             appendNote(cwd, sid, note);
@@ -129,7 +158,7 @@ export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNo
         // riempirebbe il sidecar di smarcature di conversazioni mai marcate.
         if (priority)
             appendPriority(cwd, sid, true);
-        const spawned = spawnDeck(id, cwd, sid, kind, modelKind, note, prompt);
+        const spawned = spawnDeck(id, cwd, sid, modelKind, note, prompt);
         spawned.child.on('error', () => setNote(`⚠ spawn ${id} fallito (${DECK_RUN})`));
         // Il modello resta SEMPRE visibile anche quando è il default, perché è un
         // argomento esplicito del comando (T108): gli acceleratori della lista non
@@ -145,11 +174,16 @@ export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNo
     // invece deve restare vivo.
     function spawnTaskSession(kind, keyLabel) {
         const task = selectedTaskOr(keyLabel, 'spawnare');
-        // T152 — stesso catalogo del detail: senza, `^R` partirebbe sul default
-        // fisso mentre l'azione `run` del detail parte sul modello del kind, e le
-        // due superfici divergerebbero sullo stesso comando.
-        if (task)
-            spawnForTask(task.id, kind, modelFor(catalog, kind) ?? MODEL_DEFAULT);
+        if (!task)
+            return;
+        // T161 — stessa risoluzione del detail, sullo stesso id di catalogo: senza,
+        // `^R` e l'azione `run` del detail partirebbero su due terne diverse per lo
+        // stesso comando. Il kind NON si specializza qui: gli acceleratori leggono
+        // solo `tasks.md`, dove il `Size` non c'è, quindi `recap` resta il
+        // dispatcher — che è la riga di catalogo giusta per chi non sa se la task è
+        // un cappello.
+        const d = spawnDefaults(kind, taskHoles(task.id));
+        spawnForTask(task.id, d.model, d.title ?? '', d.prompt ?? '');
     }
     // T49 — resume di una conversazione in una nuova tab. Unico punto: lo chiamano
     // il `⏎` della lista sessioni e quello sulla riga-sessione della ricerca, che
@@ -330,26 +364,50 @@ export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNo
      * darebbe due tabelle capaci di divergere, e la seconda si scoprirebbe solo
      * il giorno in cui una natura nuova apre la skill sbagliata.
      *
-     * Sessione NUDA e modello esplicito: il drain lavora sulla doc, non sulla
-     * task (D10 preflight), e `MODEL_DEFAULT` passa nell'argv anche essendo il
-     * default, come `permissionMode`.
+     * Sessione NUDA: il drain lavora sulla doc, non sulla task (D10 preflight).
+     * Modello e titolo vengono dalla riga `drain` del catalogo delle azioni
+     * (T161), non più da un letterale scritto qui; il PROMPT resta del chiamante,
+     * perché la skill è una funzione della natura del file e quella mappa vive in
+     * un posto solo (`inboxPrompt`, `src/inbox.ts`).
+     *
+     * Il titolo interpola il basename del file, e serve un `sessionId` pinnato
+     * per scriverlo nel sidecar — senza, la nota non avrebbe una chiave e la riga
+     * in lista resterebbe nuda mentre la tab porta un nome. Le due scritture
+     * stanno qui accanto per la stessa ragione di `spawnForTask`: il nome che le
+     * due superfici mostrano nasce da un valore solo.
      */
     function drainInbox(file, prompt) {
-        const spawned = spawnBare(cwd, prompt, MODEL_DEFAULT);
+        const sid = randomUUID();
+        const d = spawnDefaults('drain', { file: inboxWords(file) });
+        const title = d.title ?? '';
+        if (title)
+            appendNote(cwd, sid, title);
+        const spawned = spawnBare(cwd, prompt, d.model, sid, title);
         spawned.child.on('error', () => setNote(`⚠ drain ${file.basename} fallito (${DECK_RUN})`));
         noteSpawn(spawned);
     }
     /**
      * T134 — apre la sessione che SROTOLA l'hard-wrap di un path.
      *
-     * `sonnet` e non il default (D9): lo srotolamento è una passata meccanica con
-     * un verificatore deterministico dietro (`md-wrap --apply` confronta le due
-     * versioni normalizzate `\s+ → spazio` e rimette indietro il file se
-     * differiscono), quindi il giudizio richiesto al modello è leggere un diff e
-     * decidere se committarlo — non progettare niente.
+     * Terna intera dalla riga `unwrap` del catalogo (T161): il modello, il titolo
+     * e anche il PROMPT, che fino a T134 era cablato in `wrap-scan.ts`. A
+     * differenza del drain qui un template unico basta — la skill è sempre la
+     * stessa e l'unico buco è il `{path}`.
+     *
+     * Il default resta `sonnet` e non il modello di default del deck (D9): lo
+     * srotolamento è una passata meccanica con un verificatore deterministico
+     * dietro (`md-wrap --apply` confronta le due versioni normalizzate
+     * `\s+ → spazio` e rimette indietro il file se differiscono), quindi il
+     * giudizio richiesto al modello è leggere un diff e decidere se committarlo —
+     * non progettare niente.
      */
-    function unwrapPath(path, prompt) {
-        const spawned = spawnBare(cwd, prompt, 'sonnet');
+    function unwrapPath(path) {
+        const sid = randomUUID();
+        const d = spawnDefaults('unwrap', { path: wrapWords(path) });
+        const title = d.title ?? '';
+        if (title)
+            appendNote(cwd, sid, title);
+        const spawned = spawnBare(cwd, d.prompt ?? '', d.model, sid, title);
         spawned.child.on('error', () => setNote(`⚠ srotolamento ${path} fallito (${DECK_RUN})`));
         noteSpawn(spawned);
     }
@@ -392,6 +450,8 @@ export function useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNo
     return {
         ...taskOps,
         selectedTaskOr,
+        spawnDefaults,
+        spawnTaskDefaults,
         spawnForTask,
         spawnTaskSession,
         resumeSession,

package/dist/cli.js

@@ -14,13 +14,15 @@ import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
 // come valore, e prima di questo split la leggeva da una closure risolta solo
 // all'arrivo dell'evento, cioè dopo la fine del render.
 import { render, Box, Text } from 'ink';
-import { useState } from 'react';
+import { useMemo, useState } from 'react';
 import { resolveTasksPath, resolveTasksDir } from './tasks.js';
 import { LAUNCH_SEP } from './config.js';
 import { anchorFrame, enableMouse } from './mouse.js';
 import { sanitize } from './width.js';
 import { MODEL_SHORT_LIST, modelAlias } from './glyphs.js';
-import { MODEL_DEFAULT, MODELS } from './spawn.js';
+import { MODEL_DEFAULT, MODELS } from './spawn-catalog.js';
+import { loadPromptCatalog } from './prompt-catalog.js';
+import { resolveSpawnId } from './spawn-config.js';
 import { BARE_BUTTONS_WIDTH, BARE_LABEL, deckLegend, frameGeometry, headlineWidth, indicatorRow, launchRow, } from './frame.js';
 import { choiceButtons } from './ui/fields.js';
 import { useDeckModel } from './deck-model.js';
@@ -32,10 +34,11 @@ import { useAssignOverlay } from './overlays/assign.js';
 import { useProjectStatus } from './overlays/status.js';
 import { useInboxOverlay } from './overlays/inbox.js';
 import { useWrapOverlay } from './overlays/wrap.js';
+import { useSpawnPage } from './overlays/spawn.js';
 import { useGitlink } from './overlays/gitlink.js';
 import { usePurgeOverlay } from './overlays/purge.js';
 import { useTextModals, useViewModals } from './overlays/modals.js';
-import { useTerminalSize } from './hooks.js';
+import { useTerminalSize, useSpawnConfig } from './hooks.js';
 import { EditModal, FilterModal, PurgeModal, SortModal } from './ui/modals.js';
 import { StatusHeadline } from './ui/status-screen.js';
 import { InboxPane, SessionsPane, TasksPane } from './ui/panes.js';
@@ -50,8 +53,29 @@ function Deck({ cwd, tasksPath, tasksDir }) {
     const [mode, setMode] = useState('normal');
     // Dimensioni vive del terminale: sono l'input del budget d'altezza.
     const { rows, columns } = useTerminalSize();
-    const model = useDeckModel({ cwd, tasksPath, tasksDir, setNote });
-    const actions = useDeckActions({ cwd, tasksPath, tasksDir, columns, model, setNote });
+    // T161 — il catalogo dati dei prompt e gli override di progetto: i due
+    // gradini del default di ogni azione di spawn. Si leggono una volta per vita
+    // del deck e scendono a chi risolve la terna (l'attuatore, il detail) e a chi
+    // la configura (la pagina), invece di essere riletti a ogni sede di chiamata.
+    const catalog = useMemo(() => loadPromptCatalog(), []);
+    const spawnConfig = useSpawnConfig({ cwd, setNote });
+    const model = useDeckModel({
+        cwd,
+        tasksPath,
+        tasksDir,
+        bareModel: resolveSpawnId('bare', spawnConfig.overrides, catalog).model,
+        setNote,
+    });
+    const actions = useDeckActions({
+        cwd,
+        tasksPath,
+        tasksDir,
+        columns,
+        model,
+        overrides: spawnConfig.overrides,
+        catalog,
+        setNote,
+    });
     const assign = useAssignOverlay({
         viewTasks: model.viewTasks,
         rows,
@@ -65,6 +89,10 @@ function Deck({ cwd, tasksPath, tasksDir }) {
         columns,
         setMode,
         setNote,
+        // T161 — il detail chiede la terna per ID DI CATALOGO e task aperta; chi la
+        // risolve è l'attuatore, che ha già in mano override, catalogo dati e i
+        // fornitori dei buchi.
+        defaults: actions.spawnTaskDefaults,
         onAction: actions.spawnForTask,
     });
     const search = useSearchOverlay({
@@ -84,11 +112,14 @@ function Deck({ cwd, tasksPath, tasksDir }) {
     // Il nome è quello del file config quando c'è, la cartella altrimenti: la
     // testata deve dire di quale progetto parla anche su un checkout non ancora
     // registrato.
+    const statusDefaults = actions.spawnDefaults('project-status');
     const status = useProjectStatus({
         cwd,
         name: model.projectCore ?? model.projectName,
         rows,
         columns,
+        model: statusDefaults.model,
+        prompt: statusDefaults.prompt ?? '',
         setMode,
         setNote,
     });
@@ -116,6 +147,19 @@ function Deck({ cwd, tasksPath, tasksDir }) {
     // schermata da aprire — l'unica superficie è l'indicatore, e l'unica azione
     // committa.
     const gitlink = useGitlink({ cwd, setNote });
+    // T161 — la pagina delle azioni di spawn. Come il detail e la lista hard-wrap
+    // non esce dal deck da sé: qui riceve il saver degli override, e lo spawn che
+    // quegli override governano parte da tutt'altra parte.
+    const spawn = useSpawnPage({
+        cwd,
+        rows,
+        hasNote: Boolean(note),
+        overrides: spawnConfig.overrides,
+        save: spawnConfig.save,
+        catalog,
+        setMode,
+        setNote,
+    });
     const purge = usePurgeOverlay({
         setMode,
         setNote,
@@ -145,6 +189,7 @@ function Deck({ cwd, tasksPath, tasksDir }) {
         status,
         inbox,
         wrap,
+        spawn,
         gitlink,
         purge,
         view: viewModals,
@@ -251,7 +296,7 @@ function Deck({ cwd, tasksPath, tasksDir }) {
         projectName: model.projectName,
         taskRowData: model.taskRowData,
         hiddenTasks: model.hiddenTasks,
-        overlays: { assign, sheet, search, status, inbox, wrap },
+        overlays: { assign, sheet, search, status, inbox, wrap, spawn },
     });
     if (screen)
         return screen;

package/dist/deck-model.js

@@ -26,7 +26,7 @@ import { ALL, MAX_SESSIONS, MAX_SESSIONS_ALL, META_ROWS, ROW_ALL, ROW_SPOT, SPOT
 import { applyView, epicRollup, taskColumns } from './view.js';
 import { loadView } from './view-store.js';
 import { termWidth } from './width.js';
-import { MODELS, MODEL_DEFAULT } from './spawn.js';
+import { MODELS, MODEL_DEFAULT } from './spawn-catalog.js';
 /**
  * Conteggio dei figli per task, più il rollup delle VIVE e le conversazioni
  * senza binding.
@@ -105,7 +105,7 @@ export function childSessionsOf(sessions, bindings, selectedTaskId, isAll) {
         return selectedTaskId ? bound === selectedTaskId : !bound;
     });
 }
-export function useDeckModel({ cwd, tasksPath, tasksDir, setNote, }) {
+export function useDeckModel({ cwd, tasksPath, tasksDir, bareModel: bareModelDefault, setNote, }) {
     const { tasks, loadError } = useTasks(tasksPath);
     // `notes` esce dall'indice come `sessionNotes`: nel deck `note` è già la riga
     // di STATO in fondo al frame (il feedback di un'azione). Due concetti diversi
@@ -136,7 +136,7 @@ export function useDeckModel({ cwd, tasksPath, tasksDir, setNote, }) {
     // ha una riga, è un'azione sulla surface del cappello) e quindi non si
     // azzera mai — resta quello scelto finché non si sceglie altro, per tutta la
     // vita del deck.
-    const [bareModel, setBareModel] = useState(MODEL_DEFAULT);
+    const [bareModel, setBareModel] = useState(bareModelDefault);
     // T39 — vista corrente (filtri + sort). Vive nel modello e non nell'hook dei
     // modali che la editano: è ciò che `applyView` consuma per produrre la lista,
     // è persistita su disco e la rilegge il tasto `w`. È stato del modello che due

package/dist/frame.js

@@ -117,6 +117,10 @@ export function deckLegend(state) {
         // direbbe il contrario di ciò che il tasto fa. Stessa regola di `CANC
         // elimina tutte`, che nomina il bersaglio e non il tasto.
         state.inboxPane ? '^B sessioni' : '^B inbox',
+        // T161 — la voce nomina l'OGGETTO e non il gesto, al contrario di `^G`/
+        // `^O`/`^U`: lì il tasto fa qualcosa (genera, bumpa) e il nome dell'oggetto
+        // da solo sarebbe ambiguo, qui apre una pagina e basta.
+        '^S azioni',
         '^F cerca',
         'C nuova',
         'E edit',

package/dist/glyphs.js

@@ -1,11 +1,11 @@
 // Glifi letterali del frame e formatter di display. Fase VISTA, ma senza JSX:
 // tutto qui è puro e testabile, e nessun sito di render scrive un glifo nudo.
 import { sanitize } from './width.js';
-// T148/P3 — costo accettato: la fase vista importa dalla fase effetti esterni.
-// Il TIPO si cancella alla compilazione (nessuna dipendenza runtime); T154
-// aggiunge MODELS come VALORE — una dipendenza runtime vera, ma senza ciclo:
-// `spawn.ts` non importa questo file, quindi il verso resta uno solo.
-import { MODELS } from './spawn.js';
+// T161 — il catalogo dei modelli è DATO PURO (`spawn-catalog.ts`) e non importa
+// nessuno: la fase vista può leggerlo senza ciclo. Prima di T161 la stessa riga
+// prendeva `MODELS` da `spawn.ts`, cioè dalla fase «effetti esterni» — costo
+// accettato allora (T148/P3) e caduto adesso.
+import { MODELS } from './spawn-catalog.js';
 // Glifi LETTERALI del JSX. I dati passano dai loader, che sanificano al
 // confine; questi no — quindi passano da `sanitize` una volta qui, così nessun
 // sito di render scrive un glifo nudo. `↳ ○ ▸ ⏎ · − ↑ ↓` sono già concordi e

package/dist/hooks.js

@@ -15,6 +15,7 @@ import { scanEpicHierarchy, EMPTY_EPIC_HIERARCHY } from './epic-hierarchy.js';
 import { scanInbox, INBOX_SCAN_INTERVAL_MS } from './inbox.js';
 import { mixedCount, readWrapCache, runWrapScan, wrapCacheFile, wrapCount, } from './wrap-scan.js';
 import { purgeTargets } from './purge.js';
+import { loadSpawnOverrides, saveSpawnOverrides, } from './spawn-config.js';
 import { POLL_MS } from './model.js';
 // Dimensioni del terminale, live sul resize.
 //
@@ -398,3 +399,38 @@ export function useTaskDetail(tasksDir, id) {
     }, [tasksDir, id]);
     return detail;
 }
+/**
+ * T161 — gli OVERRIDE di spawn del progetto, tenuti vivi per la durata del deck.
+ *
+ * Lettura una volta al mount, e da lì in poi lo stato in memoria è la fonte: la
+ * pagina delle azioni è l'unico scrittore, e rileggere il file a ogni tick del
+ * poll significherebbe pagare una `readFileSync` ogni 1,5 secondi per un dato
+ * che cambia quando lo si cambia. Chi lo modifica fuori dal deck (a mano, o un
+ * altro deck sullo stesso progetto) si riallinea alla riapertura, che è lo stesso
+ * regime di `launch` e `archivableDays`.
+ *
+ * Gli AVVISI del parse si mostrano una volta, all'avvio, nella riga di stato: una
+ * voce scartata in silenzio si presenta come un override che non fa niente, cioè
+ * come un guasto del deck. La riga di stato è l'unica superficie sempre presente
+ * — la pagina potrebbe non venire mai aperta.
+ *
+ * Il salvataggio NON si fida: ricarica dal disco quello che ha appena scritto,
+ * così quello che la pagina mostra dopo `w` è quello che il file dice davvero,
+ * riduzione del titolo e scarti compresi.
+ */
+export function useSpawnConfig({ cwd, setNote, }) {
+    const [parsed, setParsed] = useState(() => loadSpawnOverrides(cwd));
+    const warned = useRef(false);
+    useEffect(() => {
+        if (warned.current || parsed.warnings.length === 0)
+            return;
+        warned.current = true;
+        const [first, ...rest] = parsed.warnings;
+        setNote(`⚠ ${first}${rest.length > 0 ? ` · +${rest.length}` : ''}`);
+    }, [parsed, setNote]);
+    const save = useCallback((entries) => {
+        saveSpawnOverrides(cwd, entries);
+        setParsed(loadSpawnOverrides(cwd));
+    }, [cwd]);
+    return { overrides: parsed.entries, warnings: parsed.warnings, save };
+}

package/dist/inbox.js

@@ -192,6 +192,25 @@ export function inboxPrompt(f) {
     }
     return `/loom-works:${DRAIN_SKILL[f.natura]} ${f.basename}`;
 }
+/**
+ * T161 — il buco `{file}` del titolo di una sessione di drain: il basename senza
+ * estensione e senza punti. L'emoji del prefisso non sta più qui — è dentro il
+ * template della riga `drain` del catalogo delle azioni, dove il progetto può
+ * riscriverla.
+ *
+ * Il `.md` si toglie QUI e non lo si lascia cadere a valle: l'alfabeto di
+ * `_sane_note` non ha il punto, quindi il titolo della tab uscirebbe con le due
+ * lettere saldate al nome (`…-prioritariamd`) mentre la lista del deck, che
+ * legge la nota grezza dal sidecar, mostrerebbe il nome intero — la stessa
+ * conversazione con due nomi, senza errore.
+ *
+ * Uno per ogni natura, `malformato` compreso: quella sessione ripara il marker
+ * invece di drenare, ma l'oggetto su cui lavora è lo stesso file, ed è il file
+ * che il titolo nomina. L'azione la dice il prompt.
+ */
+export function inboxWords(f) {
+    return f.basename.replace(/\.md$/i, '').replace(/\./g, '-');
+}
 /**
  * Il testo del file inbox, per il detail fullscreen. `null` = illeggibile —
  * il detail lo dice e tiene l'azione attiva, come fa quello della task con un

package/dist/input-modes.js

@@ -26,6 +26,7 @@ export const CAPTURING_MODES = [
     'status',
     'inbox',
     'wrap',
+    'spawn',
     'reader',
     'search',
     'assign',

package/dist/input.js

@@ -79,6 +79,7 @@ export function useDeckInput({ cwd, tasksDir, mode, setMode, setNote, model, act
         status: overlays.status.onKey,
         inbox: overlays.inbox.onKey,
         wrap: overlays.wrap.onKey,
+        spawn: overlays.spawn.onKey,
         reader: overlays.search.onReaderKey,
         search: overlays.search.onSearchKey,
         assign: overlays.assign.onKey,
@@ -335,6 +336,21 @@ export function useDeckInput({ cwd, tasksDir, mode, setMode, setNote, model, act
                 // stesso doppio significato per contesto già in esercizio su `^F`.
                 overlays.gitlink.bump();
             }
+            else if (input === 's') {
+                // T161/P13 preflight — `^S` apre la pagina delle azioni di spawn. Le
+                // schermate sostitutive si aprono tutte con `CTRL` più lettera, e `s`
+                // sta per «spawn»; `^A`, che sarebbe l'altra mnemonica, è già
+                // inizio-riga dentro ogni campo di testo del deck.
+                //
+                // Sul flow-control XON/XOFF il repo porta due commenti in
+                // contraddizione — `model.ts` dice che il raw mode di Ink lo disattiva e
+                // il tasto passa pulito, `cli.tsx` che il terminale lo intercetta. La
+                // contraddizione si chiude qui con una MISURA, non con un'opinione: il
+                // gate pty di `test/modes-smoke.test.ts` manda `^S` al deck vero dentro
+                // un pseudo-terminale e pretende che la pagina si apra, quindi se il
+                // byte non arrivasse il test fallirebbe invece di lasciare il dubbio.
+                overlays.spawn.openPage();
+            }
             else if (input === 'b') {
                 // T134/D8 preflight — `^B` (box/bacheca) scambia i due pane dello slot
                 // destro. Non è un modale né una schermata: il pane resta uno dei due