Codex/console tui navigation wip 20260402

README.md

@@ -10,16 +10,17 @@ Fuente de verdad operativa del VPS DAVLOS.
 - Fase 4 abierta y en pausa operativa.
 - La suboperación 4.2 quedó recuperada y no es bloqueo activo.
 - Sin secretos en este repositorio.
-- OpenClaw MVP local desplegado y validado documentalmente en esta rama.
+- OpenClaw ya no está solo en baseline MVP: el boundary opera en host con `inference-gateway`, broker restringido, Telegram persistente y helper readonly.
+- La DAVLOS VPN Console ya actúa como CLI operativo del boundary con dashboard, broker/capacidades, seguridad guiada y diagnóstico.
 
 ## Objetivo actual
 
 Prioridad operativa vigente:
 
-1. mantener el estado estable actual de `n8n`
-2. consolidar trazabilidad mínima de Fase 4
-3. fijar baseline técnico y documental de `OpenClaw` e `inference-gateway`
-4. revalidar tooling readonly antes de cualquier siguiente cambio
+1. mantener estable el runtime actual de `n8n` y `OpenClaw`
+2. consolidar la operación real de consola, broker y Telegram sin abrir superficie innecesaria
+3. mantener el helper readonly y el control restringido como baseline seguro del boundary
+4. mantener la documentación viva alineada con el estado real ya desplegado y con la operación vigente
 5. mantener Fase 4 en pausa hasta nueva decisión operativa
 
 ## Estado de n8n
@@ -44,6 +45,9 @@ Hechos confirmados en la documentación operativa actual:
 Checkpoint actual:
 
 - despliegue MVP local ejecutado y validado en host
+- broker restringido operativo en host con policy viva y auditoría
+- canal Telegram privado operativo como runtime persistente
+- helper readonly host-side instalado para inspección segura de broker y Telegram desde consola
 - runtime materializado en host bajo:
   - `/opt/automation/agents/openclaw`
   - `/etc/davlos/secrets/openclaw`
@@ -66,17 +70,59 @@ Checkpoint actual:
   - `docs/OPENCLAW_SECURITY_BOOTSTRAP_MVP.md`
   - `docs/OPENCLAW_HOST_SECRETS_CONTRACT_MVP.md`
   - `templates/openclaw/openclaw.json.example`
-- observabilidad readonly integrada en consola:
+- operación integrada actual en consola:
+  - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh overview`
   - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw`
-  - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-health`
-  - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-logs`
-- todavía no existe en este baseline:
-  - broker restringido
-  - menú final de control con acciones de escritura
-  - integración Telegram
-  - chat operativo final
-  - acciones A/B/C/D
-  - allowlist real de egress aplicada en runtime
+  - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-capabilities`
+  - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-capabilities-audit`
+  - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-telegram`
+  - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-diagnostics`
+- helper readonly host-side para visibilidad runtime:
+  - `/usr/local/sbin/davlos-openclaw-readonly`
+  - `/etc/sudoers.d/davlos-openclaw-readonly`
+- ownership observado en runtime:
+  - `root` conserva `compose`, `broker`, `dropzone` y secretos
+  - `devops` posee `config`, `state` y `logs`
+  - este reparto debe tratarse como deliberado hasta que exista una decisión posterior respaldada por evidencia y rollback
+- superficie operativa actual:
+  - dashboard de consola con estado de host, broker, Telegram y runtime
+  - consola reorganizada por runtime, broker, seguridad, evidencias y diagnóstico
+  - control guiado de capacidades con TTL y reset one-shot
+  - presets de seguridad en consola
+  - Telegram como canal corto de consulta, ejecución cerrada y modo conversacional controlado
+  - local-first en Telegram: frases conocidas siguen por reglas; el fallback LLM solo entra en `wake` cuando el matcher local no resuelve
+  - Gemini puede operar como fallback controlado en runtime mediante env seguro, sin alterar el perímetro `auth/policy/broker`
+- límites que siguen vigentes:
+  - no hay UI web final de control; la operación principal sigue en consola + Telegram
+  - start/stop/restart no se exponen directamente desde la consola
+  - el hardening final de egress no se declara cerrado en este README
+
+## Distinción operativa obligatoria
+
+Para OpenClaw, este repositorio debe distinguir siempre entre tres planos:
+
+- documentación y diseño objetivo;
+- plantillas y scripts de despliegue versionados;
+- estado operativo real observado en host.
+
+Las plantillas del repo no deben leerse automáticamente como espejo exacto del runtime vivo.
+
+Ejemplos ya conocidos de drift que exigen prudencia:
+
+- el publish northbound observado del gateway es loopback-only en `127.0.0.1:18789`;
+- `templates/openclaw/openclaw.json.example` mantiene `bind: "lan"` y hoy debe tratarse como drift contractual pendiente, no como permiso para corregir el runtime a ciegas;
+- `scripts/agents/openclaw/30_first_local_deploy.sh` es despliegue real y no mero staging;
+- el helper readonly versionado ya expone cinco modos, incluido `operational_logs_recent`.
+
+Mientras exista drift material repo/host:
+
+- no redeployar a ciegas;
+- no sobrescribir runtime vivo con plantillas por reflejo;
+- no asumir que una plantilla sensible ya representa el estado efectivo del VPS.
+
+La referencia documental explícita para este punto es:
+
+- `docs/OPENCLAW_RUNTIME_DRIFT_2026-04-08.md`
 
 ## Documentos clave
 
@@ -93,9 +139,16 @@ Checkpoint actual:
 - `runbooks/OPENCLAW_DEPLOY_MVP.md`
 - `docs/OPENCLAW_SECURITY_BOOTSTRAP_MVP.md`
 - `docs/OPENCLAW_HOST_SECRETS_CONTRACT_MVP.md`
+- `docs/CONSOLE_OPENCLAW_CAPABILITIES_MVP.md`
+- `docs/DAVLOS_VPN_CONSOLE_PRESENTATION_MVP.md`
+- `docs/OPENCLAW_OPERATOR_FLOWS_MVP.md`
+- `docs/TELEGRAM_OPENCLAW_RUNTIME_FINAL.md`
+- `docs/TELEGRAM_OPENCLAW_CONVERSATIONAL_MVP.md`
+- `docs/TELEGRAM_OPENCLAW_LLM_FALLBACK_PHASE_16_17.md`
+- `docs/OPENCLAW_READONLY_HELPER_INSTALL.md`
 
 Nota:
-Algunos documentos conservan contexto histórico y deben leerse con fecha y alcance. La verdad operativa actual de `n8n` queda reflejada en este `README`, en `evidence/FASE_4_ESTADO.md`, en `evidence/PHASE4_PAUSE_AND_4_2_RECOVERED_2026-03-31.md` y en las evidencias recientes de prechecks. La verdad actual de `OpenClaw` en este checkpoint es: MVP local desplegado, aislado y observable en modo readonly, pero todavía sin capa final de control restringido ni hardening completo de egress.
+Algunos documentos conservan contexto histórico y deben leerse con fecha y alcance. La verdad operativa actual de `n8n` queda reflejada en este `README`, en `evidence/FASE_4_ESTADO.md`, en `evidence/PHASE4_PAUSE_AND_4_2_RECOVERED_2026-03-31.md` y en las evidencias recientes de prechecks. La verdad actual de `OpenClaw` en este checkpoint es: boundary operativo con `inference-gateway`, broker restringido con policy viva y auditoría, Telegram persistente como canal corto, modo conversacional controlado `local-first`, fallback LLM acotado a `wake` y helper readonly host-side para inspección segura desde consola. El hardening final de egress sigue documentado por fases y no se declara cerrado en este `README`.
 
 ## Regla base
 

docs/AGENTS.md

@@ -13,16 +13,30 @@ No sustituye la evidencia operativa validada en runtime.
 - existe un único runtime de agente documentado y validado: `OpenClaw`
 - el servicio desplegado es `openclaw-gateway`
 - el runtime host-side vive bajo `/opt/automation/agents/openclaw`
-- la ruta host-side de secretos reservada es `/etc/davlos/secrets/openclaw`
+- la ruta host-side de secretos usada hoy es `/etc/davlos/secrets/openclaw`
 - la red usada es `agents_net`
 - el bind host publicado para el gateway es `127.0.0.1:18789`
 - OpenClaw consume inferencia por `http://172.22.0.1:11440/v1`
 - el upstream real de inferencia es `inference-gateway.service` en host
 - `inference-gateway` escucha solo en `127.0.0.1:11440` y `172.22.0.1:11440`
 - `inference-gateway` ya no responde por la IP pública del host
 - la reachability `agents_net -> 172.22.0.1:11440` quedó validada en runtime
+- existe broker restringido operativo en host con policy viva y auditoría
+- existe Telegram persistente operativo como canal corto, con degradación/intermitencia de polling ya observada
+- existe helper readonly host-side y debe tratarse como vía preferente de observabilidad controlada
 - la consola `DAVLOS VPN Console` expone observabilidad readonly para `OpenClaw` e `inference-gateway`
 
+## precedencia documental
+
+Para OpenClaw deben distinguirse siempre tres planos:
+
+- estado operativo real observado;
+- plantillas y scripts versionados;
+- diseño y documentación del repo.
+
+Este documento describe el contrato operativo vigente del repo, pero no sustituye evidencia de host.
+Cuando exista drift material entre repo y runtime, debe prevalecer la evidencia observada y documentarse el gap antes de cualquier redeploy.
+
 ## trust boundary operativa
 
 La zona de agentes actual se compone de dos piezas separadas:
@@ -59,6 +73,10 @@ Motivo de la separación:
   - `no-new-privileges`
   - `cap_drop: ALL`
   - sin publicación en IP pública
+- drift contractual conocido:
+  - el control northbound observado es loopback-only por publish host
+  - `templates/openclaw/openclaw.json.example` mantiene `bind: "lan"`
+  - este punto debe tratarse como drift contractual/documental pendiente y no corregirse a ciegas en runtime
 
 ### inference-gateway
 
@@ -79,7 +97,18 @@ Motivo de la separación:
 - el repositorio no contiene secretos reales
 - `OPENCLAW_GATEWAY_TOKEN` sigue siendo el único secreto operativo mínimo del MVP local
 - hoy puede vivir en el `.env` root-owned del runtime de OpenClaw
-- `/etc/davlos/secrets/openclaw` queda reservado para crecimiento posterior sin reestructurar mounts ni contrato host-side
+- `/etc/davlos/secrets/openclaw` ya forma parte del runtime host-side efectivo
+
+### ownership observado del runtime
+
+- `root` conserva `compose`, `broker`, `dropzone` y secretos
+- `devops` posee `config`, `state` y `logs`
+
+Juicio operativo:
+
+- este reparto debe tratarse como deliberado;
+- no debe simplificarse a `chown -R` completo a `devops`;
+- si hiciera falta más visibilidad operativa para `devops`, la vía preferente sigue siendo helper readonly o un mecanismo acotado equivalente.
 
 ## límites explícitos de acceso
 
@@ -113,15 +142,17 @@ Motivo de la separación:
 - trust boundary separada respecto a `n8n`, NPM, WireGuard y PostgreSQL
 - mínimo privilegio en el contenedor
 - sin credenciales cloud necesarias en este MVP local
+- broker restringido y Telegram ya forman parte del runtime operativo observado
 - cambios operativos posteriores deben ser pequeños, reversibles y con evidencia
-- el siguiente tramo de evolución es broker restringido, no nuevas capacidades prematuras
+- cualquier intervención posterior debe pasar antes por revisión explícita de drift repo/runtime
 
 ## riesgos residuales conocidos
 
-- la allowlist real de egress para `agents_net` sigue pendiente
+- el hardening final de egress sigue pendiente de cierre documental final
 - la imagen sigue fijada por tag revisado y no por digest operativo final
 - el `healthcheck` actual de OpenClaw es suficiente para MVP, pero no equivale a política final de liveness/readiness
 - existe drift operativo en UFW entre configuración declarada y reglas runtime cargadas; hoy no bloquea la operación, pero debe normalizarse antes de endurecimientos posteriores
+- existe drift material entre documentación, plantillas y runtime observado; no debe redeployarse a ciegas mientras siga abierto
 
 ## superficie disponible hoy
 
@@ -133,14 +164,13 @@ Motivo de la separación:
 
 ## lo que no debe darse por implementado
 
-- broker restringido
-- policy store
 - menú final de control de capacidades con escritura
-- integración Telegram
 - chat operativo final
 - acciones A/B/C/D
-- allowlist final de egress aplicada
+- allowlist final de egress declarada como totalmente cerrada por toda la documentación
 - política final de secretos para proveedores externos
+- resolución definitiva del drift entre publish loopback y `bind: "lan"`
+- coincidencia exacta entre plantillas sensibles y runtime vivo
 
 ## documentos de referencia
 
@@ -151,5 +181,6 @@ Motivo de la separación:
 - `docs/OPENCLAW_HOST_SECRETS_CONTRACT_MVP.md`
 - `runbooks/OPENCLAW_DEPLOY_MVP.md`
 - `runbooks/OPENCLAW_ROLLBACK_MVP.md`
+- `docs/OPENCLAW_RUNTIME_DRIFT_2026-04-08.md`
 - `docs/reports/OPENCLAW_BOUNDARY_RUNTIME_FIX_2026-04-01.md`
 - `docs/reports/OPENCLAW_AGENTS_NET_REACHABILITY_FIX_2026-04-01.md`

docs/CONSOLE_OPENCLAW_CAPABILITIES_MVP.md

@@ -2,58 +2,96 @@
 
 ## objetivo
 
-Documentar el uso del submenú de capacidades OpenClaw en la DAVLOS VPN Console, reutilizando la CLI del broker y la política viva existentes.
+Documentar el uso del bloque `Broker y capacidades` de la DAVLOS VPN Console, reutilizando la CLI del broker, la policy viva y el helper readonly host-side cuando el runtime no es legible directamente.
 
 ## principio de integración
 
 La consola no edita JSON directamente.
 
-Toda operación se apoya en:
+Toda mutación se apoya en:
 
 - `scripts/agents/openclaw/restricted_operator/cli.py`
 
-La consola solo actúa como front-end Bash de operador para:
+La consola actúa como front-end Bash de operador para:
 
 - listar estado efectivo
+- ver auditoría reciente
+- ver catálogo de acciones
 - habilitar o deshabilitar acciones
 - habilitar una acción con TTL
 - resetear una acción `one_shot`
-- ver auditoría reciente
 
 Las mutaciones no se aplican directamente desde Bash:
 
 - la consola resuelve un `operator_id`
 - la CLI valida ese `operator_id` contra la allowlist viva de operadores
 - si el operador no está autorizado, la mutación se rechaza y queda auditada
 
+La inspección readonly del runtime intenta este orden:
+
+1. lectura directa del runtime
+2. helper host-side `sudo -n /usr/local/sbin/davlos-openclaw-readonly`
+3. fallback declarativo a la policy visible del repo
+
 ## entrada al menú
 
 Desde la consola:
 
-- `7) OpenClaw / inference-gateway`
-- `5) Capacidades OpenClaw`
+- `3) Broker y capacidades`
+- `1) Estado efectivo`
+- `2) Auditoría reciente`
+- `3) Catálogo de acciones`
+- `4) Control manual por acción`
+- `5) Diagnóstico broker/runtime`
 
 También existen accesos directos:
 
 - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-capabilities`
 - `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-capabilities-audit`
+- `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-actions`
+- `bash /opt/control-plane/scripts/console/davlos-vpn-console.sh openclaw-diagnostics`
 
 ## operaciones disponibles
 
 ### ver acciones y estado efectivo
 
 Muestra por acción:
 
-- `action_id`
-- `enabled`
+- `status`
 - `mode`
+- `allowed`
+- `permission`
+- `action_id`
 - `expires_at`
 - `one_shot`
-- `one_shot_consumed`
-- `status`
+- `consumed`
 - `reason`
 - `updated_by`
 
+Cuando el runtime no es legible directamente pero el helper readonly está instalado, la consola usa:
+
+- `sudo -n /usr/local/sbin/davlos-openclaw-readonly broker_state_console`
+
+### ver auditoría reciente
+
+Llama a:
+
+- `cli.py audit-tail --lines 20`
+
+Si la CLI no puede leer el runtime por permisos y el helper readonly está instalado, la consola usa:
+
+- `sudo -n /usr/local/sbin/davlos-openclaw-readonly broker_audit_recent`
+
+### ver catálogo de acciones
+
+La consola muestra una ficha operativa por acción conocida con:
+
+- `label`
+- `action_id`
+- `permission`
+- descripción corta
+- badge visual `READONLY`, `RESTRICTED` o `CONTROL`
+
 ### habilitar acción
 
 Pide:
@@ -103,11 +141,17 @@ Llama a:
 
 - `cli.py reset-one-shot`
 
-### ver auditoría reciente
+### control manual por acción
 
-Llama a:
+En modo interactivo, la consola ya no obliga al operador a memorizar siempre `action_id`.
 
-- `cli.py audit-tail --lines 20`
+Puede seleccionar desde menú:
+
+- `action.webhook.trigger.v1`
+- `action.dropzone.write.v1`
+- `action.openclaw.restart.v1`
+
+o introducir un `action_id` manual cuando haga falta.
 
 ## trazabilidad mínima
 
@@ -122,24 +166,28 @@ Los cambios de capacidades dejan al menos:
 
 La auditoría se conserva en el audit log del broker.
 
+Cuando existe helper readonly, la consola puede leer esa auditoría y el estado efectivo sin abrir permisos generales sobre `/opt/automation`.
+
 ## degradación segura
 
 Si la sesión no tiene:
 
 - acceso a la policy
 - acceso a Python
-- permisos para escribir el state store
+- permisos para leer o escribir el state store
 - un `operator_id` autorizado para mutaciones
 
 la consola:
 
 - muestra un mensaje corto y claro
 - no rompe otros menús
 - no intenta editar JSON manualmente
+- si existe helper readonly, intenta leer runtime y auditoría por esa vía antes de degradar
 
 ## límites conocidos
 
 - no existe autenticación fuerte final
-- no hay menú final de producto, solo menú de operador
-- el restart de OpenClaw sigue fuera del alcance de esta fase
-- el menú opera sobre la policy disponible en runtime o, si no existe, sobre el ejemplo versionado visible
+- no hay UI web final de control; la operación sigue siendo consola + Telegram
+- `action.openclaw.restart.v1` sigue siendo la acción más sensible y debe abrirse con TTL corto
+- sin helper readonly o permisos equivalentes, la visibilidad del runtime activo puede degradarse
+- el menú prioriza siempre policy/runtime real; el ejemplo versionado del repo solo es fallback declarativo