@saulwade/swl-ses 2.0.0 → 2.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CLAUDE.md +196 -196
- package/README.md +579 -579
- package/agentes/_propose-step.md +90 -0
- package/agentes/implementador-swl.md +2 -0
- package/agentes/orquestador-swl.md +2 -0
- package/agentes/perfilador-usuario-swl.md +14 -1
- package/bin/swl-ses.js +1 -1
- package/comandos/swl/aprobar-plan.md +3 -2
- package/comandos/swl/briefing.md +122 -0
- package/comandos/swl/compactar.md +29 -2
- package/comandos/swl/discutir-fase.md +8 -5
- package/comandos/swl/ejecutar-fase.md +6 -0
- package/comandos/swl/planear-fase.md +5 -3
- package/comandos/swl/release.md +46 -0
- package/comandos/swl/status.md +69 -0
- package/comandos/swl/verificar.md +3 -2
- package/habilidades/changelog-generator/scripts/parse-commits.js +6 -4
- package/habilidades/ejecutar-fase/SKILL.md +541 -518
- package/habilidades/planear-fase/SKILL.md +3 -2
- package/habilidades/tdd-workflow/SKILL.md +715 -713
- package/habilidades/validacion-ci-sistema/SKILL.md +17 -1
- package/hooks/calidad-pre-commit.js +5 -1
- package/hooks/check-update.js +39 -1
- package/hooks/lib/autonomia.js +208 -0
- package/hooks/lib/briefing.js +474 -0
- package/hooks/lib/propose-step.js +357 -0
- package/hooks/session-briefing.js +98 -0
- package/hooks/telemetria-skill-routing.js +100 -0
- package/instintos/autonomia.yaml +27 -0
- package/llms.txt +4 -4
- package/manifiestos/hooks-config.json +18 -0
- package/manifiestos/modulos.json +25 -3
- package/manifiestos/skills-lock.json +14 -14
- package/package.json +93 -93
- package/plugin.json +371 -371
- package/reglas/analizar-directorios-antes-de-escribir.md +228 -0
- package/reglas/consultar-vault-primero.md +195 -0
- package/reglas/debatir-antes-de-aceptar.md +158 -0
- package/reglas/git-coauthor.md +100 -0
- package/reglas/monitor-ci.md +309 -0
- package/reglas/registro-componentes-nuevos.md +38 -10
- package/reglas/sesiones-paralelas.md +180 -0
- package/reglas/usar-code-review-graph.md +155 -0
- package/reglas/verificar-citas-normativas.md +548 -0
- package/scripts/instalador.js +52 -6
- package/scripts/lib/ci-reader.js +193 -0
- package/scripts/lib/detectar-host-swl.js +175 -0
- package/scripts/lib/evidencia-release.js +322 -0
- package/scripts/lib/gate-hooks-requires.js +249 -0
- package/scripts/lib/gate-licencias.js +212 -0
- package/scripts/lib/git-metricas.js +257 -0
- package/scripts/lib/metricas-dora.js +204 -0
- package/scripts/tui/ejecutores.js +1 -1
- package/scripts/validar-manifest.js +92 -1
- package/scripts/verificar-evolucion.js +54 -4
- package/scripts/verificar-release.js +102 -0
- package/scripts/verificar-trazabilidad.js +11 -5
- package/reglas/arquitectura.evolved.json +0 -7
- package/reglas/seguridad.evolved.json +0 -7
|
@@ -0,0 +1,548 @@
|
|
|
1
|
+
# Regla: Verificar citas verificables antes de escribirlas o aceptarlas
|
|
2
|
+
|
|
3
|
+
Esta regla es OBLIGATORIA y aplica a todo contenido que Claude genere o acepte
|
|
4
|
+
como válido en cualquier proyecto del usuario donde aparezca una cita
|
|
5
|
+
verificable. Cubre dos familias del mismo principio:
|
|
6
|
+
|
|
7
|
+
1. **Citas normativas / legales / documentales**: artículo de ley o reglamento,
|
|
8
|
+
sección de un estándar, número de RFC/ISO, página de documento oficial,
|
|
9
|
+
referencia a un acuerdo institucional, nombre de un programa o catálogo
|
|
10
|
+
oficial, fecha de promulgación, o atribución de fundamento normativo a una
|
|
11
|
+
entidad de datos.
|
|
12
|
+
2. **Citas técnicas archivo:línea**: cualquier afirmación que cite una
|
|
13
|
+
ubicación específica del codebase (`path/al/archivo.py:123`,
|
|
14
|
+
`module/file.ts:45-90`, `schema.sql:438`) en reportes de auditoría,
|
|
15
|
+
análisis de bugs, hallazgos de seguridad, code review, post-mortems,
|
|
16
|
+
reportes de revisión externa, o conclusiones que tú mismo escribas
|
|
17
|
+
acerca del código.
|
|
18
|
+
|
|
19
|
+
Las dos familias comparten el mismo problema y la misma defensa: el agente
|
|
20
|
+
o el reporte afirma evidencia específica, y esa evidencia puede inventarse,
|
|
21
|
+
trasladarse mal o estar desactualizada. El antídoto es siempre el mismo:
|
|
22
|
+
**`grep` / `Read` sobre la fuente real antes de aceptar o re-emitir la cita**.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Principio
|
|
27
|
+
|
|
28
|
+
> Antes de escribir una cita verificable (normativa o técnica archivo:línea)
|
|
29
|
+
> en código, UI, documentación, reportes, comentarios, docstrings o
|
|
30
|
+
> conclusiones, **debes verificarla con `grep` o `Read` sobre la fuente real
|
|
31
|
+
> del proyecto**. Si no puedes encontrar evidencia textual de la cita, NO la
|
|
32
|
+
> escribas. Una cita plausible que suena correcta NO es una cita verificada.
|
|
33
|
+
>
|
|
34
|
+
> El mismo principio aplica cuando ACEPTAS una cita ajena: un reporte de
|
|
35
|
+
> otro agente, un hallazgo de auditoría, una afirmación del usuario sobre
|
|
36
|
+
> "el bug está en X:42". Si vas a actuar sobre la cita (priorizarla,
|
|
37
|
+
> remediarla, reproducirla en tu propio output), verifícala primero contra
|
|
38
|
+
> la fuente. Aceptar sin verificar es propagar la confabulación.
|
|
39
|
+
|
|
40
|
+
Las normas mexicanas (RINEMAABMS, LGCG, LAASSP, CONAC, Constitución, leyes
|
|
41
|
+
generales) y los estándares técnicos (RFC, ISO, OWASP, WCAG) son tentadores
|
|
42
|
+
para confabular contextos plausibles. **Las citas archivo:línea generadas
|
|
43
|
+
por otros agentes son tentadoras para aceptar sin verificar** — vienen con
|
|
44
|
+
apariencia de evidencia "ya hecha". Plausible ≠ verificado. El costo de
|
|
45
|
+
inventar o propagar una cita es pérdida de confianza del usuario y debug
|
|
46
|
+
innecesario; el costo de verificar es un `grep` o `Read` de 2 segundos.
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## Qué cuenta como "cita verificable"
|
|
51
|
+
|
|
52
|
+
### Familia 1 — citas normativas / legales / documentales
|
|
53
|
+
|
|
54
|
+
OBLIGATORIO verificar antes de escribir:
|
|
55
|
+
|
|
56
|
+
- Artículo numerado de una norma: "Art. 23 RINEMAABMS", "Art. 30 LGCG",
|
|
57
|
+
"Art. 134 CPEUM", "fracción IV del Art. 17", etc.
|
|
58
|
+
- Número de RFC / ISO / IEEE: "RFC 7231", "ISO/IEC 27001", "IEEE 802.11n".
|
|
59
|
+
- Sección de un estándar: "OWASP Top 10 A03", "WCAG 2.1 SC 1.4.3", "NIST
|
|
60
|
+
SP 800-63".
|
|
61
|
+
- Nombre de catálogo, programa o acuerdo oficial: "PAAASINE-INE", "PAF",
|
|
62
|
+
"Acuerdo INE/CG2024/15".
|
|
63
|
+
- Atribución de fundamento normativo a un dato/tabla/módulo: "según
|
|
64
|
+
Art. X de la norma Y".
|
|
65
|
+
- Fechas y números de páginas de documentos oficiales: "actualización
|
|
66
|
+
julio 2017, 71 páginas".
|
|
67
|
+
- Citas textuales entre comillas atribuidas a un documento concreto.
|
|
68
|
+
|
|
69
|
+
### Familia 2 — citas técnicas archivo:línea
|
|
70
|
+
|
|
71
|
+
OBLIGATORIO verificar antes de escribir o de aceptar como base para acción:
|
|
72
|
+
|
|
73
|
+
- Ubicación específica de un bug, hallazgo o evidencia:
|
|
74
|
+
`auth/service.py:191-243`, `schema.sql:438-451`, `repository.py:1260`.
|
|
75
|
+
- Atribución de un fragmento de código a un archivo: "la función `foo`
|
|
76
|
+
en `bar/baz.ts:42` hace X".
|
|
77
|
+
- Cita textual de líneas de código incluidas en un reporte: si el reporte
|
|
78
|
+
pega 4 líneas como evidencia, esas 4 líneas deben coincidir letra por
|
|
79
|
+
letra con el archivo en el HEAD actual del repo.
|
|
80
|
+
- Citas dentro de reportes de auditoría externa, nemesis, code review,
|
|
81
|
+
análisis de seguridad, post-mortems, RCAs, hallazgos consolidados
|
|
82
|
+
(incluyendo los que tú mismo emites).
|
|
83
|
+
- Conclusiones derivadas de una cita: "es bug porque X:42 ignora Y" —
|
|
84
|
+
hay que confirmar primero que X:42 realmente hace lo que el reporte
|
|
85
|
+
dice.
|
|
86
|
+
- Citas en commit messages, PR descriptions o issues que pretenden ser
|
|
87
|
+
evidencia accionable.
|
|
88
|
+
|
|
89
|
+
NO requiere verificación previa:
|
|
90
|
+
|
|
91
|
+
- Conceptos genéricos del dominio sin atribución a artículo específico
|
|
92
|
+
("auditoría interna", "contratación pública", "expediente de
|
|
93
|
+
contratación").
|
|
94
|
+
- Conocimiento técnico estable sin cita numérica ("SQL injection",
|
|
95
|
+
"OAuth2 flow", "JWT").
|
|
96
|
+
- Descripciones funcionales del propio código que estás editando en
|
|
97
|
+
ese momento.
|
|
98
|
+
- Referencias a archivos sin número de línea cuando solo se discute la
|
|
99
|
+
existencia, no el contenido ("el módulo `auth/` está implementado").
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## Cómo verificar — protocolo obligatorio
|
|
104
|
+
|
|
105
|
+
### Paso 1: identificar la fuente potencial
|
|
106
|
+
|
|
107
|
+
Antes de escribir la cita, identifica de dónde podría salir:
|
|
108
|
+
|
|
109
|
+
- Seeds del proyecto: `grep -rn "TEXTO_CITA" backend/app/seeds/`
|
|
110
|
+
- Modelos / docstrings: `grep -rn "TEXTO_CITA" backend/app/modules/`
|
|
111
|
+
- Documentación normativa: `grep -rn "TEXTO_CITA" referencia/normativa/`
|
|
112
|
+
- ADRs: `grep -rn "TEXTO_CITA" docs/adr/`
|
|
113
|
+
- README, CHANGELOG, planning: `grep -rn "TEXTO_CITA" docs/`
|
|
114
|
+
|
|
115
|
+
### Paso 2: ejecutar la búsqueda
|
|
116
|
+
|
|
117
|
+
Usar `grep` con el patrón exacto de lo que vas a escribir:
|
|
118
|
+
|
|
119
|
+
```bash
|
|
120
|
+
# Verificar "Art. 23 RINEMAABMS"
|
|
121
|
+
grep -rin "art.*23.*rinemaabms\|rinemaabms.*art.*23" path/
|
|
122
|
+
|
|
123
|
+
# Verificar nombre de catálogo
|
|
124
|
+
grep -rin "clasif" referencia/normativa/
|
|
125
|
+
|
|
126
|
+
# Verificar número RFC
|
|
127
|
+
grep -rin "RFC 7231" .
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
### Paso 3: leer la fuente original
|
|
131
|
+
|
|
132
|
+
Si grep devuelve coincidencias, abrir el archivo con `Read` y verificar
|
|
133
|
+
que el contexto sí respalda la cita. Una coincidencia léxica no es prueba
|
|
134
|
+
suficiente — el contexto puede ser opuesto al que asumes.
|
|
135
|
+
|
|
136
|
+
### Paso 4: decidir
|
|
137
|
+
|
|
138
|
+
- **Si la fuente confirma la cita**: escríbela con el contenido que dice
|
|
139
|
+
textualmente el origen.
|
|
140
|
+
- **Si la fuente dice algo parecido pero distinto**: usa el wording real
|
|
141
|
+
del origen, no el que recuerdes de memoria.
|
|
142
|
+
- **Si no hay fuente**: NO escribas la cita. Sustituye por descripción
|
|
143
|
+
neutra sin atribución, o pide al usuario la cita exacta.
|
|
144
|
+
|
|
145
|
+
---
|
|
146
|
+
|
|
147
|
+
## Protocolo para citas archivo:línea en reportes
|
|
148
|
+
|
|
149
|
+
Cuando trabajas con un reporte que cita ubicaciones del codebase (auditoría
|
|
150
|
+
nemesis, hallazgos de revisor-seguridad-swl, output de revisor-codigo-swl,
|
|
151
|
+
informe externo, RCA, post-mortem, hallazgo del usuario):
|
|
152
|
+
|
|
153
|
+
### Paso 1: clasificar las citas
|
|
154
|
+
|
|
155
|
+
Lista cada `archivo:línea` mencionada y clasifícala:
|
|
156
|
+
|
|
157
|
+
- **Crítica accionable** — bug que se va a remediar, hallazgo que se va a
|
|
158
|
+
priorizar, evidencia que se va a citar en un commit o PR. OBLIGATORIO
|
|
159
|
+
verificar.
|
|
160
|
+
- **Contextual** — mención de paso en un párrafo sin que ninguna acción
|
|
161
|
+
dependa de su exactitud. Verificación opcional pero recomendada al
|
|
162
|
+
primer hallazgo crítico que la cite indirectamente.
|
|
163
|
+
|
|
164
|
+
### Paso 2: muestreo mínimo verificable
|
|
165
|
+
|
|
166
|
+
Si el reporte tiene N citas críticas, verificar como mínimo:
|
|
167
|
+
|
|
168
|
+
- **Las top 4-6 acciones priorizadas** del reporte (P1 / críticas).
|
|
169
|
+
- **Cualquier cita con número exacto de líneas** (`:191-243`, `:438-451`)
|
|
170
|
+
— porque exactitud específica es la más propensa a confabulación.
|
|
171
|
+
- **Cualquier hallazgo etiquetado "regresión", "latente" o "extra"** —
|
|
172
|
+
porque suelen detectarse de carambola y son los más frágiles.
|
|
173
|
+
- **Cualquier cita que contradiga decisiones documentadas** — un reporte
|
|
174
|
+
que dice "esto está mal" sobre algo que un ADR / APRENDIZAJES dice
|
|
175
|
+
"esto se decidió así" requiere verificación dura antes de actuar.
|
|
176
|
+
|
|
177
|
+
### Paso 3: verificar con `Read` y `grep`, no asumir
|
|
178
|
+
|
|
179
|
+
Para cada cita crítica:
|
|
180
|
+
|
|
181
|
+
```bash
|
|
182
|
+
# Verificar que las líneas existen y dicen lo que el reporte dice
|
|
183
|
+
Read file_path="<archivo>" offset=<inicio-2> limit=<rango+4>
|
|
184
|
+
|
|
185
|
+
# Buscar evidencia complementaria (¿hay más sitios con el mismo patrón?)
|
|
186
|
+
grep -rn "<patrón>" backend/app/ --include="*.py"
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
Una afirmación del tipo "X:42 ignora la validación" debe verificarse
|
|
190
|
+
leyendo X:42 directamente. Si el reporte cita 4 líneas como evidencia,
|
|
191
|
+
las 4 líneas deben coincidir con el archivo en el HEAD actual.
|
|
192
|
+
|
|
193
|
+
### Paso 4: detectar gaps del reporte
|
|
194
|
+
|
|
195
|
+
Aprovechar la verificación para detectar lo que el reporte NO dice:
|
|
196
|
+
|
|
197
|
+
- **Sweep por patrón**: si el reporte cita un bug en `X.py:1260` por usar
|
|
198
|
+
`u.col_inexistente`, hacer `grep -rn "u\.col_inexistente"` en TODO el
|
|
199
|
+
módulo para descartar regresiones adicionales. Los reportes suelen
|
|
200
|
+
parar en el primer hallazgo del patrón.
|
|
201
|
+
- **Búsqueda inversa**: si el reporte dice "RESUELTO en commit Y",
|
|
202
|
+
verificar que el commit realmente toca el archivo citado.
|
|
203
|
+
- **Evidencia complementaria**: si el reporte cita una columna SQL,
|
|
204
|
+
verificar el `CREATE TABLE` del schema correspondiente. La doble
|
|
205
|
+
evidencia (código + schema) refuerza o refuta el hallazgo.
|
|
206
|
+
|
|
207
|
+
### Paso 5: separar lo verificado de lo no verificado
|
|
208
|
+
|
|
209
|
+
Al re-emitir conclusiones a partir del reporte:
|
|
210
|
+
|
|
211
|
+
- **Marca explícitamente qué citas verificaste personalmente** vs. qué
|
|
212
|
+
citas reproducís sin re-verificar.
|
|
213
|
+
- **NO presentes el reporte como si fuera tu análisis directo** si no
|
|
214
|
+
lo verificaste. Es propagación de cita ajena, no análisis propio.
|
|
215
|
+
- **Si el reporte tiene 11 acciones y solo verificaste 6**, dilo así.
|
|
216
|
+
"Verifiqué 6/11; las 5 restantes asumo correctas por consistencia
|
|
217
|
+
metodológica con las que sí verifiqué" es honesto. "Las 11 acciones
|
|
218
|
+
están confirmadas" cuando solo viste 6 es propagación deshonesta.
|
|
219
|
+
|
|
220
|
+
---
|
|
221
|
+
|
|
222
|
+
## Pattern de redacción cuando NO hay cita verificada
|
|
223
|
+
|
|
224
|
+
En vez de inventar fundamento normativo:
|
|
225
|
+
|
|
226
|
+
- "Documento oficial INE, actualización julio 2017" (cita textual del seed).
|
|
227
|
+
- "Catálogo administrativo interno" (descripción neutra).
|
|
228
|
+
- "Definido por el equipo de proyecto" (atribución honesta sin invento).
|
|
229
|
+
- Sin cualquier cita ni atribución (preferible a inventar).
|
|
230
|
+
|
|
231
|
+
NUNCA:
|
|
232
|
+
|
|
233
|
+
- "Art. X de Y" sin verificación.
|
|
234
|
+
- "Catálogo oficial Z" sin verificación.
|
|
235
|
+
- "Conforme a la sección N del estándar" sin verificación.
|
|
236
|
+
|
|
237
|
+
---
|
|
238
|
+
|
|
239
|
+
## Anti-patrones explícitos
|
|
240
|
+
|
|
241
|
+
### Confabulación plausible
|
|
242
|
+
|
|
243
|
+
Inventar una cita que suena correcta porque el contexto sugiere que
|
|
244
|
+
podría existir. Ejemplo real (SIGAF, 2026-05-13): asocié "Art. 23
|
|
245
|
+
RINEMAABMS" como fundamento del Clasificador de Gasto del INE porque
|
|
246
|
+
RINEMAABMS regula contratación INE y el Art. 23 trata adquisiciones —
|
|
247
|
+
plausible pero falso. El seed `07_clasificador_gasto.sql` no menciona
|
|
248
|
+
ningún artículo, solo cita "Documento oficial INE, actualización julio
|
|
249
|
+
2017, 71 páginas".
|
|
250
|
+
|
|
251
|
+
### Asociación incorrecta entre instrumento y catálogo
|
|
252
|
+
|
|
253
|
+
Confundir un programa de planeación con un catálogo de clasificación.
|
|
254
|
+
Ejemplo: presentar "PAAASINE" (Programa Anual de Adquisiciones del INE,
|
|
255
|
+
instrumento de planeación) como si fuera el "catálogo oficial" del
|
|
256
|
+
Clasificador de Gasto. Son cosas distintas en el dominio.
|
|
257
|
+
|
|
258
|
+
### Cita por intuición de memoria del modelo
|
|
259
|
+
|
|
260
|
+
Atribuir contenido a un artículo o estándar porque "lo aprendí en el
|
|
261
|
+
entrenamiento". El conocimiento de entrenamiento sobre normas mexicanas
|
|
262
|
+
específicas, especialmente las del INE/OIC y reglamentos administrativos,
|
|
263
|
+
es alto en confabulación. Trata cada cita normativa como si NO lo supieras
|
|
264
|
+
hasta que el grep al proyecto lo confirme.
|
|
265
|
+
|
|
266
|
+
### Cita por inferencia transitiva
|
|
267
|
+
|
|
268
|
+
"Si la norma X regula Y, entonces la cita debe ser Art. N de X". No.
|
|
269
|
+
La transición lógica no es prueba documental.
|
|
270
|
+
|
|
271
|
+
### Cita "para dar peso"
|
|
272
|
+
|
|
273
|
+
Inventar fundamento normativo para hacer ver la UI/docs como más
|
|
274
|
+
profesional o jurídicamente sólida. Una cita falsa es peor que ninguna
|
|
275
|
+
cita — destruye la confianza del usuario en TODO lo demás que escribiste.
|
|
276
|
+
|
|
277
|
+
### Aceptar reporte ajeno sin re-verificar evidencia
|
|
278
|
+
|
|
279
|
+
Recibir un reporte de auditoría / nemesis / revisor con citas
|
|
280
|
+
archivo:línea y proceder a priorizar, planear remediación o re-emitir
|
|
281
|
+
las conclusiones SIN haber hecho `Read` ni `grep` sobre las citas
|
|
282
|
+
críticas. El reporte puede:
|
|
283
|
+
|
|
284
|
+
- Tener una cita correcta en archivo pero incorrecta en número de línea
|
|
285
|
+
(el código se movió post-reporte).
|
|
286
|
+
- Tener una cita totalmente inventada por confabulación del agente que
|
|
287
|
+
lo produjo.
|
|
288
|
+
- Estar desactualizado: el bug citado ya se cerró en un commit posterior.
|
|
289
|
+
- Confundir dos archivos similares (`router.py` de módulo A con
|
|
290
|
+
`router.py` de módulo B).
|
|
291
|
+
|
|
292
|
+
Propagar el reporte como si fuera tu análisis directo es deshonesto y
|
|
293
|
+
multiplica el costo del error. La verificación de las top 4-6 citas
|
|
294
|
+
críticas toma 5-10 minutos y separa lo verificado de lo asumido.
|
|
295
|
+
|
|
296
|
+
### Sweep parcial cuando el patrón sugiere más sitios
|
|
297
|
+
|
|
298
|
+
Verificar la cita exacta del reporte (`X.py:1260`) y detenerse ahí
|
|
299
|
+
cuando el bug es **un patrón** (uso de columna inexistente, llamada a
|
|
300
|
+
función deprecada, falta de validación). Los reportes de auditoría
|
|
301
|
+
suelen parar en el primer hallazgo del patrón. Si verificaste que
|
|
302
|
+
`u.col_inexistente` está mal en `X.py:1260`, ejecuta `grep -rn` sobre
|
|
303
|
+
toda la base para encontrar los hermanos antes de marcar el hallazgo
|
|
304
|
+
como cerrado.
|
|
305
|
+
|
|
306
|
+
### "El reporte ya lo verificó"
|
|
307
|
+
|
|
308
|
+
Falacia. Un reporte declara haber verificado, no demuestra haber
|
|
309
|
+
verificado. Si vas a actuar sobre la cita, tu firma vale lo que
|
|
310
|
+
verificaste personalmente — no lo que el reporte afirma haber hecho.
|
|
311
|
+
|
|
312
|
+
---
|
|
313
|
+
|
|
314
|
+
## Excepciones legítimas
|
|
315
|
+
|
|
316
|
+
NO aplica la regla cuando:
|
|
317
|
+
|
|
318
|
+
1. **El usuario dictó la cita explícitamente**: si el usuario escribe
|
|
319
|
+
"agrega que esto es por el Art. 23 RINEMAABMS", asume que el usuario
|
|
320
|
+
verificó. Pero si la cita parece dudosa, repregunta.
|
|
321
|
+
2. **La cita ya existe en el codebase verificado**: si encuentras "Art.
|
|
322
|
+
23 RINEMAABMS" ya escrito en un docstring del modelo, puedes
|
|
323
|
+
reutilizarlo en UI sin re-verificar la fuente externa (asumes que
|
|
324
|
+
alguien antes la verificó).
|
|
325
|
+
3. **Conceptos canónicos sin atribución específica**: "auditoría",
|
|
326
|
+
"expediente", "contratación" — no requieren cita.
|
|
327
|
+
4. **Citas de standards técnicos universalmente conocidos sin número**:
|
|
328
|
+
"OWASP", "WCAG" sin sub-versión. Si pones "WCAG 2.1 SC 1.4.3" sí
|
|
329
|
+
aplica la regla.
|
|
330
|
+
5. **Cita archivo:línea producida por TU MISMO en ESTE turno** sobre un
|
|
331
|
+
archivo que acabas de leer con `Read` en este mismo turno. La
|
|
332
|
+
evidencia es directa, no necesita re-verificación.
|
|
333
|
+
6. **Reporte ajeno que solo vas a leer / archivar / referenciar como
|
|
334
|
+
contexto histórico** sin tomar acción. La verificación se activa
|
|
335
|
+
cuando vas a priorizar, remediar, propagar o concluir a partir del
|
|
336
|
+
reporte.
|
|
337
|
+
|
|
338
|
+
---
|
|
339
|
+
|
|
340
|
+
## Familia 2 extendida — reportes COMPACTACION.md y status reports SWL
|
|
341
|
+
|
|
342
|
+
Los reportes generados por `/swl:compactar` (Delta vN en `.planning/COMPACTACION.md`),
|
|
343
|
+
`/swl:checkpoint` (continue-here.md), y similares **son también sub-productos
|
|
344
|
+
verificables**. El agente que los escribió puede sintetizar afirmaciones cuantitativas
|
|
345
|
+
sin re-verificar contra `git`/`pytest`/`grep`, y el agente que los lee después
|
|
346
|
+
hereda los errores si los acepta como base para decisiones.
|
|
347
|
+
|
|
348
|
+
### Cuándo aplica
|
|
349
|
+
|
|
350
|
+
OBLIGATORIO verificar antes de tomar acción sobre afirmaciones cuantitativas
|
|
351
|
+
extraídas de:
|
|
352
|
+
|
|
353
|
+
- `COMPACTACION.md` Delta vN (la última sección de cierre de sesión).
|
|
354
|
+
- `RESUMEN.md` de fase (conteos de archivos, commits, slices).
|
|
355
|
+
- `ESTADO.md` (DT activas, OP pendientes, fases completadas).
|
|
356
|
+
- `continue-here.md` (commits pendientes, archivos sin terminar).
|
|
357
|
+
- Reportes de auditoría con cifras agregadas ("N hallazgos críticos resueltos").
|
|
358
|
+
|
|
359
|
+
### Verificaciones rápidas obligatorias
|
|
360
|
+
|
|
361
|
+
Cuando un reporte declara una cifra accionable, ejecutar la primitiva equivalente
|
|
362
|
+
ANTES de basar decisiones en ella:
|
|
363
|
+
|
|
364
|
+
| Afirmación del reporte | Verificación |
|
|
365
|
+
|---|---|
|
|
366
|
+
| "N commits sin push" | `git log origin/main..HEAD --oneline \| wc -l` |
|
|
367
|
+
| "N archivos modificados" | `git diff --stat HEAD~M..HEAD \| tail -1` |
|
|
368
|
+
| "N DT activas" | `grep -cE "^### (DT\|DA\|OP)-" .planning/DEUDAS.md` (sección Activas) |
|
|
369
|
+
| "N tests verdes" | output reciente de `pytest --co -q` o último run de CI |
|
|
370
|
+
| "Fase N completada" | revisar `NN-CIERRE.md` y commits asociados, no solo el reporte |
|
|
371
|
+
| "Cobertura X%" | re-ejecutar `coverage report` si la cifra es relevante para decisión |
|
|
372
|
+
|
|
373
|
+
### Caso real (origen — sesión SIGM 2026-05-21)
|
|
374
|
+
|
|
375
|
+
El reporte v10 de COMPACTACION.md afirmó:
|
|
376
|
+
|
|
377
|
+
> "Trabajo pendiente mapeado: 11 commits acumulados sin push"
|
|
378
|
+
|
|
379
|
+
Verificación con `git log origin/main..HEAD --oneline | wc -l` retornó **2**.
|
|
380
|
+
Los otros 9 commits ya estaban en `origin/main`; el fetch falló por red pero la
|
|
381
|
+
referencia local seguía válida. Si el siguiente turno hubiera aceptado el dato
|
|
382
|
+
como cierto, habría "esperado créditos GH para pushear 11" sin necesidad.
|
|
383
|
+
|
|
384
|
+
Lección: el reporte de compactación es un artefacto de prosa con cifras — NO
|
|
385
|
+
es la fuente de verdad. La fuente es el filesystem + git + el output de las
|
|
386
|
+
herramientas. Tres segundos de `git log origin/main..HEAD` previenen propagación
|
|
387
|
+
de error.
|
|
388
|
+
|
|
389
|
+
### Anti-patrón específico
|
|
390
|
+
|
|
391
|
+
- **Aceptar el reporte v10 (o vN) tras `/compact` como base de decisiones**: el
|
|
392
|
+
reporte fue escrito por el agente al cerrar contexto, sin re-verificar. Tras
|
|
393
|
+
la compactación, el agente NUEVO lo lee con confianza por defecto y propaga
|
|
394
|
+
cualquier desalineación. Aplicar Familia 2: verificar 2-3 cifras críticas
|
|
395
|
+
del reporte contra git/pytest/grep antes de planificar la siguiente acción.
|
|
396
|
+
|
|
397
|
+
---
|
|
398
|
+
|
|
399
|
+
## Familia 2 extendida — comentarios temporales en código
|
|
400
|
+
|
|
401
|
+
(Absorbe la regla `verificar-citas-temporales.md`, unificada aquí el 2026-06-11
|
|
402
|
+
porque su propio texto se declaraba extensión de esta Familia 2.)
|
|
403
|
+
|
|
404
|
+
> Un comentario en código que afirma alineación con otro commit, versión o
|
|
405
|
+
> contrato (`// Alineado con commits X+Y`, `// Refactorizado a vN.M.0`,
|
|
406
|
+
> `# Sincronizado con backend`, `<!-- Coherente con schema X -->`) **NO es
|
|
407
|
+
> verificación** — es afirmación temporal sin prueba. Antes de actuar sobre el
|
|
408
|
+
> comentario como si fuera evidencia, verificar contra la fuente real con
|
|
409
|
+
> `grep` / `Read` / `git show`.
|
|
410
|
+
|
|
411
|
+
El comentario puede haberse desactualizado silenciosamente si el commit
|
|
412
|
+
referenciado se revirtió, nunca se aplicó, o el refactor citado cambió después.
|
|
413
|
+
|
|
414
|
+
**Cuándo aplica**: comentarios que afirman alineación cross-stack o con commits,
|
|
415
|
+
versiones, schemas. NO aplica a comentarios de intención, `TODO`/`FIXME` con
|
|
416
|
+
ticket, ni explicaciones del POR QUÉ.
|
|
417
|
+
|
|
418
|
+
**Cómo verificar**: identificar QUÉ se afirma alineado → `git show <SHA> --
|
|
419
|
+
<archivo>` o `grep` del campo clave en ambos stacks → comparar campo por campo.
|
|
420
|
+
Si hay drift, NO confiar en el comentario: actualizarlo o eliminarlo en el mismo
|
|
421
|
+
commit (un comentario stale es peor que ninguno).
|
|
422
|
+
|
|
423
|
+
**Alternativas seguras** al comentario temporal: test de contrato en CI (en vez
|
|
424
|
+
de `// Alineado con commits X+Y`), versión semántica + lock (en vez de
|
|
425
|
+
`// Refactorizado a vN`), tipos generados/codegen (en vez de `# Sincronizado con
|
|
426
|
+
backend`), validador en pre-commit (en vez de `<!-- Coherente con schema -->`).
|
|
427
|
+
Si el comentario es la única opción, incluir **fecha y SHA explícitos** y la
|
|
428
|
+
condición de re-verificación.
|
|
429
|
+
|
|
430
|
+
**Caso de origen** (SIGAF 2026-05-22): `contrato.models.ts:2` decía "Alineados
|
|
431
|
+
con el backend refactorizado (commits 284df74 + 5869ac9)" pero el backend nunca
|
|
432
|
+
aplicó ese refactor; Pydantic con `extra=ignore` descartaba 5 campos en
|
|
433
|
+
silencio y los contratos se crearon sin monto ni vigencia durante semanas. El
|
|
434
|
+
comentario funcionó como falso anclaje de confianza para los reviewers.
|
|
435
|
+
|
|
436
|
+
**Anti-patrones**: confiar en el comentario en code review sin `git show`;
|
|
437
|
+
propagarlo en refactors (viaja con el copy-paste hasta volverse falso); no
|
|
438
|
+
actualizarlo al revertir el commit citado; usarlo como "prueba" en debates
|
|
439
|
+
técnicos.
|
|
440
|
+
|
|
441
|
+
---
|
|
442
|
+
|
|
443
|
+
## Origen de esta regla
|
|
444
|
+
|
|
445
|
+
### Origen Familia 1 — citas normativas (versión inicial)
|
|
446
|
+
|
|
447
|
+
Sesión 2026-05-13, proyecto SIGAF. Durante implementación del refactor
|
|
448
|
+
ADR-076 F4 del form de Nuevo Expediente, agregué como fundamento del
|
|
449
|
+
catálogo "Clasificador por objeto y tipo de gasto para el INE" la cita
|
|
450
|
+
"Art. 23 RINEMAABMS · catálogo oficial PAAASINE-INE" sin haberla
|
|
451
|
+
verificado en ningún archivo del proyecto. Era plausible (RINEMAABMS
|
|
452
|
+
regula contratación INE; PAAASINE es el programa anual de adquisiciones)
|
|
453
|
+
pero ambas atribuciones eran falsas:
|
|
454
|
+
|
|
455
|
+
- El modelo `CatClasificadorGasto` y el seed `07_clasificador_gasto.sql`
|
|
456
|
+
no mencionan ningún artículo del RINEMAABMS.
|
|
457
|
+
- El seed cita textualmente "Documento oficial INE, actualización julio
|
|
458
|
+
2017, 71 páginas" como fuente — sin asociarlo a artículo legal.
|
|
459
|
+
- PAAASINE es un instrumento de planeación, no un catálogo de
|
|
460
|
+
clasificación. Conceptualmente distintos.
|
|
461
|
+
|
|
462
|
+
El usuario detectó la alucinación al verificar el SQL de referencia y
|
|
463
|
+
pidió analizarla. La regla se promueve a global porque el patrón puede
|
|
464
|
+
repetirse en cualquier proyecto del usuario que toque normas mexicanas o
|
|
465
|
+
estándares técnicos numerados — el sesgo de confabulación plausible no es
|
|
466
|
+
específico de SIGAF.
|
|
467
|
+
|
|
468
|
+
Commit donde se corrigió la alucinación original: `f2b025a` en SIGAF.
|
|
469
|
+
|
|
470
|
+
### Extensión Familia 2 — citas archivo:línea en reportes
|
|
471
|
+
|
|
472
|
+
Sesión 2026-05-16, proyecto SIGM. El usuario pidió analizar un reporte
|
|
473
|
+
de auditoría nemesis con 16 hallazgos (F-01 a F-16) más 3 hallazgos
|
|
474
|
+
heredados (H5.A1, H5.A2, H3.1), todos con citas `archivo:línea`
|
|
475
|
+
específicas (`auth/service.py:191-243`, `dependencies.py:73-78`,
|
|
476
|
+
`database/init/init.sh`, `catastro/repository.py:1260`, etc.).
|
|
477
|
+
|
|
478
|
+
Detecté que aceptar el reporte sin verificar habría sido propagación
|
|
479
|
+
de cita ajena. Apliqué el principio de la regla original adaptado al
|
|
480
|
+
dominio técnico: cada cita crítica priorizada (top 6) se verificó con
|
|
481
|
+
`Read` + `grep` contra el código real antes de re-emitir conclusiones.
|
|
482
|
+
|
|
483
|
+
Resultado: 6/6 hallazgos top verificados al 100%, con **evidencia
|
|
484
|
+
adicional** que el reporte no había detallado:
|
|
485
|
+
|
|
486
|
+
- F-04 lockout: además del backend que no escribe `intentos_fallidos`,
|
|
487
|
+
el schema declara `CHECK (intentos_fallidos >= 0 AND intentos_fallidos
|
|
488
|
+
<= 10)` — el tope de 10 es invariante de la BD, doble confirmación.
|
|
489
|
+
- Regresión `u.nombre_completo`: el reporte citó 2 sitios; la
|
|
490
|
+
verificación con `grep -n "u.nombre_completo"` reveló que **podían
|
|
491
|
+
haber más** y el reporte no había hecho sweep global.
|
|
492
|
+
|
|
493
|
+
Esa última observación se promueve a sub-regla operativa (Paso 4
|
|
494
|
+
del protocolo archivo:línea: detectar gaps del reporte con sweep por
|
|
495
|
+
patrón).
|
|
496
|
+
|
|
497
|
+
La adaptación se fusiona en esta regla en lugar de crear una nueva
|
|
498
|
+
porque el principio es idéntico — solo cambia el dominio de la cita
|
|
499
|
+
(normativa vs. archivo:línea). Mantener una sola regla evita
|
|
500
|
+
duplicación operativa y refuerza que el origen del riesgo es siempre el
|
|
501
|
+
mismo: una afirmación con apariencia de evidencia que en realidad no
|
|
502
|
+
se verificó.
|
|
503
|
+
|
|
504
|
+
### Extensión Familia 2 — reportes COMPACTACION.md (2026-05-21)
|
|
505
|
+
|
|
506
|
+
Sesión SIGM 2026-05-21. Tras `/swl:compactar` v10, el reporte declaró
|
|
507
|
+
"11 commits acumulados sin push". Verificación con
|
|
508
|
+
`git log origin/main..HEAD --oneline | wc -l` retornó **2**. El reporte se
|
|
509
|
+
escribió desde la perspectiva del agente al cerrar contexto, sin re-verificar
|
|
510
|
+
contra `origin/main` (que sigue local actualizada incluso con `git fetch`
|
|
511
|
+
fallando por red).
|
|
512
|
+
|
|
513
|
+
La adaptación se incorpora como sub-sección "Familia 2 extendida — reportes
|
|
514
|
+
COMPACTACION.md y status reports SWL" arriba, no como Familia 3 separada. El
|
|
515
|
+
principio es el mismo: afirmación cuantitativa en un reporte = sub-producto
|
|
516
|
+
verificable. Cambia el dominio (compactación SWL vs. nemesis auditorías), no
|
|
517
|
+
el protocolo.
|
|
518
|
+
|
|
519
|
+
Lección operativa: las 3 cifras que más se desalinean tras un `/compact` son
|
|
520
|
+
"commits sin push" (depende de fetch reciente), "DT activas" (depende del
|
|
521
|
+
último Edit de DEUDAS.md vs lo que la prosa del reporte describe) y "tests
|
|
522
|
+
verdes" (depende del último run de CI vs lo que el agente recuerda). Verificar
|
|
523
|
+
esas 3 antes de decidir siguiente acción.
|
|
524
|
+
|
|
525
|
+
---
|
|
526
|
+
|
|
527
|
+
## Checklist antes de escribir una cita verificable (Familia 1)
|
|
528
|
+
|
|
529
|
+
- [ ] ¿La cita tiene un número, artículo, fracción o referencia
|
|
530
|
+
específica?
|
|
531
|
+
- [ ] ¿Ejecuté `grep` o `Read` sobre la fuente real del proyecto?
|
|
532
|
+
- [ ] ¿La fuente respalda textualmente la cita?
|
|
533
|
+
- [ ] Si no respalda: ¿sustituí por descripción neutra o eliminé la cita?
|
|
534
|
+
- [ ] Si no encontré fuente y el usuario no la dictó: ¿pregunté al
|
|
535
|
+
usuario por la cita exacta antes de inventarla?
|
|
536
|
+
|
|
537
|
+
## Checklist antes de aceptar o re-emitir una cita archivo:línea (Familia 2)
|
|
538
|
+
|
|
539
|
+
- [ ] ¿Identifiqué cuáles citas del reporte son críticas accionables vs.
|
|
540
|
+
contextuales?
|
|
541
|
+
- [ ] ¿Hice `Read` sobre cada cita crítica priorizada (top 4-6)?
|
|
542
|
+
- [ ] ¿El archivo:línea citado dice textualmente lo que el reporte afirma?
|
|
543
|
+
- [ ] ¿Hice sweep por patrón (`grep -rn`) para detectar hermanos del bug
|
|
544
|
+
que el reporte no listó?
|
|
545
|
+
- [ ] ¿Verifiqué evidencia complementaria (schema, ADRs, commits citados)
|
|
546
|
+
antes de aceptar el hallazgo?
|
|
547
|
+
- [ ] Al re-emitir conclusiones: ¿marqué explícitamente qué citas
|
|
548
|
+
verifiqué vs. cuáles reproduzco sin verificar?
|
package/scripts/instalador.js
CHANGED
|
@@ -101,17 +101,24 @@ async function install(opciones) {
|
|
|
101
101
|
// 1. opciones.profile — flag explícito del usuario (también acepta --perfil)
|
|
102
102
|
// 2. manifest.profile — declarado en .swl-ses del proyecto
|
|
103
103
|
// 3. install-state existente en el destino — preserva el perfil ya instalado
|
|
104
|
-
// 4. '
|
|
104
|
+
// 4. 'completo' — default final
|
|
105
105
|
//
|
|
106
106
|
// Antes del fix v1.3.5, `install --force` sin --profile defaulteaba directamente
|
|
107
|
-
//
|
|
107
|
+
// al default aunque ya existiera una instalación con perfil distinto. El usuario
|
|
108
108
|
// perdía silenciosamente componentes y el update subsiguiente reproducía el
|
|
109
109
|
// estado contaminado (los archivos del completo quedaban con contenido viejo).
|
|
110
110
|
//
|
|
111
|
+
// El default final es 'completo' (cambiado desde 'core'): una instalación sin
|
|
112
|
+
// --profile entrega el sistema entero (todos los agentes, skills y comandos).
|
|
113
|
+
// Razón: un `install --target=... --with-mcp --global --force` sin --perfil
|
|
114
|
+
// parecía una instalación completa pero entregaba el perfil mínimo, dejando al
|
|
115
|
+
// usuario sin la mayoría de comandos /swl:* (caso reportado 2026-06-12). Para
|
|
116
|
+
// instalar solo el núcleo, pasar --perfil core explícito.
|
|
117
|
+
//
|
|
111
118
|
// La detección del install-state aquí es deliberadamente best-effort: si no
|
|
112
|
-
// existe o no se puede leer, caemos al default '
|
|
119
|
+
// existe o no se puede leer, caemos al default 'completo'. Solo aplica para
|
|
113
120
|
// `install --force` (reinstalación); en una primera instalación no hay state
|
|
114
|
-
// todavía y
|
|
121
|
+
// todavía y el sistema completo es el default razonable.
|
|
115
122
|
let perfilDeState = null;
|
|
116
123
|
if (!opciones.profile && !(manifest && manifest.profile)) {
|
|
117
124
|
try {
|
|
@@ -131,7 +138,7 @@ async function install(opciones) {
|
|
|
131
138
|
const perfil = opciones.profile
|
|
132
139
|
|| (manifest && manifest.profile)
|
|
133
140
|
|| perfilDeState
|
|
134
|
-
|| '
|
|
141
|
+
|| 'completo';
|
|
135
142
|
|
|
136
143
|
console.log(`swl-ses install v${VERSION}`);
|
|
137
144
|
console.log(`${'='.repeat(40)}`);
|
|
@@ -247,7 +254,7 @@ async function install(opciones) {
|
|
|
247
254
|
if (allLangs && !tieneReglasLenguaje && !esGlobal) {
|
|
248
255
|
console.log(
|
|
249
256
|
'\n[stack] Aviso: --all-langs ignorado — el perfil actual (' +
|
|
250
|
-
(resolucion.perfil || '
|
|
257
|
+
(resolucion.perfil || 'completo') +
|
|
251
258
|
') no incluye reglas de lenguajes. ' +
|
|
252
259
|
'Usa --perfil completo o --perfil polyglot para activar las reglas por lenguaje.'
|
|
253
260
|
);
|
|
@@ -644,6 +651,45 @@ async function install(opciones) {
|
|
|
644
651
|
}
|
|
645
652
|
}
|
|
646
653
|
|
|
654
|
+
// Copiar fragmentos compartidos (agentes/_*.md) — NO van en modulos.json
|
|
655
|
+
// (no son agentes routables) pero los agentes que los importan vía
|
|
656
|
+
// `fragmentos:` los leen al cargarse. El loader los espera en el dir de
|
|
657
|
+
// agentes del destino. Se copian raw (sin transformar: no tienen frontmatter).
|
|
658
|
+
// Cierra DT-FRAGMENTOS-DISTRIBUCION (Fase 13).
|
|
659
|
+
if (
|
|
660
|
+
runtime.tiposSoportados &&
|
|
661
|
+
runtime.tiposSoportados.includes('agentes') &&
|
|
662
|
+
rutas.agentes &&
|
|
663
|
+
resolucion.archivos.some(a => a.tipo === 'agentes')
|
|
664
|
+
) {
|
|
665
|
+
const fragmentosOrigen = path.join(RAIZ_PKG, 'agentes');
|
|
666
|
+
try {
|
|
667
|
+
const fragmentos = fs.existsSync(fragmentosOrigen)
|
|
668
|
+
? fs.readdirSync(fragmentosOrigen).filter(f => f.startsWith('_') && f.endsWith('.md'))
|
|
669
|
+
: [];
|
|
670
|
+
if (fragmentos.length > 0 && !fs.existsSync(rutas.agentes)) {
|
|
671
|
+
fs.mkdirSync(rutas.agentes, { recursive: true });
|
|
672
|
+
}
|
|
673
|
+
let fragmentosCopiados = 0;
|
|
674
|
+
for (const frag of fragmentos) {
|
|
675
|
+
const destino = path.join(rutas.agentes, frag);
|
|
676
|
+
fs.copyFileSync(path.join(fragmentosOrigen, frag), destino);
|
|
677
|
+
registrarArchivo(estado, {
|
|
678
|
+
origen: `agentes/${frag}`,
|
|
679
|
+
destino,
|
|
680
|
+
tipo: 'fragmentos', // distinto de 'agentes' → no infla el conteo del doctor
|
|
681
|
+
});
|
|
682
|
+
fragmentosCopiados++;
|
|
683
|
+
}
|
|
684
|
+
if (fragmentosCopiados > 0) {
|
|
685
|
+
console.log(` + Fragmentos compartidos: ${fragmentosCopiados} (agentes/_*.md)`);
|
|
686
|
+
}
|
|
687
|
+
} catch (err) {
|
|
688
|
+
console.error(` ! Error copiando fragmentos: ${err.message}`);
|
|
689
|
+
errores++;
|
|
690
|
+
}
|
|
691
|
+
}
|
|
692
|
+
|
|
647
693
|
// Instalar userland (prioridad sobre core)
|
|
648
694
|
for (const archivo of archivosUserland) {
|
|
649
695
|
try {
|