@saulwade/swl-ses 2.6.0 → 2.8.0

package/habilidades/proceso-discovery-machote/SKILL.md

@@ -1,157 +1,157 @@
----
-name: proceso-discovery-machote
-description: >
-  Patrón de discovery para modelar entidades regulatorias (papeles de trabajo,
-  cédulas, oficios, informes, expedientes, actas, dictámenes). Antes de modelar
-  desde el Artículo legal, pedir al usuario el machote oficial real (template
-  institucional). El Art. define el mínimo normativo; el machote revela el
-  contrato institucional real con prácticas no codificadas pero exigidas.
-  Cargar al iniciar la modelación de cualquier entidad nueva que represente
-  un documento normativo emitido por una institución regulatoria (OIC, INE,
-  SAT, etc.), durante /swl:discutir-fase de un módulo regulatorio, o cuando
-  el usuario rechaza un primer diseño por "faltan campos del documento real".
-version: "1.0.0"
-herramientasPermitidas: [Read, Grep, Glob]
-exclusiones:
-  - "No cargar para entidades NO regulatorias (productos, usuarios, sesiones, eventos de log) — el machote no aplica a entidades de aplicación generales."
-  - "No cargar cuando el modelo de la entidad ya está estabilizado y solo se va a agregar 1-2 campos — el discovery completo es overhead innecesario para ajustes pequeños."
-  - "No cargar para refactor de entidad existente que ya tiene 6+ meses en producción — el machote ya se consolidó implícitamente en el modelo; cualquier diferencia es decisión de evolución, no de discovery."
-  - "No cargar para CRUD administrativo simple (catálogos, configuraciones) — esos no tienen contrato institucional rico; cargar `discutir-fase` regular."
-evolvable: true
----
-
-# Proceso Discovery Machote
-
-Patrón obligatorio antes de modelar entidades regulatorias.
-
-## Cuándo NO cargar
-
-- La entidad NO es regulatoria (un producto de catálogo, una sesión de usuario, un evento de log).
-- El modelo ya está estabilizado en producción y solo se agregan 1-2 campos.
-- Es refactor de entidad consolidada (≥6 meses prod) — cargar reglas de refactor, no de discovery.
-- Es CRUD administrativo simple sin contrato institucional rico.
-
-## El gap conceptual
-
-**El Artículo legal define el mínimo normativo. El machote oficial revela el contrato institucional real.**
-
-Caso real SIGAF ADR-081 IPHI (2026-05-15). El Informe de Presunta Hipótesis de Irregularidad (IPHI) se modeló inicialmente desde Art. 44 DBC_FISC_OIC, que enumera 10 fracciones (I-X) de contenido obligatorio:
-
-> Art. 44. El informe contendrá:
-> I.   Antecedentes
-> II.  Marco normativo
-> III. Hechos
-> IV.  Análisis
-> V.   Presunto daño patrimonial
-> VI.  Cuantificación del daño
-> VII. Sujetos involucrados
-> VIII. Pruebas documentales
-> IX.  Conclusiones
-> X.   Auditores que intervinieron
-
-Modelo Pydantic + tabla SQL creados con esas 10 secciones. Commit inicial Fase 1.
-
-Tras Fase 1, el usuario proporcionó el machote oficial real `OIC-DATIC-02-ESP-2025-IPHI-01.docx`. Reveló **7 extensiones institucionales NO presentes en Art. 44**:
-
-| # | Extensión del machote | NO está en Art. 44 |
-|---|---|---|
-| 1 | Distinción `presunto_dano_patrimonial` (directo) vs `perjuicio_total_estimado` (agregado: daño + depreciación + costo oportunidad) | Art. 44 fracción V/VI no distinguen |
-| 2 | Observaciones origen N:M con `hallazgo_identificador` (tabla puente `iphi_observacion_origen`) | Art. 44 no define la relación |
-| 3 | `procedimientos_contratacion_relacionados` JSONB (lista de LP-INE asociadas) | No aparece en el Art. |
-| 4 | `normas_infringidas` JSONB estructurado `[{norma, articulo, contenido}]` | Art. 44 dice "marco normativo" sin estructura |
-| 5 | `desglose_dano_patrimonial` JSONB (auditabilidad del cálculo) | No exigido por Art. |
-| 6 | Estructura específica de `antecedentes` JSONB con 6 sub-secciones | Art. 44 dice "antecedentes" sin desglose |
-| 7 | Roles claros de `auditores_integrantes`: Elaboró/Revisó/Supervisó/Autorizó mapeando a flujo VBO de 3 niveles | Art. 44 dice "auditores que intervinieron" sin roles |
-
-Refactor de Fase 1 = ~600 LOC de cambios + 1 tabla puente nueva + modelo Pydantic re-estructurado. Si el machote hubiera estado disponible al inicio, ese refactor no existiría.
-
-## El patrón
-
-### Paso 1: identificar si la entidad es regulatoria
-
-Una entidad es regulatoria cuando representa un **documento normativo emitido por una institución**:
-
-- Papel de trabajo (de auditoría).
-- Cédula (preliminar, definitiva, observación derivada).
-- Oficio (de investigación, de notificación, de respuesta).
-- Informe (de hipótesis, de irregularidad, de auditoría).
-- Acta (de inicio, de hechos, de cierre).
-- Dictamen.
-- Expediente (con composición fija de documentos).
-- Resolución.
-
-NO es regulatoria:
-- Producto de catálogo, usuario, sesión, configuración.
-- Evento de log o auditoría técnica.
-- Entidad transaccional puramente operacional (pago, factura interna).
-
-### Paso 2: durante /swl:discutir-fase, preguntar explícitamente
-
-Antes de modelar la entidad, plantear al usuario las 3 preguntas:
-
-1. **¿Existe un machote oficial real del documento?** (formato Word/PDF emitido por la institución, no template generado por el equipo).
-2. **¿Existe un Artículo legal o Reglamento que defina el contenido obligatorio?** (cita exacta del Art.).
-3. **Si solo hay Art., ¿hay práctica institucional documentada (manuales operativos, guías, ejemplos previos)?**
-
-Estados posibles del discovery:
-
-| Machote | Art. legal | Acción |
-|---|---|---|
-| ✅ Disponible | ✅ Disponible | Modelar desde machote + verificar que cubre todos los puntos del Art. (el Art. es el mínimo, el machote es el contrato real). |
-| ✅ Disponible | ❌ No disponible | Modelar desde machote. Marcar campos como "exigidos por práctica institucional, sin base legal explícita". |
-| ❌ No disponible | ✅ Disponible | Modelar desde Art. con marca explícita "modelo derivado solo del Art. — pendiente de validar contra machote oficial cuando el usuario lo proporcione". Crear DT formal `DT-MODELO-{ENTIDAD}-MACHOTE-PENDIENTE` con criterio de disparo: "modelo se considera estable cuando el machote oficial confirme o requiera ajustes". |
-| ❌ No disponible | ❌ No disponible | Escalar al usuario: "No hay fuente oficial ni machote — ¿la entidad existe como tal? ¿O debería modelarse como entidad de aplicación sin contrato institucional?". |
-
-### Paso 3: extraer del machote, no del modelo mental
-
-Cuando el machote esté disponible, leerlo COMPLETO con `markitdown` (regla global `markitdown.md` para .docx/.pdf):
-
-```bash
-markitdown OIC-DATIC-02-ESP-2025-IPHI-01.docx > /tmp/machote-iphi.md
-```
-
-Auditar cada sección visible:
-
-- **Tablas estructuradas**: cada fila/columna → posible columna de la entidad o tabla puente.
-- **Campos repetidos con formato uniforme**: posible tipo enum o catálogo.
-- **Secciones con sub-secciones**: posible JSONB estructurado.
-- **Espacios para firma/aprobación**: posible flujo de estados (VBO, aprobación multi-nivel).
-- **Numeración de párrafos**: posible array o relación 1:N.
-- **Referencias a otros documentos**: posibles FKs a otras entidades.
-
-NO inferir campos del modelo mental — extraer literal del machote.
-
-### Paso 4: registrar la divergencia Art. ↔ machote
-
-En el ADR de la entidad (o sección `### Modelo derivado` del schema):
-
-```markdown
-## Origen del modelo
-
-**Artículo legal**: DBC_FISC_OIC Art. 44 (10 fracciones I-X).
-**Machote oficial**: OIC-DATIC-02-ESP-2025-IPHI-01.docx (~25 páginas).
-
-**Extensiones del machote sobre el Art.**:
-1. `perjuicio_total_estimado` distinto de `presunto_dano_patrimonial`.
-2. Observaciones origen N:M con `hallazgo_identificador`.
-3. `procedimientos_contratacion_relacionados` JSONB.
-4. ...
-
-**Cobertura**: el modelo cubre 100% del Art. 44 + 7 extensiones del machote.
-**Divergencia**: cuando el Art. y el machote contradicen, prevalece el machote (es el contrato real de la institución).
-```
-
-## Anti-patrones
-
-- **Modelar desde solo el Art. legal sin pedir el machote** — el modelo cubre el mínimo legal pero pierde 30-50% del contenido institucional real. Refactor garantizado cuando aparezca el machote.
-- **Modelar desde un machote sin verificar contra el Art.** — riesgo de campos derivados de versiones obsoletas del documento. El Art. es la fuente de verdad legal; el machote puede tener campos "heredados" de versiones previas.
-- **Asumir que el machote está internalizado en el modelo del equipo** — el equipo del agente NO tiene el machote en su contexto entrenado. Pedirlo explícitamente al usuario; no inferir.
-- **Diferir el machote a "después del MVP"** — el refactor para incorporar el machote en una entidad regulatoria es 80% reescritura del modelo + cascada a schemas Pydantic + frontend forms. NO es post-MVP barato.
-- **Aceptar un machote en formato propietario sin convertirlo a markdown legible** — abrir el Word/PDF directamente lleva al modelo a olvidar campos. Convertir SIEMPRE con `markitdown` y auditar el markdown resultante.
-
-## Gotchas / Errores comunes no obvios
-
-- **El machote tiene campos "sólo para impresión" que NO son datos de la entidad**: encabezados con logos, secciones de "Para uso oficial", footers. Esos NO van al modelo. Discriminar mientras se audita el markdown extraído.
-- **El machote tiene campos calculados o derivados que SE ALMACENAN para auditoría**: ej. `perjuicio_total_estimado` se calcula desde 3 sumandos pero se persiste explícitamente porque el documento legal lo cita como cifra. Almacenar como columna calculada con backfill o como dato denormalizado con trigger de recálculo.
-- **El machote evoluciona entre años fiscales** (`OIC-DATIC-02-ESP-2024-...` vs `OIC-DATIC-02-ESP-2025-...`): el modelo debe versionar el contrato. Agregar `machote_version: str` a la entidad para registrar contra qué versión se emitió cada documento. Migrar es costoso si no se versiona desde el inicio.
-- **El usuario puede proporcionar un machote "informal" que es solo un Word con texto libre**: discriminar entre machote oficial (emitido por la institución con código de documento, fecha de actualización, autoridad emisora) vs borrador interno del equipo. El borrador NO es contrato — usar Art. como base con DT formal.
+---
+name: proceso-discovery-machote
+description: >
+  Patrón de discovery para modelar entidades regulatorias (papeles de trabajo,
+  cédulas, oficios, informes, expedientes, actas, dictámenes). Antes de modelar
+  desde el Artículo legal, pedir al usuario el machote oficial real (template
+  institucional). El Art. define el mínimo normativo; el machote revela el
+  contrato institucional real con prácticas no codificadas pero exigidas.
+  Cargar al iniciar la modelación de cualquier entidad nueva que represente
+  un documento normativo emitido por una institución regulatoria (OIC, INE,
+  SAT, etc.), durante /swl:discutir-fase de un módulo regulatorio, o cuando
+  el usuario rechaza un primer diseño por "faltan campos del documento real".
+version: "1.0.0"
+herramientasPermitidas: [Read, Grep, Glob]
+exclusiones:
+  - "No cargar para entidades NO regulatorias (productos, usuarios, sesiones, eventos de log) — el machote no aplica a entidades de aplicación generales."
+  - "No cargar cuando el modelo de la entidad ya está estabilizado y solo se va a agregar 1-2 campos — el discovery completo es overhead innecesario para ajustes pequeños."
+  - "No cargar para refactor de entidad existente que ya tiene 6+ meses en producción — el machote ya se consolidó implícitamente en el modelo; cualquier diferencia es decisión de evolución, no de discovery."
+  - "No cargar para CRUD administrativo simple (catálogos, configuraciones) — esos no tienen contrato institucional rico; cargar `discutir-fase` regular."
+evolvable: true
+---
+
+# Proceso Discovery Machote
+
+Patrón obligatorio antes de modelar entidades regulatorias.
+
+## Cuándo NO cargar
+
+- La entidad NO es regulatoria (un producto de catálogo, una sesión de usuario, un evento de log).
+- El modelo ya está estabilizado en producción y solo se agregan 1-2 campos.
+- Es refactor de entidad consolidada (≥6 meses prod) — cargar reglas de refactor, no de discovery.
+- Es CRUD administrativo simple sin contrato institucional rico.
+
+## El gap conceptual
+
+**El Artículo legal define el mínimo normativo. El machote oficial revela el contrato institucional real.**
+
+Caso real SIGAF ADR-081 IPHI (2026-05-15). El Informe de Presunta Hipótesis de Irregularidad (IPHI) se modeló inicialmente desde Art. 44 DBC_FISC_OIC, que enumera 10 fracciones (I-X) de contenido obligatorio:
+
+> Art. 44. El informe contendrá:
+> I.   Antecedentes
+> II.  Marco normativo
+> III. Hechos
+> IV.  Análisis
+> V.   Presunto daño patrimonial
+> VI.  Cuantificación del daño
+> VII. Sujetos involucrados
+> VIII. Pruebas documentales
+> IX.  Conclusiones
+> X.   Auditores que intervinieron
+
+Modelo Pydantic + tabla SQL creados con esas 10 secciones. Commit inicial Fase 1.
+
+Tras Fase 1, el usuario proporcionó el machote oficial real `OIC-DATIC-02-ESP-2025-IPHI-01.docx`. Reveló **7 extensiones institucionales NO presentes en Art. 44**:
+
+| # | Extensión del machote | NO está en Art. 44 |
+|---|---|---|
+| 1 | Distinción `presunto_dano_patrimonial` (directo) vs `perjuicio_total_estimado` (agregado: daño + depreciación + costo oportunidad) | Art. 44 fracción V/VI no distinguen |
+| 2 | Observaciones origen N:M con `hallazgo_identificador` (tabla puente `iphi_observacion_origen`) | Art. 44 no define la relación |
+| 3 | `procedimientos_contratacion_relacionados` JSONB (lista de LP-INE asociadas) | No aparece en el Art. |
+| 4 | `normas_infringidas` JSONB estructurado `[{norma, articulo, contenido}]` | Art. 44 dice "marco normativo" sin estructura |
+| 5 | `desglose_dano_patrimonial` JSONB (auditabilidad del cálculo) | No exigido por Art. |
+| 6 | Estructura específica de `antecedentes` JSONB con 6 sub-secciones | Art. 44 dice "antecedentes" sin desglose |
+| 7 | Roles claros de `auditores_integrantes`: Elaboró/Revisó/Supervisó/Autorizó mapeando a flujo VBO de 3 niveles | Art. 44 dice "auditores que intervinieron" sin roles |
+
+Refactor de Fase 1 = ~600 LOC de cambios + 1 tabla puente nueva + modelo Pydantic re-estructurado. Si el machote hubiera estado disponible al inicio, ese refactor no existiría.
+
+## El patrón
+
+### Paso 1: identificar si la entidad es regulatoria
+
+Una entidad es regulatoria cuando representa un **documento normativo emitido por una institución**:
+
+- Papel de trabajo (de auditoría).
+- Cédula (preliminar, definitiva, observación derivada).
+- Oficio (de investigación, de notificación, de respuesta).
+- Informe (de hipótesis, de irregularidad, de auditoría).
+- Acta (de inicio, de hechos, de cierre).
+- Dictamen.
+- Expediente (con composición fija de documentos).
+- Resolución.
+
+NO es regulatoria:
+- Producto de catálogo, usuario, sesión, configuración.
+- Evento de log o auditoría técnica.
+- Entidad transaccional puramente operacional (pago, factura interna).
+
+### Paso 2: durante /swl:discutir-fase, preguntar explícitamente
+
+Antes de modelar la entidad, plantear al usuario las 3 preguntas:
+
+1. **¿Existe un machote oficial real del documento?** (formato Word/PDF emitido por la institución, no template generado por el equipo).
+2. **¿Existe un Artículo legal o Reglamento que defina el contenido obligatorio?** (cita exacta del Art.).
+3. **Si solo hay Art., ¿hay práctica institucional documentada (manuales operativos, guías, ejemplos previos)?**
+
+Estados posibles del discovery:
+
+| Machote | Art. legal | Acción |
+|---|---|---|
+| ✅ Disponible | ✅ Disponible | Modelar desde machote + verificar que cubre todos los puntos del Art. (el Art. es el mínimo, el machote es el contrato real). |
+| ✅ Disponible | ❌ No disponible | Modelar desde machote. Marcar campos como "exigidos por práctica institucional, sin base legal explícita". |
+| ❌ No disponible | ✅ Disponible | Modelar desde Art. con marca explícita "modelo derivado solo del Art. — pendiente de validar contra machote oficial cuando el usuario lo proporcione". Crear DT formal `DT-MODELO-{ENTIDAD}-MACHOTE-PENDIENTE` con criterio de disparo: "modelo se considera estable cuando el machote oficial confirme o requiera ajustes". |
+| ❌ No disponible | ❌ No disponible | Escalar al usuario: "No hay fuente oficial ni machote — ¿la entidad existe como tal? ¿O debería modelarse como entidad de aplicación sin contrato institucional?". |
+
+### Paso 3: extraer del machote, no del modelo mental
+
+Cuando el machote esté disponible, leerlo COMPLETO con `markitdown` (regla global `markitdown.md` para .docx/.pdf):
+
+```bash
+markitdown OIC-DATIC-02-ESP-2025-IPHI-01.docx > /tmp/machote-iphi.md
+```
+
+Auditar cada sección visible:
+
+- **Tablas estructuradas**: cada fila/columna → posible columna de la entidad o tabla puente.
+- **Campos repetidos con formato uniforme**: posible tipo enum o catálogo.
+- **Secciones con sub-secciones**: posible JSONB estructurado.
+- **Espacios para firma/aprobación**: posible flujo de estados (VBO, aprobación multi-nivel).
+- **Numeración de párrafos**: posible array o relación 1:N.
+- **Referencias a otros documentos**: posibles FKs a otras entidades.
+
+NO inferir campos del modelo mental — extraer literal del machote.
+
+### Paso 4: registrar la divergencia Art. ↔ machote
+
+En el ADR de la entidad (o sección `### Modelo derivado` del schema):
+
+```markdown
+## Origen del modelo
+
+**Artículo legal**: DBC_FISC_OIC Art. 44 (10 fracciones I-X).
+**Machote oficial**: OIC-DATIC-02-ESP-2025-IPHI-01.docx (~25 páginas).
+
+**Extensiones del machote sobre el Art.**:
+1. `perjuicio_total_estimado` distinto de `presunto_dano_patrimonial`.
+2. Observaciones origen N:M con `hallazgo_identificador`.
+3. `procedimientos_contratacion_relacionados` JSONB.
+4. ...
+
+**Cobertura**: el modelo cubre 100% del Art. 44 + 7 extensiones del machote.
+**Divergencia**: cuando el Art. y el machote contradicen, prevalece el machote (es el contrato real de la institución).
+```
+
+## Anti-patrones
+
+- **Modelar desde solo el Art. legal sin pedir el machote** — el modelo cubre el mínimo legal pero pierde 30-50% del contenido institucional real. Refactor garantizado cuando aparezca el machote.
+- **Modelar desde un machote sin verificar contra el Art.** — riesgo de campos derivados de versiones obsoletas del documento. El Art. es la fuente de verdad legal; el machote puede tener campos "heredados" de versiones previas.
+- **Asumir que el machote está internalizado en el modelo del equipo** — el equipo del agente NO tiene el machote en su contexto entrenado. Pedirlo explícitamente al usuario; no inferir.
+- **Diferir el machote a "después del MVP"** — el refactor para incorporar el machote en una entidad regulatoria es 80% reescritura del modelo + cascada a schemas Pydantic + frontend forms. NO es post-MVP barato.
+- **Aceptar un machote en formato propietario sin convertirlo a markdown legible** — abrir el Word/PDF directamente lleva al modelo a olvidar campos. Convertir SIEMPRE con `markitdown` y auditar el markdown resultante.
+
+## Gotchas / Errores comunes no obvios
+
+- **El machote tiene campos "sólo para impresión" que NO son datos de la entidad**: encabezados con logos, secciones de "Para uso oficial", footers. Esos NO van al modelo. Discriminar mientras se audita el markdown extraído.
+- **El machote tiene campos calculados o derivados que SE ALMACENAN para auditoría**: ej. `perjuicio_total_estimado` se calcula desde 3 sumandos pero se persiste explícitamente porque el documento legal lo cita como cifra. Almacenar como columna calculada con backfill o como dato denormalizado con trigger de recálculo.
+- **El machote evoluciona entre años fiscales** (`OIC-DATIC-02-ESP-2024-...` vs `OIC-DATIC-02-ESP-2025-...`): el modelo debe versionar el contrato. Agregar `machote_version: str` a la entidad para registrar contra qué versión se emitió cada documento. Migrar es costoso si no se versiona desde el inicio.
+- **El usuario puede proporcionar un machote "informal" que es solo un Word con texto libre**: discriminar entre machote oficial (emitido por la institución con código de documento, fecha de actualización, autoridad emisora) vs borrador interno del equipo. El borrador NO es contrato — usar Art. como base con DT formal.

package/habilidades/proceso-dynamic-workflows/SKILL.md

@@ -12,6 +12,7 @@ when_to_use: >
   Usar cuando el usuario diga "ultracode", "workflow", "orquesta esto", "fan-out", "panel
   de revisores", "tournament", o cuando una tarea sea larga, masivamente paralela o
   adversarial y un solo context window sufra laziness/goal-drift.
+version: "1.0.2"
 herramientasPermitidas: [Read, Grep, Glob]
 exclusiones:
   - "No cargar para tareas de codificación normales de un solo paso — la mayoría NO necesitan un workflow; el harness por defecto basta y un workflow gasta muchos más tokens."
@@ -131,6 +132,65 @@ saneada. Coherente con `seguridad-agentes.md § Prompt injection` y el quarantin
   hacer que el subagente explore el codebase completo (ver `harness-claude-code`).
 - **Barrier injustificado** mata wall-clock: si no hay dependencia cross-ítem entre stages,
   usa `pipeline()`, no `parallel()` entre stages.
+- **Template literals con backticks anidados rompen el parser del script**: construir
+  prompts largos con `` `...${var}...` `` que contienen spans de código inline (p. ej.
+  `` `verifyOperation()` ``) produce "Unexpected token" — el backtick interno cierra el
+  template literal externo antes de tiempo. Caso real (swl-ses F32-T04): el primer intento
+  de un script `Disenar → Implementar → Verificar` falló así. Fix: construir strings largos
+  con arrays de strings simples unidos por `[...].join('\n')`, nunca template literals
+  anidados, en cualquier prompt que vaya a citar código entre backticks.
+- **El memo de una fase larga puede llegar truncado a la fase siguiente**: en un workflow
+  `pipeline()` de tipo Diseñar→Implementar, el valor de retorno de `agent()` de la fase de
+  diseño (memo extenso, ~9 secciones) llegó truncado (solo 3 secciones) al agente
+  implementador de la fase siguiente — sin error visible, el implementador simplemente
+  recibió menos contexto del que el diseñador produjo. El implementador que detecta el gap
+  y lo documenta explícitamente (en vez de improvisar en silencio) permite que el
+  orquestador verifique después si sus decisiones de relleno fueron sólidas — pero la causa
+  raíz (paso de contexto entre `agent()` calls con memos largos) sigue sin mitigación
+  estructural. Para memos de diseño extensos, pedir al agente de diseño un resumen
+  ejecutivo compacto ADEMÁS del memo completo, o persistir el memo a un archivo intermedio
+  en vez de depender solo del valor de retorno entre fases.
+- **Archivos disjuntos NO son suficientes para saltarse `isolation:"worktree"` en un
+  `pipeline()`/`parallel()` con múltiples `agent()` que mutan el repo** (confirma y extiende
+  L-294/`git-worktrees-paralelo/SKILL.md`): el criterio "disjuntos → seguro sin worktree"
+  ignora que cualquier agente puede ejecutar un comando git de alcance AMPLIO por una razón
+  ajena a su propio scope declarado (ej. `git stash` sin pathspec para revisar si un fallo de
+  test es preexistente) — eso muta el working tree COMPLETO, no solo los archivos que ese
+  agente declaró tocar, y clobbea el trabajo sin commitear de los agentes hermanos. Confirmado
+  en producción (dos rondas de la misma sesión, 2026-07-19): ronda 1 con 3 tickets en
+  `pipeline()` sin worktree — un agente corrió `git stash` sin pathspec y perdió temporalmente
+  las ediciones de dos agentes hermanos (recuperado sin daño, pero real). Mitigación validada
+  más barata que `isolation:"worktree"` para cuando el costo de N worktrees no se justifica:
+  agregar una guarda EXPLÍCITA en el prompt de cada agente prohibiendo `git stash` sin
+  pathspec, `git checkout .`, `git reset --hard`, y cualquier comando git de alcance amplio —
+  instruir a *reportar* (vía `SendMessage` al padre) si detecta archivos ajenos modificados en
+  vez de intentar "arreglarlo". Ronda 2 (mismo día, misma sesión) con la guarda añadida: los
+  agentes detectaron archivos ajenos y NO los tocaron — cero incidente. La guarda de prompt
+  reduce el riesgo pero no lo elimina tan bien como `isolation:"worktree"` real — sigue
+  dependiendo de que cada agente obedezca la instrucción; para lotes de alto riesgo fiscal o
+  con historial de incidentes, preferir worktree real pese al costo.
+- **La verificación independiente (agente distinto al implementador, re-derivando el
+  comportamiento esperado desde cero) encuentra bugs reales que el implementador + sus propios
+  tests no detectan** — confirmado 2 veces en la misma sesión (2026-07-19): (a) un trigger SQL
+  con un enum-drift que rompía TODO cobro de un módulo en producción, encontrado al escribir
+  un test de integración nuevo (nemesis-style, no por el propio implementador); (b) un cálculo
+  de sello criptográfico que usaba un campo inexistente en ambos caminos reales (generación y
+  verificación), pasando 100% de los tests del propio implementador porque su fixture
+  enmascaraba el bug con un shape de datos que nunca ocurre en producción. En ambos casos el
+  implementador reportó "tests pasan, todo verde" — el stage de verificación solo lo detectó
+  porque su instrucción explícita era "NO confíes en el resumen del implementador, re-verifica
+  tú mismo" + releer el código real contra el comportamiento prometido, no solo re-correr las
+  mismas aserciones. Refuerza el patrón canónico de este skill (adversarial-verification):
+  SIEMPRE separar implementación de verificación en `agent()` DISTINTOS con escepticismo
+  explícito en el prompt, incluso para tickets "decision-free" de bajo riesgo aparente.
+- **Las notificaciones "agent-message" de sub-agentes de un mismo `Workflow` pueden llegar
+  enmarcadas como si fueran de "otra sesión de Claude"**, aunque sean simplemente ramas
+  paralelas del pipeline propio (`pipeline()`/`parallel()` con varios `agent()` concurrentes).
+  Antes de escalar al protocolo completo de coordinación multi-sesión (pausar todo, presentar
+  opciones), verificar si el remitente (`agentId` del mensaje) aparece en
+  `ls <workflow-transcript-dir>/agent-*.jsonl` del propio Workflow en curso — si sí, es
+  autocolisión de tu propio diseño sin `isolation:"worktree"` (ver gotcha de arriba), no una
+  sesión externa genuina.
 
 ## Origen
 

package/habilidades/proceso-dynamic-workflows/recursos/template-adversarial-verify.js

@@ -1,65 +1,65 @@
-// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
-// Patrón: fan-out de hallazgos -> verificación adversarial por hallazgo -> filtrar reales.
-// Combate self-preferential bias y agentic laziness. Adapta DIMENSIONS, rubrics y schemas.
-//
-// Uso: el agente lee esta plantilla, la ajusta al caso concreto y la pasa al Workflow tool.
-
-export const meta = {
-  name: 'adversarial-verify',
-  description: 'Revisa por dimensiones y verifica cada hallazgo adversarialmente antes de aceptarlo',
-  phases: [{ title: 'Review' }, { title: 'Verify' }],
-}
-
-// Dimensiones de revisión — una por lente independiente (no se contaminan entre sí).
-const DIMENSIONS = [
-  { key: 'correctness', prompt: 'Revisa SOLO correctness del scope. Devuelve hallazgos.' },
-  { key: 'security', prompt: 'Revisa SOLO seguridad del scope. Devuelve hallazgos.' },
-  { key: 'dry', prompt: 'Revisa SOLO duplicación/DRY del scope. Devuelve hallazgos.' },
-]
-
-const FINDINGS = {
-  type: 'object', additionalProperties: false,
-  properties: {
-    findings: {
-      type: 'array',
-      items: {
-        type: 'object', additionalProperties: false,
-        properties: {
-          title: { type: 'string' }, file: { type: 'string' }, line: { type: 'string' },
-          severity: { type: 'string', enum: ['critico', 'mayor', 'menor'] },
-        },
-        required: ['title', 'file', 'severity'],
-      },
-    },
-  },
-  required: ['findings'],
-}
-
-const VERDICT = {
-  type: 'object', additionalProperties: false,
-  properties: {
-    isReal: { type: 'boolean' },
-    reason: { type: 'string' },
-  },
-  required: ['isReal', 'reason'],
-}
-
-// pipeline (sin barrier): cada dimensión verifica sus hallazgos en cuanto su review termina.
-const results = await pipeline(
-  DIMENSIONS,
-  (d) => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS }),
-  (review, d) =>
-    parallel(
-      (review?.findings || []).map((f) => () =>
-        // Verificador adversarial: prompt orientado a REFUTAR (default refutado si dudoso).
-        agent(
-          `Intenta REFUTAR este hallazgo contra el código real (cita archivo:linea). ` +
-          `Si no puedes probarlo, isReal=false: ${JSON.stringify(f)}`,
-          { label: `verify:${f.file}`, phase: 'Verify', schema: VERDICT }
-        ).then((v) => ({ ...f, verdict: v }))
-      )
-    )
-)
-
-const confirmados = results.flat().filter(Boolean).filter((f) => f.verdict?.isReal)
-return { confirmados }
+// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
+// Patrón: fan-out de hallazgos -> verificación adversarial por hallazgo -> filtrar reales.
+// Combate self-preferential bias y agentic laziness. Adapta DIMENSIONS, rubrics y schemas.
+//
+// Uso: el agente lee esta plantilla, la ajusta al caso concreto y la pasa al Workflow tool.
+
+export const meta = {
+  name: 'adversarial-verify',
+  description: 'Revisa por dimensiones y verifica cada hallazgo adversarialmente antes de aceptarlo',
+  phases: [{ title: 'Review' }, { title: 'Verify' }],
+}
+
+// Dimensiones de revisión — una por lente independiente (no se contaminan entre sí).
+const DIMENSIONS = [
+  { key: 'correctness', prompt: 'Revisa SOLO correctness del scope. Devuelve hallazgos.' },
+  { key: 'security', prompt: 'Revisa SOLO seguridad del scope. Devuelve hallazgos.' },
+  { key: 'dry', prompt: 'Revisa SOLO duplicación/DRY del scope. Devuelve hallazgos.' },
+]
+
+const FINDINGS = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    findings: {
+      type: 'array',
+      items: {
+        type: 'object', additionalProperties: false,
+        properties: {
+          title: { type: 'string' }, file: { type: 'string' }, line: { type: 'string' },
+          severity: { type: 'string', enum: ['critico', 'mayor', 'menor'] },
+        },
+        required: ['title', 'file', 'severity'],
+      },
+    },
+  },
+  required: ['findings'],
+}
+
+const VERDICT = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    isReal: { type: 'boolean' },
+    reason: { type: 'string' },
+  },
+  required: ['isReal', 'reason'],
+}
+
+// pipeline (sin barrier): cada dimensión verifica sus hallazgos en cuanto su review termina.
+const results = await pipeline(
+  DIMENSIONS,
+  (d) => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS }),
+  (review, d) =>
+    parallel(
+      (review?.findings || []).map((f) => () =>
+        // Verificador adversarial: prompt orientado a REFUTAR (default refutado si dudoso).
+        agent(
+          `Intenta REFUTAR este hallazgo contra el código real (cita archivo:linea). ` +
+          `Si no puedes probarlo, isReal=false: ${JSON.stringify(f)}`,
+          { label: `verify:${f.file}`, phase: 'Verify', schema: VERDICT }
+        ).then((v) => ({ ...f, verdict: v }))
+      )
+    )
+)
+
+const confirmados = results.flat().filter(Boolean).filter((f) => f.verdict?.isReal)
+return { confirmados }