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

Riga 7:

== Cantieri attivi ==

=== modalita-contabilita ===

''Aggiornato 2026-08-25 14:56 UTC'' — dominio: finance

; Obiettivo : Modalita Contabilita: rispondere in automatico a Perche questa spesa (alert ARGO) collegando classificazione, ricorrenti attesi, contratti fornitori e Tier1 ads ROI del TESORIERE

; Vincoli in vigore :

* NON ripartire da zero: spec TESORIERE architecture_1783460671236_4nxv6j

* riusare classification_rules (678 regole), controparti, pagamenti_ricorrenti_attesi, tesoriere_v2.py, argo_watch.py

* MAI LLM sui numeri

* coordinarsi col cantiere finanze-classificazione

; Fatto (con prova) :

* Riletto MRO v7.1 completo

* recuperata spec TESORIERE 4 tier

* censiti asset esistenti (tabelle isicnv_finance, tesoriere_daily/v2, cantiere finanze-classificazione)

* best practices raccolte: tagging deterministico prima di tutto, alert+allocazione insieme, closed-loop spesa-lead-ricavo con identificatore comune

; Provato ed escluso :

* Progettare rami di spesa ex novo: esistono gia come classification_rules+controparti+tier

* /memory/get non esiste, full text memoria via gsutil su GCS

; Prossimo passo :

* 1) perche_spesa.py: dato movimento produce report 5 blocchi (identificazione, classificazione+ricorrenza attesa, serie storica, risultati Tier1 se ADV, verdetto LEGITTIMO/ANOMALO) e agganciarlo ad argo_watch.py 2) tabella contratti_fornitori partendo da VMK (BLOCCATO: serve da Marco accordo mensile VMK e dove stanno le fatture) 3) pagina wiki Contabilita con template e routing 4) sentinella DA_CLASSIFICARE (prossimo passo cantiere finanze-classificazione)

=== cruscotto-marketing-quotidiano ===

''Aggiornato 2026-08-25 11:25 UTC'' — dominio: ads/analytics/report

@@ Riga 7: / Riga 7: @@
 == Cantieri attivi ==
+=== modalita-contabilita ===
+''Aggiornato 2026-08-25 14:56 UTC'' &mdash; dominio: finance
+; Obiettivo : Modalita Contabilita: rispondere in automatico a Perche questa spesa (alert ARGO) collegando classificazione, ricorrenti attesi, contratti fornitori e Tier1 ads ROI del TESORIERE
+; Vincoli in vigore :
+* NON ripartire da zero: spec TESORIERE architecture_1783460671236_4nxv6j
+* riusare classification_rules (678 regole), controparti, pagamenti_ricorrenti_attesi, tesoriere_v2.py, argo_watch.py
+* MAI LLM sui numeri
+* coordinarsi col cantiere finanze-classificazione
+; Fatto (con prova) :
+* Riletto MRO v7.1 completo
+* recuperata spec TESORIERE 4 tier
+* censiti asset esistenti (tabelle isicnv_finance, tesoriere_daily/v2, cantiere finanze-classificazione)
+* best practices raccolte: tagging deterministico prima di tutto, alert+allocazione insieme, closed-loop spesa-lead-ricavo con identificatore comune
+; Provato ed escluso :
+* Progettare rami di spesa ex novo: esistono gia come classification_rules+controparti+tier
+* /memory/get non esiste, full text memoria via gsutil su GCS
+; Prossimo passo :
+* 1) perche_spesa.py: dato movimento produce report 5 blocchi (identificazione, classificazione+ricorrenza attesa, serie storica, risultati Tier1 se ADV, verdetto LEGITTIMO/ANOMALO) e agganciarlo ad argo_watch.py 2) tabella contratti_fornitori partendo da VMK (BLOCCATO: serve da Marco accordo mensile VMK e dove stanno le fatture) 3) pagina wiki Contabilita con template e routing 4) sentinella DA_CLASSIFICARE (prossimo passo cantiere finanze-classificazione)
 === cruscotto-marketing-quotidiano ===
 ''Aggiornato 2026-08-25 11:25 UTC'' &mdash; dominio: ads/analytics/report