# Prompt Zero: mockupAWS - Project Kickoff ## 🎯 Missione Sviluppare **mockupAWS**, un ambiente di simulazione locale per profilare traffico log e calcolare i driver di costo AWS (SQS, Lambda, Bedrock/LLM) prima del deploy in produzione. **Repository:** `/home/google/Sources/LucaSacchiNet/mockupAWS` **PRD:** `/home/google/Sources/LucaSacchiNet/mockupAWS/export/prd.md` --- ## πŸ“Š Stato Attuale - βœ… **PRD Completo**: Requisiti funzionali e non funzionali definiti (v0.2.0) - βœ… **Team Configurato**: 6 agenti specializzati pronti - ⚠️ **Codice Base Parziale**: API base implementata (v0.1), manca database e persistenza - ❌ **Database**: Schema da creare (PostgreSQL) - ❌ **Frontend**: Dashboard React da implementare - ❌ **Docker**: Configurazione da creare ### Cosa Γ¨ giΓ  fatto: - FastAPI base con endpoint `/ingest`, `/metrics`, `/reset`, `/flush` - Calcolo metriche: SQS blocks, token count (tiktoken), PII detection - Test suite pytest (5 test passanti) - Documentazione: README, PRD, architettura - Struttura progetto e configurazione uv ### Cosa manca (PrioritΓ ): 1. Database PostgreSQL con tabelle scenarios, logs, metrics, pricing 2. Alembic migrations 3. API CRUD scenari complete 4. Calcolo costi con prezzi AWS reali 5. Frontend React con dashboard 6. Docker Compose setup --- ## πŸ‘₯ Team di Sviluppo | Agente | Ruolo | Config | ResponsabilitΓ  | |--------|-------|--------|----------------| | `@spec-architect` | Software Architect | `.opencode/agents/spec-architect.md` | Specifiche tecniche, architettura, coordinamento | | `@db-engineer` | Database Engineer | `.opencode/agents/db-engineer.md` | Schema DB, Alembic migrations, queries | | `@backend-dev` | Backend Developer | `.opencode/agents/backend-dev.md` | FastAPI endpoints, services, tests | | `@frontend-dev` | Frontend Developer | `.opencode/agents/frontend-dev.md` | React dashboard, UI components | | `@devops-engineer` | DevOps Engineer | `.opencode/agents/devops-engineer.md` | Docker, CI/CD, deployment | | `@qa-engineer` | QA Engineer | `.opencode/agents/qa-engineer.md` | Testing strategy, E2E tests | --- ## πŸ”„ Workflow Obbligatorio ``` β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ FASE 1: ARCHITETTURA & DATABASE β”‚ β”‚ @spec-architect + @db-engineer β”‚ β”‚ └── Finalizza architecture.md + Crea schema DB + Migrations β”‚ β”‚ β”‚ β”‚ ↓ β”‚ β”‚ β”‚ β”‚ FASE 2: BACKEND API β”‚ β”‚ @backend-dev + @db-engineer β”‚ β”‚ └── Implementa API CRUD scenari + Persistenza metriche β”‚ β”‚ β”‚ β”‚ ↓ β”‚ β”‚ β”‚ β”‚ FASE 3: FRONTEND β”‚ β”‚ @frontend-dev β”‚ β”‚ └── Dashboard React + Forms + Visualizzazione dati β”‚ β”‚ β”‚ β”‚ ↓ β”‚ β”‚ β”‚ β”‚ FASE 4: DEVOPS & QA β”‚ β”‚ @devops-engineer + @qa-engineer β”‚ β”‚ └── Docker Compose + CI/CD + Testing E2E β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ ``` --- ## πŸš€ Task Iniziale: Fase 1 - Architettura e Database **AGENTE:** `@spec-architect` + `@db-engineer` **OBIETTIVO:** Completare le specifiche tecniche e creare il database schema. ### Azioni Richieste #### 1. @spec-architect - Analisi e Specifiche 1. **Leggere** `/home/google/Sources/LucaSacchiNet/mockupAWS/export/prd.md` 2. **Analizzare** il codice esistente in `/home/google/Sources/LucaSacchiNet/mockupAWS/src/` 3. **Aggiornare** `/home/google/Sources/LucaSacchiNet/mockupAWS/export/architecture.md` con: - Stack tecnologico dettagliato (conferma FastAPI + PostgreSQL + React) - Struttura cartelle progetto finale - Diagrammi flusso dati (Mermaid o ASCII) - API specifications complete (OpenAPI specs) - Piano di sicurezza (JWT, API keys) 4. **Creare** `/home/google/Sources/LucaSacchiNet/mockupAWS/export/kanban.md` con: - Task breakdown per Fase 1 (Database + Backend API) - Task breakdown per Fase 2 (Frontend) - Stima complessitΓ  (XS/S/M/L) - Dipendenze tra task - Regola "little often": task < 2 ore 5. **Inizializzare** `/home/google/Sources/LucaSacchiNet/mockupAWS/export/progress.md` con: - Feature corrente: "Fase 1 - Database e Backend API" - Stato: "πŸ”΄ Pianificazione" - Percentuale: 10% #### 2. @db-engineer - Schema Database 1. **Progettare** schema PostgreSQL completo: ```sql -- Tabelle richieste: - scenarios (metadata scenario) - scenario_logs (log ricevuti con hash) - scenario_metrics (metriche aggregate) - aws_pricing (prezzi AWS per regione) - reports (report generati) ``` 2. **Creare** Alembic setup: - `alembic init alembic` - Configurare `alembic.ini` - Creare `migrations/env.py` con async support 3. **Creare** migrazioni iniziali: - `001_create_scenarios_table.py` - `002_create_scenario_logs_table.py` - `003_create_scenario_metrics_table.py` - `004_create_aws_pricing_table.py` - `005_create_reports_table.py` - `006_seed_aws_pricing_data.py` 4. **Documentare** in `docs/database_schema.md`: - Schema ER completo - Indici creati - Constraints e foreign keys ### Criteri di Accettazione Fase 1 - [ ] `architecture.md` completo con tutte le sezioni - [ ] `kanban.md` con task pronti per sviluppo - [ ] `progress.md` inizializzato con stato attuale - [ ] Schema database progettato e documentato - [ ] Migrazioni Alembic create e testate - [ ] Tabelle create correttamente in PostgreSQL --- ## πŸ“‹ Requisiti Chiave (Dal PRD) ### PrioritΓ  Alta (MVP v0.2.0) 1. **Database & Persistenza** - PostgreSQL con tabelle scenarios, logs, metrics, pricing - Alembic migrations - Seed dati prezzi AWS reali 2. **API Scenari** - CRUD completo: GET/POST/PUT/DELETE /api/v1/scenarios - Gestione stati: draft β†’ running β†’ completed β†’ archived - Associazione log a scenario via X-Scenario-ID header 3. **Calcolo Costi** - Formula SQS: blocks Γ— price_per_million / 1000000 - Formula Lambda: invocations Γ— price + gb_seconds Γ— price - Formula Bedrock: tokens Γ— price_per_1k / 1000 - Prezzi per regione (us-east-1, eu-west-1) 4. **Testing** - Test coverage > 80% - Unit tests per services - Integration tests per API ### PrioritΓ  Media (v0.3.0) 5. **Dashboard Web** - React + TypeScript + Tailwind - Lista scenari con filtri - Form creazione scenario - Vista dettaglio con metriche 6. **Report** - Export CSV - Visualizzazione grafici ### PrioritΓ  Bassa (v0.4.0) 7. **Report PDF** 8. **Confronto scenari** 9. **Autenticazione** --- ## πŸ›‘οΈ Vincoli e Best Practices ### Sicurezza (Critico) - SQL injection prevention (SQLAlchemy ORM) - XSS prevention (React escaping) - CSRF protection - Rate limiting (slowapi) - Hashing messaggi per privacy - No PII in logs persistenti ### QualitΓ  - Test coverage β‰₯ 80% - TDD obbligatorio per backend - Type hints obbligatori (Python + TypeScript) - Conventional commits - Commit atomici ### Organizzazione - Task "little often" (< 2 ore) - Documentazione in `/export/` - Bug complessi in `/docs/bug_ledger.md` - PR con code review --- ## πŸ“ Struttura Progetto Finale ``` /home/google/Sources/LucaSacchiNet/mockupAWS/ β”œβ”€β”€ export/ # Output spec-driven β”‚ β”œβ”€β”€ prd.md # Product Requirements β”‚ β”œβ”€β”€ architecture.md # Architettura sistema β”‚ β”œβ”€β”€ kanban.md # Task breakdown β”‚ └── progress.md # Tracciamento progresso β”œβ”€β”€ docs/ β”‚ β”œβ”€β”€ architecture.md # ADR (Architecture Decision Records) β”‚ β”œβ”€β”€ bug_ledger.md # Bug tracking β”‚ └── database_schema.md # Schema DB documentazione β”œβ”€β”€ prompt/ β”‚ └── prompt-zero.md # Questo file β”œβ”€β”€ .opencode/ β”‚ └── agents/ # Configurazioni agenti β”‚ β”œβ”€β”€ spec-architect.md β”‚ β”œβ”€β”€ backend-dev.md β”‚ β”œβ”€β”€ db-engineer.md β”‚ β”œβ”€β”€ frontend-dev.md β”‚ β”œβ”€β”€ devops-engineer.md β”‚ └── qa-engineer.md β”œβ”€β”€ backend/ # FastAPI application β”‚ β”œβ”€β”€ src/ β”‚ β”‚ β”œβ”€β”€ __init__.py β”‚ β”‚ β”œβ”€β”€ main.py # Entry point β”‚ β”‚ β”œβ”€β”€ config.py # Configuration β”‚ β”‚ β”œβ”€β”€ models/ # SQLAlchemy models β”‚ β”‚ β”œβ”€β”€ schemas/ # Pydantic schemas β”‚ β”‚ β”œβ”€β”€ api/ # API endpoints β”‚ β”‚ β”œβ”€β”€ services/ # Business logic β”‚ β”‚ └── core/ # Utils, auth, etc. β”‚ β”œβ”€β”€ tests/ β”‚ β”‚ β”œβ”€β”€ unit/ β”‚ β”‚ β”œβ”€β”€ integration/ β”‚ β”‚ └── conftest.py β”‚ β”œβ”€β”€ alembic/ # Database migrations β”‚ β”œβ”€β”€ Dockerfile β”‚ └── pyproject.toml β”œβ”€β”€ frontend/ # React application β”‚ β”œβ”€β”€ src/ β”‚ β”‚ β”œβ”€β”€ components/ # React components β”‚ β”‚ β”œβ”€β”€ pages/ # Page components β”‚ β”‚ β”œβ”€β”€ hooks/ # Custom hooks β”‚ β”‚ β”œβ”€β”€ services/ # API clients β”‚ β”‚ └── types/ # TypeScript types β”‚ β”œβ”€β”€ public/ β”‚ β”œβ”€β”€ Dockerfile β”‚ └── package.json β”œβ”€β”€ docker-compose.yml # Full stack orchestration β”œβ”€β”€ nginx.conf # Reverse proxy config └── README.md ``` --- ## βœ… Checklist Pre-Sviluppo - [ ] @spec-architect ha letto questo prompt e il PRD - [ ] @db-engineer ha revisionato il PRD sezione database - [ ] Team allineato sulle priorita (MVP v0.2.0) - [ ] Architettura approvata - [ ] Schema database pronto --- ## 🎬 Prossima Azione **@spec-architect**: Inizia analizzando il PRD e il codice esistente, poi aggiorna `architecture.md` e `kanban.md`. **@db-engineer**: Inizia progettando lo schema database e le migrazioni Alembic. **NON iniziare l'implementazione del codice di business logic** finchΓ© architettura e schema DB non sono completati e revisionati. --- ## πŸ“ž Note per il Team - **Domande sul PRD?** Leggi prima `export/prd.md` completamente - **Codice esistente?** Esamina `/home/google/Sources/LucaSacchiNet/mockupAWS/src/` prima di iniziare - **AmbiguitΓ ?** Chiedi prima di procedere - **Vincoli tecnici?** Documentali in `architecture.md` - **Task troppo grandi?** Spezza in task piΓΉ piccoli seguendo "little often" --- **Data Creazione:** 2026-04-07 **Versione:** 2.0 **Stato:** Pronto per kickoff - Fase 1: Architettura e Database --- ## πŸ“ Note sullo Stato Attuale Il progetto ha giΓ  una base solida con: - API FastAPI funzionante con metriche base - Test suite completa (pytest) - Documentazione PRD dettagliata Il team deve ora: 1. Completare l'architettura tecnica 2. Implementare il database layer 3. Evolvere l'API esistente per supportare scenari 4. Costruire il frontend 5. Containerizzare tutto Il lavoro puΓ² procedere in parallelo dopo la fase di architettura: - Backend e DB possono procedere insieme - Frontend puΓ² iniziare con mock data - DevOps puΓ² preparare l'infrastruttura