@saulwade/swl-ses 2.6.0 → 2.6.1

package/habilidades/changelog-generator/SKILL.md

@@ -1,174 +1,174 @@
----
-name: changelog-generator
-description: >
-  Generador automático de entradas CHANGELOG.md en formato Keep a Changelog
-  desde commits Conventional Commits. Parser determinista que clasifica feat/
-  fix/perf/refactor/docs/etc. en categorías user-facing en español, detecta
-  breaking changes (marca '!' o trailer 'BREAKING CHANGE:') y reporta nivel
-  de conformidad para decidir fallback manual. Cargar en /swl:release Paso 7
-  cuando hay commits Conventional, o manualmente para previsualizar el
-  changelog antes de un release.
-version: 1.1.1
-nivelRiesgo: BAJO
-herramientasPermitidas: [Read, Bash]
-skillsInvocables: [release-semver]
-exclusiones:
-  - "No invocar para generar release notes con marketing copy o anuncios para usuarios finales — este skill produce listado técnico-legible, no narrativa."
-  - "No invocar si el repo no usa Conventional Commits — el parser detecta <80% conformidad y el caller debe abortar a flujo manual de release-semver."
-  - "No invocar para reescribir CHANGELOG histórico — solo agrega entrada de la próxima versión al inicio."
----
-
-# /habilidades/changelog-generator — CHANGELOG automático desde Conventional Commits
-
-## Cuándo cargar
-
-- Durante `/swl:release` Paso 7 (Generar CHANGELOG), cuando el flujo automático
-  está disponible y los commits del rango siguen Conventional Commits.
-- Para previsualizar el changelog candidato antes de bumpear versión:
-  `node habilidades/changelog-generator/scripts/parse-commits.js --version X`
-- Cuando un colaborador pide un resumen legible de cambios entre dos refs
-  arbitrarias del repo.
-
-## Cuándo NO cargar
-
-- Repo sin Conventional Commits (<80% de conformidad): el parser detecta y
-  reporta; el caller debe usar `Skill("release-semver")` flujo manual.
-- Generación de **release notes** (texto narrativo con contexto de producto):
-  este skill produce CHANGELOG técnico-legible; las release notes con marketing
-  son tarea aparte (`documentador-swl` con plantilla específica).
-- Reescritura histórica del CHANGELOG (squash de varias versiones, corrección
-  de entradas antiguas): solo se agrega entrada de la versión nueva al inicio.
-
-## Qué hace el skill
-
-1. **Lee commits** desde la última tag (o entre dos refs arbitrarias) con
-   `git log --format=...` usando un separador único para parsear subject + body
-   sin colisiones.
-2. **Parsea con Conventional Commits 1.0.0**: regex que captura tipo, scope,
-   marca `!`, descripción. Soporta tipos extendidos del proyecto SWL:
-   `evolucion` (cambios de skills/agentes), además de `feat/fix/perf/refactor/
-   docs/style/test/ci/build/chore/revert`. Tolera el prefijo opcional de
-   trazabilidad `[T-NN]` / `[REQ-NN]` de la convención de `ejecutar-fase`
-   (no altera la semántica CC — el tipo+scope+descripción siguen presentes).
-3. **Detecta breaking changes** por marca `!` después del tipo o trailer
-   `BREAKING CHANGE:` en el body. Los breaking siempre van al inicio del
-   release, sin importar el tipo original.
-4. **Transforma descripción técnica → legible**:
-   - Elimina referencias a issues al final (`(#123)`, `Refs #456`).
-   - Capitaliza primera letra.
-   - Elimina punto final (Keep a Changelog usa bullets sin punto).
-5. **Agrupa en categorías** con orden canónico:
-   1. Breaking changes
-   2. Nuevas funcionalidades (feat)
-   3. Correcciones (fix)
-   4. Mejoras de rendimiento (perf)
-   5. Cambios internos (refactor)
-   6. Reversiones (revert)
-   7. Evoluciones de skills/agentes (evolucion — SWL-specific)
-   8. Mantenimiento (docs/style/test/ci/build/chore — colapsadas)
-   9. Otros (commits sin prefijo CC válido)
-6. **Reporta conformidad**: ratio commits conformes / total. Si <80%, el
-   caller debe decidir si abortar o seguir manualmente.
-
-## Helper programático
-
-```js
-const {
-  parsearCommits,
-  leerCommitsGit,
-  generarChangelog,
-} = require('./habilidades/changelog-generator/scripts/parse-commits');
-
-// 1. Leer commits desde la última tag hasta HEAD
-const commits = leerCommitsGit({ to: 'HEAD' });
-
-// 2. Parsear y clasificar
-const { categorias, conformidad, totalCommits, conformes } = parsearCommits(commits);
-
-// 3. Si conformidad < 0.8, abortar o avisar al usuario
-if (conformidad < 0.8) {
-  console.warn(`Conformidad CC: ${conformes}/${totalCommits}. Revisar "Otros".`);
-}
-
-// 4. Generar markdown listo para insertar en CHANGELOG.md
-const md = generarChangelog(categorias, {
-  version: '1.6.5',
-  fecha: '2026-05-22',  // opcional, default = hoy
-  incluirHash: true,    // muestra hash corto al inicio de cada bullet
-});
-```
-
-## Uso CLI
-
-Previsualizar changelog candidato sin escribir nada:
-
-```bash
-node habilidades/changelog-generator/scripts/parse-commits.js \
-  --version 1.6.5 \
-  --format markdown
-```
-
-Filtrar por rango específico:
-
-```bash
-node habilidades/changelog-generator/scripts/parse-commits.js \
-  --from v1.6.4 \
-  --to HEAD \
-  --version 1.6.5
-```
-
-Salida JSON estructurado para post-procesamiento:
-
-```bash
-node habilidades/changelog-generator/scripts/parse-commits.js \
-  --from v1.6.4 \
-  --format json > /tmp/changelog-candidato.json
-```
-
-## Reglas de uso desde /swl:release
-
-1. Llamar a `leerCommitsGit` con la última tag detectada en el Paso 1 del
-   release.
-2. Verificar `conformidad >= 0.8`. Si menor, presentar al usuario los commits
-   bajo "Otros" y pedir decisión: (a) continuar con el changelog, (b) abortar
-   y reescribir commits, (c) editar manualmente la categoría "Otros".
-3. Si `--dry-run` está activo en `/swl:release`, mostrar el output de
-   `generarChangelog` sin escribir a disco.
-4. Si conformidad OK: leer CHANGELOG.md actual, insertar el bloque generado
-   al inicio después del header `# Changelog`, escribir atómicamente.
-5. NO hacer commit aquí — eso lo hace el Paso 8 de `/swl:release`.
-
-## Gotchas observables
-
-- **Conventional Commits sin scope son válidos**: `fix: corregir X` parsea
-  igual que `fix(modulo): corregir X`. El parser no exige scope.
-- **El subject debe ir en una sola línea**: si un commit usa newline en el
-  subject, el parser lo trata como completo pero `git log %s` ya lo trunca.
-- **Tipos no estándar van a "Otros"**: si un equipo usa `mejora:`, `cambio:`,
-  el parser los marca como no conformes. El usuario debe ajustar la lista
-  `CATEGORIAS` en `parse-commits.js` o adoptar tipos estándar.
-- **El skill NO escribe a disco directamente**: solo retorna markdown. El
-  caller (`/swl:release` Paso 7) es responsable de leer el CHANGELOG actual,
-  insertar al inicio y escribir atómicamente.
-- **Commits revert vienen del propio git**: `git revert` genera mensajes
-  `Revert "Subject original"` que el parser categoriza correctamente bajo
-  Reversiones (regex matchea `revert:` sin que el usuario lo escriba si usa
-  `git revert -e` para editar el mensaje al formato CC).
-- **El hash corto se trunca a 7 chars**: alineado con el formato `git log
-  --oneline` estándar.
-
-## Origen
-
-Adaptado del skill `changelog-generator` de
-`temp/awesome-codex-skills-master/changelog-generator/` (ComposioHQ, MIT) con:
-
-- Frontmatter al estándar SWL (es-MX, `nivelRiesgo: BAJO`, `exclusiones`).
-- Parser determinista en Node.js (`parse-commits.js`) — el origen es solo
-  documentación; este skill agrega la implementación ejecutable.
-- Tipo `evolucion:` específico de SWL agregado al parser.
-- Soporte para breaking changes `!` y trailer `BREAKING CHANGE:` (origen
-  solo menciona el segundo).
-- Reporte de conformidad <80% como gate explícita para fallback manual.
-- Integración con `/swl:release` Paso 7 documentada en `comandos/swl/release.md`.
-
-Documentado en ADR-0029 (integración parcial awesome-codex-skills, Opción B).
+---
+name: changelog-generator
+description: >
+  Generador automático de entradas CHANGELOG.md en formato Keep a Changelog
+  desde commits Conventional Commits. Parser determinista que clasifica feat/
+  fix/perf/refactor/docs/etc. en categorías user-facing en español, detecta
+  breaking changes (marca '!' o trailer 'BREAKING CHANGE:') y reporta nivel
+  de conformidad para decidir fallback manual. Cargar en /swl:release Paso 7
+  cuando hay commits Conventional, o manualmente para previsualizar el
+  changelog antes de un release.
+version: 1.1.1
+nivelRiesgo: BAJO
+herramientasPermitidas: [Read, Bash]
+skillsInvocables: [release-semver]
+exclusiones:
+  - "No invocar para generar release notes con marketing copy o anuncios para usuarios finales — este skill produce listado técnico-legible, no narrativa."
+  - "No invocar si el repo no usa Conventional Commits — el parser detecta <80% conformidad y el caller debe abortar a flujo manual de release-semver."
+  - "No invocar para reescribir CHANGELOG histórico — solo agrega entrada de la próxima versión al inicio."
+---
+
+# /habilidades/changelog-generator — CHANGELOG automático desde Conventional Commits
+
+## Cuándo cargar
+
+- Durante `/swl:release` Paso 7 (Generar CHANGELOG), cuando el flujo automático
+  está disponible y los commits del rango siguen Conventional Commits.
+- Para previsualizar el changelog candidato antes de bumpear versión:
+  `node habilidades/changelog-generator/scripts/parse-commits.js --version X`
+- Cuando un colaborador pide un resumen legible de cambios entre dos refs
+  arbitrarias del repo.
+
+## Cuándo NO cargar
+
+- Repo sin Conventional Commits (<80% de conformidad): el parser detecta y
+  reporta; el caller debe usar `Skill("release-semver")` flujo manual.
+- Generación de **release notes** (texto narrativo con contexto de producto):
+  este skill produce CHANGELOG técnico-legible; las release notes con marketing
+  son tarea aparte (`documentador-swl` con plantilla específica).
+- Reescritura histórica del CHANGELOG (squash de varias versiones, corrección
+  de entradas antiguas): solo se agrega entrada de la versión nueva al inicio.
+
+## Qué hace el skill
+
+1. **Lee commits** desde la última tag (o entre dos refs arbitrarias) con
+   `git log --format=...` usando un separador único para parsear subject + body
+   sin colisiones.
+2. **Parsea con Conventional Commits 1.0.0**: regex que captura tipo, scope,
+   marca `!`, descripción. Soporta tipos extendidos del proyecto SWL:
+   `evolucion` (cambios de skills/agentes), además de `feat/fix/perf/refactor/
+   docs/style/test/ci/build/chore/revert`. Tolera el prefijo opcional de
+   trazabilidad `[T-NN]` / `[REQ-NN]` de la convención de `ejecutar-fase`
+   (no altera la semántica CC — el tipo+scope+descripción siguen presentes).
+3. **Detecta breaking changes** por marca `!` después del tipo o trailer
+   `BREAKING CHANGE:` en el body. Los breaking siempre van al inicio del
+   release, sin importar el tipo original.
+4. **Transforma descripción técnica → legible**:
+   - Elimina referencias a issues al final (`(#123)`, `Refs #456`).
+   - Capitaliza primera letra.
+   - Elimina punto final (Keep a Changelog usa bullets sin punto).
+5. **Agrupa en categorías** con orden canónico:
+   1. Breaking changes
+   2. Nuevas funcionalidades (feat)
+   3. Correcciones (fix)
+   4. Mejoras de rendimiento (perf)
+   5. Cambios internos (refactor)
+   6. Reversiones (revert)
+   7. Evoluciones de skills/agentes (evolucion — SWL-specific)
+   8. Mantenimiento (docs/style/test/ci/build/chore — colapsadas)
+   9. Otros (commits sin prefijo CC válido)
+6. **Reporta conformidad**: ratio commits conformes / total. Si <80%, el
+   caller debe decidir si abortar o seguir manualmente.
+
+## Helper programático
+
+```js
+const {
+  parsearCommits,
+  leerCommitsGit,
+  generarChangelog,
+} = require('./habilidades/changelog-generator/scripts/parse-commits');
+
+// 1. Leer commits desde la última tag hasta HEAD
+const commits = leerCommitsGit({ to: 'HEAD' });
+
+// 2. Parsear y clasificar
+const { categorias, conformidad, totalCommits, conformes } = parsearCommits(commits);
+
+// 3. Si conformidad < 0.8, abortar o avisar al usuario
+if (conformidad < 0.8) {
+  console.warn(`Conformidad CC: ${conformes}/${totalCommits}. Revisar "Otros".`);
+}
+
+// 4. Generar markdown listo para insertar en CHANGELOG.md
+const md = generarChangelog(categorias, {
+  version: '1.6.5',
+  fecha: '2026-05-22',  // opcional, default = hoy
+  incluirHash: true,    // muestra hash corto al inicio de cada bullet
+});
+```
+
+## Uso CLI
+
+Previsualizar changelog candidato sin escribir nada:
+
+```bash
+node habilidades/changelog-generator/scripts/parse-commits.js \
+  --version 1.6.5 \
+  --format markdown
+```
+
+Filtrar por rango específico:
+
+```bash
+node habilidades/changelog-generator/scripts/parse-commits.js \
+  --from v1.6.4 \
+  --to HEAD \
+  --version 1.6.5
+```
+
+Salida JSON estructurado para post-procesamiento:
+
+```bash
+node habilidades/changelog-generator/scripts/parse-commits.js \
+  --from v1.6.4 \
+  --format json > /tmp/changelog-candidato.json
+```
+
+## Reglas de uso desde /swl:release
+
+1. Llamar a `leerCommitsGit` con la última tag detectada en el Paso 1 del
+   release.
+2. Verificar `conformidad >= 0.8`. Si menor, presentar al usuario los commits
+   bajo "Otros" y pedir decisión: (a) continuar con el changelog, (b) abortar
+   y reescribir commits, (c) editar manualmente la categoría "Otros".
+3. Si `--dry-run` está activo en `/swl:release`, mostrar el output de
+   `generarChangelog` sin escribir a disco.
+4. Si conformidad OK: leer CHANGELOG.md actual, insertar el bloque generado
+   al inicio después del header `# Changelog`, escribir atómicamente.
+5. NO hacer commit aquí — eso lo hace el Paso 8 de `/swl:release`.
+
+## Gotchas observables
+
+- **Conventional Commits sin scope son válidos**: `fix: corregir X` parsea
+  igual que `fix(modulo): corregir X`. El parser no exige scope.
+- **El subject debe ir en una sola línea**: si un commit usa newline en el
+  subject, el parser lo trata como completo pero `git log %s` ya lo trunca.
+- **Tipos no estándar van a "Otros"**: si un equipo usa `mejora:`, `cambio:`,
+  el parser los marca como no conformes. El usuario debe ajustar la lista
+  `CATEGORIAS` en `parse-commits.js` o adoptar tipos estándar.
+- **El skill NO escribe a disco directamente**: solo retorna markdown. El
+  caller (`/swl:release` Paso 7) es responsable de leer el CHANGELOG actual,
+  insertar al inicio y escribir atómicamente.
+- **Commits revert vienen del propio git**: `git revert` genera mensajes
+  `Revert "Subject original"` que el parser categoriza correctamente bajo
+  Reversiones (regex matchea `revert:` sin que el usuario lo escriba si usa
+  `git revert -e` para editar el mensaje al formato CC).
+- **El hash corto se trunca a 7 chars**: alineado con el formato `git log
+  --oneline` estándar.
+
+## Origen
+
+Adaptado del skill `changelog-generator` de
+`temp/awesome-codex-skills-master/changelog-generator/` (ComposioHQ, MIT) con:
+
+- Frontmatter al estándar SWL (es-MX, `nivelRiesgo: BAJO`, `exclusiones`).
+- Parser determinista en Node.js (`parse-commits.js`) — el origen es solo
+  documentación; este skill agrega la implementación ejecutable.
+- Tipo `evolucion:` específico de SWL agregado al parser.
+- Soporte para breaking changes `!` y trailer `BREAKING CHANGE:` (origen
+  solo menciona el segundo).
+- Reporte de conformidad <80% como gate explícita para fallback manual.
+- Integración con `/swl:release` Paso 7 documentada en `comandos/swl/release.md`.
+
+Documentado en ADR-0029 (integración parcial awesome-codex-skills, Opción B).

package/habilidades/compactacion-contexto/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: compactacion-contexto
 description: Anti-context-rot. Detectar cuándo compactar el contexto, guardar estado antes de compactar, técnicas de resumen progresivo y handoff limpio entre contextos. Recalibrado para el tokenizer de Opus 4.8 (+15-30% tokens vs 4.6).
-version: "1.1.0"
+version: "1.1.1"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar si el contexto está por debajo del 50% y no hay señales cualitativas de degradación — compactar sin necesidad solo interrumpe el flujo."
@@ -235,6 +235,7 @@ instrucción más conservadora o compactar por secciones individuales.
 - **Invariante de headings violada silenciosamente**: el contexto compactado pierde dos secciones `##` del original porque el modelo resumió párrafos en lugar de preservar la estructura. Causa: no se ejecutó la validación post-compactación. Solución: antes de descartar el contexto original, contar `#` en ambos con regex y comparar — tolerancia 0% para headings perdidos.
 - **Compactar todo el codebase al inicio de sesión**: el agente lee 20 archivos en el nuevo contexto "para orientarse" y los compacta de inmediato. Causa: se interpretó "cargar contexto fresco" como cargar y compactar todo. Solución: en el contexto entrante, cargar ESTADO.md + DECISIONS.md + 3 últimos commits, y solo los archivos de la tarea inmediata — no más.
 - **Umbral de 70% sin recalibrar para Opus 4.8**: en proyectos que migraron de Opus 4.6 a 4.7, el umbral de compactación sigue configurado al 70% del contexto cuando debe ser 50%. Causa: el tokenizer de 4.7 produce 1.0-1.35× más tokens y el umbral efectivo llega antes. Solución: al actualizar modelo, ajustar el umbral de compactación a 50% como documenta este skill en su sección de señales cuantitativas.
+- **Análisis forense de un transcript JSONL gigante = digest determinista + lectores paralelos, nunca `Read` directo** [VALIDADO 2026-07-11, sesión de 61.6 MB / 24,862 líneas cubierta al 100%]: para analizar la sesión de otro agente (post-mortem, auditoría, extracción de decisiones), (1) script Node línea-por-línea que emite SOLO el contenido conversacional — mensajes de usuario íntegros, texto del asistente, tool calls como `>> Tool: args` de una línea, tool_results truncados a 200-400 chars (1,200 si `is_error`), resúmenes de compactación completos — en chunks de ~350 KB; (2) un agente por chunk con mandato de leer el 100% (Read con offset/limit hasta cubrir) y reporte estructurado fijo (cronología, intervenciones del usuario con cita+línea, bugs con estado, deudas, hallazgos QA/adversarial, pendientes, problemas de proceso); (3) el driver verifica las citas críticas de cada reporte antes de usarlas. Gotcha descubierto: **los mensajes del usuario que solo sobreviven dentro de un resumen de compactación NO son diálogo crudo** — el digest debe marcarlos como "cobertura parcial" y el análisis debe declararlo en vez de citarlos como verbatim; en la sesión analizada, 3 de 6 instrucciones del usuario del tramo final solo existían en resúmenes de compactación.
 
 ## Anti-patrones a evitar
 

package/habilidades/contenedores-docker/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: contenedores-docker
 description: Docker y containerización. Dockerfiles optimizados con multi-stage builds, docker-compose, volúmenes, networking, health checks, security scanning, build caching, distroless images. Anti-patrones comunes.
-version: "1.0.3"
+version: "1.0.4"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para orquestación Kubernetes (Deployments, Services, Helm, HPA) — para Kubernetes cargar `kubernetes-orquestacion`."
@@ -140,4 +140,6 @@ Para ejemplos completos de multi-stage Node.js/Angular, .dockerignore, docker-co
 
 **Proxy de desarrollo del frontend (Angular CLI, Vite, webpack-dev-server) con target hardcodeado a `localhost` es deuda invisible hasta el primer `docker compose up`**: en local todo funciona porque frontend y backend comparten host; en cuanto corren en contenedores separados, `localhost` dentro del contenedor del frontend apunta a sí mismo — el proxy devuelve 500/ECONNREFUSED en cada llamada a la API (síntoma típico: el login falla solo en Docker). Causa: el target del proxy es configuración de entorno, no constante del repo. Fix: usar `proxy.conf.js` (no `.json`) que lea `process.env.BACKEND_URL || 'http://localhost:8000'` y pasar `BACKEND_URL=http://backend:8000` (nombre del servicio de compose) vía `environment:` del servicio frontend. Origen: SIGAF 2026-07-02.
 
-**`docker exec ... psql` lanzado en background contra una BD donde el rol no autentica cuelga y congestiona el subsistema `docker exec` de Docker Desktop (Windows)**: lanzar en background (`run_in_background`/`&`) un `docker exec <contenedor> psql -U rol -d db -c "..."` donde el rol no puede autenticar deja la sesión `exec` colgada esperando; varias de esas sesiones huérfanas **saturan el subsistema de `docker exec`** y luego TODO `docker exec` (incluso `echo`) y hasta `docker restart` hacen timeout, aunque `docker ps`/`version` sigan respondiendo. Causa: cada `exec` abre una sesión que no termina; el daemon las acumula. Síntoma distintivo: `docker ps` responde pero cualquier `docker exec` cuelga. Fix: `docker restart <contenedor>` mata las sesiones `exec` huérfanas y destraba el daemon — detener el bash local con TaskStop NO mata el `psql` que corre dentro del contenedor. Prevención: NUNCA lanzar `docker exec ... psql` en background contra una BD/rol cuya autenticación no esté confirmada; correrlo en foreground con timeout corto y verificar el `psql` interactivo primero. En Git Bash (Windows), pasar `MSYS_NO_PATHCONV=1` cuando el comando lleva rutas POSIX (`/tmp/...`) a `docker exec`/`docker cp` para que MSYS no las convierta.
+**`docker exec ... psql` lanzado en background contra una BD donde el rol no autentica cuelga y congestiona el subsistema `docker exec` de Docker Desktop (Windows)**: lanzar en background (`run_in_background`/`&`) un `docker exec <contenedor> psql -U rol -d db -c "..."` donde el rol no puede autenticar deja la sesión `exec` colgada esperando; varias de esas sesiones huérfanas **saturan el subsistema de `docker exec`** y luego TODO `docker exec` (incluso `echo`) y hasta `docker restart` hacen timeout, aunque `docker ps`/`version` sigan respondiendo. Causa: cada `exec` abre una sesión que no termina; el daemon las acumula. Síntoma distintivo: `docker ps` responde pero cualquier `docker exec` cuelga. Fix: `docker restart <contenedor>` mata las sesiones `exec` huérfanas y destraba el daemon — detener el bash local con TaskStop NO mata el `psql` que corre dentro del contenedor. Prevención: NUNCA lanzar `docker exec ... psql` en background contra una BD/rol cuya autenticación no esté confirmada; correrlo en foreground con timeout corto y verificar el `psql` interactivo primero. En Git Bash (Windows), pasar `MSYS_NO_PATHCONV=1` cuando el comando lleva rutas POSIX (`/tmp/...`) a `docker exec`/`docker cp` para que MSYS no las convierta [CONFIRMADO x2 — aplica igual de necesario a `docker cp` que a `docker exec`, no solo al segundo].
+
+**`docker cp <dir-local> contenedor:<dir-remoto>` cuando `<dir-remoto>` YA EXISTE dentro del contenedor NO reemplaza su contenido — lo anida un nivel más profundo** [CONFIRMADO]: un segundo `docker cp database/tests contenedor:/tmp/verify/database/tests` sobre un `/tmp/verify/database/tests/` ya poblado por una corrida anterior crea `/tmp/verify/database/tests/tests/` con los archivos actualizados, mientras el path original sigue con los archivos VIEJOS — silenciosamente, sin error. Causa real de confusión de debugging: un fix a un `.sql` de test parece "no surtir efecto" porque el script verificador (`find /tmp/verify/database/tests -name "*.sql"`) sigue recogiendo la copia vieja en el path esperado; la copia nueva, correcta, queda un nivel más abajo sin que nada la use. Fix: SIEMPRE `docker exec <contenedor> rm -rf <dir-remoto>` inmediatamente antes de cada `docker cp` hacia ese mismo destino — nunca asumir semántica de overwrite en `docker cp` de directorios.