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

Riga 8:

== Cantieri attivi ==

=== harness-standard ===

''Aggiornato 2026-08-07 20:28 UTC'' — dominio: architettura / knowledge base

''Aggiornato 2026-08-07 22:21 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 40:

* SOSTITUTO CREATO E VERIFICATO: /home/claudeuser/scripts/job.py --run/--status/--log/--list, nohup con sessione staccata. Test reale: job da 140 secondi, rc=0, timestamp /tmp/j_start e /tmp/j_end confermano la durata

* MASTER v7.2 pubblicata su Drive (canonico rinominato, intestazione, txt id 1ptmfkfwlsqZWvV3LrS77guhF251U7FAr), v7.1 marcata SUPERATO

* AUDIT ROUTE ESEGUITO (22 route, una per una, con verifica effetto reale, lanciato via job.py in 111s): 8 REALI, 10 FORMA, 1 ERRORE, 1 FALSO_OK, 2 saltate perche distruttive. Rapporto gs://isicnv-command-center-routes/state/route_audit_AUDIT1786141034.json

* UNICO falso successo confermato: /vm/task

* SCOPERTO /bq/query vuole {sql} NON {query}: stessa famiglia del bug /vm/task (task non cmd). Prima di dire che una route e rotta, controllare il nome del parametro

* SCOPERTO /cc/check riporta http_vm ERR fetch failed come esito normale (Cloud Run non ha TCP diretto verso VM): allarme falso, ignorare quella riga

* SCOPERTO incoerenza conteggi memoria: /memory/list dice 1000, /memory/search dice 2822 indicizzati

* SCOPERTO sheet STATE 1KRoCu ha #ERROR! nella riga di intestazione

* MASTER v7.3 pubblicata su Drive, txt id 1HQKcSHCr1uPHbCvae94DITcSgWs0AV7a

; Provato ed escluso :

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

Riga 53:

Riga 60:

* Rifare il login della CLI Claude Code sulla VM per riparare /vm/task: richiede OAuth interattivo di Marco, e job.py risolve senza dipendenze

* Fidarsi della documentazione delle route senza provarle: due bug su due (headless GET, vm/task) erano documentati male

* Testare /vm/reset e /routes/deploy: distruttive, saltate di proposito

* Cancellare i record di prova via /memory/delete: la route NON ESISTE (Cannot POST). Restano da ripulire test_1786141053523_gbv40d e system_state_1786092629694_7idl9o

; Prossimo passo :

* ~~REGOLA DA VERIFICARE~~: ~~quante altre~~ route ~~documentate restituiscono successo senza eseguire? Fare un giro~~ di ~~prova sulle 25 route piu usate~~

* Capire perche /memory/list dice 1000 e /memory/search 2822: uno dei due mente, e il lint della memoria si basa su quel numero

* Riparare intestazione #ERROR! nello sheet STATE 1KRoCu

* Creare una route o script per cancellare record di memoria (oggi non esiste)

* Recuperare da v6.4: R49 edit/rename Docs -> routing DRIVE, R47 routing per tier -> Master, R45 pattern RLM -> routing dati

* Compilare i 7 routing file dallo harvest in /home/claudeuser/routing_src/

* Cercare i chiamanti cron delle 525 route prima di archiviarle

[[Categoria:Domini operativi]]

@@ Riga 8: / Riga 8: @@
 == Cantieri attivi ==
 === harness-standard ===
-''Aggiornato 2026-08-07 20:28 UTC'' &mdash; dominio: architettura / knowledge base
+''Aggiornato 2026-08-07 22:21 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 40: / Riga 40: @@
 * SOSTITUTO CREATO E VERIFICATO: /home/claudeuser/scripts/job.py --run/--status/--log/--list, nohup con sessione staccata. Test reale: job da 140 secondi, rc=0, timestamp /tmp/j_start e /tmp/j_end confermano la durata
 * MASTER v7.2 pubblicata su Drive (canonico rinominato, intestazione, txt id 1ptmfkfwlsqZWvV3LrS77guhF251U7FAr), v7.1 marcata SUPERATO
+* AUDIT ROUTE ESEGUITO (22 route, una per una, con verifica effetto reale, lanciato via job.py in 111s): 8 REALI, 10 FORMA, 1 ERRORE, 1 FALSO_OK, 2 saltate perche distruttive. Rapporto gs://isicnv-command-center-routes/state/route_audit_AUDIT1786141034.json
+* UNICO falso successo confermato: /vm/task
+* SCOPERTO /bq/query vuole {sql} NON {query}: stessa famiglia del bug /vm/task (task non cmd). Prima di dire che una route e rotta, controllare il nome del parametro
+* SCOPERTO /cc/check riporta http_vm ERR fetch failed come esito normale (Cloud Run non ha TCP diretto verso VM): allarme falso, ignorare quella riga
+* SCOPERTO incoerenza conteggi memoria: /memory/list dice 1000, /memory/search dice 2822 indicizzati
+* SCOPERTO sheet STATE 1KRoCu ha #ERROR! nella riga di intestazione
+* MASTER v7.3 pubblicata su Drive, txt id 1HQKcSHCr1uPHbCvae94DITcSgWs0AV7a
 ; Provato ed escluso :
 * Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC
@@ Riga 53: / Riga 60: @@
 * Rifare il login della CLI Claude Code sulla VM per riparare /vm/task: richiede OAuth interattivo di Marco, e job.py risolve senza dipendenze
 * Fidarsi della documentazione delle route senza provarle: due bug su due (headless GET, vm/task) erano documentati male
+* Testare /vm/reset e /routes/deploy: distruttive, saltate di proposito
+* Cancellare i record di prova via /memory/delete: la route NON ESISTE (Cannot POST). Restano da ripulire test_1786141053523_gbv40d e system_state_1786092629694_7idl9o
 ; Prossimo passo :
-* REGOLA DA VERIFICARE: quante altre route documentate restituiscono successo senza eseguire? Fare un giro di prova sulle 25 route piu usate
+* Capire perche /memory/list dice 1000 e /memory/search 2822: uno dei due mente, e il lint della memoria si basa su quel numero
+* Riparare intestazione #ERROR! nello sheet STATE 1KRoCu
+* Creare una route o script per cancellare record di memoria (oggi non esiste)
 * Recuperare da v6.4: R49 edit/rename Docs -> routing DRIVE, R47 routing per tier -> Master, R45 pattern RLM -> routing dati
 * Compilare i 7 routing file dallo harvest in /home/claudeuser/routing_src/
-* Cercare i chiamanti cron delle 525 route prima di archiviarle
 [[Categoria:Domini operativi]]