Una meta-repo orchestra i 3 componenti reali di iAgro — Flutter, .NET 8 a moduli CQRS e la VM Python di computer vision — con 21 agenti specializzati e security review obbligatoria.
Il workspace è il "cervello" dello sviluppo: istruzioni globali, agenti, masterplan e regole di sicurezza. Il codice di prodotto vive sotto iAgro/, ognuno con il proprio CLAUDE.md e i propri agenti.
# Agrobit Dev pipeline — orchestrazione Agrobit Dev pipeline/ ├── CLAUDE.md # istruzioni globali AI ├── .claude/agents/ # 6 orchestratori ├── catalog/repos.yml # i 3 componenti ├── masterplans/YYYY/MM/ # documenti di design ├── docs/security/ # 5 doc di sicurezza └── iAgro/ # CODICE DI PRODOTTO ├── Agrobit-Mobile/ # Flutter + CLAUDE.md + agenti ├── api/ # .NET 8 + CLAUDE.md + agenti └── VM iAgro/ # Python CV/DL + CLAUDE.md + agenti
Contiene solo orchestrazione. I 3 componenti mantengono la propria storia git e i propri agenti.
Ogni componente ha i pattern reali del suo stack (BLoC, CQRS, pipeline CV). Le regole del workspace sono ereditate.
Claude naviga Mobile → API .NET → VM Python e applica modifiche coordinate in un'unica sessione.
Un sistema a tre strati: l'app sul campo, il backend modulare che custodisce dati e logica, e il motore di computer vision che trasforma le acquisizioni in modelli 3D, mappe e stime di resa.
App i_agro iOS/Android/web: acquisizioni georeferenziate, 3D/AR, mappe, diagnosi, resa, report.
Monolite modulare CQRS: organizzazioni, FarmCenters, Fields, Acquisitions, Maps, Media, Shop, Surveys.
Motore su VM Azure: 3 pipeline — modelli 3D, mappe vigore/prescrizione (CV classica) e stima resa (deep learning).
Agrobit-Mobile (Flutter, BLoC) │ http + JWT ▼ Agrobit-API (.NET 8 · CQRS/MediatR · EF Core → SQL Server) ├── Azure Blob Storage # immagini / acquisizioni / output ├── Agrobit.Agricolus.SDK # integrazione partner Agricolus └── chiama → VM iAgro (FastAPI) ├── POST /3dmodel # Pipeline 1 — modelli 3D (q1→r1) ├── POST /map # Pipeline 2 — mappe vigore/prescrizione (q2→r2) └── resa # Pipeline 3 — stima resa grappoli, DL (q3→r3)
VM ibrida: CV classica (GDAL/rasterio/scikit-image) per mappe e 3D · deep learning (Faster R-CNN, YOLOv9-seg, SAM, Depth-Anything-V2) per la stima resa.
Sei orchestratori cross-componente coordinano quindici specialisti — uno conosce a fondo un solo stack. Niente tuttologi generici.
product-ux-designermasterplan-architectmasterplan-executorcodebase-researcherbest-practices-researchermockup-builderPlanning con ricerca in parallelo, approvazione dell'utente, poi implementazione coordinata con security review obbligatoria.
masterplan-architect ├── codebase-researcher # per componente ├── best-practices # ricerca web └── mockup-builder # dopo il testo ▼ masterplan.md + mockup.html ▼ L'utente revisiona → Approved ✓
═══ APPROVAZIONE UTENTE ═══ ▼ masterplan-executor ├── Agrobit-Mobile/ dev ↔ review ├── api/ (.NET) dev ↔ review └── VM iAgro/ dev ↔ review └── cv-agronomy-validator ▼ security review incrementale
Ogni modifica passa una security review. Cinque documenti coprono OWASP Top 10 su mobile, .NET, VM Python e Azure.
Ogni operazione del backend .NET è scopata per organizationId — niente accesso cross-organizzazione (IDOR).
La VM lancia pipeline via subprocess: parametri validati e whitelistati prima dell'esecuzione.
Chiavi, connection string, config Firebase fuori dal sorgente. Azure Key Vault / variabili d'ambiente.
I pesi DL (.pth/.pt: SAM, Depth-Anything, grape) fuori da git; torch.load solo da fonti fidate.
Mappe di prescrizione, dosi atomizzatore e stime di resa passano dal cv-agronomy-validator.
Blob privati, SAS a scadenza minima, Managed Identity, NSG restrittivi: la VM è esposta solo al backend.