Delivery Hub · OpenClaw empresarial

Resumen Ejecutivo

La idea no es “instalar OpenClaw y ya está”. La oportunidad real es crear una distribución corporativa de OpenClaw orientada a Delivery Hub: un entorno de trabajo local, repetible y seguro que se conecte a las herramientas de delivery y reduzca la fricción de empezar en un cliente nuevo.

Objetivo

Que un consultor instale un paquete interno, autentique sus accesos y pueda enganchar un repositorio de cliente para empezar a entender backlog, código, PRs y contexto operativo.

Restricción clave

La información de cliente permanece en el portátil de empresa, salvo las llamadas al LLM cloud empresarial autorizado por la compañía.

Primer MVP útil

Instalador + repo genérico + configuración de Azure DevOps/Slack/LLM + ingesta inicial de backlog + resumen navegable del cliente.

Decisión recomendada: empezar con WSL2 dedicada en Windows 11 para velocidad de adopción, y dejar una variante Hyper-V para clientes o contextos donde se necesite una frontera de aislamiento más visible.

Principios de Diseño

Repositorio genérico separado de cliente. Delivery Hub vive en un repositorio corporativo genérico. La información de cada cliente se almacena en repositorios, workspaces o carpetas separadas.
Instalación repetible. El setup debe funcionar como un producto interno, no como una receta artesanal. El instalador prepara entorno, dependencias, configuración base y comprobaciones.
Proveedor LLM único y aprobado. La distribución debe venir sin proveedores personales configurados. El único destino de prompts con contenido de cliente debe ser el LLM empresarial autorizado.
Menor contexto suficiente. Antes de llamar al LLM, usar Graphify, Caveman, repo maps, búsqueda local y filtros de diff para reducir tokens y exposición.
Auditable por defecto. Cada ejecución relevante debe dejar rastro: repositorio, PR, modelo, coste estimado, fecha, tipo de revisión y resultado. Evitar guardar prompts completos si incluyen cliente.
Enganche rápido a cliente. El usuario no debería editar JSON a mano para empezar. Debe poder ejecutar un comando tipo delivery-hub attach y completar un asistente guiado.

Arquitectura Objetivo

La arquitectura se divide en tres capas: distribución corporativa, workspace de cliente y conectores aprobados. El portátil de empresa es el perímetro operativo, y el LLM empresarial es la única salida permitida para contexto sensible cuando la política lo autorice.

Componentes

Componente	Responsabilidad	Datos que maneja	Notas de seguridad
OpenClaw custom	Gateway, agentes, skills, comandos internos y políticas de herramientas.	Configuración local, conversaciones, artefactos de análisis.	Debe venir sin providers personales y con allowlist de herramientas.
Delivery Hub repo	Plantillas, prompts, playbooks, reglas de ingestión, conectores y documentación.	Información genérica no cliente.	Debe poder actualizarse sin tocar repos de cliente.
Workspace cliente	Repositorios, índices locales, caché del backlog, notas de discovery.	Información sensible de cliente.	No mezclar con el repo genérico. Backups y logs según política.
Conector Azure DevOps	Clonar repos, leer PRs, Work Items, Boards y pipelines.	Código, backlog, comentarios y metadatos.	PAT mínimo, ideal OAuth corporativo, scopes separados para read/write.
Conector Slack	Publicar resúmenes, pedir confirmaciones, recibir comandos.	Mensajes de coordinación, no código completo salvo permiso explícito.	Canales allowlist y modo confirmación antes de publicar.
LLM empresarial	Razonamiento, resumen, clasificación y revisión.	Contexto mínimo necesario extraído localmente.	Endpoint único aprobado, sin fallback accidental a proveedores personales.

Seguridad y Gobierno de Datos

El diseño debe partir de una política explícita: los datos de cliente pueden salir únicamente hacia el LLM cloud empresarial aprobado, y solo cuando la tarea lo justifica. Todo lo demás debe ejecutarse localmente o contra sistemas corporativos autorizados.

Permitido

Azure DevOps corporativo o del cliente autorizado.
Slack corporativo con canales allowlist.
LLM empresarial aprobado.
Registros locales de auditoría sin prompts completos sensibles.

Evitar o bloquear

APIs personales de OpenAI, Anthropic u otros proveedores.
Fallback automático a modelos no corporativos.
Subidas a servicios externos no aprobados.
Sincronización del workspace cliente con OneDrive personal.

Fronteras de aislamiento

Hay dos niveles razonables para Windows 11:

WSL2 dedicada: rápida, suficiente para un MVP, cómoda para Node/OpenClaw/Docker, y fácil de automatizar. Recomendable desactivar el automount de discos Windows si se quiere evitar lectura accidental de C:\Users.
VM Hyper-V dedicada: más pesada, pero con una frontera más clara. Útil si el cliente o seguridad interna exigen aislamiento fuerte.

Docker Desktop no sustituye a una política de datos. Docker ayuda a empaquetar, pero si se montan carpetas amplias, el socket de Docker o credenciales del host, el aislamiento real cae mucho. Para este caso, Docker debe ser una herramienta dentro del entorno dedicado, no la frontera principal de seguridad.

Política mínima de secretos

DELIVERY_HUB_HOME=~/.delivery-hub
DELIVERY_HUB_CLIENTS=~/.delivery-hub/clients
AZDO_ORG_URL=https://dev.azure.com/empresa
AZDO_AUTH_MODE=device-code|pat|oauth
SLACK_WORKSPACE=empresa.slack.com
LLM_PROVIDER=enterprise
LLM_ENDPOINT=https://llm.empresa.example/v1
LLM_MODEL_MINI=enterprise-mini
LLM_MODEL_STRONG=enterprise-frontier
DISABLE_PERSONAL_PROVIDERS=true

El instalador no debería pedir secretos y escribirlos en texto claro sin control. Para el MVP puede usar .env local con permisos restringidos dentro del entorno aislado. Para una versión corporativa, conviene pasar a Windows Credential Manager, Azure Key Vault, 1Password Business o el mecanismo que ya use la compañía.

Instalador Empresarial

El instalador debe comportarse como un bootstrapper: prepara el entorno y deja la máquina lista para ejecutar Delivery Hub, pero no debe contener secretos de cliente ni lógica específica de un cliente concreto.

Forma de distribución

Opción	Ventaja	Coste	Recomendación
Script PowerShell firmado	Rápido para MVP, fácil de versionar y auditar.	Menos experiencia de producto, más dependencias del entorno.	MVP
MSIX / instalador Windows	Mejor UX corporativa, actualización y desinstalación más limpias.	Más trabajo de empaquetado y firma.	Fase 2
Imagen WSL preconfigurada	Muy reproducible. Reduce “en mi máquina falla”.	Gestión de versiones y tamaño de imagen.	Buena
VM Hyper-V appliance	Aislamiento claro y entorno homogéneo.	Más pesada, más fricción para el usuario.	Alta seguridad

Comandos previstos

# Instalación inicial
powershell -ExecutionPolicy Bypass -File install-delivery-hub.ps1

# Comprobación del entorno
delivery-hub doctor

# Login guiado en proveedores aprobados
delivery-hub login devops
delivery-hub login slack
delivery-hub login llm

# Conectar un cliente nuevo
delivery-hub attach \
  --client canfordlaw \
  --repo https://dev.azure.com/org/project/_git/repo \
  --board https://dev.azure.com/org/project/_boards/board

# Ingestar backlog y generar primer mapa
delivery-hub ingest backlog --client canfordlaw
delivery-hub ingest repo --client canfordlaw
delivery-hub brief --client canfordlaw

Preflight checks

Windows 11 compatible y virtualización habilitada.
WSL2 instalada o capacidad de instalarla con privilegios de admin.
Docker Desktop disponible si el modo elegido lo necesita.
Node compatible para OpenClaw dentro del entorno dedicado.
Conectividad a Azure DevOps, Slack y endpoint LLM empresarial.
No hay providers personales configurados como fallback.
Workspace de cliente no está dentro de carpetas sincronizadas no aprobadas.

Integraciones

Azure DevOps

Azure DevOps es el conector principal porque aporta repositorios, pull requests, work items y boards. Conviene dividir permisos por capacidades.

Capacidad	Permiso mínimo	Uso	Modo MVP
Clonar repo	Code Read	Indexar y analizar código localmente.	PAT temporal o OAuth/device code.
Leer PRs	Code Read	Resumir diffs, revisar riesgos, detectar cambios sensibles.	API REST + git local.
Comentar PRs	Code Read & Write	Publicar revisión automática.	Desactivado por defecto; requerir confirmación.
Leer Boards	Work Items Read	Ingestar backlog, épicas, features, bugs, estados.	Solo lectura al principio.
Actualizar backlog	Work Items Read & Write	Crear sugerencias, refinar tareas, mover estados.	Fase posterior con aprobación humana.

Slack

Slack debe ser una interfaz de coordinación, no un vertedero de contexto sensible. El uso inicial debería limitarse a publicar resúmenes, avisos y enlaces internos.

Canales allowlist por cliente o proyecto.
Mensajes cortos con enlaces a Azure DevOps, no dumps de código.
Modo confirmación para cualquier mensaje generado por IA que vaya a un canal humano.
Separar “triage bot” de “worker agent” si se quiere reducir exposición en Slack.

LLM empresarial

El LLM empresarial es la pieza permitida para razonamiento con datos de cliente. Aun así, el diseño debe minimizar contexto y controlar modelo.

Modelo mini para clasificación, routing, resúmenes iniciales y revisiones de bajo riesgo.
Modelo fuerte solo para arquitectura, seguridad, datos, migraciones, incidentes o cambios extensos.
Prompt caching si el proveedor lo soporta: instrucciones estables y policy block al principio.
Sin fallback automático a otros proveedores.

Ingesta de Backlog

La primera experiencia útil de Delivery Hub debería ser: “conecto un repo y un board, y en pocos minutos tengo una lectura navegable del estado del cliente”.

Datos a capturar

Épicas, features, historias, bugs, tareas y estados.
Relaciones padre-hijo, dependencias, bloqueos y ownership.
PRs abiertos y recientes, commits relacionados y ramas activas.
Áreas funcionales inferidas desde código, carpetas, tags y naming.
Riesgos: backlog huérfano, PRs sin task, tareas sin criterios, bugs recurrentes, cambios en zonas críticas.

Artefactos generados

Brief de cliente

Qué hace el producto, cómo está organizado el backlog, qué módulos parecen críticos y qué conviene revisar primero.

Mapa de delivery

Flujo desde idea hasta release: estados, cuellos de botella, reglas implícitas y gaps de proceso.

Mapa técnico

Repos, carpetas principales, dependencias, puntos de entrada, servicios, tests y zonas calientes.

Radar de riesgos

Lista priorizada de riesgos técnicos y operativos con evidencia y próximos pasos sugeridos.

Automatización de PR Review

La automatización de PRs debe usar modelo mini como primera línea. El objetivo no es reemplazar la revisión humana, sino filtrar ruido, detectar riesgos repetibles y dar contexto rápido.

Flujo recomendado

Recibir evento de PR o ejecutar revisión bajo demanda.
Leer diff y metadatos: autor, rama, work item vinculado, archivos modificados.
Clasificar tipo de cambio con modelo mini: UI, backend, datos, auth, tests, infra, documentación.
Extraer contexto local mínimo con Graphify/Caveman/repo map.
Ejecutar revisores especializados: seguridad, datos, errores, tests, arquitectura.
Generar resultado con severidad, evidencia, línea/archivo y recomendación.
Publicar como comentario solo si está habilitado; si no, dejarlo en informe local o Slack privado.

Política de escalado de modelo

Condición	Modelo	Razón
Docs, copy, estilos, cambios pequeños de UI	Mini	Coste bajo y suficiente para checks básicos.
Tests, refactors locales, cambios de naming	Mini + reglas locales	La evidencia está en el diff y en comandos locales.
Auth, permisos, datos personales, secretos	Fuerte	Mayor coste aceptable por riesgo alto.
Migraciones, concurrencia, integración externa	Fuerte	Requiere razonamiento contextual más profundo.
PR grande o multi-repo	Mini para particionar, fuerte por zonas críticas	Evita pasar contexto masivo de golpe.

Formato de salida

## AI PR Review

Resumen:
- Tipo de cambio: backend + validación
- Riesgo estimado: medio
- Work item vinculado: DH-1423

Hallazgos:
1. [Alta] Falta validación de tenant en `src/api/orders.ts`
   Evidencia: el handler usa `orderId` pero no comprueba ownership.
   Recomendación: validar tenant antes de recuperar o mutar la orden.

2. [Media] No hay test para el caso de permisos denegados
   Recomendación: añadir test de usuario sin acceso al tenant.

Checks locales:
- npm test: no ejecutado
- lint: no ejecutado
- análisis estático: sin secretos detectados

Operación Diaria

El valor de Delivery Hub aparece cuando el sistema se integra en la rutina: discovery inicial, seguimiento de backlog, revisión de PRs, resúmenes y preparación de conversaciones.

Modos de uso

Modo discovery

Primeros días de cliente. Ingesta backlog, mapa técnico, glosario, riesgos iniciales, módulos y owners.

Modo delivery

Uso recurrente. PR review, daily brief, detección de bloqueos, resumen de cambios y preparación de refinamientos.

Modo consultoría

Generar propuestas, diagnósticos, recomendaciones, planes de mejora y material para AI-Day.

Modo governance

Auditoría de uso, coste LLM, endpoints, permisos, clientes conectados y riesgos de privacidad.

Comandos de trabajo

# Estado del cliente
delivery-hub status --client canfordlaw

# Resumen diario
delivery-hub brief daily --client canfordlaw

# Preparar refinamiento
delivery-hub refine --client canfordlaw --area billing

# Revisar PR
delivery-hub pr review --client canfordlaw --id 1234 --mode draft

# Publicar resumen en Slack con confirmación
delivery-hub slack post --client canfordlaw --report daily --confirm

Roadmap MVP

Fase	Objetivo	Entregables	Criterio de éxito
0. Spike	Validar instalación y conectividad en portátil Windows 11.	Script PowerShell, WSL2 dedicada, OpenClaw instalado, provider LLM empresarial.	Se puede ejecutar una tarea simple sin providers personales.
1. Bootstrap	Instalar Delivery Hub genérico y configurar identidad.	Repo clonado, config local, doctor, login DevOps/Slack/LLM.	El usuario ejecuta `delivery-hub doctor` sin errores críticos.
2. Attach cliente	Conectar un repo y un board.	Comando `attach`, clonación, registro de cliente, caché inicial.	El sistema lista backlog y repos del cliente.
3. Ingesta	Generar primer brief útil.	Ingesta backlog, índice repo, mapa técnico, radar de riesgos.	Un consultor entiende el estado del cliente en menos de 30 minutos.
4. PR review	Automatizar revisión de PR con modelo mini.	CLI de review, salida local, draft de comentario, política de escalado.	Detecta hallazgos útiles sin coste excesivo.
5. Producto interno	Convertir el MVP en distribución mantenible.	Instalador firmado, actualización, documentación, auditoría, onboarding.	Otro consultor lo instala sin ayuda directa.

Riesgos y Mitigaciones

Riesgo	Impacto	Mitigación
Proveedor LLM incorrecto configurado por accidente	Exposición de datos de cliente fuera del canal aprobado.	Distribución sin providers personales, validación en `doctor`, bloqueo por config y revisión de variables de entorno.
Mezcla de repo genérico y datos de cliente	Filtraciones, mantenimiento difícil y forks divergentes.	Estructura obligatoria: `delivery-hub-core/` separado de `clients/CLIENT/`.
PR review con falsos positivos ruidosos	Los equipos dejarán de leer los informes.	Severidad estricta, salida corta, evidencia concreta y modo draft hasta calibrar.
Coste LLM descontrolado	Rechazo interno por coste o lentitud.	Modelo mini por defecto, límites por PR, cache, deduplicación de contexto y métricas.
Dependencias de instalación frágiles	Adopción baja por problemas en portátiles corporativos.	Preflight claro, logs de instalación, fallback manual documentado y paquete WSL preconfigurado.
Slack publica información sensible	Exposición dentro de canales no autorizados.	Canales allowlist, confirmación humana, resúmenes sin código y enlaces internos en lugar de contenido completo.

Checklist de Implementación

MVP técnico

Definir nombre del paquete interno: delivery-hub-openclaw, dhub o similar.
Crear repo genérico con estructura base: installer/, skills/, prompts/, connectors/, policies/, docs/.
Implementar install-delivery-hub.ps1 con preflight y logs.
Preparar WSL2 dedicada o perfil de instalación en entorno Linux.
Instalar OpenClaw y registrar skills corporativas.
Configurar provider LLM empresarial como único proveedor.
Implementar delivery-hub doctor.
Implementar delivery-hub attach para repo + board.
Implementar ingesta inicial de Azure Boards y repos.
Generar brief HTML/Markdown local del cliente.
Implementar review de PR en modo draft/local.

MVP organizativo

Aclarar por escrito la política de uso del LLM empresarial con datos de cliente.
Definir quién mantiene el repo genérico de Delivery Hub.
Definir scopes mínimos de Azure DevOps para usuarios y automatizaciones.
Definir canales Slack permitidos y reglas de publicación.
Preparar un AI-Day interno para compartir casos, aprendizajes y límites.
Crear una guía de onboarding de 30 minutos para consultores.

Primera demo sugerida

Instalar en un portátil limpio o VM Windows 11.
Login con Azure DevOps, Slack y LLM empresarial.
Conectar un repo de prueba no sensible.
Ingestar backlog y repo.
Generar brief inicial.
Revisar un PR pequeño con modelo mini.
Publicar un resumen manualmente confirmado en Slack.

Resultado esperado: una historia de producto clara: “instalo, conecto cliente, entiendo backlog, reviso PRs y comparto contexto útil en menos de una hora”.