Roadmap Akira v5.16 — Timeline realistica post-checkpoint v5.15
Owner: Massimo Bagnoli (PM/architetto) Documento di riferimento: sostituisce cap. 47 del docx Akira v5.2 Stato: bozza per congelamento in v5.16 Data: 2026-05-13
Questo documento riscrive il capitolo Roadmap del docx Akira con una timeline realistica, costruita a valle del checkpoint v5.15 (mockup cristallizzato, schema DB completo, stack congelato). Recepisce le decisioni di scope prese il 2026-05-13:
- Tutti e 6 i Reports estesi (cap. 22-28) entrano in MVP: allunga Fase 3b.
- Topologia 12 VM full mirror-prod dal day 1 (no staging ridotto).
- Scope creep cap. 62.2 chiuso: Interconnection Wizard AI-guided e Calendar Future Tariffs spostati a v2; tier1/2/3 taxonomy rimossa (sostituita da premium/standard/grey); Invoice viewer 3-pagine pager rimandato a v1.1 (MVP-light con singola pagina); autoCat keyword Payments resta in MVP.
1. Stato attuale (checkpoint v5.15+)
| Asset | Stato | Note |
|---|---|---|
Mockup akira-mockup.html | Cristallizzato | 22 route, hash-routed; gap cap. 62.1 ancora aperti |
Mockup akira-routing-topology.html | Cristallizzato | Reference visiva cap. 45 |
| Schema DB | akira_schema_v1.sql in produzione (2012 righe, 74 tabelle, 139 indici) | Squash baseline per Alembic |
| Stack tecnologico | Congelato (ADR-0001) | Python 3.12 + FastAPI + SQLAlchemy + TimescaleDB + Next.js 14 |
| ADR firmati | 7+ | 0001 (stack), 0006 (sip-creds-encryption), 0007 (cdr-pipeline-nats), 0008 (kamailio-ha-hetzner), 0009 (imap-oauth2) + conventions error-handling + branch-strategy |
| Repo layout | Singolo akira/ monorepo | Decisione utente vs 3 repo separati |
| Documento corrente | Akira v5.2 docx | da rigenerare in v5.16 a chiusura Fase 0 |
Gap residui rilevati
- cap. 62.1 lacune mockup ancora aperte (Agent Mgmt, Rebill, Auto-Upload, Currency, Routing avanzato, Access Policies, 6 Reports, Settings tabs).
- cap. 62.3 incoerenze terminologiche solo parzialmente risolte (tier1/2/3 → premium/standard/grey applicato, altri glossari in coda).
- Stati Loading/Error/Empty/Toast non sistematizzati nel design system.
- Login + MFA + Empty-state mockup mancanti.
- WCAG: focus visible, ARIA labels, contrasto ancora con fix puntuali.
2. Fase 0 — Hardening pre-backend (3-4 settimane)
Obiettivo: chiudere tutti i gap "carta" prima di scrivere una riga di backend. Le attività sono parallelizzabili dove indicato.
| ID | Attività | Durata | Parallelo | Owner | Output |
|---|---|---|---|---|---|
| A0.1 | Fix cap. 62.3 incoerenze terminologia | 1 sett | sì | Massimo | Glossary v1, applicato a docx + mockup |
| A0.2 | Fix cap. 62.1 lacune mockup | 2 sett | parz. | Massimo + Francesco | 8 schermate aggiunte/rifinite (Agent Mgmt, Rebill, Auto-Upload, Currency, Routing avanzato, Access Policies, 6 Reports, Settings tabs) |
| A0.3 | Validazione Francesco mockup | 2 sett wallclock | sì | Francesco | 4 sessioni totali (2/sett), checklist UX firmata |
| A0.4 | Ansible inventory + ruoli core | 1.5 sett | sì | Massimo | akira-infra con ruoli base (common, postgres, redis, kamailio-base) |
| A0.5 | .env populate + secrets generate + Vault encrypt | 3gg | sì | Massimo | .env.staging + .env.prod cifrati Ansible Vault |
| A0.6 | Onboarding Akira su Toolbox VPS | 2gg | sì | Massimo | task notturni akira-* registrati in toolbox runner |
| A0.7 | Bozza importer Stealth mapping tabelle | 1 sett | sì | Massimo | mapping doc Stealth→Akira (companies, rates, cdr, balance) |
| A0.8 | Login + MFA + Empty-state mockup | 1 sett | sì | Massimo + Francesco | 3 nuove schermate nel mockup |
| A0.9 | Stati Loading/Error/Empty/Toast nel design system | 1 sett | sì | Massimo | tokens + componenti nel mockup |
| A0.10 | WCAG fixes (focus, ARIA, contrasto) | 0.5 sett | sì | Massimo | pass automatico axe-core su mockup |
Output Fase 0:
- docx v5.16 freezed;
- mockup cristallizzato senza lacune note;
- infra Ansible scaffold completo;
.envstaging popolato;- ready per primo
provision_staging.yml.
Gate uscita Fase 0: walkthrough completo mockup + design system con Francesco, zero blocker UX residui.
3. Fase 1 — Backend foundation (3 settimane)
| ID | Attività | Durata | Parallelo | Note |
|---|---|---|---|---|
| F1.1 | Alembic squash schema = akira_schema_v1.sql + seed reference data | 1 sett | no | baseline 0001_initial_squash + seed (countries, currencies, default tariffs) |
| F1.2 | FastAPI scaffold + routers stub per ogni dominio + JWT auth + MFA TOTP + recovery codes | 1 sett | no | OpenAPI dump in CI; pyotp + cryptography per TOTP |
| F1.3 | Deploy staging 12 VM via Ansible + smoke ping E2E | 1 sett | no | provision_staging.yml esegue su 12 host Hetzner |
| F1.4 | AgentCore container deploy su mgmt-01 + system prompt akira-docs/agentcore-akira-prompt.md | 1 sett | sì | container A.Sheep, prompt iniziale read-only |
| F1.5 | Importer Stealth — sviluppo ETL script standalone read-only | 1 sett | sì | run nightly su Toolbox VPS, output JSONL su Storage Box |
| F1.6 | DR test PG+Timescale: pg_dump → Storage Box → restore su db-02 ephemeral | 0.5 sett | sì | verifica RTO/RPO documentati (target Fase 4) |
Gate Fase 1 → Fase 2: smoke test SIP REGISTER E2E green su staging (softphone esterno → Kamailio staging → 200 OK).
4. Fase 2 — Signaling core (4-5 settimane)
| ID | Attività | Durata | Parallelo | Note |
|---|---|---|---|---|
| F2.1 | Kamailio config + htable sync DB 30s + Redis pub/sub event-driven invalidation | 2 sett | no | dispatcher + permissions + acc, hot-reload via Redis |
| F2.2 | RTPengine + media bridge + recording G.711 via FreeSWITCH | 1.5 sett | parz. | recording dual-leg, WAV su Storage Box |
| F2.3 | FreeSWITCH B2BUA + transcoding on-demand G.729→G.711 | 1 sett | no | profilo transcode-only, no media full-anchoring |
| F2.4 | Integration test E2E softphone + benchmark 200 CPS burst | 1 sett | no | sipp scenari + grafana dashboard |
| F2.5 | Frontend scaffold Next.js + design system + componenti foundation | 2 sett | sì | App Router, Tailwind + shadcn, design tokens dal mockup |
Gate Fase 2 → Fase 3a: 200 CPS burst test passa con loss < 0.5%.
5. Fase 3a — Management plane CRUD (3 settimane)
| ID | Attività | Durata | Note |
|---|---|---|---|
| F3a.1 | Frontend CRUD Companies + Originators + Terminators + Devices | 1.5 sett | include static vs dynamic device UI differenziato (vedi feedback) |
| F3a.2 | Frontend CRUD Tariffs + Destinations + Offers | 1 sett | offer con valid_to opzionale, reverts_to in advanced |
| F3a.3 | Frontend Routing Plans editor + Access Policies | 0.5 sett | DnD priority + IP/CIDR allowlist |
6. Fase 3b — Reports + Topology + Pattern Analyzer (4 settimane)
Decisione 2026-05-13: tutti e 6 i Reports estesi entrano in MVP.
| ID | Attività | Durata | Capitoli docx |
|---|---|---|---|
| F3b.1 | Active Calls (NOC Live View) + SSE live | 1 sett | cap. 22 |
| F3b.2 | Live Performance (Carrier Health Matrix) + Calls per Day | 1 sett | cap. 23 + cap. 24 |
| F3b.3 | Consumption (Period Comparison) + SLA Quality Agreements | 1 sett | cap. 26 + cap. 27 |
| F3b.4 | Source Destinations + Topology Map + Pattern Analyzer UI | 1 sett | cap. 28 + cap. 45 + cap. 46 |
Note tecniche:
- Active Calls usa Server-Sent Events (SSE), vedi ADR-0018 per razionale:
GET /api/v1/live/calls(stream) eGET /api/v1/live/calls/snapshot(initial state). - Carrier Health Matrix aggrega da
cdr_continuous_aggregate_5m(TimescaleDB). - Pattern Analyzer UI consuma output del runner notturno (Toolbox
akira-pattern-detector).
7. Fase 3c — Integrations parallel (2 settimane)
Esegue in parallelo a Fase 3b (lavoro indipendente dal frontend Reports).
| ID | Attività | Durata | Note |
|---|---|---|---|
| F3c.1 | AgentCore tools registry + MCP integration | 1 sett | tools = endpoint FastAPI esposti come MCP; auth via service token |
| F3c.2 | Revolut OAuth2 + webhook + auto-match Payments | 0.5 sett | autoCat keyword in MVP |
| F3c.3 | IMAP pipelines (tickets + supplier invoices) OAuth2 | 0.5 sett | ADR-0009 reference; Gmail + M365 |
8. Fase 4 — Pilot + import + go-live (5-6 settimane)
| ID | Attività | Durata | Note |
|---|---|---|---|
| F4.1 | Importer Stealth → Akira dry-run staging + reconciliation | 1 sett | tolleranza delta 0% su counts, < 0.5% su somme monetarie |
| F4.2 | Dual-stack 1 customer side-by-side billing 7gg | 2 sett | Apex Telecom (interno A.Sheep candidato) |
| F4.3 | Pilot 2 customer reali ≥ 14gg continui dual-stack | 2 sett | gating KPI in pilot-gating-kpi.md |
| F4.4 | Cutover progressivo + rollback plan | 1 sett | runbook cutover + DR drill finale |
Vedi pilot-gating-kpi.md per criteri di promozione/rollback.
9. Totali e milestone
| Fase | Durata |
|---|---|
| Fase 0 (Hardening) | 3-4 sett |
| Fase 1 (Backend foundation) | 3 sett |
| Fase 2 (Signaling core) | 4-5 sett |
| Fase 3a (CRUD) | 3 sett |
| Fase 3b (Reports + Topology + Pattern) | 4 sett |
| Fase 3c (Integrations, parallelo a 3b) | 2 sett (assorbiti) |
| Fase 4 (Pilot + go-live) | 5-6 sett |
- TOTALE post-kickoff backend (Fase 1→4): 21-23 settimane (5-6 mesi).
- TOTALE incluso Fase 0: 24-27 settimane (6-7 mesi).
- Target go-live pilot: dicembre 2026 / gennaio 2027.
Gantt sintetico
Mese 1 | F0 hardening ████████
Mese 2 | F1 backend ██████
Mese 3 | F2 signaling ██████████
Mese 4 | F2 (coda) + F3a CRUD ██████████
Mese 5 | F3b Reports ████████ // F3c Integrations ████ (parallelo)
Mese 6 | F4 import + pilot ████████
Mese 7 | F4 pilot + cutover ████████
10. Out-of-scope MVP (parking lot v2)
| Feature | Destinazione | Note |
|---|---|---|
| Interconnection Tool AI-guided wizard | v2 (cap. 63 v2) | richiede AgentCore maturo + dataset reale |
| Calendar view Future Tariffs | v2 (cap. 14 v2) | UI ricca, MVP usa lista flat |
| Invoice viewer 3-pagine pager + supplier side-by-side | v1.1 (cap. 58/60) | MVP-light singola pagina |
| Cost Explorer | v1.1 (cap. 21) | post-pilot, richiede dati storici reali |
| TLS/SRTP signaling | v2 (cap. 5.4) | MVP solo UDP + IP allowlist |
| Hardware MFA WebAuthn/YubiKey | v2 (cap. 5.2) | MVP solo TOTP + recovery codes |
| Multi-region DR HEL1 | v2 (cap. 7.4) | MVP solo single-region FSN1 + Storage Box backup |
| HashiCorp Vault enterprise | v2 (cap. 5.3) | MVP Ansible Vault sufficiente |
| Mutation testing | post-MVP | nice-to-have, dopo stabilità |
| Bug bounty | post-MVP | richiede maturità + base utenti |
11. Rischi principali residui
| Rischio | Probabilità | Impatto | Mitigazione |
|---|---|---|---|
| 200 CPS non raggiunto in Fase 2 | media | alto | benchmark anticipato F2.4; profilo Kamailio già validato in lab |
| Importer Stealth con drift su balance | media | alto | reconciliation in F4.1, tolleranza < 0.5%, alert su mismatch |
| Francesco non disponibile per validazione UX | bassa | medio | sessioni preregistrate calendar, fallback async via Loom |
| AgentCore non production-ready entro F3c | media | basso | tools-registry può ritardare a v1.1 senza bloccare pilot |
| DR restore eccede RTO target | bassa | alto | test ripetuto in F1.6 e F4.4; eventuale upgrade Storage Box |
12. Riferimenti
docs/adr/0001-stack-python-fastapi-nextjs.mddocs/adr/0007-cdr-pipeline-nats-jetstream.mddocs/adr/0008-kamailio-ha-hetzner-cloud.mddocs/adr/0009-imap-oauth2-gmail-m365.mddocs/architecture/signaling-decisions.mddocs/architecture/pilot-gating-kpi.md(KPI di gating Fase 4)docs/conventions/definition-of-done.md(DoD feature)docs/db/SCHEMA_DELTA_v515_to_v1.md- Akira docx v5.2 (rigenerato in v5.16 a fine Fase 0)