El Método ya viajaba completo a este repo desde el cutover del 2026-08-19, pero
se midió que en 9 de 18 repos NADA lo enrutaba: la copia llegaba y no la abría
nadie. Es el raíl §8 aplicado al propio Método — un fallo benigno solo protege
si alguien LEE la línea; una constitución solo gobierna si alguien la ABRE.
El puntero va a CLAUDE.md porque es el único fichero que el harness carga solo
en toda sesión sobre el repo; cualquier otro destino reproduce la enfermedad.
Bloque GESTIONADO entre marcadores (<!-- metodo:puntero -->): `metodo update`
sustituye sólo su interior y no toca un byte fuera — probado con diff contra
git en los dos CLAUDE.md ricos, e idempotente (3 updates, mismo md5).
Y su gate: `metodo check` gana `check_pointer` — el bloque existe y su destino
resuelve. Probado EN ROJO en los tres estados (sin CLAUDE.md, sin bloque,
destino inexistente) y con el código de salida moviéndose, que es lo que
separa un gate de un aviso que nadie lee.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La fuente del Método pasa del árbol de trabajo a la matriz (repo `metodo`).
Esta copia deja de llevar los 10 raíles base EN UNA LÍNEA con un puntero a
`redes/workflows/metodo.md` — nombre viejo, ruta que en un clon ajeno no existe.
Ahora los raíles viajan COMPLETOS, con sus cicatrices, más el §0 «si no escala
no vale para nada» y el raíl de §8 del 2026-08-19 («un fallo benigno solo
protege si alguien LEE la línea»). Las 6 adiciones que estaban «pendientes de
inlinar» viven ya dentro de su raíl.
Estampado con `metodo update`: byte a byte idéntico al máster.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Estampada por 'metodo init' el 2026-08-12 (master 2026-08-08); sin commit no viaja al clonar (D1).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
El README describia un flujo que no existe: ./build.sh con Kaniko y un workflow de
Gitea Actions. Kaniko y Gitea Actions se estan retirando, y ademas este workflow
llevaba roto desde mayo -- era el unico del arbol que usaba actions/checkout@v4,
que necesita node, y el runner :host no lo tiene. Fallaba en 70 s en cada push sin
que nadie lo mirara: la imagen que sostuvo el correo 70 dias era del 20 de mayo.
Un CI que falla siempre y en silencio es peor que no tener CI, asi que se borra en
vez de dejarlo de adorno.
Se documenta el build con mcp-build (con el gotcha del image_name sin host, que
duplica el registro y muere con 401) y, sobre todo, POR QUE cada linea de la config
es la que es. Las cuatro que no se pueden tocar sin reabrir el incidente llevan su
sintoma exacto al lado, para que el siguiente que las vea raras sepa lo que cuesta
"limpiarlas": tlsmgr, el grupo sasl, el realm desde RELAY_AUTH_DOMAIN y chroot=n.
Y queda escrito como se prueba un cambio de esta imagen ANTES de desplegarlo, que
aqui no es opcional: desplegar es reiniciar el unico pod que sostiene el correo, y
si falla no hay alerta que lo diga porque la alerta ES el correo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El correo saliente de manabo.org lo sostenian cuatro cambios aplicados con
postconf/adduser sobre el contenedor vivo. Llevaban 70 dias fuera de git: el
primer rollout restart, reschedule o actualizacion del Image Updater los borraba
y el relay volvia a quedar mudo -- sin aviso posible, porque la alerta ES el
correo.
La lista no se copio del README: se midio. Se arranco un contenedor de la imagen
que corre hoy (digest 38ebbe1d) y se diffeo su postconf -n/-M contra el pod vivo.
Son SEIS cambios, no cuatro:
master.cf falta el daemon tlsmgr -> smtpd ANUNCIA STARTTLS en el EHLO y luego
no puede hacerlo: 454 4.7.0 TLS not available due to local problem
master.cf falta postlog/postlogd -> Postfix escribe a syslog, aqui no hay
ninguno y kubectl logs sale VACIO (el incidente se diagnostico a
ciegas)
master.cf chroot y->n en los 20 servicios
main.cf falta maillog_file = /var/log/postfix.log
main.cf smtpd_sasl_local_domain: $myhostname -> el dominio real
Dockerfile postfix no estaba en el grupo sasl -> /etc/sasldb2 es root:sasl 0640
y smtpd no puede abrirlo: 454 Temporary authentication failure
Dos matices sobre lo que estaba anotado:
El chroot no se "pobla desde el build", se DESACTIVA. En el pod vivo
/var/spool/postfix/etc sigue vacio con fecha Mar 6 2024: nadie lo poblo nunca.
Poblarlo habria metido un mecanismo jamas ejercitado y dejado fuera el que
sostiene el correo. En un contenedor el chroot no aporta nada: el contenedor ES
el jail.
El realm no se fija a pelo en main.cf sino desde RELAY_AUTH_DOMAIN en el
entrypoint, que es la misma variable con la que saslpasswd2 crea la entrada del
sasldb. Declarados aparte pudieron divergir en silencio, y eso es exactamente lo
que causo el fallo de autenticacion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Manual chmod 1730 on maildrop caused postsuper scan_dir_push failures
because the group (postdrop) lacked read permission. Let Postfix set
the exact permissions it expects via set-permissions.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Move build.sh to scripts/build.sh (convention from project-template)
- Add .gitea/workflows/build.yml: triggers on push to main when
Dockerfile or config files change, builds :dev tag via Kaniko
- Every push → CI builds harbor.manabo.org/library/smtp-relay:dev
→ ArgoCD Image Updater detects new digest → deploys to hermes
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Postfix relay image with Cyrus SASL (sasldb2) authentication.
Replaces mwader/postfix-relay with a controlled image built via Kaniko and
stored in Harbor. Credentials injected from Vault ExternalSecret at startup.
