ComandeskHelp Inicio

Estado actual del proyecto OPS

Fecha de referencia: 2026-05-29.

Este documento es la foto corta para retomar trabajo sin depender de memoria de chat. El plan estrategico activo es convertir OPS/Komandesk en un producto hibrido vendible: SaaS como plano de control y runner local/repo remoto como plano de ejecucion.

Rama, entorno y documentacion

  • Rama de trabajo: codex/ops-hardening-restructure.
  • Repo OPS local: /Volumes/Disco SSD/Desarrollo/clientes/soluciones-abiertas/ops.
  • Produccion OPS: https://ops.solucionesabiertas.net.
  • Documentacion interna OPS: https://ops.solucionesabiertas.net/help/.
  • Export publico ES: /Volumes/Disco SSD/Desarrollo/docs/ops.
  • Export tecnico: /Volumes/Disco SSD/Desarrollo/docs/ops-technical.

Situacion actual

  • Fases HYB F1-F6 ejecutadas en el bloque estrategico del 2026-05-28.
  • No quedaban tareas HYB activas en cola tras cerrar F6.
  • El arbol git estaba limpio antes de esta actualizacion documental.
  • Produccion quedo activa despues de los deploys de F4, F5 y F6.
  • Documentacion publica y tecnica fue publicada despues de cada fase desplegada.
  • La arquitectura queda orientada a dos usos: uso personal/local-first y SaaS vendible/equipo.

Capacidades cerradas

F1 Cartera de proyectos

  • Vista de proyectos simplificada para localizar proyectos entre listas largas.
  • Busqueda, orden reciente, filtros rapidos y controles de cartera mas visibles.
  • Nombres/etiquetas de portfolio preparados para reducir confusion entre proyectos parecidos.

Commits principales:

  • 7018b35 simplify projects portfolio view
  • 58f7dd2 improve project portfolio search and prominence
  • 70534aa improve project portfolio triage
  • f9c17af improve project portfolio controls
  • 5797628 simplify project portfolio filters
  • 90fdc93 support project portfolio labels
  • 166b6c1 document flowtitude portfolio labels

F2 Memoria y asistente por proyecto

  • Contrato de memoria de proyecto documentado.
  • Panel de asistente con contexto de proyecto activo.
  • Perfiles/intenciones de modelo para tarea: rapido, razonamiento, codigo, revision y local.

Commits principales:

  • 2b3408c add project assistant memory contract
  • 5d70e3f add project context to assistant panel
  • 2b9136a add assistant model intent profiles

F3 Runner local MVP

  • Contrato base de local_runner_bindings.
  • Endpoints base para alta, edicion, borrado y heartbeat de runners locales.
  • Token de runner como API token revocable con scopes minimos.
  • Launcher con modo runner local, evidencia de runtime y adapters iniciales para OpenCode/Codex.

Commits principales:

  • 1e33bb8 add local runner binding contract
  • c03b407 enable local runner launcher mode
  • 9dcb2b5 record opencode runtime evidence
  • 39d9239 harden codex local runner adapter
  • 2957de4 fix local runner jsonb payloads
  • 1094795 fix public local runner docs link

F4 Catalogo runtime/modelo/credencial y BYOK/BYOS

  • API GET /api/security/runtime-catalog.
  • Vista tecnica en Gestion -> Credenciales con agentes, runtimes, proveedores, modelos, credenciales y runners.
  • Politica BYOK/BYOS visible:

- workspace y account: automatizables si el runtime/preflight encaja.

- personal-only: no automatizable desde SaaS.

- BYOS/local: solo via runner local autorizado y preflight.

Commits:

  • 8205f28 add runtime model credential catalog
  • 5448262 add byok byos runtime policy

Deploy F4:

  • Backup: /var/backups/ops-deploy/20260528_060100-hyb-f4-runtime-policy.
  • smoke:final: OK.
  • Docs publica/tecnica: publicadas.

F5 Watchdog, recurrentes y QA

  • Dispatch stale crea o reabre alerta de sistema y mueve tarea atascada a waiting.
  • Scheduler de recurrentes crea alertas para RRULE invalida, error de scheduler o instancia activa bloqueante.
  • Si una recurrente necesita correccion, se crea o reutiliza tarea scheduler-watchdog con tag recurring-watchdog.
  • Cierre IA exige QA por tipo de tarea y tiempo registrado antes de done.

Commits:

  • ac5f0fd add watchdog alerts for automations
  • 4d2c473 enforce task qa evidence checks

Deploy F5:

  • Backup: /var/backups/ops-deploy/20260528_061500-hyb-f5-watchdog-qa.
  • smoke:watchdog: OK.
  • Resultado de smoke registrado: workspace_id=1, dispatch.taskId=1180, dispatch.alertId=24, recurring.templateId=31, recurring.taskId=1181, recurring.alertId=25.
  • smoke:final: OK.
  • Docs publica/tecnica: publicadas.

F6 Onboarding y beta vendible

  • Readiness de proyecto crea tareas Onboarding piloto por modo de ejecucion.
  • Modos cubiertos:

- SaaS worker.

- Runner local.

- Repo/remoto.

  • Cada modo declara limite de promesa, checklist y primera ejecucion pequena.
  • Pricing inicial beta documentado para validar venta sin prometer autonomia imposible.

Commits:

  • c01c888 add execution mode onboarding pilot
  • bd243ad document beta pricing package

Deploy F6:

  • Backup: /var/backups/ops-deploy/20260528_062600-hyb-f6-onboarding-beta.
  • smoke:final: OK.
  • Docs publica/tecnica: publicadas.

Estado de runtime y ejecucion

El enfoque vigente no es "el SaaS entra al disco del usuario". La promesa correcta es:

> Komandesk coordina, audita y planifica; el runner local autorizado ejecuta en la maquina del usuario cuando hace falta acceso local.

Esto permite usar runtimes instalados por el usuario, como codex, opencode, claude, hermes, ollama u otros, siempre que:

  • el usuario los haya instalado y autenticado;
  • el runtime permita ejecucion no interactiva o suficientemente automatizable;
  • la tarea tenga ruta permitida, preflight y evidencia;
  • Komandesk no capture credenciales personales ni prometa saltarse terminos del proveedor.

Estado adicional 2026-05-29:

  • npm run runner:local:doctor valida entorno local antes de arrancar el runner.
  • npm run runner:local:doctor -- --offline permite preparar maquina sin token.
  • El doctor comprueba API, token, rutas permitidas, runtimes declarados, herramientas auxiliares y heartbeat.

Estado auditado F3.1 2026-05-29:

  • Dispatch global esta activo (dispatch_enabled=true) y dispatch_stale_minutes=20.
  • Worker launcher-ubuntu esta vivo, en idle, con agentes opencode y hermes.
  • ops-templates-scheduler.timer esta activo; ops-templates-scheduler.service queda inactivo entre ejecuciones por ser oneshot.
  • No hay runners locales activos reales en produccion; los dos bindings existentes estan revocados y eran de smoke.
  • CL-N1: Buscar topics comunidad Flowtitude si se ejecuto el 2026-05-29 a las 06:00 Europe/Madrid: creo la tarea #1263 en Flowtitude / comunidad, estado waiting, bloqueada para seleccion humana de topics.
  • Hay 7 task_templates activas, pero ninguna esta enlazada a flow_id; funcionan por flow_ref, descripcion y contrato de ejecucion.
  • Riesgo principal F3: las automatizaciones dejan evidencia, pero la UI no muestra aun con suficiente claridad que se ejecuto, que produjo y que decision humana queda pendiente.
  • F3.2 anade una vista operativa en Automatizaciones: recurrentes con ultima tarea, proxima ejecucion, estado, chips de filtro y acceso directo a tarea/proyecto.
  • F3.3 anade decisiones humanas estructuradas en tareas bloqueadas: opciones detectadas, seleccion unica/multiple y accion directa para flujos como CL-N1.
  • F3.4 anade una vista de Bloqueos accionable por causa y separa en Automatizaciones decision humana, runtime y review.
  • F3.5 enlaza todas las recurrentes activas con workflows REC-* de workspace; task_templates sigue siendo el driver runtime, pero la trazabilidad visible ya pasa por flow_id.

Documentos de entrada

  • Plan hibrido principal: docs/product/hybrid-saas-local-runner-plan-2026-05-28.md.
  • Contrato runner local: docs/architecture/local-runner-contract.md.
  • Catalogo runtime/modelo/credencial: docs/architecture/runtime-model-credential-catalog.md.
  • QA por tipo de tarea: docs/architecture/task-qa-evidence.md.
  • Onboarding por modo de ejecucion: docs/product/onboarding-execution-modes.md.
  • Pricing beta: docs/product/beta-pricing-2026-05-28.md.
  • Recurrentes: docs/how-to/recurring-tasks.md.
  • Dispatch: docs/runbooks/dispatch.md.

Riesgos y limites actuales

  1. Runner local aun no esta empaquetado como instalador final para cliente.
  2. BYOS es coordinable via runner local, pero no desde el servidor SaaS usando suscripciones personales del usuario.
  3. QA de cierre puede bloquear cierres validos si falta evidencia escrita o tiempo; usar force=true solo con justificacion.
  4. Las recurrentes tienen watchdog, pero sigue siendo necesario que cada plantilla tenga proyecto, owner, salida esperada y fallback.
  5. El pricing beta es orientativo hasta validar pilotos reales y carga de soporte.
  6. La UI esta mejor, pero todavia conviene seguir reduciendo botones visibles y moviendo controles tecnicos a vistas avanzadas.

Siguiente paso recomendado

  1. Ejecutar un piloto end-to-end en un proyecto real con modo runner local usando runner:local:doctor.
  2. Empaquetar runner local: script/instalador, vinculacion, preflight y revocacion de dispositivo.
  3. Poblar specs/planes de proyectos clave para que el asistente no trabaje con contexto vacio.
  4. Validar pricing beta con 1-2 pilotos y medir soporte, coste de runtime y tiempo humano.
  5. Seguir simplificando interfaz sin tocar de nuevo los flujos hasta comprobar uso real.
  6. Implementar una vista operativa de automatizaciones/recurrentes antes de ampliar el catalogo de flujos.

Regla operativa vigente

  • Cada tarea debe tener tiempo registrado, aunque no sea facturable.
  • Cada tarea cerrada debe tener evidencia o comentario de cierre.
  • Cada tarea implementada debe tener commit propio.
  • Cada fase desplegada debe tener backup, verificacion y publicacion de docs cuando aplique.
  • No introducir fallback silencioso de runtime/modelo/proveedor.
  • Antes de tocar dispatch, agentes, modelos, credenciales o plantillas, revisar:

- docs/architecture/saas-multitenant-operating-contract.md;

- docs/runbooks/dispatch.md;

- docs/architecture/runtime-model-credential-catalog.md;

- docs/architecture/task-qa-evidence.md.