Inicio / Documentación / CHANGELOG.md

📜 Changelog — Social Bot Scheduler#

Todos los cambios notables en este proyecto se documentan sistemáticamente en este archivo. Seguimos los principios de Keep a Changelog y el versionado semántico.

📦 [4.10.0] — 2026-08-19#

🌐 Sitio público del laboratorio en GitHub Pages#

El repositorio pasa a publicar un sitio propio en https://vladimiracunadev-create.github.io/social-bot-scheduler/: portada con la matriz de casos, tabla completa de integraciones y toda la documentación del repo navegable como HTML.

El sitio no se versiona. Se genera en cada despliegue desde las fuentes de verdad del repositorio (cases/*/app.manifest.yml y los 85 documentos Markdown), de modo que la web no puede afirmar algo distinto de lo que dice el código.

Añadido#

• scripts/build_site.py: generador del sitio (solo stdlib). Lee los manifiestos de los 20

  casos, renderiza los 85 .md a HTML y produce index.html, casos.html, documentacion.html, 404.html, sitemap.xml, robots.txt y .nojekyll.

• scripts/site_markdown.py: renderizador Markdown → HTML sin dependencias, con soporte de

  tablas, listas anidadas, bloques de código y alertas de GitHub (> [!NOTE]).

• scripts/check_site_links.py: verificador que falla si hay un enlace roto, un anchor

  muerto, un destino .md, una ruta absoluta o un recurso cargado desde otro host.

• .github/workflows/pages.yml: genera → verifica → publica. La verificación ocurre

  antes de subir el artefacto: Pages despliega un 404 con el mismo éxito que una página buena.

• site-src/assets/site.css: hoja de estilo del sitio, con la paleta del Master Dashboard y

  sin fuentes ni recursos remotos.

Cambiado#

• Manifiestos 01–09: se declara explícitamente status: "ready" y el bloque database:

  (MySQL, MariaDB, PostgreSQL, SQLite, MongoDB, Redis, Cassandra, SQL Server, DuckDB). Los manifiestos quedan como catálogo completo y legible por máquina de los 20 casos.

• .gitignore: se ignora site/ (artefacto generado).

Corregido#

• Enlaces rotos en la documentación: docs/DOCKER_RESOURCES.md apuntaba a un file:///

  local; el índice del README.md tenía tres anchors desactualizados; BEGINNERS_GUIDE, HUB y wiki/Usage-Guide apuntaban a un anchor inexistente de HEALTH_CHECK.md.

• CI en verde: axios sube a ^1.18.0 en los casos 03 y 04 (GHSA-gcfj-64vw-6mp9, el

  adaptador HTTP de Node podía reutilizar un proxy heredado tras clonar la config del interceptor) con sus pnpm-lock.yaml regenerados, y el job de Python actualiza setuptools/wheel antes de pip-audit (PYSEC-2026-3447 venía del runner, no del repo).

• Escaneo de contenedor limpio: la imagen final ya no lleva pip. hub.py no instala nada

  en ejecución y el árbol vendorizado de pip (msgpack, el pkg_resources de setuptools) era el único origen de hallazgos HIGH en Trivy — y ningún pip install --upgrade lo parchea.

📦 [4.9.1] — 2026-07-09#

✨ Migración de npm a pnpm en toda la superficie Node + follow-ups de coherencia#

Se estandariza el tooling JS del laboratorio en pnpm (el proyecto ya usaba pnpm-lock.yaml y pnpm audit en CI; quedaban usos de npm en Dockerfiles y runtime).

Cambiado#

• Dockerfiles Node (casos 03, 13, 14, 16, 17): npm install → corepack enable && corepack prepare pnpm@10.0.0 --activate + pnpm install --prod.
• Firebase (caso 20): firebase-tools global vía pnpm add -g con PNPM_HOME en PATH.
• docker-compose (caso 05, runtime): el command usa corepack + CI=1 pnpm install --prod.
• packageManager pnpm@11.0.0 → pnpm@10.0.0 en casos 03/04/05 (pnpm 11 exige Node ≥22.13 node:sqlite; las imágenes son node:20-alpine y el CI ya usa pnpm 10).
• Docs/comandos: npm → pnpm en cases/16 README, setup.py, killed.md, TROUBLESHOOTING; se aclara que el ecosistema npm de Dependabot rastrea los pnpm-lock.yaml.

Corregido#

• docs/API.md: el contrato de canal no era homogéneo — se documentan las dos formas (channel string en casos 10-20, channels array en el núcleo 01-06; 07-09 sin campo) y se marca la unificación como deuda técnica.
• README: badge de versión, conteo de motores (17 → 18+), y Dependabot ("11 ecosistemas" → "12 manifiestos en 6 ecosistemas").
• docs/AWS_MIGRATION.md: se completan los motores 10-20 (Kafka→MSK, MQTT→IoT Core, Neo4j→Neptune, InfluxDB→Timestream, CockroachDB, ClickHouse, pgvector) en tablas, diagramas y costos.

Verificado#

• Builds Docker OK de todos los Dockerfiles pnpm; flujos end-to-end confirmados en casos 03, 05, 14, 16, 17 y 20 (incl. el CLI global firebase-tools arrancando el emulador en runtime). CI verde.

🔍 [4.9.0] — 2026-07-08#

✨ Auditoría Docker end-to-end de los 19 casos + sincronización documental#

Barrido caso por caso levantando cada stack con Docker (limpieza total de contenedores e imágenes entre cada caso) y verificando la persistencia real en cada motor. Objetivo: eliminar incoherencias y falsas promesas no validadas. Detalle completo en docs/AUDIT_v4.9.0.md.

Corregido — bugs reales encontrados#

• Caso 09 (FastAPI Gateway): from __future__ import annotations + el wrapper de @limiter.limit hacían que FastAPI tratara payload como query param → /webhook daba 422 y /openapi.json 500. El endpoint nunca funcionó; se elimina el import.
• Casos 11, 14, 18: healthcheck con localhost resolvía a ::1 (IPv6) mientras el servidor escucha IPv4 → unhealthy permanente pese a responder 200. Se fija 127.0.0.1.
• Caso 06 (Symfony): faltaba la extensión phpredis (Class "Redis" not found) → nuevo Dockerfile con pecl install redis.
• Caso 07 (Ruby/Cassandra): cassandra-driver usa SortedSet (removido del stdlib en Ruby 3.2) → gema sorted_set.
• Caso 08 (Flask): python:3.9 no resolvía click>=8.4 → python:3.11 + repo mssql bookworm.
• Casos 03, 14, 16, 17: .dockerignore para evitar que node_modules del host rompa el build.

Documentación#

• Sincronizada toda la suite de docs (README, index.html, ROADMAP, FILE_MAP, PLANNED_CASES, DOCKER_RESOURCES, ARCHITECTURE, wiki, REQUIREMENTS): se eliminan los claims obsoletos de "12 implementados / 8 planificados" y "scaffolding"; ahora reflejan 19 casos operativos y sólo el 19 pendiente.
• Dashboard maestro: el contador PLANNED se calcula en vivo (ya no queda fijo en "11").
• Caso 19: sus badges/estado se corrigen de "Ready/verificado" a pendiente de verificación (era una falsa promesa).

Notas#

• CI en verde: black --check . (47 OK), validate_ports, validate_case_matrix, docker compose --profile full config, flake8.

🚀 [4.8.0] — 2026-07-08#

✨ Matriz Tecnológica — Lote 4: Kafka/ClickHouse (13) y Next.js/Supabase (14)#

Los dos casos más pesados del roadmap pasan a implementados y verificados (build + boot + health con Docker). La matriz operativa llega a 19 de 20 casos; sólo resta el 19 (código completo, verificación pendiente).

Añadido#

• Caso 13 · Node+Kafka → n8n → Go consumer → ClickHouse (puerto 8093): event streaming con Kafka (KRaft) y sink columnar ClickHouse. Patrón CQRS — el receiver Go produce en /webhook y una goroutine consumer proyecta los eventos en ClickHouse (ReplacingMergeTree, idempotente).
• Caso 14 · Next.js → n8n → Supabase (Postgres + RLS) (puerto 8094): primer caso BaaS. Núcleo de Supabase — Postgres + PostgREST + Row Level Security. Next.js emite; el receiver persiste vía PostgREST gobernado por la política RLS del rol web_anon.

Notas#

• Ambos respetan la regla de puertos 8080 + id y pasan scripts/validate_ports.py.
• ClickHouse: se añade un rol sbuser accesible desde la red del lab (el default sólo permite localhost).
• Caso 19 (F#/Clojure/XTDB): sigue con el código completo y el bug de arranque AOT corregido; pendiente sólo de la verificación end-to-end.

🚀 [4.7.0] — 2026-07-08#

✨ Matriz Tecnológica — Lote 3: gRPC/CockroachDB (15) y Swift/Dart/Firestore (20)#

Dos casos más pasan a implementados y verificados (build + boot + health con Docker). La matriz operativa crece de 15 → 17 casos. El caso 19 (F#/Clojure/XTDB) queda con el código completo pero pendiente de verificación (se cierra al final).

Añadido#

• Caso 15 · Go (gRPC server) → n8n → Python (gRPC client) + CockroachDB (puerto 8095): protocolo binario gRPC entre servidor Go y cliente Python (stubs generados desde un .proto compartido); el receiver Python adapta el contrato REST a llamadas gRPC. Persistencia en CockroachDB (SQL distribuido).
• Caso 20 · Swift → n8n → Dart (Shelf) + Firestore emulator (puerto 8100): stack mobile-backend server-side. Receiver Dart compilado AOT que persiste en el emulador de Firestore (Firebase Emulator Suite) vía su API REST v1.

Notas#

• Ambos respetan la regla de puertos 8080 + id y pasan scripts/validate_ports.py.
• Caso 19: se corrigió un bug de arranque (XTDB se iniciaba en tiempo de compilación AOT → build colgado); el nodo se difiere con delay. Marcado como planificado hasta su verificación end-to-end.

🚀 [4.6.0] — 2026-07-08#

✨ Matriz Tecnológica — Lote 2 de casos planificados implementados (10, 12, 18)#

Tres casos más pasan de scaffolding a implementados y verificados (build + boot + health con Docker). La matriz operativa crece de 12 → 15 casos.

Añadido#

• Caso 10 · Java (Spring Boot) → n8n → Kotlin (Ktor) + PostgreSQL (puerto 8090): contraste JVM entre el modelo bloqueante (Spring MVC) y no-bloqueante (Ktor + corrutinas sobre Netty). Receptor empaquetado como fat-jar (Shadow).
• Caso 12 · Python (LLM) → n8n → FastAPI RAG + pgvector (puerto 8092): pipeline RAG — cada post se embebe (vector 256d) y se indexa en pgvector; /search hace retrieval por similitud coseno (<=>). Embedding hashing determinista, swappable por un modelo real.
• Caso 18 · Zig → n8n → Crystal (Kemal) + Neo4j (puerto 8098): lenguajes emergentes (Zig sin GC, Crystal compilado) + base de grafos. El receptor Crystal persiste nodos (:Post) vía la API HTTP transaccional de Neo4j con Cypher.

Notas#

• Los tres casos respetan la regla de puertos canónica 8080 + id (ver docs/PORTS.md) y pasan el validador scripts/validate_ports.py.
• Cada caso es independiente (perfil caseNN) y aditivo: ningún servicio previo fue modificado.

🔌 [4.5.1] — 2026-07-08#

🧭 Esquema de puertos canónico + validador anti-colisión#

Los puertos se asignaban por orden de implementación (11→8092, 16→8091, 17→8093), lo que escalaba mal. Se establece una regla determinista y su garantía en CI.

Añadido#

• Regla canónica puerto = 8080 + id documentada en docs/PORTS.md: el número de caso se lee en el puerto; escala sin límite práctico (caso 30→8110, 99→8179).
• scripts/validate_ports.py (sin dependencias) cableado en CI (matrix-integrity): falla el build si algún puerto se desvía de la fórmula, si hay dos puertos host duplicados, si un caso implementado no publica su puerto, o si la infra colisiona con la banda de casos. Ningún caso puede romper a otro.

Cambiado#

• Renumeración a la fórmula: 09 8090→8089, 11 8092→8091, 16 8091→8096, 17 8093→8097.
• cAdvisor 8089→9091 (fuera de la banda de casos, junto a Prometheus).
• Sincronizadas todas las referencias (compose, index.html, manifests, README, SECURITY, docs) al nuevo mapa. El edge/Caddy no se ve afectado (referencia al caso 09 por nombre de servicio, no por puerto).

🚀 [4.5.0] — 2026-07-07#

✨ Matriz Tecnológica — Lote 1 de casos planificados implementados (16, 11, 17)#

Tres casos del roadmap v5.0 pasan de scaffolding a implementados y verificados (build + boot + health con Docker). La matriz operativa crece de 9 → 12 casos.

Añadido#

• Caso 16 · Apollo GraphQL → n8n → Hasura + TimescaleDB (puerto 8091): emisor Apollo Server (schema-first) y micro-receiver que traduce el contrato REST a mutaciones/queries GraphQL contra Hasura (DB-first) sobre una hypertable de TimescaleDB. Trackeo de tabla vía Metadata API en el arranque.
• Caso 11 · Elixir → n8n → Erlang (Cowboy) + Mnesia (puerto 8092): emisor Elixir y receptor Erlang/Cowboy empaquetado como release OTP con persistencia en Mnesia embebida (ram_copies) — la única BD de la matriz sin contenedor separado.
• Caso 17 · Rust (MQTT) → n8n → Node → InfluxDB (puerto 8093): emisor Rust (rumqttc) que publica en Mosquitto; un subscriber Node persiste en InfluxDB (series temporales). El receiver REST reinyecta la entrega de n8n en el mismo bus MQTT (un sink, dos entradas).

Cambiado#

• Resiliencia de arranque: los nuevos servicios con motor turnkey usan healthcheck + depends_on: condition: service_healthy (Hasura no arranca hasta que TimescaleDB está healthy, etc.), eliminando los crashes por orden de arranque.
• Dashboard maestro (index.html): tarjetas CASE-11/16/17 en estado READY con test de integración; el objeto CASES y los contadores (Total, pills READY/OFFLINE) son ahora dinámicos sobre Object.keys(CASES).
• Contrato de CI: scripts/validate_case_matrix.py incorpora los tres casos; scripts/generate_workflows.py genera sus workflows n8n con los guardrails canónicos (fingerprint · circuit breaker · idempotencia · reintentos · DLQ).

Notas#

• Cada caso es independiente (perfil caseNN) y aditivo: ningún servicio 01–09 fue modificado. Puertos reasignados a 8091–8093 (se corrige el solape con el Gateway 8090 y cAdvisor 8089 del plan original).
• Verificación por caso: POST /webhook persiste en el motor real, GET /logs lo recupera, validación 422 en payload inválido, confirmación directa en la BD.

🔒 [4.4.1] — 2026-07-02#

🛡️ Seguridad — Cierre de los follow-ups de v4.4.0 (P-05, P-06, P-07)#

Los tres follow-ups que quedaron abiertos tras v4.4.0 pasan a CORREGIDO.

Añadido / Cambiado#

• P-07 · SHA-pinning de GitHub Actions: las 27 referencias uses: de ci-cd.yml y wiki-sync.yml se pinnean a SHA de 40 chars con comentario # vX (p.ej. actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4). Cierra la ventana de un tag reescrito maliciosamente; Dependabot sigue proponiendo bumps sobre el comentario de versión.
• P-05 · cargo audit bloqueante: el sample 07-rust-to-ruby/origin se moderniza — dotenv → dotenvy (cierra RUSTSEC-2021-0141, crate sin mantener) y reqwest 0.11 → 0.12 (elimina rustls-pemfile, cierra RUSTSEC-2025-0134). El paso cargo audit deja el modo observación y pasa a bloqueante.
• P-06 · bundler-audit con cobertura real: se añaden Gemfile + Gemfile.lock al caso Ruby (sinatra, cassandra-driver + árbol transitivo). El paso deja de ser condicional y audita de verdad (verde contra la ruby-advisory-db).

Notas#

• Con esto, los 5 ecosistemas (Python, Go, Node, .NET, Rust, Ruby) auditan CVEs de forma bloqueante en CI.
• Verificado localmente en contenedores: cargo generate-lockfile deja dotenvy 0.15.7 y reqwest 0.12.28 sin rustls-pemfile; bundle-audit check → «No vulnerabilities found».
• Dependabot: 23 PRs abiertos tras el release v4.4.0. Los de actions (setup-node, setup-go, etc.) quedan cubiertos por el SHA-pin; los majors (Express 5, Python 3.14, reqwest 0.13) se triarán manualmente por su riesgo de ruptura.

🔒 [4.4.0] — 2026-07-02#

🛡️ Seguridad — Cierre de los 4 pendientes priorizados de la auditoría#

Los cuatro ítems que quedaban como RIESGO ACEPTADO en SECURITY.md pasan a CORREGIDO.

Añadido#

• P-01 · Hashes SHA en dependencias Python: nuevos requirements.in como fuente y requirements.txt regenerados con uv pip compile --universal --generate-hashes --python-version 3.11 en los 5 archivos (root, 01/origin, 02/origin, 08/dest, 09/dest). Cada dependencia directa y transitiva queda pinneada con hash SHA256, forzando el modo pip --require-hashes en CI y en el build Docker (Python 3.11). La resolución universal incluye backports condicionales (python_version < "3.12", p.ej. backports.tarfile) con su marcador — imprescindible para que --require-hashes funcione en 3.11.
• P-02 · Rate limiting en Case 09: slowapi aplica throttling por IP en POST /webhook (30/min) y POST /errors (60/min). Límites configurables por GATEWAY_WEBHOOK_RATE_LIMIT / GATEWAY_ERRORS_RATE_LIMIT; el excedente devuelve HTTP 429. Protege la cuota de la GitHub API y contiene el abuso de una X-API-Key filtrada.
• P-03 · Whitelist de owner en Case 09: el campo owner de RequestParamsDTO valida el patrón de usuario de GitHub (^[A-Za-z0-9](?:[A-Za-z0-9-]{0,37}[A-Za-z0-9])?$) en el borde (pydantic → 422), como defensa en profundidad sobre el value object Owner del dominio. Cierra la superficie tipo SSRF del parámetro que forma la URL saliente.
• P-04 · Auditoría CVE multi-lenguaje en CI: govulncheck (Go), pnpm audit --audit-level high (Node) y dotnet list package --vulnerable (.NET) como pasos bloqueantes; cargo audit (Rust) en modo observación (el sample origin fija reqwest 0.11 a propósito); bundler-audit (Ruby) condicionado a la existencia de Gemfile.lock.

Corregido — advisories transitivos detectados por el nuevo pnpm audit (P-04)#

El gate de Node destapó 3 HIGH + 1 moderate en dependencias transitivas, resueltos vía pnpm.overrides + regeneración de lockfile:

• cases/03-go-to-node/dest y cases/04-node-to-fastapi/origin: form-data >=4.0.0 <4.0.6 (CRLF injection, GHSA-hmw2-7cc7-3qxx, vía axios) → >=4.0.6.
• cases/05-laravel-to-react/dest: path-to-regexp <0.1.13 (ReDoS, GHSA-37ch-88jc-xwx2, vía express) → >=0.1.13 <0.2.0 (se mantiene la línea 0.1.x que espera Express 4); qs >=6.11.1 <=6.15.1 (DoS, GHSA-q8mj-m7cp-5q26) → >=6.15.2 <7.0.0.

Además, el gate de Go (govulncheck) forzó subir el toolchain de CI a stable (cerrando advisories de stdlib GO-2026-5037/5039 en go1.22.12).

Notas#

• slowapi es dependencia nueva de Case 09 (añadida a requirements.in + lockfile con hashes).
• Follow-ups registrados en SECURITY.md: P-05 (cargo audit bloqueante), P-06 (Gemfile.lock para Ruby), P-07 (SHA-pinning de GitHub Actions).
• Verificación local con fastapi.testclient: owner malformado → 422, 4ª petición sobre el límite → 429; los 5 lockfiles validan con pip install --require-hashes.

🔒 [4.3.1] — 2026-06-19#

🛡️ Seguridad — Supply chain (npm → pnpm v11)#

Mitigación de la campaña Shai-Hulud en npm. pnpm v11 trae postinstall scripts bloqueados por defecto y minimumReleaseAge=24h, lo que cierra la ventana de explotación típica de los paquetes maliciosos publicados con auto-install hooks.

Casos migrados (todos con onlyBuiltDependencies: []):

• cases/03-go-to-node/dest (express, pg, axios) — pnpm-lock.yaml nuevo
• cases/04-node-to-fastapi/origin (axios) — pnpm-lock.yaml nuevo
• cases/05-laravel-to-react/dest (cors, express, mongodb) — pnpm import desde package-lock.json existente

NO migrado (intencional):

• n8n/data/nodes/package.json — generado en runtime por el contenedor de n8n; tocarlo no aporta beneficio y puede causar conflictos al arrancar.

🔧 Notas operativas#

• CI: sin cambios — el workflow node-cases solo hace node --check para syntax, no corre npm install.
• Dependabot: package-ecosystem: npm se mantiene; GitHub Dependabot auto-detecta pnpm-lock.yaml en esa misma categoría.
• Sin impacto en producto: ningún cambio funcional ni de API; solo manifest + lockfile.

🎛️ [4.3.0] — 2026-05-05#

✨ Añadido — Master Dashboard interactivo#

• Detección automática de estado por caso: cada 20 s el dashboard hace ping (fetch no-cors) al puerto del receptor y marca cada tarjeta como 🟢 READY o 🔴 OFFLINE. Sin backend nuevo, sin agotar RAM al usuario.
• Modal "Mostrar comando para levantarlo": cuando un caso está OFFLINE, el botón se transforma y abre un modal con el comando docker-compose --profile caseXX up -d, la RAM estimada y un botón 📋 Copiar al portapapeles (con fallback execCommand).
• Barra global Docker: contadores live 🟢 N/9 READY · 🔴 N/9 OFFLINE · 🚧 11 PLANNED, indicador Última comprobación: HH:MM:SS y botón 🔄 Re-comprobar manual.
• Sistema de toasts: notificaciones top-right cuando un caso transiciona ONLINE↔OFFLINE, al copiar comandos o al re-comprobar.
• Badges de RAM por tarjeta: 💾 ~X.X GB en cada uno de los 20 casos (verde para ligeros, rojo ⚠️ para los pesados 07/08/13/14).
• Separador visual entre los 9 casos implementados y los 11 planificados, con enlace a docs/PLANNED_CASES.md.

📚 Documentación de recursos#

• docs/DOCKER_RESOURCES.md: nueva sección "Consumo de RAM por Caso" con desglose receptor + DB + núcleo (1.13 GB), tabla de combinaciones recomendadas según RAM disponible (2/4/8/16 GB) y estimaciones para los 11 casos planificados.

🔧 Fix — Dependabot puede escanear todo el repo#

Se añadieron los 4 manifiestos que faltaban desde v4.2.0 (rompían los runs scheduled de Dependabot):

• cases/02-python-to-go/dest/go.mod (+ Dockerfile actualizado a go mod tidy)
• cases/03-go-to-node/origin/go.mod (stdlib only)
• cases/04-node-to-fastapi/origin/package.json (axios ^1.7.7)
• cases/06-go-to-symfony/origin/go.mod (stdlib only)

🔧 Fix — Validador tolera casos planificados#

scripts/validate_case_matrix.py ahora lee status: planned del manifest y excluye esos casos de la comparación estricta. Implementados (01–09) se siguen validando como antes; planificados se reportan como "skipped".

🚧 [Unreleased] — Roadmap v5.0#

✨ Añadido — Scaffolding de 11 casos planificados (cases 10–20)#

Se incorpora la documentación de diseño y estructura de carpetas para 11 nuevos casos de integración. Sin implementación funcional: solo README.md, app.manifest.yml (con status: planned) y carpetas origin/ + dest/.

📚 Documentación#

• Nuevo: docs/PLANNED_CASES.md — single source of truth de la matriz planificada.
• Actualizado: README.md, ROADMAP.md, CHANGELOG.md, index.html y 10+ MD del catálogo (docs/CASES_INDEX.md, docs/wiki/Cases-Index.md, docs/FILE_MAP.md, docs/INSTALL.md, docs/REQUIREMENTS.md, docs/INSIGHTS.md, docs/GUARDRAILS.md, docs/wiki/Resilience.md, docs/wiki/Home.md, docs/wiki/Usage-Guide.md, COMO_ACTIVAR_WORKFLOWS.md) con referencias cruzadas a los casos planificados.

Nota

No se ha modificado docker-compose.yml, scripts ni código fuente. Los perfiles case10–case20 no existen aún — su implementación se planifica en bloques (Tier 1 → Tier 2 → Tier 3).

🔒 [4.2.0] — 2026-04-06#

🛡️ Seguridad — Auditoría de 8 Capas#

• HTTP Security Headers (Capa 4): Los tres servicios php:8.2-apache (master-dashboard, dest-php, dest-symfony) ahora sirven X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy y Permissions-Policy. Se deshabilita el listado de directorios (Options -Indexes). Implementado vía apache/security-headers.conf montado en :ro.
• CSP + Permissions-Policy en Edge Proxy (Capa 4): El proxy Caddy ya incluía HSTS, X-Frame-Options, etc. Se añaden los dos headers faltantes: Content-Security-Policy y Permissions-Policy.
• Dependabot (Capa 7): Configurado .github/dependabot.yml con 11 ecosistemas: github-actions, pip (hub + 3 cases), docker, gomod (3 cases), cargo, npm (2 cases). Abre PRs automáticos ante versiones vulnerables.
• Line endings LF (Capa 8): Creado .gitattributes para garantizar que todos los scripts shell, Python, Go, Ruby, Rust y JS se almacenen con LF en Git, independientemente del OS del colaborador. Evita el error bad interpreter: \r al ejecutar scripts en contenedores Linux desde un clon Windows.
• Detección de Unicode bidi/CVE-2021-42574 (Capa 8): Nuevo job supply-chain-checks en CI que escanea el código fuente completo en busca de caracteres de control bidireccionales (Trojan Source) usando Python puro, sin dependencias externas.
• Detección de ofuscación base64+eval (Capa 8): El mismo job detecta patrones eval(b64decode(...)) y equivalentes en Python, JS, Ruby, PHP y Shell.

✨ Añadido#

• apache/security-headers.conf — configuración Apache de hardening (headers + -Indexes).
• .gitattributes — normalización de line endings por tipo de archivo.
• .github/dependabot.yml — actualizaciones automáticas de dependencias para 11 ecosistemas.

⚙️ Cambiado#

• docker-compose.yml — master-dashboard, dest-php y dest-symfony montan apache/security-headers.conf y ejecutan a2enmod headers al arrancar.
• edge/start-caddy.sh — añadidos Content-Security-Policy y Permissions-Policy al bloque de headers.
• .github/workflows/ci-cd.yml — nuevo job supply-chain-checks (bidi + obfuscación), precede a build-and-push.
• SECURITY.md — reemplazado por resultados completos de auditoría de 8 capas con estado por punto, riesgos aceptados documentados y tabla de pendientes priorizados.

🚀 [4.1.0] — 2026-03-24#

🛡️ Seguridad#

• Fix Crítico: Mitigación del ataque de cadena de suministro en aquasecurity/trivy-action. Upgrade a v0.35.0.
• Hardening CI/CD: Refuerzo de permisos en los flujos de GitHub Actions.

✨ Añadido#

• 🔍 Verificación de Recursos: Nuevo script check_resources.py para monitoreo en tiempo real (CPU, RAM, Disco).
• 📊 Health Dashboard: Interfaz visual de diagnóstico para verificar la preparación del entorno antes de la ejecución.
• 🧹 Deep Clean: Comandos make clean y hub clean para purga total de recursos Docker (volúmenes e imágenes).
• 🧩 Docker Profiles: Soporte para carga selectiva de servicios mediante perfiles (ej: case01, full).

⚙️ Cambiado#

• 🏎️ Optimización: Límites granulares de CPU/RAM para los 20+ contenedores del ecosistema.
• 📂 Alpine Migration: Todos los servicios de destino ahora utilizan imágenes ligeras basadas en Alpine Linux para reducir la superficie de ataque.

🏗️ [4.0.0] — 2026-02-18#

📂 Persistencia Políglota#

• Integración Nativa: Soporte para 8 motores de bases de datos distintos: 🐬 MySQL, 🍃 MariaDB, 🐘 PostgreSQL, 📂 SQLite, 🍃 MongoDB, 🏎️ Redis, 👁️ Cassandra y 🏢 SQL Server.
• Auto-Provisionamiento: Lógica inteligente de creación de esquemas y tablas en el primer arranque de cada receptor.

✨ Añadido#

• 🖥️ Master Dashboard v2: Visualización unificada del estado de las bases de datos y previsualización de posts en tiempo real.
• 🔗 Nuevos Drivers: Soporte para pyodbc, cassandra-driver, pg, y extensiones de Redis para PHP.

🛡️ [3.0.0] — 2026-02-11#

🏗️ Arquitectura de Resiliencia#

• Guardrails Globales: Implementación de Idempotencia (SQLite) y Circuit Breaker en todos los ejes tecnológicos.
• 📥 Dead Letter Queue (DLQ): Sistema de captura de mensajes fallidos en todos los receptores.
• 📚 Nueva Documentación: Creación de docs/GUARDRAILS.md y guías técnicas de arquitectura profesional.

🛠️ [2.1.0] — 2026-01-25#

🔧 Corregido#

• Estandarización de Endpoints: Todos los receptores ahora escuchan de forma uniforme en /webhook.
• Normalización de Payload: Los campos de envío se han estandarizado a id, text y channel.
• CI Fixes: Aplicación de black a todo el repositorio y corrección de dependencias de Ruby en Docker.

🏁 [1.0.0] — 2026-01-20#

• Lanzamiento inicial del laboratorio con 6 casos de integración base.
• Soporte para orquestación multi-contenedor mediante Docker Compose.

Mantenido con rigor técnico por Vladimir Acuña