Developing#

Guía para extender docker-labs sin romper el flujo Docker actual ni la nueva capa de distribución Windows.

Principios#

Cada carpeta debe resolver un problema concreto.
La documentación debe coincidir con el flujo soportado de verdad.
El launcher y el instalador son una capa aditiva; no reemplazan docker compose.
Si cambias puertos, scripts o manifests, debes alinear docs, launcher y release scripts.

Flujo soportado hoy#

scripts\start-control-center.cmd en Windows
./scripts/start-control-center.sh en Linux/macOS
docker-labs-launcher.exe para la distribución empaquetada Windows
dashboard-control/docker-compose.yml + 05 + 09 + 06 como experiencia principal

Estándar mínimo para un lab#

README.md
docker-compose.yml
Dockerfile si aplica
lab-manifest.json cuando el lab expone metadata para el panel
Healthcheck útil cuando el servicio lo justifica
URL principal o explicación de por qué no existe
Documentación del costo o conflicto de puertos si aplica

Capa Windows#

La distribución Windows vive en estas piezas:

version.txt: fuente única de la versión actual del proyecto
labs.config.json: fuente única de labs, puertos, URLs y metadata (cargado por dashboard-control/labs.js)
launcher/main.go: launcher Go — valida prerequisitos, levanta el Control Center y abre el browser
installer/docker-labs.iss: script Inno Setup 6.x para empaquetar el instalador
scripts/windows/build-launcher.ps1: compila el launcher con go build
scripts/windows/build-installer.ps1: empaqueta el instalador con ISCC.exe
scripts/windows/release.ps1: pipeline completo build + packaging en un solo comando
.github/workflows/build-windows.yml: CI/CD — genera el instalador al hacer push de un tag vX.Y.Z

Reglas para tocar la capa Windows#

No empaquetes Docker Desktop.
No hardcodees rutas del repo a C:\docker-labs\docker-labs.
No dejes binarios finales versionados en el repo.
Mantén el mensaje de binario no firmado claro y profesional.
Publica checksums junto al instalador.

Skills de automatización (Claude Code)#

El proyecto incluye dos skills de Claude Code que automatizan tareas frecuentes. Los skills se activan automáticamente cuando describes la tarea en lenguaje natural.

`docker-labs-release`#

Automatiza el flujo completo de release:

Lee la versión actual de version.txt
Propone un bump patch / minor / major (o versión específica)
Actualiza version.txt, hace commit, crea el tag vX.Y.Z y pushea a GitHub
El tag dispara build-windows.yml que compila y publica docker-labs-setup-X.Y.Z.exe

Frases que lo activan: _"haz un release"_, _"bump de versión"_, _"nueva versión"_, _"publicar v1.5.0"_, etc.

`docker-labs-status`#

Muestra el estado completo del sistema en un solo vistazo:

Versión actual y último tag git
Contenedores Docker corriendo y health HTTP de cada servicio
Estado del último workflow de GitHub Actions
Últimos commits en main

Frases que lo activan: _"estado de docker-labs"_, _"qué está corriendo"_, _"cómo va el proyecto"_, _"health check"_, etc.

Los skills están instalados en Claude Code y no requieren configuración adicional.

Flujo sugerido de cambios#

Ajusta el workspace Docker.
Si cambian rutas, labs o artefactos, actualiza installer/docker-labs.iss y dashboard-control/labs.js.
Verifica que el build local funciona: .\scripts\windows\build-launcher.ps1 y .\scripts\windows\build-installer.ps1.
Actualiza README.md, RUNBOOK.md, RELEASE.md y docs afectadas.
Documenta inconsistencias reales y correcciones en docs/technical-audit.md si cambian supuestos del repo.
Para publicar el release, usa el skill docker-labs-release o ejecuta manualmente:

"X.Y.Z" | Set-Content version.txt git add version.txt; git commit -m "chore: bump version to X.Y.Z" git tag vX.Y.Z; git push origin main; git push origin vX.Y.Z