Cantieri aperti

Pagina generata automaticamente da handoff.py. Non modificare a mano: le modifiche vengono sovrascritte.

Ogni cantiere e' lo stato di un lavoro in corso, scritto durante la sessione e non alla fine. Chi riparte legge: HARNESS + il routing file del dominio + il cantiere. Nient'altro.

Cantieri attivi

harness-standard

Aggiornato 2026-08-08 07:54 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

Vincoli in vigore

• La gerarchia deve SOSTITUIRE substrati esistenti, mai affiancarsi: oggi ne esistono 7 paralleli
• Ogni routing file ha 6 sezioni fisse: chi esegue / accessi / come si verifica / criterio di accettazione / fallimenti noti / strumenti ammessi
• Nessuna credenziale nei routing file, solo puntatori

Fatto (con prova)

• Analizzato export completo Claude di marcoparet@gmail.com: 614 conversazioni, 26.921 messaggi, 55,8M caratteri (file su VM /home/claudeuser/claude_export/analysis/)
• Misurato: attrito piatto sulla lunghezza della chat (14-18 per 100 msg in ogni fascia) = problema strutturale non di contesto
• Misurato: autocorrezioni Claude raddoppiano oltre 25-50k token di contesto (8,8 -> 17,2 per 100 msg) = context rot reale, ginocchio a 25-50k
• Misurato: 899 route nel bucket, 525 MAI citate in nessuna chat, ~25 reggono il sistema
• Misurato: 8 domini coprono il traffico (spedizioni 190 chat, VM 155, BQ 151, hosting 118, token 114, route 77, drive 76, wiki 59)
• Scritti HARNESS.md (1 pagina) e INFRA-VM.md (primo routing file compilato)
• Creato handoff.py su VM + pagina wiki Cantieri aperti
• MASTER READ ORDER v7.1 scritto: 1 pagina, 3 regole, tabella routing 8 domini, STEP cantieri, STEP handoff, STEP asincronia, Appendice A per modelli non-Claude
• INFRA-VM.md primo routing file compilato su 6 sezioni fisse
• handoff.py operativo su VM (GCS + wiki + memoria CC in una chiamata), testato write/resume/list
• Pagina wiki Cantieri aperti creata e verificata via getText.php
• MISURATO tassa di interruzione: 34,3 pc dei messaggi Claude chiede a Marco di decidere, 17,1 pc di eseguire a mano, sincrono/asincrono 4,2:1, turni di sola continuazione solo 2,7 pc (sintomo non causa)
• v7.1 APPESA sul canonico Drive 1Iyxrr5 (ok:true) — la v6.3 e superata
• BUG RISOLTO: browser_service.js su :8081 vuole POST con secret, il GET ?url= documentato per mesi era sbagliato: per questo la verifica headless falliva in silenzio. Creato scripts/shot.py, testato su wiki Cantieri aperti (149 KB, titolo corretto)
• Creato gs://isicnv-command-center-routes/TOKENS_STATUS.json = fonte di verita su token vivi/morti/non-Google
• Creato state/routes_inventory.json: 525 route su 899 mai citate in chat
• Harvest memoria per 5 dei 7 routing file in /home/claudeuser/routing_src/
• DRIVE ALLINEATO: canonico 1Iyxrr5 rinominato v7.1, intestazione in cima che punta alla versione corrente, v7.1 appesa in fondo (122.869 car, verificato)
• Caricato .txt v7.1 su Drive id 1TzhV-dMUTpXnGdwbxmxvk3iV9RR0ZVME nella cartella 1VQLc638
• Marcati SUPERATO i .txt v6_3 e v6_4 (rinominati, non cancellati)
• SCOPERTA v6.4 del 09/07 mai citata nelle regole (che dicevano v6.3): conteneva DUE serie di regole con gli stessi numeri (due R45, due R46, due R47) — la numerazione si era scontrata con se stessa
• BUG CRITICO TROVATO: /vm/task NON esegue bash. Passa la stringa alla CLI Claude Code sulla VM, che e scollegata (Not logged in). Restituisce status DONE in 5 secondi SENZA eseguire nulla (verificato: /tmp/t_start non creato). Inoltre il parametro si chiama task non cmd: chi usa cmd prende error task required
• 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
• VERIFICA TOTALE eseguita con script verify_all.py via job.py: 24 controlli su 24 PASS al secondo giro. Primo giro 4 FAIL, tutti corretti
• ERRORE MIO TROVATO E CORRETTO: il .txt v7.3 caricato su Drive conteneva in realta la v7.2, per un replace v7.2->v7.3 che non catturava v7_2 con underscore. Vero v7.3 ora su Drive id 1-noo7YFS-gzhidiWO0fJzLW7rxL-VTUQ (12.955 byte)
• ERRORE MIO TROVATO E CORRETTO: INFRA-VM.md era citato nel Master ma non esisteva in nessun posto durevole, solo come allegato di chat. Ora su Drive id 1Y6ZUeoQnK514ob5-3iiR0qMYZBD_kQPJ
• BUG NUOVO: /memory/search riporta total_indexed instabile fra chiamate successive (2821, 2822, 1932). L indice non e deterministico
• EVAL HARNESS COSTRUITO: /home/claudeuser/scripts/eval_harness.py. Metodo: 6 casi doro derivati da fallimenti reali del 07/08, modello candidato DeepSeek legge il Master e dice cosa farebbe, giudice indipendente Kimi K2 valuta la TRAIETTORIA non la prosa
• PRIMO GIRO 2/6. Corretto STEP 2 del Master (--list SEGUITO da --resume, obbligatorio) -> v7.4 pubblicata
• SECONDO GIRO 5/6. Ciclo misura-correggi-rimisura funzionante
• SCOPERTA CRITICA: il giudice NON e affidabile. Primo giro ha bocciato job_lungo per uso del path assoluto (risposta in realta perfetta)
• secondo giro ha bocciato verifica_pagina che al primo giro aveva promosso, a documento invariato su quel punto. Instabilita del giudice fra run identiche

Provato ed escluso

• Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC
• Ridurre la lunghezza delle chat come rimedio: i dati mostrano che non e la lunghezza il problema
• Marcatore regex bloccato per misurare Claude in difficolta: falsi positivi pesanti (denaro bloccato, siti bloccati AGCOM)
• La cartella Drive 1TpajgASPSO non e accessibile da nessun account: 404 su tutti i token
• Creare un nome nuovo tipo HARNESS.md accanto al Master: errore, aggiungeva un substrato invece di sostituirlo. Il nome resta MASTER READ ORDER
• Ridurre i turni continua come rimedio: sono il 2,7 pc, il costo vero sono le domande di Claude
• Spostare subito le 525 route in routes_deprecated: mai citata in chat NON significa mai usata, possono esserci chiamanti cron o altre route. Prima cercare i chiamanti
• Rinominare o cancellare i token morti: si rompe chi li referenzia. Meglio TOKENS_STATUS.json come fonte di verita, senza toccare i file
• Cancellare i vecchi .txt: rinominati SUPERATO, reversibile
• Riscrivere il canonico da zero: e append-only per tracciabilita, si aggiunge intestazione in cima
• 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
• Fidarsi di un upload senza rileggere il file caricato: il nome era giusto ma il contenuto no. La verifica deve confrontare il CONTENUTO, non solo lo status 200
• Usare un modello giudice come CANCELLO di autorizzazione a procedere: produce falsi FAIL, quindi bloccherebbe lavoro corretto. Va usato come valutatore aggregato su golden set, con revisione umana dei numeri, non come autorita per singola decisione

Prossimo passo

• Stabilizzare il giudice: 3 run per caso e voto di maggioranza, oppure due giudici diversi e disaccordo = revisione umana
• Aggiungere casi doro sui domini mancanti (spedizioni, BQ, hosting)
• Capire perche /memory/search da total_indexed instabile (2821/2822/1932)
• Compilare i 7 routing file dallo harvest in /home/claudeuser/routing_src/
• Recuperare da v6.4: R49 edit/rename Docs, R47 routing per tier, R45 pattern RLM