Files

T

marcopan de61034a8d feat(harness): riscrittura skill tht-sessione (F1-F8 + 4 sottomoduli)

Skill ex-novo che riflette Thoth (non copia di ChironeWp3):
- vocabolario widget-descriptor (reviewer_select/decide/confirm) invece di 'dialog native'
- D11 save-one in F2 (upsert mirato vs full resync)
- D14a value_grounded (LSH multi-colonna non collassa) + D14b concept_formula in F4
- D13 free-text e D15 rollback nelle discipline trasversali
- memory vive SOLO nel vectordb (drop registry, spec 5): save-one/promote senza registry
- F8 datamart onesto (stub NotImplementedError)

Sottomoduli cte/memoria/rewriting/sql-generation portati adattando nsp->tht, con
i vincoli precisi trasferiti fedelmente (max 5 memorie, solo 3 tipi riusabili,
CTE solo WITH senza SELECT, dim_time join non aritmetica, sql_final pulito).

Verifica: zero residui nsp/chirone/psd nella skill; ogni 'tht <cmd>' citato e'
registrato (correzione: 'tht formula retrieve' era inesistente -> riformulato in
'ricerca nelle evidence'). Suite: 165 passed.

2026-06-27 14:24:20 +02:00

2.3 KiB

Raw Blame History

Presentazione delle memorie riapplicabili

Le memorie arrivano da tht memory search "<domanda>" --session <id> --json, gia' ordinate per similarita'. Tu le argomenti, il reviewer decide. MAI applicarle da solo. Passa SEMPRE --session <id>: la CLI esclude le memorie gia' decise in questa sessione (applicate o rifiutate), cosi' non riproponi cio' che il reviewer ha gia' scartato (anche dopo un reopen della Fase 2).

Per ogni memoria da presentare in checklist, includi nella label e/o description dell'opzione:

Cosa dice: tipo + soggetto + detail (es. "table_promoted: fact_seeablazione — tabella principale per le ablazioni").
Da dove viene: question_context e session_id di origine.
Perche' potrebbe valere qui: sovrapposizione di concetti/tabelle con la domanda corrente (campi tables/concepts), score di similarita'.
Rischio fuori-contesto: cosa c'era nella sessione originale che qui potrebbe non valere (periodo diverso, popolazione diversa, schema cambiato).

Regole:

Proponi al massimo 5 candidate. Includi SOLO memorie dei 3 tipi riusabili: concept_clarified, table_promoted, table_excluded. Le decisioni query-specifiche (es. question_rewritten, sql_approved) NON vanno proposte: non si trasferiscono ad altre domande.
Tutte le memorie candidate vanno in un solo reviewer_decide(multi:true, advance:true, allow_empty:true): ogni opzione selezionata viene applicata (registra la decisione col tipo appropriato, citando l'id memoria nel rationale), ogni opzione deselezionata viene registrata come memory_rejected dal gate (così la prossima tht memory search --session non la ripropone). Per abilitare questo, OGNI opzione memoria DEVE portare il campo mem_id:"mem-<id>" (oltre a type/subject/rationale). La checklist parte pre-selezionata con le memorie raccomandate. Con allow_empty:true una selezione vuota è accettata (nessuna memoria applicata; le deselezionate restano comunque registrate come rifiutate) e la fase avanza — nessun gate separato.
Per "ispeziona": mostra il record JSON integrale della memoria nella prosa prima di presentare la checklist, se il reviewer lo richiede.
Se nessuna memoria supera score 0.5, dillo e chiudi la fase rapidamente (con reviewer_confirm kind:"phase" se la lista è vuota).

2.3 KiB Raw Blame History

Presentazione delle memorie riapplicabili

2.3 KiB

Raw Blame History