Cantieri aperti: differenze tra le versioni - Wiki Progetto di Ricerca Metodo Paret

Riga 8:

== Cantieri attivi ==

=== harness-standard ===

''Aggiornato 2026-08-12 08:52 UTC'' — dominio: architettura / knowledge base

''Aggiornato 2026-08-12 09:11 UTC'' — dominio: architettura / knowledge base

; Obiettivo : Sostituire il MASTER READ ORDER monolitico con un harness gerarchico e togliere Marco dal ruolo di loop di esecuzione

Riga 97:

* Questo invalida retroattivamente due conclusioni: la v7.7 non era necessariamente peggiorata (5 a 4 era rumore) e il confronto Qwen 3/6 contro DeepSeek 4/6 non e significativo

* La sentinella notturna ha una regola su eval_pass in calo: con questa varianza produrra falsi allarmi

* GIUDICE STABILIZZATO: creato scripts/eval_det.py con criteri deterministici per parole chiave al posto del giudice LLM. Ogni caso doro ha un elenco DEVE e un elenco NON DEVE verificabili: shot.py presente, /vm/task assente, sql e non query, handoff.py con --list e --resume, scelgo/procedo senza chiedere a Marco. Costo del giudizio: zero

* VARIANZA AZZERATA: v7.9 misurata 5 e 5, dove il giudice LLM sullo stesso documento dava 5, 2, 4

* RIMISURATO TUTTO con il metro stabile: v7.6 mediana 5.5, v7.7 mediana 5.5, v7.9 mediana 5.0. Le differenze restano dentro 1 punto: nessuna delle versioni si distingue davvero dalle altre

* QWEN 3.8-MAX su v7.9: 5 e 5, mediana 5.0, IDENTICO a DeepSeek. Il confronto precedente Qwen 3/6 contro DeepSeek 4/6 era interamente rumore del giudice

* Il caso che fallisce sistematicamente e scelta_domanda: il modello descrive invece di scegliere ed eseguire

; Provato ed escluso :

* Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC

Riga 125:

Riga 130:

* Pubblicare una versione del Master senza misurarla: e il difetto che larticolo Harness-R1 documenta, i modelli fissi propongono patch plausibili che peggiorano

* Fidarsi di una singola esecuzione delleval: serve la mediana su piu run, e anche cosi oggi non basta

* Il giudice LLM come strumento di misura: varianza 3 punti su 6 sullo stesso input, inutilizzabile per un gate

* Le tre conclusioni basate su di lui: v7.7 peggiorata (falso), Qwen inferiore a DeepSeek (falso), differenze fra versioni del Master (non dimostrate)

; Prossimo passo :

* ~~STABILIZZARE IL GIUDICE prima di ogni altra cosa: due giudici diversi con disaccordo~~ in ~~revisione, oppure criteri di valutazione deterministici sui casi doro (la risposta cita shot~~.py ~~si o no, cita /vm/task si o no) invece di un giudizio libero~~

* Sostituire il giudice in gate_master.py e nella sentinella notturna con eval_det.py: la regola eval_pass in calo oggi darebbe falsi allarmi

* Solo dopo il giudice stabile il gate ha senso e la ~~sentinella smette di dare~~ falsi allarmi

* Il caso scelta_domanda fallisce con tutti i modelli: e un difetto del Master, non del modello. La regola C sulla continuita va resa piu operativa

* Migrare i 289 script al gateway partendo dai 5 in cron

@@ Riga 8: / Riga 8: @@
 == Cantieri attivi ==
 === harness-standard ===
-''Aggiornato 2026-08-12 08:52 UTC'' &mdash; dominio: architettura / knowledge base
+''Aggiornato 2026-08-12 09:11 UTC'' &mdash; dominio: architettura / knowledge base
 ; Obiettivo : Sostituire il MASTER READ ORDER monolitico con un harness gerarchico e togliere Marco dal ruolo di loop di esecuzione
@@ Riga 97: / Riga 97: @@
 * Questo invalida retroattivamente due conclusioni: la v7.7 non era necessariamente peggiorata (5 a 4 era rumore) e il confronto Qwen 3/6 contro DeepSeek 4/6 non e significativo
 * La sentinella notturna ha una regola su eval_pass in calo: con questa varianza produrra falsi allarmi
+* GIUDICE STABILIZZATO: creato scripts/eval_det.py con criteri deterministici per parole chiave al posto del giudice LLM. Ogni caso doro ha un elenco DEVE e un elenco NON DEVE verificabili: shot.py presente, /vm/task assente, sql e non query, handoff.py con --list e --resume, scelgo/procedo senza chiedere a Marco. Costo del giudizio: zero
+* VARIANZA AZZERATA: v7.9 misurata 5 e 5, dove il giudice LLM sullo stesso documento dava 5, 2, 4
+* RIMISURATO TUTTO con il metro stabile: v7.6 mediana 5.5, v7.7 mediana 5.5, v7.9 mediana 5.0. Le differenze restano dentro 1 punto: nessuna delle versioni si distingue davvero dalle altre
+* QWEN 3.8-MAX su v7.9: 5 e 5, mediana 5.0, IDENTICO a DeepSeek. Il confronto precedente Qwen 3/6 contro DeepSeek 4/6 era interamente rumore del giudice
+* Il caso che fallisce sistematicamente e scelta_domanda: il modello descrive invece di scegliere ed eseguire
 ; Provato ed escluso :
 * Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC
@@ Riga 125: / Riga 130: @@
 * Pubblicare una versione del Master senza misurarla: e il difetto che larticolo Harness-R1 documenta, i modelli fissi propongono patch plausibili che peggiorano
 * Fidarsi di una singola esecuzione delleval: serve la mediana su piu run, e anche cosi oggi non basta
+* Il giudice LLM come strumento di misura: varianza 3 punti su 6 sullo stesso input, inutilizzabile per un gate
+* Le tre conclusioni basate su di lui: v7.7 peggiorata (falso), Qwen inferiore a DeepSeek (falso), differenze fra versioni del Master (non dimostrate)
 ; Prossimo passo :
-* STABILIZZARE IL GIUDICE prima di ogni altra cosa: due giudici diversi con disaccordo in revisione, oppure criteri di valutazione deterministici sui casi doro (la risposta cita shot.py si o no, cita /vm/task si o no) invece di un giudizio libero
+* Sostituire il giudice in gate_master.py e nella sentinella notturna con eval_det.py: la regola eval_pass in calo oggi darebbe falsi allarmi
-* Solo dopo il giudice stabile il gate ha senso e la sentinella smette di dare falsi allarmi
+* Il caso scelta_domanda fallisce con tutti i modelli: e un difetto del Master, non del modello. La regola C sulla continuita va resa piu operativa
 * Migrare i 289 script al gateway partendo dai 5 in cron