01 · Optimista
Ritmo fluidoVentana estimada: 4–6 meses · punto medio: 5 meses
Objetivo: —0% del plazo
Pocos bloqueos, pruebas constantes y alcance controlado. Algunas integraciones podrían quedar en versión inicial.
Misión principal
Construir un asistente local útil, visual y extensible sin romper el Core estable.
Panel vivo para seguir la ruta hasta JARVIS 1.0. Marca las tareas al terminarlas: el progreso, los gráficos y las estimaciones se recalculan automáticamente. La checklist comienza sin tareas completadas porque el panel no debe dar por validado trabajo que todavía no se haya confirmado.
Estado general
Centro de control
Cálculo automático a partir de los elementos marcados.
Progreso total0%
Tareas listas0/0
Fases completadas0/9
Última actualización—
El avance se actualizará al marcar tareas.
Cuenta atrás orientativa
¿Cuánto falta para JARVIS 1.0?
Los tres escenarios se calculan desde la fecha de inicio elegida. No son fechas garantizadas.
02 · Realista
Plan baseVentana estimada: 8–12 meses · punto medio: 10 meses
Objetivo: —0% del plazo
Margen para depurar, aprender, probar en Windows y revisar seguridad antes de integrar.
03 · Pesimista
Con bloqueosVentana estimada: 15–24 meses · punto medio: 19,5 meses
Objetivo: —0% del plazo
Reprocesos, cambios de APIs, limitaciones del hardware o periodos con poco tiempo disponible.
Importante: la cuenta atrás muestra el tiempo restante hasta el punto medio de cada escenario; las ventanas completas siguen visibles. Al marcar tareas no se “acorta mágicamente” el calendario: el porcentaje del plazo avanza con el tiempo y el avance del proyecto se refleja por separado en la checklist y las gráficas.
Telemetría del proyecto
Indicadores clave
Porcentaje de tareas completadas, no una certificación técnica automática.
Checklist global
0%
Pendientes
0
Tareas por confirmar
Fase activa
Fase 0
Auditoría y estabilidad
Bloqueo crítico
Core / QA
No modificar v0.2.4 sin validación
Plan de ejecución
Hoja de ruta por fases
Marca una tarea solo cuando se haya completado y verificado.
Gráficas dinámicas
Progreso y distribución
Las gráficas se recalculan al activar o desactivar cualquier casilla.
Progreso por fase
Cada barra representa tareas completadas dentro de esa fase.
CompletadoPendiente
Completado vs. pendiente
Distribución actual de toda la checklist.
CompletadoPendiente
Panel de módulos
Estimación inicial orientativa que se deriva de las tareas asociadas. No sustituye las pruebas reales.
Planificación temporal
Estimación de tiempo
Estimación inicial basada en el alcance y las incertidumbres conocidas; revisar mensualmente.
| Bloque de trabajo | Estimación | Condición para darlo por cerrado |
|---|---|---|
| Auditar y estabilizar Core | 2–4 semanas | Árbol de código identificado, tests ejecutados en Windows, regresiones documentadas. |
| Dashboard, proyectos, tareas y herramientas | 3–6 semanas | Interfaz conectada a datos reales, errores visibles y operaciones probadas. |
| Memoria y experiencia de uso | 3–6 semanas | Recuerdo/olvido comprobados, controles de privacidad y persistencia verificada. |
| Voz y cámara/visión | 4–8 semanas | Permisos explícitos, procesamiento local cuando sea viable, interruptor físico/lógico y pruebas. |
| Reconocimiento facial y usuarios | 2–5 semanas | Alta voluntaria, umbral de desconocido, alternativa manual y sin autorización irreversible por rostro solo. |
| Navegador y múltiples cuentas | 5–10 semanas | APIs/OAuth u opciones permitidas, secretos protegidos y confirmación antes de enviar/publicar/borrar. |
| Sistema de agentes | 5–10 semanas | Agentes limitados, cancelables, auditables y siempre sujetos al Core/Permisos. |
| CAD, simulaciones y domótica | 4–8 semanas | Prototipos útiles, compatibilidad probada y componentes gratuitos/de bajo coste. |
| Seguridad, regresión y empaquetado | 4–8 semanas | Instalación reproducible, pruebas completas, documentación, recuperación y rollback. |
Los bloques pueden solaparse parcialmente; no deben sumarse como si fueran una secuencia lineal. Las pruebas en Windows y la disponibilidad de tiempo real pueden mover la fecha final.
3–5 h / semana
Ritmo reducido
15–24+ meses
Más interrupciones y menor margen para investigar incidencias.
6–10 h / semana
Ritmo base
8–15 meses
Referencia razonable para planificar y revisar cada mes.
12–20 h / semana
Ritmo intensivo
5–9 meses
Solo si hay continuidad y los bloqueos no se acumulan.
Límites de arquitectura
Reglas que no se negocian
La velocidad no puede comprometer el control local ni la seguridad.
⛨
Core estable primero
Preservar Core v0.2.4. No aceptar cambios ni ramas candidatas hasta comparar archivos, ejecutar pruebas en Windows y registrar resultados.
⌁
Permisos centralizados
LLM propone → Core decide → Permission System autoriza → ToolExecutor ejecuta. Ningún plugin o agente puede saltarse este flujo.
◉
Autonomía supervisada
Pedir confirmación para acciones sensibles. Los agentes deben ser cancelables, limitados y auditables.
⌂
Hardware y coste
Ryzen 5 7430U, 16 GB RAM, GPU integrada y presupuesto 0 €. Priorizar herramientas locales y gratuitas; medir rendimiento real.
◎
Privacidad por defecto
Cámara y voz con activación clara. Reconocimiento facial voluntario, umbral para desconocidos y alternativa manual.
↺
Validar antes de declarar “listo”
Inventario no equivale a funcionalidad. Cada fase necesita pruebas, criterios de aceptación, documentación y una forma de revertir.
Persistencia
Guardar y recuperar el estado
Ahora se guarda en este navegador. La sincronización entre dispositivos requiere backend.
Estado local
La checklist se guarda automáticamente en localStorage de este navegador. No se comparte con otros dispositivos y puede borrarse si se limpia el almacenamiento del sitio.
Guardado local activado
Sincronización Cloudflare D1
La conexión D1 todavía no está configurada en este HTML. Para sincronizar entre dispositivos, desplegar un Worker/API con autenticación y enlazarlo a D1; no poner claves privadas en el frontend.
Documentación oficial de Cloudflare D1 ↗Diseño recomendado para D1: tabla
roadmap_state con id, state_json, updated_at y, si hay varios usuarios, user_id. Un Cloudflare Worker valida el usuario y los datos, lee/escribe la fila y devuelve el estado. Añadir control de versiones/conflictos antes de permitir edición desde varios dispositivos. No se incluyen secretos ni se simula una conexión inexistente.