ROMIL UI — Concepto visual y pantallas clave

**Fecha:** 2026-06-14

**Proyecto:** ROMIL

**Estado:** concepto visual inicial

**Decisión:** diseñar antes de construir, para evitar otra app decorativa sin función operativa.

---

1. Principio brutal

ROMIL UI no debe ser una app bonita para mirar tu sistema.

Debe ser una **cabina de mando para decidir y producir evidencia**.

Si la interfaz no ayuda a responder una de estas preguntas, sobra:

1. ¿Qué debo hacer hoy?

2. ¿Qué está bloqueado?

3. ¿Qué proyecto mueve ingreso, validación o cierre?

4. ¿Qué evidencia produje?

5. ¿Qué debe registrar Seldon en ROMIL?

---

2. Propósito del producto

Crear una interfaz local/deployable encima de `/root/ROMIL` que permita:

• leer el dashboard estratégico;
• navegar proyectos, áreas, recursos y archivo;
• ver tareas activas por prioridad;
• registrar capturas rápidas;
• revisar actividad diaria;
• exponer el estado de agentes/background tasks;
• convertir conversaciones con Seldon en cambios visibles dentro de ROMIL.

La UI no reemplaza Markdown. Markdown sigue siendo la fuente de verdad.

La UI es una **capa operacional**.

---

3. Dirección estética

Nombre visual de trabajo

**ROMIL Command Deck**

Tono

**Terminal retro operacional + cabina estratégica sobria.**

No SaaS genérico. No dashboard blanco con cards redondas. No “Notion clone”.

Debe sentirse como:

• una consola de navegación personal;
• una estación de mando para vida/proyectos;
• un sistema de campo, no una app de productividad aspiracional;
• una herramienta que presiona a ejecutar, no que consuela.

Referencia interna

Alinear con el estilo que Felix ya validó como atractivo:

/root/referencias/diseno/terminal-retro-operacional-2026-06-09/

Paleta sugerida

Fondo profundo:       #070A0D / #0B0F12
Paneles:              #111820 / #151D26
Texto principal:      #E8F1E8
Texto secundario:     #8FA39A
Verde operativo:      #8CFFB0
Ámbar advertencia:    #F5B84B
Rojo bloqueo:         #FF5C5C
Azul señal:           #5CC8FF
Líneas/bordes:        rgba(140,255,176,0.18)

Tipografía sugerida

• Display/terminal: `IBM Plex Mono`, `JetBrains Mono` o `Space Mono`.
• Texto largo: `Atkinson Hyperlegible`, `IBM Plex Sans` o `Aptos`.

Evitar una estética demasiado gamer. La sensación correcta es **sistema serio con alma de terminal**.

Firma visual

Una barra superior tipo telemetría:

ROMIL // FELIX OPERATING SYSTEM // YYYY-MM-DD // PRIORIDAD: INGRESO + EVIDENCIA

Y un indicador permanente:

EVIDENCIA HOY: 0 / 1

Ese número debe incomodar si está en cero.

---

4. Estructura general de navegación

Sidebar izquierda

ROMIL
├── Command
├── Today
├── Projects
├── Goals
├── Captures
├── Agents
├── Archive
└── Search

Zona central

Área de trabajo principal según pantalla.

Rail derecho

Panel persistente de Seldon:

SELDON CHECK
- Prioridad dominante
- Bloqueo actual
- Siguiente acción no negociable
- Última evidencia
- Advertencia fría

Este rail debe estar visible en pantallas críticas para evitar dispersión.

---

5. Pantallas clave

Pantalla 1 — Command Deck

**Objetivo:** responder en menos de 10 segundos qué importa hoy.

Contenido

• Prioridad dominante desde `DASHBOARD.md`.
• Objetivo guía desde `GOALS.md`.
• Semáforo operativo: verde / amarillo / rojo.
• Próxima acción no negociable.
• Evidencia de hoy desde `DAY_BY_DAY/YYYY-MM-DD.md`.
• Proyectos críticos por impacto.

Wireframe textual

┌────────────────────────────────────────────────────────────────────────────┐
│ ROMIL // COMMAND DECK // 2026-06-14          EVIDENCIA HOY: 0/1   ● LIVE   │
├───────────────┬──────────────────────────────────────────────┬─────────────┤
│ NAV           │ PRIORIDAD DOMINANTE                          │ SELDON      │
│ > Command     │ Convertir capacidad en ingreso y evidencia   │ CHECK       │
│   Today       │ externa.                                     │             │
│   Projects    │                                              │ Bloqueo:    │
│   Goals       │ [OBJ-P1] Independencia financiera progresiva │ cierre com. │
│   Captures    │                                              │             │
│   Agents      │ ┌─────────┐ ┌─────────┐ ┌─────────┐          │ Siguiente:  │
│               │ │ VERDE   │ │ AMARILLO│ │ ROJO    │          │ enviar /    │
│               │ │ ventas  │ │ sistema │ │ rediseño│          │ publicar    │
│               │ └─────────┘ └─────────┘ └─────────┘          │             │
│               │                                              │ Advertencia │
│               │ PROYECTOS POR IMPACTO                        │ No optimices│
│               │ 1. fdata       → landing/oferta              │ para evitar │
│               │ 2. Energo Pro  → seguimiento                 │ vender.     │
│               │ 3. Dillman     → reunión                     │             │
└───────────────┴──────────────────────────────────────────────┴─────────────┘

Interacciones mínimas

• Click en proyecto abre ficha.
• Click en “registrar evidencia” abre captura rápida.
• Click en “actualizar prioridad” edita/propone cambio para `DASHBOARD.md`.

---

Pantalla 2 — Today / Day Log

**Objetivo:** convertir el día en evidencia.

Fuente

/root/ROMIL/DAY_BY_DAY/YYYY-MM-DD.md

Contenido

• Foco del día.
• Tareas/avances.
• Evidencia producida.
• Pensamientos/decisiones.
• Mañana / siguiente acción.

Wireframe textual

┌────────────────────────── TODAY // 2026-06-14 ──────────────────────────┐
│ Foco del día                                                             │
│ [_______________________________________________________________] [Save] │
│                                                                          │
│ Tareas / avances                         Evidencia producida             │
│ ┌───────────────────────────────────┐    ┌────────────────────────────┐  │
│ │ [ ] Enviar seguimiento Dillman    │    │ + mensaje enviado          │  │
│ │ [ ] Publicar landing CV ATS       │    │ + archivo creado           │  │
│ │ [ ] Registrar decisión ROMIL UI   │    │ + reunión agendada         │  │
│ └───────────────────────────────────┘    └────────────────────────────┘  │
│                                                                          │
│ Pensamientos / decisiones                                                │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ - La UI será cabina de mando, no Notion clone.                       │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────┘

Interacciones mínimas

• Añadir tarea.
• Marcar completada.
• Añadir evidencia.
• Añadir decisión.
• Exportar/guardar en Markdown.

---

Pantalla 3 — Projects Matrix

**Objetivo:** mostrar qué proyectos merecen energía y cuáles son distracción.

Fuente

/root/ROMIL/DASHBOARD.md
/root/ROMIL/PROYECTS/*/README.md
/root/ROMIL/PROYECTS/*/TASKS.md

Layout

Una matriz por categoría estratégica:

1. Ingreso inmediato / comercial.

2. Activo propio / producto.

3. Sistema interno / apalancamiento.

4. Pausado / subordinado.

Campos por proyecto

Nombre
Estado
Objetivo vinculado
Siguiente acción
Última evidencia
Riesgo de dispersión

Wireframe textual

┌──────────────────────── PROJECTS MATRIX ────────────────────────┐
│ FILTRO: [Ingreso inmediato ▼] [Solo bloqueados] [Sin evidencia] │
├──────────────────────────────────────────────────────────────────┤
│ ENERGO PRO       activo   ingreso cliente     next: seguimiento │
│ DILLMAN ACCESS   activo   validación B2B      next: agendar     │
│ FDATA            activo   captación directa   next: landing ES  │
│ HOTMART CV ATS   activo   producto mínimo     next: oferta v1   │
├──────────────────────────────────────────────────────────────────┤
│ SISTEMA INTERNO                                                   │
│ ROMIL           activo    apalancamiento      riesgo: refugio    │
│ 1% Más          activo    evidencia diaria    riesgo: concepto   │
└──────────────────────────────────────────────────────────────────┘

Interacciones mínimas

• Abrir ficha de proyecto.
• Añadir tarea al proyecto.
• Registrar nota.
• Marcar riesgo o bloqueo.

---

Pantalla 4 — Project Detail

**Objetivo:** una vista de proyecto que fuerce siguiente acción.

Fuente

PROYECTS/<proyecto>/README.md
PROYECTS/<proyecto>/TASKS.md
PROYECTS/<proyecto>/NOTES.md
PROYECTS/<proyecto>/DOCS/

Contenido

• Qué es.
• Meta.
• Estado.
• Tareas activas.
• Notas recientes.
• Documentos.
• Decisiones.
• Siguiente acción recomendada.

Regla UX

La ficha no debe abrir con historia extensa. Debe abrir con:

Siguiente acción real: ______

Luego contexto.

---

Pantalla 5 — Capture Inbox

**Objetivo:** capturar sin fricción y clasificar después.

Inputs mínimos

• texto libre;
• tipo: tarea / nota / proyecto / decisión / recurso;
• proyecto relacionado opcional;
• prioridad opcional;
• destino sugerido por Seldon.

Wireframe textual

┌────────────────────────── CAPTURE INBOX ──────────────────────────┐
│ Captura rápida                                                     │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ t: llamar a Fernando para Dillman esta semana                  │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ Tipo detectado: Tarea         Destino: PROYECTS/Dillman-Access    │
│ [Guardar] [Guardar + crear tarea] [Mandar a revisión]             │
├───────────────────────────────────────────────────────────────────┤
│ Inbox pendiente                                                   │
│ - n: idea sobre ROMIL UI                                          │
│ - d: no construir Seldon como producto todavía                    │
└───────────────────────────────────────────────────────────────────┘

Conexión con flujo existente

Debe respetar convención documentada en `DOCS/mobile-capture-flow.md`:

t: tarea
n: nota
p: proyecto
d: decisión

---

Pantalla 6 — Agents / Autonomy Status

**Objetivo:** saber si los agentes están empujando trabajo o solo están vivos.

Fuente

/root/ROMIL/agent-status/task-*.json

Contenido

• tareas autónomas activas;
• estado: pending / running / blocked / stalled / completed;
• último heartbeat;
• evidencia;
• archivos tocados;
• next step.

Regla visual

El estado del agente debe medirse por evidencia, no por actividad.

Heartbeat sin evidencia = ruido.

---

Pantalla 7 — Search / Knowledge Map

**Objetivo:** buscar dentro de ROMIL sin perder el hilo estratégico.

Fuentes posibles

• búsqueda local en Markdown;
• OpenViking: `viking://resources/romil`;
• enlaces directos a archivos.

Comportamiento esperado

Cada resultado debe mostrar:

• archivo;
• tipo: goal / project / day log / note / resource / archive;
• fragmento;
• fecha aproximada;
• acción posible: abrir, convertir en tarea, registrar decisión.

---

6. Modelo de datos inicial

MVP sin base de datos.

Leer/escribir directamente Markdown y JSON:

/root/ROMIL/DASHBOARD.md
/root/ROMIL/GOALS.md
/root/ROMIL/DAY_BY_DAY/*.md
/root/ROMIL/PROYECTS/*/README.md
/root/ROMIL/PROYECTS/*/TASKS.md
/root/ROMIL/PROYECTS/*/NOTES.md
/root/ROMIL/agent-status/*.json

Regla arquitectónica

La UI no debe crear un segundo estado oculto.

Si necesita persistir algo, debe hacerlo en Markdown/JSON dentro de ROMIL.

---

7. MVP recomendado

No construir todo.

Primera versión funcional:

1. Command Deck.

2. Today / Day Log.

3. Projects Matrix.

4. Project Detail básico.

5. Capture Inbox simple.

Dejar para después:

• edición avanzada de Markdown;
• búsqueda semántica con OpenViking;
• estado de agentes en tiempo real;
• autenticación;
• multiusuario;
• gráficos complejos.

---

8. Stack técnico sugerido

Opción A — más rápida y suficiente

Python stdlib HTTP server + HTML/CSS/JS vanilla

Ventajas:

• cero dependencia pesada;
• deployable fácil;
• lee archivos locales;
• rápido de prototipar;
• coherente con la wiki app ya existente en `/root/referencias/repos/seldon-wiki-app`.

Opción B — si crece

FastAPI + HTMX + Jinja + CSS propio

Ventajas:

• más mantenible;
• formularios sencillos;
• server-side rendering;
• buena ergonomía para Markdown local.

Opción C — si se vuelve producto visual

React/Vite + API local

No recomendado para la primera versión. Riesgo de sobreingeniería.

---

9. Criterios de aceptación visual

La primera UI debe cumplir:

• carga el dashboard real desde `/root/ROMIL/DASHBOARD.md`;
• lista proyectos reales desde `/root/ROMIL/PROYECTS`;
• muestra el archivo diario actual;
• permite registrar una captura simple;
• visualmente se siente como consola estratégica, no SaaS genérico;
• tiene indicador de evidencia del día;
• funciona en desktop y móvil básico;
• no rompe archivos Markdown existentes.

---

10. Decisiones tomadas

• ROMIL UI será **cabina de mando**, no clon de Notion.
• Markdown seguirá como fuente de verdad.
• El primer enfoque visual será terminal retro operacional.
• El MVP debe reducir fricción de decisión, captura y evidencia diaria.
• No se construirá primero una arquitectura compleja ni una app React completa.

---

11. Próximo paso recomendado

Crear un prototipo navegable local con archivos estáticos/servidor mínimo:

/root/ROMIL/PROYECTS/ROMIL/ui-prototype/

Pantallas iniciales:

/index.html          Command Deck
/today.html          Day Log
/projects.html       Projects Matrix
/project.html        Project Detail mock/real
/capture.html        Capture Inbox
/styles.css          sistema visual
/app.js              lectura/interacciones mínimas

Verificación mínima:

1. Levantar servidor local.

2. Abrir en navegador.

3. Confirmar que no hay errores JS.

4. Confirmar que la UI representa datos reales de ROMIL, aunque sea parcialmente.

---

12. Advertencia Seldon

Construir ROMIL UI solo se justifica si baja fricción real.

Si se convierte en otra superficie para rediseñar identidad, ajustar paletas y evitar contacto comercial, se corta.

La interfaz debe empujar esto:

pensamiento → decisión → tarea → evidencia

No esto:

pensamiento → sistema → estética → más sistema