Vitruvyan Docs
Vitruvyan Frontier — Odoo Connector Roadmap
Last updated: Mar 15, 2026 14:00 UTC
Cos'è Vitruvyan Frontier
Vitruvyan Frontier è la linea di connettori premium che collega sistemi enterprise (ERP, CRM, ECM) al kernel epistemico Vitruvyan. Ogni connettore è un plugin di Oculus Prime — non un servizio separato — che si registra sull'APIRegistry esistente tramite auto-discovery via Python entry points.
Modello commerciale:
| Tier | Contenuto | Prezzo |
|---|---|---|
| Core | Vitruvyan OS + Oculus Prime (7 media agents + GDrive + APIRegistry) | Open / gratuito |
| Frontier (per connettore) | vitruvyan-frontier-odoo, vitruvyan-frontier-sap, etc. | Premium (licenza) |
| Enterprise Bundle | Tutti i connettori Frontier + supporto prioritario | Enterprise |
Website: Pagina dedicata /frontier — spec in omni-ui/FRONTIER_PAGE_ABSTRACT.md
Obiettivo
Collegare una sandbox Odoo a Vitruvyan tramite il primo connettore Vitruvyan Frontier per dimostrare il sistema come cognitive layer aziendale: l'utente fa domande in linguaggio naturale e ottiene risposte narrative con dati ERP reali, passando per l'intero pipeline epistemico (Perception → Memory → Reason → Discourse → Truth).
Architettura
Decisioni architetturali chiave:
- Plugin inside Oculus Prime — zero container aggiuntivi, stessa pipeline evidence, stesso bus
- Dominio "enterprise" unico — non un dominio per ogni ERP; il fetcher normalizza i dati ERP-specifici, la cognizione è universale
- Auto-discovery —
pip install vitruvyan-frontier-odoo→ Oculus Prime lo scopre automaticamente al boot via entry points
Prerequisiti
- Stack Vitruvyan attivo (redis, postgres, qdrant, graph, babel, codex, memory, pattern, vault, orthodoxy, conclave, mcp, embedding, oculus_prime)
- Accesso a sandbox Odoo (es.
demo.odoo.como istanza self-hosted) - Credenziali Odoo (database, username, API key)
Fase 0 — Env vars e config
Dove: infrastructure/docker/.env
Contratti rispettati: Nessun secret hardcoded nel codice (Golden Rule).
Fase 1 — Fetcher Odoo (Perception / Oculus Prime)
1.0 — Struttura pacchetto Frontier
Sviluppo iniziale: dentro vitruvyan-core come reference implementation (sotto infrastructure/edge/oculus_prime/plugins/frontier_odoo/). Quando validato, viene estratto in un repo separato vitruvyan-frontier-odoo per distribuzione premium.
pyproject.toml (template per il pacchetto standalone futuro):
Auto-discovery in Oculus Prime (da aggiungere a APIRegistry):
CLI: vit install frontier-odoo → wrappa pip install vitruvyan-frontier-odoo + riavvia Oculus Prime.
1.1 — Creare i fetcher
Dove: infrastructure/edge/oculus_prime/plugins/frontier_odoo/fetchers.py
Contratto: AbstractAPIFetcher da api_intake.py
Modelli Odoo da coprire (3 fetcher, un file):
| Fetcher class | Odoo model | Dati estratti |
|---|---|---|
OdooInvoiceFetcher | account.move | Fatture emesse/ricevute, importi, scadenze, stato pagamento |
OdooSaleOrderFetcher | sale.order | Ordini di vendita, righe prodotto, quantità, totali |
OdooPartnerFetcher | res.partner | Clienti/fornitori, anagrafica, categorie |
4 metodi astratti per ciascun fetcher:
Attenzione: Odoo usa XML-RPC (non REST puro). Il fetcher wrappa xmlrpc.client.ServerProxy dentro il pattern AbstractAPIFetcher, delegando l'auth a un modulo auth.py con classe OdooAuthenticator che restituisce lo uid e lo cachea.
1.2 — Normalized text (contratto IntakeGuardrails)
Il normalized_text dell'Evidence Pack DEVE essere letterale-descrittivo, validato da IntakeGuardrails.validate_no_semantics():
1.3 — Evidence Pack (contratto schema.sql)
1.4 — Registrazione su APIRegistry (auto-discovery)
Due modalità (coesistono):
A) Auto-discovery via entry points (produzione — pacchetti installati con pip/vit):
B) Registrazione esplicita (sviluppo locale — plugin nel repo):
In entrambi i casi, zero nuovi container — i fetcher vivono dentro Oculus Prime.
1.5 — Evento StreamBus
Il fetcher NON emette eventi direttamente. Il flusso è:
Payload evento (contratto EvidenceCreatedEvent):
1.6 — Endpoint API (opzionale, per trigger manuale)
Dove: services/api_edge_oculus_prime/api/routes.py — nuovo endpoint
1.7 — Ingestione schedulata (opzionale)
Dove: services/api_edge_oculus_prime/streams_listener.py (attualmente placeholder)
Cron o scheduled task che ogni N ore fa fetch incrementale:
- Filtro:
write_date > last_fetch_timestamp - Persiste il timestamp in PostgreSQL per idempotenza
- Usa
idempotency_key= SHA-256 di(source_system, source_model, source_id, write_date)per evitare duplicati
Fase 2 — Pipeline epistemico (zero codice, già cablato)
Una volta che gli Evidence Pack sono sul bus, il pipeline esistente li processa automaticamente:
Nessun codice da scrivere in questa fase. Il pipeline è event-driven via StreamBus.
Fase 3 — Query in linguaggio naturale (Graph / CAN)
3.1 — Intent config enterprise (dominio unico condiviso)
Il dominio "enterprise" è unico per tutti i connettori Frontier — non esiste un dominio "odoo", "sap", "salesforce". Il fetcher normalizza i dati ERP-specifici; la cognizione opera su entità universali (clienti, fatture, ordini).
Dove: vitruvyan_core/domains/enterprise/intent_config.py
Contratto: IntentRegistry, IntentDefinition, ScreeningFilter
Attivazione: INTENT_DOMAIN=enterprise nel .env
3.2 — Vertical manifest
Dove: vitruvyan_core/domains/enterprise/vertical_manifest.yaml
Fase 4 — Demo script e ingestione iniziale
4.1 — Script di ingestione bulk
Dove: scripts/odoo_initial_ingest.py
4.2 — Scenari demo (5 domande precaricate)
| # | Domanda | Pipeline path | Output atteso |
|---|---|---|---|
| 1 | "Quanto abbiamo fatturato questo mese?" | Graph → RAG (Memory Orders) → CAN | Importo totale, numero fatture, ticket medio, variazione vs mese precedente |
| 2 | "Quali clienti hanno fatture scadute?" | Graph → RAG → CAN | Lista clienti con importi scaduti, giorni di ritardo, priorità |
| 3 | "Confronta vendite Q4 vs Q3" | Graph → Pattern Weavers + RAG → CAN | Delta %, driver principali, variazione margine |
| 4 | "C'è qualcosa di anomalo negli ordini?" | Graph → Pattern Weavers (anomaly) → CAN | Ordini fuori pattern (quantità, inattività, frequenza) con spiegazione |
| 5 | "Dimmi tutto su Rossi SpA" | Graph → Codex (entity) + RAG → CAN | Grafo relazionale: fatturato, ordini, scaduto, trend, anomalie — tutto narrativo |
Fase 5 — Test e validazione
5.1 — Unit test fetcher (LIVELLO 1, nessun I/O)
Dove: infrastructure/edge/oculus_prime/plugins/frontier_odoo/tests/test_fetchers.py
- Test
build_params()con diversi filtri - Test
parse_response()con mock response Odoo - Test
create_evidence_metadata()— verifica struttura source_ref - Test
validate_no_semantics()sul normalized_text generato
5.2 — Integration test (con sandbox Odoo)
Dove: scripts/test_odoo_integration.py
- Connessione a sandbox Odoo
- Fetch reale di 10 fatture
- Verifica Evidence Pack in PostgreSQL
- Verifica evento su StreamBus
- Verifica embedding in Qdrant (post-pipeline)
5.3 — E2E test (domanda → risposta)
- Ingestione dati Odoo
- Query via graph API: "Quanto abbiamo fatturato?"
- Verifica che la risposta contenga dati reali dalla sandbox
File deliverables (riepilogo)
| Fase | File | Tipo | Note |
|---|---|---|---|
| 0 | .env (variabili Odoo + INTENT_DOMAIN=enterprise) | Config | 5 min |
| 1.0 | infrastructure/edge/oculus_prime/plugins/frontier_odoo/__init__.py | Nuovo | Package Frontier |
| 1.0 | infrastructure/edge/oculus_prime/plugins/frontier_odoo/pyproject.toml | Nuovo | Template pacchetto standalone |
| 1.1 | infrastructure/edge/oculus_prime/plugins/frontier_odoo/fetchers.py | Nuovo | Core fetcher (3 classi) |
| 1.1 | infrastructure/edge/oculus_prime/plugins/frontier_odoo/auth.py | Nuovo | OdooAuthenticator |
| 1.6 | services/api_edge_oculus_prime/api/routes.py | Edit | Endpoint ERP |
| 3.1 | vitruvyan_core/domains/enterprise/__init__.py | Nuovo | Dominio enterprise (condiviso) |
| 3.1 | vitruvyan_core/domains/enterprise/intent_config.py | Nuovo | Intent registry |
| 3.2 | vitruvyan_core/domains/enterprise/vertical_manifest.yaml | Nuovo | Manifest |
| 4.1 | scripts/odoo_initial_ingest.py | Nuovo | Script ingestione bulk |
| 5.1 | infrastructure/edge/oculus_prime/plugins/frontier_odoo/tests/test_fetchers.py | Nuovo | Unit test |
Codice Vitruvyan core toccato: 1 edit (routes.py — endpoint opzionale). Tutto il resto è estensione plugin.
Ordine di esecuzione
Strategia distribuzione
Fase sviluppo (ora)
Plugin sviluppato dentro vitruvyan-core come reference implementation:
Registrazione esplicita in main.py di Oculus Prime.
Fase produzione (post-validazione)
Estrazione in repo separato vitruvyan-frontier-odoo:
Installazione: pip install vitruvyan-frontier-odoo o vit install frontier-odoo
Auto-discovery: Oculus Prime scopre i fetcher via importlib.metadata.entry_points(group="vitruvyan.oculus_connect") al boot.
Connettori futuri (stesso pattern)
| Pacchetto | ERP/CRM | Status |
|---|---|---|
vitruvyan-frontier-odoo | Odoo | 🔵 In sviluppo |
vitruvyan-frontier-sap | SAP S/4HANA | ⚪ Planned |
vitruvyan-frontier-salesforce | Salesforce | ⚪ Planned |
vitruvyan-frontier-sharepoint | SharePoint / M365 | ⚪ Planned |
Tutti i connettori condividono lo stesso dominio enterprise e la stessa pipeline evidence.
Dipendenze esterne
| Dipendenza | Necessaria? | Note |
|---|---|---|
xmlrpc.client | Sì | Stdlib Python — zero pip install |
| Odoo sandbox | Sì | demo.odoo.com (gratuito, reset giornaliero) o istanza self-hosted |
| Nuove librerie pip | No | Tutto stdlib + librerie già nel requirements |