docs(log): 2026-07-25 — fix 403 senato-votes e bill-progress Camera

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: aborruso

LOG.md

@@ -1,5 +1,13 @@
 # LOG
 
+## 2026-07-25
+
+- **fix `senato-votes` — eliminati i 403 sistematici da query troppo lunga, e misurato il limite vero dell'endpoint Senato** (#72, PR #76) — `senato-votes --keyword` falliva sempre con 403 a meno di aggiungere `--final-vote true` o `--confidence-vote false`. Non era il blocco anti-burst: l'endpoint accetta una request-URI (`/sparql?query=…`) fino a **2047 byte** e da **2048** in su risponde con una pagina 403 HTML — non un 414, non un errore SPARQL. Confine trovato per bisezione al singolo byte, con query di controllo a 200 subito prima e subito dopo ogni misura (un blocco per frequenza respinge anche l'hello-world; qui no). Il **POST è sempre rifiutato**, anche su 448 byte, quindi il limite non si aggira spostando la query nel corpo: l'unica strada è tenere corta la GET. La Camera, per confronto, accetta query da 4 KB: `votes.ts:369` ha lo stesso pattern OR-chain ma non è a rischio e resta invariato. Sotto la soglia finivano **tre** query, non una: le OR-chain `FILTER(STR(?f) = "S.<num>" || …)` in due punti distinti (supplemento fiducie e Fallback 1), con 53 fiducie in leg. 19, ora spezzate in blocchi da 25 con merge invariato first-wins; e soprattutto **la query principale, che sfora da sola** appena la keyword è multi-parola (2059 byte con `"corte dei conti"`), dove non c'è nessuna lista da spezzare — il chunking non l'avrebbe mai risolta. Rimossa l'indentazione, che finisce dritta nella URI, e ridotto l'header dei prefissi ai due effettivamente usati (`xsd:` solo quando serve): 2081 → 1926 byte. La keyword entra **tre volte** nella query (label, `osr:titolo`, `osr:titoloBreve`), quindi la lunghezza cresce di circa tre volte la keyword e il margine non è infinito: `BIND` risolverebbe alla radice ma questa istanza Virtuoso non lo supporta, perciò `assertQueryFits` blocca in partenza con un messaggio che dice cosa fare, invece di lasciare arrivare un 403 opaco. Nuovi helper `src/core/chunk.ts` e `src/core/senato-query-size.ts` (+10 test, incluso il confine esatto 2047/2048, così il prossimo filtro aggiunto non rompe la soglia in silenzio). Verifica: la fiducia sul DL 48/2025 del 2025-06-04 (109-69-1) torna nei risultati ed è proprio una riga che arriva dal supplemento — il suo label non contiene "sicurezza" — quindi il chunking non perde nulla; 189/189 test verdi. **Lezione**: i due test `senato-votes` rossi da giorni sembravano rate limit della suite, ma fallivano anche isolati in 0,6 s con l'endpoint raggiungibile — era il difetto.
+
+- **fix `bill-progress` (Camera) — `presentation_date` e `initiative_description` non sono più vuoti** (#74, PR #75) — sul ramo Camera le due colonne erano hardcoded a stringa vuota pur essendo il dato sulla stessa risorsa già interrogata dalla query, e già letto senza problemi da `bills list`. `initiative_description` non è ricavabile in nessun altro modo dalla timeline (governativa, parlamentare o popolare è la prima cosa che si guarda in un iter), e `presentation_date` di solito coincide con la data del primo `statoIter` ma non sempre: in leg. 19 divergono su **23 atti**, quindi dedurla dalla prima riga era un'euristica sbagliata in quei casi. Fix a costo zero: due `OPTIONAL` (`dc:date`, `ocd:iniziativa`) nella query esistente, nessuna chiamata di rete in più. Proiettarle in `SELECT DISTINCT` è sicuro perché sono proprietà dell'atto con cardinalità 1 — verificato prima di editare su leg. 17, 18 e 19: zero atti con più di un valore, nessuna moltiplicazione di righe (`ac19_824`: 6 righe prima, 6 dopo). `nature` resta vuota: `dc:type` è semantica diversa, fuori dallo scopo.
+
+- **documentazione della trappola** — la skill CLI (`skills/italian-parliament-cli/SKILL.md`) ora distingue i due 403 del Senato, che si presentano identici ma vogliono reazioni opposte: "Query troppo lunga" (errore locale, prima di uscire in rete) → accorciare keyword o restringere le date, ritentare è inutile; `403` dall'endpoint → richieste troppo ravvicinate, aspettare, ritentare a raffica peggiora. Il materiale è confluito anche nella campagna (`docs/campagna-parlamento-aperto/02-dossier-tecnico.md`, voci D2 e D3 + tabella di sintesi) e nella nota al Webmaster Senato (punti 11 e 12, da inviare): il limite di dimensione sommato al POST rifiutato rende **una query lunga non inviabile in alcun modo**, e il fatto che tutte le cause di rifiuto rispondano con lo stesso 403 HTML porta i client a ritentare identico invece di accorciare — codici HTTP corretti (`413`/`414`, `429` con `Retry-After`) ridurrebbero il traffico inutile verso i loro server. È il gap con il costo di intervento più basso dell'intero dossier: configurazione, non tecnologia.
+
 ## 2026-07-20
 
 - **fix `votes` (Camera) — i voti su emendamento con descrizione a codice secco ora si agganciano all'atto** — sulla seduta `s19_689` (14/7/2026, prima lettura della legge elettorale) l'intera giornata è priva di `ocd:rif_attoCamera` alla fonte e solo due votazioni su dodici citano `"PDL 2822-A"` nel testo: le altre dieci hanno `dc:description` a codice secco (`"EM 1.1077"`, `"SUBEM 0.1.1077.4"`) e restavano senza `bill_uri`. Tra queste il voto sull'emendamento preferenze, 188 contrari / 187 favorevoli, cioè il voto che ha deciso la vicenda: un giornalista che filtrava i voti per numero di atto lo perdeva. Aggiunto un terzo livello di fallback in cascata (`inheritBillFromSession`): quando l'**intera** seduta verte su un solo atto, quello è l'atto anche dei voti muti. La monotematicità è calcolata con una query dedicata sulla seduta completa — mai sulle righe già filtrate in memoria, dove un `--date-from` o un `LIMIT` stretto possono mostrare un solo atto mentre la seduta ne tratta quattro — e l'insieme degli atti unisce `rif_attoCamera` e i numeri citati nelle descrizioni delle altre votazioni (su `s19_689` il primo insieme è vuoto). Mozioni e risoluzioni sono escluse: sono AIC a sé stanti, ereditare l'atto della seduta le legherebbe a un provvedimento che non le riguarda. Impatto misurato: sui 1000 voti del 2026 almeno 178 righe guadagnano il collegamento all'atto (copertura 369→547). Solo il 37% delle sedute leg. 19 è monotematico, quindi il resto resta deliberatamente senza aggancio invece di rischiare attribuzioni sbagliate. Estratto l'helper `resolveActUris` condiviso coi fallback precedenti (nessun URI fabbricato: il numero base è sempre verificato via `dc:identifier`). +4 test (aggancio, non-regressione su seduta multi-atto, guardia mozioni/risoluzioni, coerenza legislatura↔atto su finestra cross-legislatura). Nuova nota wiki OKF `docs/lod-wiki/camera/votazioni-atto-collegato.md` con i conteggi del buco per legislatura e le tre famiglie di `dc:description`. Emerso dal report news-agent `2026-07-20_19-49.md`. **Residuo noto**: `--bill-code` filtra `dc:description` lato server, quindi a monte dell'ereditarietà — i voti a codice secco restano fuori da quel percorso e vanno raggiunti per intervallo di date filtrando poi su `bill_number`. Renderlo consapevole della seduta significa selezionare l'intera seduta e filtrare a valle, con il `LIMIT` che non varrebbe più sulle righe restituite: tenuto fuori deliberatamente.