Add roadmap and current project status
This commit is contained in:
Carlos Tello
+186
@@ -0,0 +1,186 @@
|
|||||||
|
# Roadmap de OnEver Drive
|
||||||
|
|
||||||
|
## Objetivo
|
||||||
|
Hacer que OnEver Drive evolucione desde un sistema de backup centralizado hacia una plataforma parecida a un NAS empresarial moderno, con gestión de archivos, restauración granular, sincronización continua, permisos y experiencia de usuario final.
|
||||||
|
|
||||||
|
## Estado actual del proyecto
|
||||||
|
- Backend FastAPI funcional y levantado localmente.
|
||||||
|
- Frontend React/Vite con pantalla de login y dashboard base.
|
||||||
|
- Estructura de clientes, trabajos, eventos, estadísticas y restauración inicial.
|
||||||
|
- Agente Windows con lógica de backup y ejecución de trabajos.
|
||||||
|
- Retención y almacenamiento por cliente y trabajo.
|
||||||
|
- Base de arquitectura lista para crecimiento.
|
||||||
|
|
||||||
|
## Principios de evolución
|
||||||
|
- Priorizar valor real para usuarios finales.
|
||||||
|
- Medir progreso por entregables demostrables.
|
||||||
|
- Asegurar que cada fase pueda probarse en una UI funcional.
|
||||||
|
- Mantener la compatibilidad con el modelo actual de clientes y jobs.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fase 0: Consolidación base (Hecho / en curso)
|
||||||
|
### Objetivo
|
||||||
|
Dejar estable la base del producto para seguir construyendo sobre ella.
|
||||||
|
|
||||||
|
### Criterios de éxito
|
||||||
|
- Backend y frontend arrancan sin errores.
|
||||||
|
- Login admin funciona.
|
||||||
|
- Dashboard carga datos reales.
|
||||||
|
- API responde correctamente.
|
||||||
|
|
||||||
|
### Tareas
|
||||||
|
- [x] Backend FastAPI inicial.
|
||||||
|
- [x] Frontend React inicial.
|
||||||
|
- [x] Autenticación por JWT.
|
||||||
|
- [x] Autogeneración de admin por defecto.
|
||||||
|
- [x] Estructura de clientes y trabajos.
|
||||||
|
- [x] Dashboard principal con telemetría.
|
||||||
|
- [ ] Revisar y limpiar errores de arranque y warnings en entorno local.
|
||||||
|
- [ ] Validar flujos end-to-end de login + carga de datos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fase 1: Restore por archivo y versionado (Prioridad 1)
|
||||||
|
### Objetivo
|
||||||
|
Convertir el sistema de backups en un producto recuperable y útil para usuarios finales, no solo para administración.
|
||||||
|
|
||||||
|
### Criterios de éxito
|
||||||
|
- El usuario puede navegar por backups por cliente y trabajo.
|
||||||
|
- Puede seleccionar un archivo y restaurarlo desde una fecha anterior.
|
||||||
|
- Existe historial de versiones por archivo.
|
||||||
|
- La UI muestra snapshots y rutas de restore.
|
||||||
|
|
||||||
|
### Tareas
|
||||||
|
- [ ] Diseñar modelo de snapshot/versionado por archivo.
|
||||||
|
- [ ] Crear endpoints de listado histórico de versiones.
|
||||||
|
- [ ] Crear endpoint de restore puntual por archivo.
|
||||||
|
- [ ] Agregar metadatos de fecha, hash y ruta relativa.
|
||||||
|
- [ ] Mejorar [frontend/src/pages/RestoreView.tsx](frontend/src/pages/RestoreView.tsx) con navegación por árbol.
|
||||||
|
- [ ] Agregar filtros por cliente, trabajo, fecha y ruta.
|
||||||
|
- [ ] Añadir acciones de descarga y restore desde la UI.
|
||||||
|
- [ ] Validar flujo end-to-end con un archivo real.
|
||||||
|
|
||||||
|
### Indicador de progreso
|
||||||
|
Cuando un usuario puede ver un archivo de hace 3 días y restaurarlo sin volver a restaurar todo el job, la fase está completa.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fase 2: Explorador de archivos / File Station style
|
||||||
|
### Objetivo
|
||||||
|
Que el sistema se sienta como un NAS moderno y no como una consola de tareas.
|
||||||
|
|
||||||
|
### Criterios de éxito
|
||||||
|
- Se puede navegar por carpetas virtuales del backup.
|
||||||
|
- Se visualiza estructura de clientes y jobs como árbol de datos.
|
||||||
|
- El restore se vuelve más intuitivo para usuarios no técnicos.
|
||||||
|
|
||||||
|
### Tareas
|
||||||
|
- [ ] Crear API de exploración de rutas de backup.
|
||||||
|
- [ ] Implementar árbol de directorios y archivos.
|
||||||
|
- [ ] Agregar breadcrumb / navegación por carpeta.
|
||||||
|
- [ ] Mostrar metainformación: tamaño, fecha, tipo, hash.
|
||||||
|
- [ ] Permitir descarga individual o múltiple.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fase 3: Permisos, usuarios y multi-tenancy real
|
||||||
|
### Objetivo
|
||||||
|
Separar claramente administración del sistema de uso del almacenamiento.
|
||||||
|
|
||||||
|
### Criterios de éxito
|
||||||
|
- Roles concretos: admin, operador, usuario de backup.
|
||||||
|
- Permisos por cliente y por carpeta.
|
||||||
|
- Auditar acciones importantes por usuario.
|
||||||
|
|
||||||
|
### Tareas
|
||||||
|
- [ ] Reforzar modelo de usuarios y roles.
|
||||||
|
- [ ] Definir permisos por cliente, trabajo y backup.
|
||||||
|
- [ ] Añadir auditoría detallada de accesos y restores.
|
||||||
|
- [ ] Proteger endpoints por scope de cliente.
|
||||||
|
- [ ] Crear UI de gestión de roles.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fase 4: Sincronización continua y cambios en tiempo real
|
||||||
|
### Objetivo
|
||||||
|
Mover la solución desde “backup programado” hacia “sincronización real” en vivo.
|
||||||
|
|
||||||
|
### Criterios de éxito
|
||||||
|
- Cambios recientes se reflejan sin espera de la siguiente ejecución programada.
|
||||||
|
- El agente detecta cambios de archivos y genera eventos.
|
||||||
|
- La UI refleja estado de sincronización y fallas.
|
||||||
|
|
||||||
|
### Tareas
|
||||||
|
- [ ] Mejorar detección de cambios en carpeta local.
|
||||||
|
- [ ] Añadir mode de sync incremental o casi en tiempo real.
|
||||||
|
- [ ] Manejar conflictos y reintentos.
|
||||||
|
- [ ] Mostrar progreso de sync real en dashboard.
|
||||||
|
- [ ] Ajustar manejo de archivos abiertos / bloqueados.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fase 5: Storage enterprise y capacidad real
|
||||||
|
### Objetivo
|
||||||
|
Hacer que el sistema parezca almacenamiento serio, no solo backup.
|
||||||
|
|
||||||
|
### Criterios de éxito
|
||||||
|
- Quotas por cliente y por usuario.
|
||||||
|
- Alertas por espacio.
|
||||||
|
- Verificación periódica de integridad.
|
||||||
|
- Gestión de volumenes y pools.
|
||||||
|
|
||||||
|
### Tareas
|
||||||
|
- [ ] Añadir cuotas y alertas de espacio.
|
||||||
|
- [ ] Mejorar organización física del storage.
|
||||||
|
- [ ] Añadir validación periódica y checksums.
|
||||||
|
- [ ] Soportar storage por pools y directorios.
|
||||||
|
- [ ] Añadir cifrado y compresión opcional.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fase 6: UX premium y experiencia final
|
||||||
|
### Objetivo
|
||||||
|
Cerrar la diferencia entre el producto y una solución NAS moderna.
|
||||||
|
|
||||||
|
### Criterios de éxito
|
||||||
|
- Dashboard visual y claro para administración.
|
||||||
|
- Navegación simple para restore.
|
||||||
|
- Alertas, notificaciones y estados comprensibles.
|
||||||
|
- Diseño consistente con una experiencia de producto terminada.
|
||||||
|
|
||||||
|
### Tareas
|
||||||
|
- [ ] Mejorar diseño general del dashboard.
|
||||||
|
- [ ] Crear vistas de salud del sistema.
|
||||||
|
- [ ] Añadir alertas visuales y métricas de uso.
|
||||||
|
- [ ] Mejorar navegación por tabs y modales.
|
||||||
|
- [ ] Trabajar la experiencia móvil y desktop.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Medición del progreso
|
||||||
|
Se considera que el proyecto avanza cuando cada fase cumple los criterios objetivos y puede demostrarse funcionalmente con una prueba real.
|
||||||
|
|
||||||
|
### Indicadores clave
|
||||||
|
- Login funcionando
|
||||||
|
- Cliente registrado
|
||||||
|
- Job ejecutado correctamente
|
||||||
|
- Archivo respaldado
|
||||||
|
- Archivo restaurado por fecha
|
||||||
|
- Explicación clara del estado del sistema en la UI
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Siguiente hito recomendado
|
||||||
|
### Hito 1: Restore puntual + versionado
|
||||||
|
Es el cambio más valioso en este momento porque transforma el software de “backup programado” a “plataforma de almacenamiento recuperable”.
|
||||||
|
|
||||||
|
Este hito debería marcarse como alcanzado cuando:
|
||||||
|
- un archivo tiene historial de versiones,
|
||||||
|
- el usuario puede navegarlo,
|
||||||
|
- y restaurarlo desde una fecha concreta.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Notas finales
|
||||||
|
Este roadmap está pensado para facilitar la medición del progreso sin perder de vista la visión de producto final. El objetivo no es solo tener “más features”, sino lograr que el sistema se sienta como una solución moderna de almacenamiento y recuperación.
|
||||||
Reference in New Issue
Block a user