fix(bill-progress): valorizza presentation_date e initiative_description sul ramo Camera

[aborruso]

Closes #74.

Sul ramo Camera di bill-progress le colonne presentation_date e initiative_description erano hardcoded a stringa vuota, pur essendo il dato presente sull'atto — la stessa risorsa che la query già interrogava — e già letto senza problemi da bills list.

Modifica

Due OPTIONAL nella query esistente (dc:date, ocd:iniziativa) e mappatura dei due campi, con dc:date passata per il fmtDate già presente (YYYYMMDD → ISO, come il ramo Senato). Nessuna query aggiuntiva, nessun costo di rete.

nature resta vuota: dc:type è semantica diversa, fuori dallo scopo dell'issue.

Sulla dedup

Il commento nel codice avverte che proiettare variabili in più in SELECT DISTINCT può moltiplicare le righe. Verificato prima di editare: zero atti con più di un dc:date o più di un ocd:iniziativa in legislatura 17, 18 e 19 — cardinalità 1, nessuna moltiplicazione. Il motivo è annotato nel codice.

Verifica

ac19_824 (PDL costituzionale Morrone, separazione delle carriere): 6 righe prima, 6 righe dopo, e i campi ora popolati.

{"status":"Da assegnare","status_date":"2023-01-26","presentation_date":"2023-01-26","initiative_description":"Parlamentare"}
...
{"status":"Assorbito dall'approvazione di pdl abbinato","status_date":"2025-01-16","presentation_date":"2023-01-26","initiative_description":"Parlamentare"}

Provati anche un atto di iniziativa governativa (ac19_1930 → Governo) e un caso in legislatura 18 via --number 1354 --branch C (→ Parlamentare, presentazione 2018-11-08).

npm test -- --run: 177 passati. I 2 falliti sono senato-votes in 403, cioè #72 — preesistenti e indipendenti da questa modifica.

Nota

presentation_date di solito coincide con la data del primo statoIter, ma non sempre: in legislatura 19 divergono su 23 atti. Dedurla dalla prima riga sarebbe stata un'euristica sbagliata in quei casi.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Questo PR corregge il tool bill-progress (ramo Camera) popolando correttamente le colonne presentation_date e initiative_description, che prima erano hardcoded a stringa vuota pur essendo dati disponibili sulla stessa risorsa atto già interrogata dalla query. Il cambiamento mantiene l’approccio “single query” (nessun roundtrip aggiuntivo) e allinea l’output Camera al comportamento già presente in altri tool.

Changes:

• Estesa la query SPARQL Camera in cameraIterTimeline con due OPTIONAL su dc:date e ocd:iniziativa.
• Mappati i nuovi binding su presentation_date (formattata via fmtDate) e initiative_description.
• Aggiunta nota in commento sul perché la proiezione di ?pres/?ini non altera la deduplica (SELECT DISTINCT) dato che sono proprietà dell’atto con cardinalità 1 (come indicato nel commento).

[greptile-apps]

Greptile Summary

Populates Camera bill-progress presentation metadata without additional network requests.

• Extends the existing SPARQL query with optional presentation date and initiative fields.
• Formats Camera presentation dates consistently with the existing timeline date format.
• Maps initiative descriptions into the existing response contract.

Important Files Changed

Filename	Overview
src/tools/bill-progress.ts	Safely extends the Camera timeline query and mapping with optional act-level presentation metadata; missing values retain the existing empty-string convention.

_{Reviews (1): Last reviewed commit: "fix(bill-progress): valorizza presentati..." | Re-trigger Greptile}