Vai al contenuto

Cantieri aperti

Da Wiki Progetto di Ricerca Metodo Paret.
Versione del 7 ago 2026 alle 09:06 di WikiBot (discussione | contributi) (handoff automatico)

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-07 09:06 UTC — dominio: architettura / knowledge base

Obiettivo
Sostituire il MASTER READ ORDER monolitico con un harness gerarchico: 1 entry point + 8 routing file di dominio, 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)
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
Prossimo passo
  • Marco approva -> append v7.1 sul canonico Drive 1Iyxrr5 via /docs/append-v2 e bump versione
  • Compilare i 7 routing file mancanti sullo schema INFRA-VM, ordine: spedizioni 190, bigquery 151, hosting 118, token 114, route CC 77, drive 76, wiki 59
  • Archiviare 525 route mai usate in routes_deprecated/
  • Deprecare 6 token invalid_grant e separare i non-Google dal prefisso token-
  • Pulire record memoria spazzatura system_state_1786092629694_7idl9o
  • Verificare servizio headless localhost:8081 che risponde 405