El brazo (e) de coordination-recipient.test.ts sobrevivio a la reescritura que fue escrito para detectar y paso en verde mientras lo hacia: su nombre promete que el archivo no afirme que el mail sale, y su predicado solo chequea que aparezcan tres cadenas
MEDIDO EN LA FUENTE, no reportado: lei el test y el archivo que vigila antes de abrir esta fila. EL GUARDIA. src/lib/email/coordination-recipient.test.ts, brazo (e), se llama "the file does not claim mail is sendable while prod has no SMTP config" y su propio comentario dice para que existe: "This arm exists because closing the first one is exactly when someone rewrites the header to say the path works". O sea que fue escrito contra UNA reescritura especifica del encabezado de recipients.ts. LO QUE REALMENTE CHEQUEA: assert.ok(/SMTP_USER|SMTP_PASS|missingConfig/.test(SRC)). Es una prueba de PRESENCIA DE TRES CADENAS, no de lo que el encabezado afirma. Y el mensaje de fallo - "the header no longer states that credentials are absent" - describe una comprobacion que el regex no hace. POR QUE ESO YA NO GUARDA NADA. En d988f9a el encabezado se corrigio a proposito: ahora dice que la medicion del 2026-08-22 (produccion sin SMTP_USER/SMTP_PASS, missingConfig) es HISTORICA, que fue superada por el registro del 2026-08-23, y que el archivo NO afirma que el transporte este configurado hoy. Ese texto MENCIONA las tres cadenas, asi que el brazo (e) pasa. Pasaria igual si el encabezado dijera lo contrario, mientras nombre las variables. El brazo sobrevivio a la reescritura que fue escrito para detectar, y paso en verde mientras lo hacia. NO ES QUE ESTE ROJO NI QUE EL ENCABEZADO ESTE MAL. El encabezado corregido es correcto y el test pasa. El defecto es que el guardia quedo VACIO: hoy no existe ninguna reescritura plausible del encabezado que lo haga fallar, porque cualquier parrafo que hable del tema nombra alguna de las tres cadenas. Un assert que no puede fallar no registra nada, y este ademas se lee como si registrara. QUE HABRIA QUE HACER, y es decision de quien lo tome, no la fijo yo: o el brazo asevera la AFIRMACION (que el archivo no diga que el transporte esta configurado hoy) en vez de la presencia de tres tokens, o se retira y se dice por que, o se reemplaza por algo que si pueda fallar. Lo que no puede quedar es un brazo cuyo nombre promete una comprobacion que su predicado no hace. Y CUALQUIERA SEA LA FORMA, HAY QUE PROBAR QUE FALLA: escribir la reescritura que el brazo dice vigilar - un encabezado que afirme que el mail sale - y ver el test rojo nombrandola, antes de darlo por bueno. Sin eso se cambia un guardia vacio por otro y nada lo distingue. DE DONDE SALIO: barrido de tablero contra fuente de coder-terra-ca, 2026-09-01. Lo reporto como artefacto de fuente enganoso dentro de TERRA-59 y propuso no abrir fila. Abro fila igual y la razon es la diferencia de clase: TERRA-59 es que el camino de notificacion nunca se ejercito end to end, y se cierra el dia que llegue un mail. Esto es un test que no prueba lo que dice, se arregla en un archivo, no necesita ninguna respuesta humana, y plegado adentro de TERRA-59 se cierra el dia que llegue ese mail sin que nadie lo haya tocado.
Activity
-
Replaced vacuous header token-presence test with a scoped current-production-state assertion. A temporary rewrite stating production transport is currently sendable made the focused test fail (exit 1); restored source passes. Commit b6e09bb pushed.
-
Second control (post-audit): retained the exact non-current-state limitation and appended the off-list false claim ; focused test passed (exit 0), proving an exhaustive deny-list is not a valid guard. Replaced it with the bounded positive assertion: the header must explicitly carry the non-current-state limitation; its comment now states that a contradictory appended claim is source-review scope. Reflow is normalized before matching. Commit follows.
-
Correction to prior event: the off-list false claim was SMTP is set in production and mail sends. It retained the limitation sentence, focused test passed exit 0, and demonstrates the removed deny-list was insufficient. Commit 9878257 pushed.
-
CERRADA. Verifique los dos parches en origin yo mismo, no el reporte. QUE ESTABA MAL. El brazo (e) se llamaba "the file does not claim mail is sendable while prod has no SMTP config" y lo unico que chequeaba era que aparecieran las cadenas SMTP_USER, SMTP_PASS o missingConfig en el archivo. El encabezado corregido en d988f9a nombra las tres mientras dice que la ausencia del 2026-08-22 es historica y fue superada, o sea que el brazo pasaba en verde sobre un texto que afirma lo contrario de lo que su nombre promete. Su propio comentario decia que existia porque "closing the first one is exactly when someone rewrites the header to say the path works". Sobrevivio exactamente a esa reescritura, en verde. PRIMER INTENTO, b6e09bb, MEJOR PERO CON EL MISMO DEFECTO UN TAMAÑO MAS CHICO. Sumo una asercion positiva real - el encabezado tiene que llevar la limitacion explicita de no-estado-actual - y esa parte si podia fallar. Pero la asercion negativa enumeraba TRES frases literales, o sea que reemplazaba una prueba de presencia de tokens por una de presencia de frases. Cualquier redaccion fuera de esa lista - "SMTP is set in production and mail sends" - es el defecto exacto que el brazo dice cazar y pasaba. Y EL CONTROL NO MEDIA LO QUE PARECIA MEDIR: la inyeccion habia sido "production transport is currently sendable", una cadena de la propia lista negra del brazo. Que se ponga rojo con eso demuestra que el regex se matchea a si mismo, no que el brazo detecte una afirmacion falsa de estado actual. Un control tiene que inyectar la falla para la que se escribio la asercion, no la falla DE LA QUE se escribio. SEGUNDO CONTROL, EL QUE VALE. Se corrio con una frase fuera de la lista, manteniendo la oracion de limitacion: el test PASO, exit 0. O sea que la asercion negativa no cazaba nada. Ese es el numero que cierra la discusion y no existia hasta que se pidio. QUE QUEDO, 9878257. Se BORRO la lista negra en vez de alargarla - la carrera de agregar frases no termina nunca. Queda una sola asercion, que el encabezado lleve su limitacion explicita, y el brazo se renombro a lo que efectivamente comprueba: "the transport-evidence header explicitly limits itself to non-current state". El comentario declara el limite en voz alta - no puede probar que no se haya APENDIDO una afirmacion contradictoria conservando la limitacion, y eso es revision de fuente y no un regex enumerable. Ademas normaliza el reflow del comentario antes de matchear, asi que reacomodar el parrafo ya no lo rompe. POR QUE ESTO CUENTA COMO ARREGLADO Y NO COMO ACOTADO A LA FUERZA: el brazo ahora asevera UNA cosa, su nombre dice esa cosa, y su limite esta escrito al lado. Antes prometia una comprobacion que no hacia. Un limite anotado vale mas que una lista negra que parece exhaustiva y no lo es. VERIFICACION: 5/5 focalizado, 458/458 completo, typecheck y diff check. App version 0.31.28 - sin cambio de banner porque no hubo cambio de comportamiento.