marcopan
de61034a8d
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.
41 lines
2.3 KiB
Markdown
41 lines
2.3 KiB
Markdown
# 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).
|