@lamemind/loom-deck 0.45.0 → 0.47.0

package/dist/overlays/sheet.js

@@ -18,7 +18,8 @@ import { scanText, topForOffset } from '../text-search.js';
 import { parseMarkdown } from '../markdown.js';
 import { cpLen, insertAt, removeAt } from '../layout.js';
 import { sanitizeTyped } from '../glyphs.js';
-import { ACTION_HOTKEYS, DETAIL_ACTIONS, MODELS, MODEL_DEFAULT, } from '../spawn.js';
+import { ACTION_HOTKEYS, DETAIL_ACTIONS, MODELS, MODEL_DEFAULT, specializeRecap, } from '../spawn.js';
+import { taskIsEpic } from '../tasks.js';
 import { fieldsKey } from '../fields.js';
 import { loadPromptCatalog, promptFor } from '../prompt-catalog.js';
 // T117 — le quattro righe dell'area di compilazione del detail, nell'ordine in
@@ -50,6 +51,10 @@ export function useSheetOverlay(deps) {
     // T117 — il prompt iniziale, EDITABILE. Quello che si legge nel campo è quello
     // che parte: non un'anteprima di qualcos'altro.
     const [prompt, setPrompt] = useState('');
+    /** La task aperta è un cappello (`Size: Epic`)? Deciso UNA VOLTA all'apertura,
+     *  dal testo che il detail ha già in mano: rifarlo a ogni cambio di azione
+     *  riparserebbe l'intero task file per un campo dell'header. */
+    const [epic, setEpic] = useState(false);
     const [cursor, setCursor] = useState({ row: DROW.action, caret: 0 });
     // Il catalogo si legge una volta per vita del deck: è un file di quattro righe
     // accanto al codice, non un dato che cambia sotto i piedi.
@@ -105,12 +110,16 @@ export function useSheetOverlay(deps) {
     }, [findRes, occCur, lines, capacity]);
     /** Apre il detail su una task, azzerando scroll, area di compilazione e ricerca. */
     function open(next) {
+        // Calcolato qui e usato subito: `setEpic` non ha ancora aggiornato lo stato
+        // quando `setPrompt` gira, quindi il valore locale è l'unico leggibile ora.
+        const isEpic = taskIsEpic(next.id, next.text);
         setSheet(next);
         setTop(0);
         setAction(0);
+        setEpic(isEpic);
         setModel(MODEL_DEFAULT);
         setSpawnNote('');
-        setPrompt(promptFor(catalog, DETAIL_ACTIONS[0].kind, next.id));
+        setPrompt(promptFor(catalog, specializeRecap(DETAIL_ACTIONS[0].kind, isEpic), next.id));
         setCursor({ row: DROW.action, caret: 0 });
         setFind(null);
         setOccIdx(0);
@@ -129,7 +138,7 @@ export function useSheetOverlay(deps) {
         setAction(index);
         const id = sheet?.id;
         if (id)
-            setPrompt(promptFor(catalog, DETAIL_ACTIONS[index].kind, id));
+            setPrompt(promptFor(catalog, specializeRecap(DETAIL_ACTIONS[index].kind, epic), id));
     }
     // Il ponte fra le quattro righe e i quattro stati. Le righe restano
     // TIPIZZATE dove vivono (`ModelKind`, indice dell'azione) invece di finire in
@@ -234,13 +243,16 @@ export function useSheetOverlay(deps) {
         if (key.return) {
             // `⏎` esegue SEMPRE l'azione selezionata, da qualunque riga: i campi sono
             // di una riga sola, quindi nessuno di loro ha da farci un a-capo.
+            // Il kind viaggia specializzato quanto il prompt che lo accompagna: se il
+            // campo è stato svuotato a mano il testo non parte e resta lui a dire cosa
+            // ricevera' la sessione, quindi i due non possono divergere.
             const act = DETAIL_ACTIONS[action];
             const id = sheet?.id;
             const note = spawnNote.trim();
             const text = prompt.trim();
             close();
             if (id)
-                onAction(id, act.kind, model, note, text);
+                onAction(id, specializeRecap(act.kind, epic), model, note, text);
             return;
         }
         if (key.pageUp) {

package/dist/spawn.js

@@ -117,6 +117,27 @@ export function onInTabCommand(child, cb) {
         }
     });
 }
+/**
+ * `recap` → la sotto-skill giusta, quando chi spawna SA se la task è un cappello.
+ *
+ * `recap` resta il kind onesto per chi non lo sa: punta al dispatcher, che
+ * risolve la task e classifica da sé. È il caso degli acceleratori della lista,
+ * dove il deck ha in mano solo `tasks.md` — e lì il `Size` non c'è. Il DETAIL
+ * invece il task file l'ha già letto, quindi può saltare il giro e pagare un
+ * turno di modello in meno.
+ *
+ * Non è una classificazione duplicata: il criterio (`Size: Epic`) resta uno solo
+ * e sta in `taskIsEpic`, che legge lo stesso campo che leggerebbe il dispatcher.
+ * Quello che si evita è il RITARDO, non il giudizio.
+ *
+ * Ogni kind diverso da `recap` passa intatto: la specializzazione è un caso, non
+ * una trasformazione da applicare a tutti.
+ */
+export function specializeRecap(kind, epic) {
+    if (kind !== 'recap')
+        return kind;
+    return epic ? 'recap-epic' : 'recap-task';
+}
 // L'ordine È il giro di `tab` nel detail, non una preferenza di lettura:
 // cambiarlo sposta le voci sotto le dita di chi le ha imparate. Fino a T111 era
 // anche il binding delle cifre `1`-`4`, passate poi al campo nota.

package/dist/tasks.js

@@ -153,6 +153,30 @@ export function parseTaskDetail(id, content) {
         description: sanitize(descLines.join('\n').trim()),
     };
 }
+/**
+ * La task è un cappello (epica)?
+ *
+ * Il marker è `Size: Epic`, e sta sul CAPPELLO perché la parentela la dichiara
+ * la figlia (`**Parent Task**`): un padre non sa di averne senza scandagliare
+ * tutti gli altri task file, cosa che il deck non può fare nel loop di poll.
+ *
+ * Legge dal testo INTEGRALE del task file, l'unico posto dove il `Size` esiste:
+ * in `tasks.md` quella colonna non c'è, quindi la lista non può rispondere e la
+ * domanda ha senso solo dove il file è già stato aperto (il detail).
+ *
+ * Riusa `parseTaskDetail` invece di una regex propria: la grammatica dei bullet
+ * header (`- **Campo**: valore`) è già scritta lì, e una seconda copia
+ * divergerebbe al primo campo che cambia forma. Confronto case-insensitive — il
+ * valore lo scrive un umano nel file, non uno script.
+ *
+ * Testo assente (`null`, task file non ancora letto) → `false`: la mancanza di
+ * prova non è prova di cappello, e degradare sul caso comune è l'esito benigno.
+ */
+export function taskIsEpic(id, text) {
+    if (!text)
+        return false;
+    return (parseTaskDetail(id, text).fields['Size'] ?? '').trim().toLowerCase() === 'epic';
+}
 /**
  * Testo INTEGRALE del task file (T66 · detail).
  *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lamemind/loom-deck",
-  "version": "0.45.0",
+  "version": "0.47.0",
   "description": "Deck TUI Ink per-progetto della famiglia loom: legge tasks.md e spawna sessioni Claude Code bound via LOOM_TASK",
   "type": "module",
   "bin": {

package/scripts/deck-run

@@ -4,8 +4,8 @@
 #
 # Apre una tab Ptyxis nella window ATTIVA (quella col focus = il deck) e vi
 # avvia una sessione Claude Code già bound alla task via LOOM_TASK, dritta sul
-# prompt iniziale scelto con --prompt-kind (default: `recap`, prompt diretto
-# "recap stato task <TaskID>" — no skill, solo recap → più controllo).
+# prompt iniziale scelto con --prompt-kind (default: `recap`, cioè la skill
+# `/loom-works:recap-status` sulla task).
 # Riusabile identico da TUI (Ink) e da web.
 #
 # Quattro assi ORTOGONALI, da non confondere fra loro:
@@ -103,7 +103,7 @@ MODEL=""
 # Sotto --fork il --session-id torna AMMESSO (anzi: è il punto) — la mutua
 # esclusione con --resume esiste perché una ripresa nuda riscrive il transcript
 # dell'id ripreso, mentre il fork ne apre uno NUOVO, che possiamo quindi pinnare.
-# --prompt-kind <none|recap|preflight|run|checkpoint> (T56, T66): sceglie il prompt iniziale fra
+# --prompt-kind <none|recap|recap-task|recap-epic|preflight|run|checkpoint>: sceglie il prompt iniziale fra
 # quelli del catalogo qui sotto. Enum e non stringa libera: il prompt viaggia
 # dentro apici singoli in `bash -lc`, quindi il testo va tenuto in un posto solo
 # e verificato una volta, invece di spostare il rischio di quoting su ogni
@@ -164,7 +164,9 @@ USAGE="uso: deck-run <TaskID> [--model <alias>] [--prompt-kind <kind>] [--sessio
 
   --prompt-kind  prompt iniziale della sessione bound (default: recap)
        none        nessun prompt — sessione aperta sulla task, a mani nude
-       recap       recap stato task <TaskID>
+       recap       /loom-works:recap-status <TaskID>       (dispatcher)
+       recap-task  /loom-works:recap-status-task <TaskID>  (task non cappello)
+       recap-epic  /loom-works:recap-status-epic <TaskID>  (Size: Epic)
        preflight   /loom-works:preflight-task <TaskID>
        run         /loom-works:run-task <TaskID>
        checkpoint  /loom-works:checkpoint-task <TaskID>
@@ -203,8 +205,8 @@ fi
 # lì il valore arriva da un file editabile a mano, qui da un argomento nostro.
 if [[ -n "$PROMPT_KIND" ]]; then
   case "$PROMPT_KIND" in
-    none|recap|preflight|run|checkpoint) ;;
-    *) echo "--prompt-kind ignoto: '${PROMPT_KIND}' (usa none|recap|preflight|run|checkpoint)" >&2
+    none|recap|recap-task|recap-epic|preflight|run|checkpoint) ;;
+    *) echo "--prompt-kind ignoto: '${PROMPT_KIND}' (usa none|recap|recap-task|recap-epic|preflight|run|checkpoint)" >&2
        echo "$USAGE" >&2
        exit 2 ;;
   esac
@@ -421,7 +423,21 @@ FORK_FLAG=""
 # eseguirlo o a mani nude. Il kind è quell'intento.
 #   none       → nessun prompt (≠ stringa vuota: PROMPT_ARG sparisce del tutto,
 #                come sul ramo --resume, altrimenti CC riceve un posizionale vuoto)
-#   recap      → prompt DIRETTO, no skill: l'utente rivede/steera prima di lanciare
+#   recap      → skill di recap sulla task. È un DISPATCHER: `recap-status`
+#                risolve la task, classifica (progetto / task / epica) e passa a
+#                una sotto-skill. Fino a v0.45 era invece un prompt diretto
+#                ("recap stato task <id>"), scelto perché non esisteva una skill
+#                di recap tarata sulla singola task e quella di progetto avrebbe
+#                risposto largo — vincolo caduto col dispatcher.
+#   recap-task → la sotto-skill diretta, senza il giro del dispatcher
+#   recap-epic → idem per un cappello (`Size: Epic`)
+#                I due specializzati li sceglie chi SA già come è fatta la task:
+#                il detail del deck, che il task file l'ha aperto. Chi non lo sa
+#                — gli acceleratori della lista, che leggono solo `tasks.md`, e
+#                quindi non vedono il `Size` — resta su `recap` e lascia
+#                classificare al dispatcher. Il criterio non è duplicato: sta in
+#                `taskIsEpic` (src/tasks.ts) e legge lo stesso campo che leggerebbe
+#                il dispatcher; quello che cambia è solo QUANDO viene letto.
 #   preflight  → skill di preflight sulla task
 #   run        → skill di esecuzione sulla task
 #   checkpoint → skill di checkpoint sulla task

package/scripts/prompt-catalog

@@ -15,7 +15,14 @@
 # Vincolo sui template: nessun apice singolo. Il testo finisce dentro `'...'`
 # nel comando passato a `bash -lc`, e questo file è committato — un apice qui
 # sarebbe un errore di scrittura, non un input da quotare.
-recap	recap stato task {TASK}
+# `recap` è il DISPATCHER: risolve la task, ne legge il Size e passa da sé alla
+# sotto-skill. Lo usa chi non sa se la task è un cappello — gli acceleratori
+# della lista, dove il deck ha in mano solo tasks.md, che il Size non ce l'ha.
+# Le due voci `recap-task`/`recap-epic` saltano quel giro: le sceglie il DETAIL,
+# che il task file l'ha già aperto e quindi il Size lo conosce.
+recap	/loom-works:recap-status {TASK}
+recap-task	/loom-works:recap-status-task {TASK}
+recap-epic	/loom-works:recap-status-epic {TASK}
 preflight	/loom-works:preflight-task {TASK}
 run	/loom-works:run-task {TASK}
 checkpoint	/loom-works:checkpoint-task {TASK}