"Lo primero que el polish Charter intentó — bootear ./sentinel desde main para correr el smoke de §5 — falló con dos panics distintos."

Así abrió el Issue #199 el 22 de mayo, presentado por el adopter Sentinel como RFC. Para cuando el thread cerró cinco actualizaciones de comentario después, la cuenta había crecido de dos a diez. El polish Charter — el Charter de cierre de Etapa 2, planeado como un docket de auditorías WCAG y verificación del quickstart — había pasado seis horas haciendo otra cosa: cazando una clase de regresión latente que ninguna de las suites de tests per-Charter de los ocho Charters previos había cazado, y que ninguna de ellas podía haber cazado dado cómo estaban escritas.

Este post es la reconstrucción de por qué ocurrió, qué forma recurrente terminó habiendo debajo, y la decisión deliberada en el PR #200 de nombrar el anti-patrón pero todavía no fabricar tooling para él. El ciclo le es familiar a quien siguió los posts previos sobre observación emergente y evolución de cadenas — este es el tercer patrón en dos semanas que cristaliza vía el mismo arco: aflorar en N=1, nombrar el meta, diferir el tooling cross-proyecto hasta que N=2 lo valide.

Los dos casos que pesaron​

De los diez gaps que la sesión de polish afloró, ocho eran o bien deterioro ambiental de dependencias (un upgrade de huma introdujo un panic en parámetros *string; Go 1.22 endureció la semántica de wildcards de http.ServeMux) o bien drift del runbook (env vars faltantes en §boot, recetas de smoke que mezclaban modos mutuamente excluyentes, afirmaciones sobre el stdout de un fake provider que el fake nunca escribió). Cada uno merece un fix. Ninguno reescribe el manual.

Los dos que sí reescribieron el manual son distintos. Comparten forma.

US3 Preference Center, shippeado el 12 de mayo. Cuando los recipients de un correo enviado por Sentinel hacen click en el link tipo unsubscribe del footer, aterrizan en una URL JWT-in-path como /preferences/<token>. El handler es público-por-contrato a propósito: el JWT es la auth; no se espera un header Authorization. El doc-comment del handler lo decía. El test de integración, escrito en humatest, montaba el handler directamente a través del adapter de testing y confirmaba: dado un JWT válido en el path, el handler devuelve el HTML correcto. CI pasó. La feature se shipeó a main.

Lo que nunca pasó: nada que ejerciera la cadena de middleware de producción enfrente de ese handler. internal/core/middleware/auth.go tiene una lista publicPrefixes de prefijos de ruta que evaden el check de Authorization. /preferences/ no estaba en ella. Durante diez días, cada recipient que hizo click en un link de unsubscribe recibió un 401 missing authorization header del middleware antes de que el request alcanzara nunca al handler que sabía que no debía esperarlo. El Preference Center era alcanzable en tests, inalcanzable en producción.

Instrumentos de observabilidad OTel del pipeline de envío, shippeados la misma semana. Ocho metric instruments — counters, histograms, gauges — declarados en internal/core/metrics/commshub.go, registrados con el meter de OpenTelemetry al boot. El Constitution Check §IV del Charter declaró formalmente satisfecha la compuerta de observabilidad FR-039..042: la capa de API era correcta, los registros pasaban, los dashboards estaban planeados. Siete de esos ocho instrumentos tenían cero call sites de .Add() / .Record() en todo el módulo commshub. Declarados, registrados, nunca invocados. Los dashboards que ops construyó encima de esas series llevaban diez días recibiendo cero datos. El smoke manual del polish Charter — bootear un OTel Collector, generar unos cuantos sends, grep del output del collector buscando los nombres FR-039..042 — afloró esto al instante.

Ninguno de los dos casos es exótico. Ninguno es un bug duro. Ambos son instancias del mismo error mecánico: un artefacto se declaró en un lugar, y la implementación que se suponía que lo cableara vivía en otro lugar, y nada en el codebase ni en CI correlacionaba los dos.

El nombre que el anti-patrón pedía​

Un nombre importa cuando la misma forma aparece suficientes veces como para merecer uno. Para la tercera actualización del comentario en #199, el autor de Sentinel había contado cuatro subclases del mismo error subyacente:

El unificador — el one-liner con el que abre el nuevo doc de gobernanza — es:

Cada artefacto de superficie declarado tiene al menos un sitio de cableado alcanzable desde un request real.

El nombre del anti-patrón, que aterriza canónicamente en dist/.straymark/00-governance/POLISH-CHARTER-PATTERN.md, es Declaración de superficie sin cableado. Ese es el deliverable. El polish Charter es el vehículo de descubrimiento, no la tesis.

Por qué los tests de integración omiten esto sistemáticamente​

Esta parte vale la pena trabajarla porque le da forma al resto del post. El modo de falla común a las cuatro subclases es que el harness estándar de tests de integración — humatest.NewTestAdapter en Go, el equivalente en TypeScript, Python, Rust — monta los handlers directamente vía la API de testing. El handler bajo prueba está correctamente cableado por el fixture. El paso de composición de producción — donde el registro de rutas se encuentra con la cadena de middleware se encuentra con el inventario de env vars se encuentra con la tabla de assets embebidos — es lo que está roto. La luz verde de CI es genuina respecto a lo que afirma: el handler devuelve la respuesta correcta dado el request correcto. No dice nada sobre si el request puede alcanzar el handler en producción, o sobre si el artefacto del que el handler depende fue alguna vez cableado al runtime.

Hay una tentación de leer esto como una crítica a humatest. No lo es. humatest (y sus equivalentes) está haciendo exactamente lo que fue diseñado para hacer: dejar que pruebes la lógica del handler en aislamiento, rápido, sin parar todo el árbol de composición. Ese aislamiento es una feature. El costo del aislamiento es lo que acabamos de nombrar — y el costo solo se vuelve visible cuando algo fuera del aislamiento aflora una divergencia. El polish Charter es el método más barato para aflorar esa divergencia, porque hace lo que ningún fixture de test hace: bootea el binario real y corre la receta operativa documentada real contra él.

Esta es la afirmación load-bearing del nuevo pattern doc. No que los polish Charters sean valiosos por razones cosméticas. Que son el único lugar donde la composición de producción se ejerce end-to-end contra una especificación externamente legible (el runbook operativo). Si tratas el polish Charter como limpieza cosmética, también tratas esa capacidad de aflorar como cosmética. Los datos de Sentinel argumentan lo opuesto.

La decisión: B′, no B​

El RFC proponía tres opciones. La decisión en el PR #200 fue ninguna de ellas tal como estaban formuladas — llamémosla B′. Vale la pena decir por qué, porque la decisión estructural pesa más de lo que parece.

La Option B del RFC pedía un pattern doc bajo docs/patterns/. Ese directorio no existe en StrayMark hoy, y crearlo habría partido la convención de documentación del proyecto. Los patterns empíricos que ya viven en el canon — FOLLOW-UPS-BACKLOG-PATTERN.md, CHARTER-CHAIN-EVOLUTION.md, EMERGENT-OBSERVATION-DESIGN.md, SPECKIT-CHARTER-BRIDGE.md — todos viven en dist/.straymark/00-governance/. Comparten una infraestructura de mirror i18n (cada doc de gobernanza tiene hermanos en inglés, español y chino simplificado). Agregar una tercera superficie de documentación habría multiplicado el overhead de i18n y desparramado los patterns del proyecto entre dos hogares. Mantener el nuevo doc dentro de 00-governance/ reusaba la infraestructura existente con costo marginal cero.

La Option C del RFC pedía un helper CLI straymark charter polish-checklist o straymark analyze declared-vs-wired. El autor de Sentinel ya había prototipado uno (CHARTERs 25/26/27, los tres guards preparatorios de CI) y ofrecido sembrarlo upstream. La decisión aquí fue conservadora: diferir. No porque el prototipo no sea valioso — lo es — sino porque Sentinel es N=1. Las cuatro subclases fueron las que un adopter, un stack afloró. La quinta, sexta y séptima subclase que el framework tendría que anticipar para shippear un CLI cross-proyecto útil aún no existen, porque ningún segundo adopter las ha empujado. Ya hemos recorrido este camino. FOLLOW-UPS-BACKLOG-PATTERN.md shippeó como v0 en fw-4.10.0 y vive ahí desde hace mes y medio, esperando que un segundo adopter lo valide antes de graduarse a un subcomando straymark followups. La misma compuerta aplica aquí. Las ## Open questions del nuevo doc lo dicen explícitamente: "Cristalización como subcomando CLI straymark analyze declared-vs-wired … Gate: N=2 adopters."

B′ es lo que aterrizó. Un nuevo governance pattern doc en la ubicación canónica, en tres idiomas. Un séptimo bullet de Format conventions en el template de Charter apuntando a los autores hacia él cuando cierran una Etapa o Fase Polish de SpecKit. Una fila en la tabla ## Patterns del QUICK-REFERENCE. Un bump fw-4.18.0 con la cascada de footers a través de unos treinta docs. Ningún subcomando CLI. Ningún nuevo campo de frontmatter. Ningún cambio de schema. El anti-patrón tiene un nombre; el ritual de descubrimiento tiene un doc; el tooling espera.

El arco que se repite​

Hace tres semanas, el patrón de backlog de follow-ups cristalizó vía el mismo arco: un adopter afloró una necesidad, el patrón se nombró en v0, el helper CLI se difirió. Hace dos semanas, los patrones de evolución de cadena cristalizaron: Pattern 1 (pre-declare SpecKit refresh) y Pattern 2 (post-close audit-driven Batch N.4), aflorados desde el mismo adopter Sentinel, nombrados en fw-4.16.0, con straymark charter refresh-suggest como helper blando en vez de gate duro. Hace una semana, el meta — EMERGENT-OBSERVATION-DESIGN.md — codificó qué hacía posibles esas observaciones de entrada: cross-referencing formal más permiso cultural. Esta semana, este patrón.

Son cuatro cristalizaciones en un mes, todas desde el mismo adopter, todas siguiendo la misma forma: aflorar en N=1 → nombrar el meta → fabricar tooling solo después de N=2. La tentación cuando un patrón aflora vívidamente — y diez gaps de producción en seis horas es vívido — es saltearse el nombre e ir directo al tooling. La disciplina es lo opuesto. El nombre hace la mayor parte del trabajo. El tooling, cuando llega, está parametrizado por lo que al menos dos adopters han aflorado; construido sobre N=1, es una extrapolación de un stack y los modos de falla de un equipo, y tiende a osificar esas elecciones como defaults del framework que no generalizan.

Hay una pieza de esta iteración que sí es genuinamente nueva y vale la pena destacar. El nuevo pattern doc nombra una predicción falsable que el autor de Sentinel ya se comprometió a publicar: el polish Charter de la próxima Etapa, ejecutado contra los tres guards preparatorios de CI que acaban de aterrizar en CHARTERs 25/26/27 de Sentinel, debería aflorar aproximadamente 80% menos gaps. Si esa predicción se sostiene, el caso para graduar la Option C de "open question" a "subcomando CLI" obtiene respaldo cuantitativo. Si falla — si el siguiente polish Charter sigue aflorando diez gaps pero en una quinta subclase no anticipada — la falla en sí misma es el siguiente data point, y reescribe el spec antes de fabricar tooling. Cualquiera de los dos resultados es útil. Ninguno se ha observado aún. Esperamos.

Una nota sobre lo que deliberadamente no se hizo​

No hay campo phase: polish en el frontmatter de Charter. No hay straymark charter polish-checklist <ID>. No hay analyzer automatizado escaneando código Go (ni de ningún otro lenguaje) por símbolos declarados-pero-no-cableados. El pattern doc lista cada una de esas como candidata de evolución, gated explícitamente en N=2 o en el retrospectivo post-Etapa-3. Ninguna está presente en fw-4.18.0.

Esto es intencional y vale la pena decirlo en voz alta, porque la reacción natural ante un hallazgo vívido es sobre-construir la respuesta. Cada una de esas postergaciones intercambia exhaustividad de corto plazo por portabilidad de largo plazo. Un campo de frontmatter compromete al framework con un vocabulario que el próximo adopter puede no compartir. Un helper CLI compromete al framework con un runtime que refleja los modos de falla de un stack específico. Un analyzer compromete al framework con escanear un lenguaje cuyas convenciones pueden divergir de las del próximo adopter. Ninguno de esos compromisos debería hacerse con la señal de un solo dominio, por más limpia que sea la señal. El pattern doc en sí mismo puede revisarse; un subcomando CLI no puede desshipearse sin romper a los adopters.

Qué te sugeriría mirar, si llegaste hasta acá​

Si operás un codebase con tests de integración basados en mock adapter — que es la mayoría de los codebases — podés correr un ejercicio interno útil sin adoptar nada de StrayMark. Elegí la feature más reciente que tu equipo shipeó que tenga tanto (a) una declaración del lado de docs (env vars, specs OpenAPI, HTML embebido, metric instruments) como (b) un sitio de cableado que viva en un archivo distinto. Booteá el binario desde una shell limpia. Corré la receta operativa del runbook end-to-end. Si funciona al primer intento, tu codebase aún no tiene la deuda latente que este patrón caza — o sí la tiene y tuviste suerte en este caso. Si no funciona, contá los gaps. El número es la calibración que necesitás para saber si el ritual de polish-Charter-como-detección-de-deuda valdría su overhead en tu proyecto.

Si adoptaste StrayMark y estás cerrando una Etapa con handlers testeados a través de adapters estilo humatest, el nuevo pattern doc tiene las cuatro verificaciones de subclase scoped para vos. Presupuestá el polish Charter como L, no XS o S. Esperá Charters emergentes de follow-on, no scope creep de limpieza residual. Leé POLISH-CHARTER-PATTERN.md antes de scopear el trabajo, no después.

Y si sos adopter en un stack distinto a Go — TypeScript, Python, Rust, Elixir — las cuatro subclases son agnósticas de lenguaje, pero la forma concreta de verificación no lo es. Aflorar una quinta o sexta subclase en tu stack es exactamente la señal de segundo-adopter que el patrón necesita para graduarse de v0. El camino de "observación interesante en tu proyecto" a "nombrada en el canon de StrayMark" corre por el mismo canal por donde corrió #199: abrir un issue. El costo de abrirlo es bajo; el costo de dejar el patrón subvalidado es real.

StrayMark fw-4.18.0 — Issue #199 · PR #200 · tag fw-4.18.0. Anclas de Sentinel: AIDEC-2026-05-22-001 · PR de CHARTERs 25/26/27.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

"Hola, ¿ya tratamos el Issue #153?"

Así empezó la conversación, hoy 16 de mayo a la mañana. Una pregunta corta, casi de housekeeping, antes de meterme en otra cosa. La respuesta era no — el Issue #153 estaba abierto a propósito, esperando un segundo dominio que ejercitara la mecánica antes de cristalizarla (Principio #12 de StrayMark, validación contra un segundo dominio antes de canonizar). Pero la pregunta abrió otra puerta, y al final de esa conversación había codificado una propiedad de diseño del framework que llevaba meses funcionando sin nombre, señalada por un episodio de hace apenas dos días.

Este post es la reconstrucción del arco, porque vale la pena guardarla. No por el resultado — un nuevo doc canónico, un Principio #8, un PR ya fusionado — sino por el mecanismo que reveló. StrayMark tiene un proyecto humano detrás: que el desarrollo asistido por agentes no se nos escape de las manos a los ingenieros que somos responsables del software que producimos. Y este episodio expuso una propiedad concreta del diseño que empuja en esa dirección.

Aclaración de oficio: StrayMark se prueba primero en mis propios proyectos. Sentinel es uno de ellos — privado, pero su interacción con StrayMark queda documentada en los Issues públicos del repo de StrayMark, así que el contexto es vinculable. Soy autor y primer adopter del framework. El Principio #12 me obliga a esperar un segundo dominio antes de declarar canónica cualquier mecánica nueva; pero el primero soy yo, y este post da cuenta de eso sin pudor.

El incidente: un agente que señaló lo que nadie le pidió señalar​

El 14 de mayo, hace dos días, en Sentinel, un agente trajo a mi atención una observación que no le había pedido. Estaba a punto de ayudarme a completar el CHARTER-18 — una pieza de trabajo concreta dentro de una cadena ya larga — y antes de poner una línea de código dijo, en esencia:

Hay un problema. El specs/002-commshub/plan.md se congeló el 21 de abril. Desde entonces han pasado siete Charters consecutivos, y a lo largo de los AILOGs de esa cadena hay doce aprendizajes empíricos no reflejados en el plan que afectan materialmente el alcance de US5. Si completamos CHARTER-18 leyendo el plan desactualizado, el próximo ciclo de auditoría va a remediar divergencias atómicamente pre-close — con aproximadamente 50% de probabilidad de al menos un hallazgo crítico o alto por herencia de premisa rancia.

Y citó los AILOGs específicos por ID. Y las referencias de código concretas.

Nadie le pidió ese análisis. No había un disparador configurado. No había un comando CLI cuyo propósito fuera producir esa salida. El agente estaba allí para ayudarme con la siguiente tarea, no para auditar el estado del proyecto. Pero al posicionarse para esa siguiente tarea, vio una divergencia entre dos fuentes que la documentación StrayMark conecta explícitamente, y eligió señalarla antes de proceder.

Abrí el Issue #150 ese mismo día por la tarde como RFC, y entre las 17:00 y la noche se discutió y aterrizó la disciplina manual de spec-refresh en fw-4.14.3. Al día siguiente, 15 de mayo, levanté el Issue #156 para llevar upstream los dos patrones que el ejercicio había revelado: un pre-declare SpecKit refresh y una post-close Batch N.4 amendment. Para la madrugada del 16 de mayo estaban canonizados en fw-4.16.0 como CHARTER-CHAIN-EVOLUTION.md, con telemetría dedicada y un helper CLI (straymark charter refresh-suggest). El comportamiento se reprodujo, los patrones se cristalizaron, ciclo cerrado.

Pero cuando me senté esa misma mañana del 16 a abrir la conversación con el Issue #153 — "¿ya tratamos esto?" — y me devolví la pregunta inversa — "un momento, ¿qué fue lo que hizo posible esa observación en primer lugar?" — me di cuenta de que el ciclo había cerrado solamente a medias. Lo que se codificó en fw-4.16.0 fue la aplicación del patrón. Lo que faltaba codificar era el mecanismo que la produjo.

La pregunta humana, dicha con palabras técnicas​

Se la formulé así, en la conversación con el agente que generó este post:

Me resultó algo sorpresivo el comportamiento del agente que se percató de ese conocimiento acumulado que, de no aplicarse, ocasionaría problemas con la implementación del Charter 18. Es decir, que no era una tarea que se le pidió analizar, ni fue el resultado de la activación de un disparador de prompt, y me parece que fue gracias a la documentación StrayMark. Quisiera que ahondáramos más en cómo ocurrió esto, que creo que es positivo, de forma en que podamos aprovechar la experiencia y engancharla en el comportamiento habitual de StrayMark, este patrón emergente que provino del agente y su relación con la documentación generada, fue muy interesante.

Lo que estoy pidiendo ahí no es implementar un feature. Es entender un mecanismo para poder reproducirlo. La diferencia es importante. Cuando uno pide implementar algo, el camino es claro: spec → tasks → código. Cuando pide entender por qué algo funcionó, el camino es más raro: hay que diagnosticar un sistema funcional, identificar qué piezas lo hicieron funcionar, y separar lo accidental de lo estructural.

Hay una urgencia particular en este tipo de pregunta cuando uno está construyendo herramientas para colaborar con agentes de IA. Porque si lo que funcionó fue accidente, el próximo agente — o la próxima versión del mismo agente — puede no reproducirlo. Si lo que funcionó fue estructura, entonces se puede preservar deliberadamente. La diferencia entre las dos cosas, para un proyecto que pretende dar a los ingenieros control sobre el desarrollo asistido por IA, es la diferencia entre suerte y diseño.

La auditoría: ¿qué piezas de StrayMark hicieron posible la observación?​

Le pedí a un agente que mapeara sistemáticamente la documentación StrayMark con tres preguntas concretas:

1. ¿Qué mecanismos documentales conectan fuentes explícitamente entre sí? (Frontmatter, secciones canónicas, IDs estables, comandos CLI que cruzan fuentes.)
2. ¿Dónde le da la documentación al agente permiso explícito para señalar cosas más allá de la tarea pedida?
3. ¿Qué pares de fuentes existen, además del que originó este caso, que podrían producir observaciones emergentes similares si la infraestructura está presente?

El reporte vino estructurado, con archivo:línea para cada hallazgo. Lo importante no fueron los detalles individuales (frontmatter con originating_charter:, secciones §Risk: R<N>, convenciones de IDs estables, comandos como charter drift) sino el patrón que emergió al verlos en conjunto. Dos propiedades coexistían consistentemente:

Propiedad 1: cross-referencing estructural obligatorio. Cada tipo de documento tiene campos obligatorios y secciones canónicas que declaran, en la propia estructura del documento, a qué otros documentos apunta. Cuando un agente lee un AILOG, no tiene que adivinar a qué Charter pertenece — el originating_charter: se lo dice. Cuando ve un riesgo, no es una observación en prosa libre — es una entrada R<N> en una sección canónica, contable. Cuando el spec apunta a Charters, lo hace formalmente; cuando los Charters apuntan a AILOGs, igual. Es un grafo de enlaces explícito que el agente puede triangular sin trabajo creativo.

Propiedad 2: permiso cultural sin control bloqueante. AGENT-RULES §6 le dice al agente: "Be Proactive — Identify potential risks, Suggest improvements when evident, Alert about technical debt". PRINCIPLES §2 le dice: "Not hide relevant information". Y críticamente, AGENT-RULES §3 le da autonomía para crear documentos (AILOG, AIDEC, TDE) sin pre-aprobación del operador. El operador retiene la priorización, no la creación. El agente no tiene que pedir permiso para señalar algo: señalarlo es ejecución de una regla, no juicio de valor.

Lo interesante es que ninguna de las dos propiedades por sí sola produce el comportamiento. Si tuvieras solamente enlaces formales (Propiedad 1) sin permiso cultural, tendrías un corpus consultable que ningún agente se atreve a consultar proactivamente. Si tuvieras solamente permiso cultural (Propiedad 2) sin estructura, tendrías señales vagas — "creo que algo podría estar mal en algún lado" — que los operadores no podemos accionar.

Combinadas, producen algo que merece nombre propio: el agente externalizó "¿debo decir algo?" como "¿existe una sección canónica donde esto encaja?". Si la respuesta es sí, señalarlo deja de ser una decisión emocional y se vuelve ejecución mecánica. El costo de señalar baja porque el destino — la sección canónica — ya existe.

Por qué esto importa más allá de StrayMark​

Estamos en un momento donde los agentes de IA pueden escribir código tan rápido como pensamos, y la pregunta de cómo no perder el control del proceso es genuinamente urgente. No es una pregunta apocalíptica — es una pregunta operativa, de oficio, de personas que estamos construyendo software ahora mismo y tenemos que entregar. Lo evidencia el ritmo mismo de este episodio: del diagnóstico del agente al meta-patrón canonizado pasaron menos de 72 horas. Esa velocidad es ganancia, pero también es la razón por la cual los mecanismos de visibilidad importan tanto.

La respuesta dominante en la industria hoy es alguna variante de prompts más estrictos, más reglas en el contexto, más gates en CI. Esos enfoques son válidos pero tienen una característica que vale la pena nombrar: convierten al agente en algo más cercano a un trabajador que ejecuta órdenes en pipelines verificables. Eso resuelve la confiabilidad pero al costo de la observación emergente. Un agente que solo hace lo que se le ordena no va a señalar algo que nadie le pidió señalar, por buen razonamiento que tenga.

Lo que el episodio de Sentinel mostró es una respuesta diferente, complementaria: construir el aparato documental de tal forma que las divergencias importantes sean estructuralmente visibles, y dar al agente permiso cultural para señalarlas sin pedir aprobación. Eso preserva la observación emergente como propiedad del sistema, no como suerte de qué tan bueno sea el agente o qué tan extenso sea el prompt.

Hay algo casi taoísta en esta postura: no le decimos al agente qué buscar; construimos un entorno donde lo que hay que ver es visible. La pareja "estructura visible + permiso para nombrar" hace el trabajo. El agente se vuelve, parafraseando a algunos colegas, un honest broker entre la documentación viva y el estado del código.

Y esto es lo que el proyecto humano detrás de StrayMark persigue, aunque rara vez se diga con esas palabras: que el cambio vertiginoso del desarrollo asistido por IA no nos arroje a un mundo donde los ingenieros perdemos visibilidad sobre lo que se está construyendo. La visibilidad no se preserva con más controles burocráticos; se preserva diseñando el entorno donde el agente trabaja para que lo importante sea naturalmente visible. El ingeniero no se vuelve un revisor de Pull Requests interminables — se vuelve un priorizador de observaciones que el agente trae estructuradas y nombradas.

Lo que hicimos al respecto​

Con el diagnóstico claro, la pregunta era cómo engancharlo al comportamiento habitual de StrayMark sin matar la calidad emergente. Esta tensión es real: cada vez que conviertes un comportamiento espontáneo en obligación, lo conviertes en otra cosa. Una regla dura puede ser robusta, pero también puede generar resistencia en el agente o falsa señal cuando se activa fuera de contexto.

La decisión fue conservadora: nombrar el meta-patrón, no obligar su uso.

Concretamente, en el PR #160 que salió como fw-4.17.0:

• Un nuevo doc canónico — EMERGENT-OBSERVATION-DESIGN.md — articula la propiedad de diseño con sus dos componentes, presenta el caso empírico de Sentinel como ancla, y construye una pirámide de instancias: el meta-patrón en la cima, y abajo todas las aplicaciones que ya estaban canonizadas (Pattern 1 y Pattern 2 de la chain evolution; charter drift; follow-ups backlog drift; escalación TDE-vs-R<N>; audit checkpoint externo). Lo que antes parecían patrones ad hoc se revelan como aplicaciones del mismo principio subyacente. Esta visualización por sí sola vale la pena: cuando ves siete cosas que parecían distintas y de pronto reconoces que comparten una misma forma, el framework gana coherencia interna sin haber añadido nada.

• Un nuevo Principio #8 — Cross-Source Dissonance Surfacing — en PRINCIPLES.md. Es la regla cultural condensada en cinco líneas. El agente la lee al incorporarse al proyecto y la aplica recursivamente.

• Una expansión a AGENT-RULES.md §6 "Be Proactive" con ejemplos concretos de divergencia a vigilar: spec desactualizado, R acumulados sin escalar a TDE, ADR contradicho por la implementación, follow-ups cruzando umbral del backlog pattern, hallazgos de auditoría emergiendo post-close. No son obligaciones; son ejemplos de lo que un agente proactivo notaría. La diferencia es importante para preservar lo emergente.

• Cuatro ejes abiertos identificados como gaps — lugares donde la infraestructura de cross-referencing existe parcialmente pero el patrón no está nombrado: MCARD ↔ código del modelo desplegado, SBOM ↔ lockfiles, ADR vigente ↔ implementación que la contradice, Constitution Check ↔ bump de versión del framework. Cada uno requiere validación N=1 empírica antes de cristalizar — Principio #12 aplica. Quedaron registrados en el Issue #161 como tracking RFC, esperando que un segundo dominio empuje alguno de ellos.

• Anti-patrones explícitos: cómo se rompe el meta. Si un nuevo tipo de documento sale con enlaces de frontmatter opcionales, el cross-referencing desarrolla puntos ciegos. Si una sección canónica se reemplaza por prosa libre, la consultabilidad se evapora. Si se introduce control bloqueante en la creación de AILOG/AIDEC/TDE, el permiso cultural se rompe. Si la telemetría evoluciona sin preservar señales como r_n_plus_one_emergent_count, el feedback loop se rompe. Estos anti-patrones son una protección barata pero efectiva contra la erosión accidental: cualquier futura propuesta de cambio se puede contrastar con la lista para detectar si está regresando el meta-patrón.

Todo esto, del diagnóstico al merge y el tag fw-4.17.0 con su release publicada, ocurrió entre las 09:00 y las 04:00 del mismo día. Quince horas. Lo cual es exactamente el tipo de ritmo que el blog admite: hay que aprender a operar bajo este reloj, o el control se nos va.

Lo que aprendí del proceso​

Tres cosas que no esperaba aprender cuando empecé respondiendo "no, el Issue #153 sigue abierto":

Primero, que codificar un meta-patrón es distinto de codificar un patrón. El meta-patrón no añade obligaciones; añade vocabulario y visibilidad de la propiedad subyacente. Esa propiedad ya estaba haciendo su trabajo; lo que faltaba era darle nombre para protegerla bajo evolución futura. Quien lee EMERGENT-OBSERVATION-DESIGN.md no aprende a hacer algo nuevo — aprende a reconocer algo que ya estaba ahí. Eso es lo que permite preservarlo deliberadamente.

Segundo, que la propiedad emergente desaparece si se sobre-regula. Hubo un momento en la conversación donde elegí no convertir Pattern 1 en obligación dura ("el agente DEBE ejecutar refresh-suggest antes de declarar Charter-(N+1)") y en cambio mantenerlo como recomendación más el nombramiento del meta. Esa decisión es contraintuitiva si uno viene del mundo de "más controles = más confiabilidad", pero es correcta para este tipo de propiedad. La proactividad del agente es frágil: en cuanto se vuelve mandato, deja de ser proactividad. Lo que escala es el motor cultural ("Be Proactive") más los enlaces estructurales, no la lista de obligaciones específicas.

Tercero, que el aparato documental que construimos para los agentes también nos está educando a los humanos. Cuando vi los siete patrones dispersos en distintos docs de governance y los reconocí como instancias del mismo meta, entendí algo sobre StrayMark que no había entendido antes — y StrayMark soy yo mismo construyéndolo a lo largo de meses. El framework está revelándole cosas a su propio autor. Esa propiedad — que la documentación estructurada produce insights sobre sí misma cuando se la audita — es una variante doméstica de lo que el agente hace cuando señala una divergencia. Es el mismo mecanismo, aplicado a una escala distinta.

El proyecto humano detrás​

Hablo en serio cuando digo que StrayMark tiene un proyecto humano. No estoy construyendo un framework de gobernanza documental porque me obsesionen los campos de frontmatter. Lo construyo porque tengo la sospecha — cada vez menos especulativa — de que los próximos cinco años de la ingeniería de software van a ser una negociación constante entre la velocidad que ofrecen los agentes y la visibilidad que los ingenieros necesitamos para seguir siendo responsables del producto. Si esa negociación se pierde del lado de los agentes, terminamos en un mundo donde el código se escribe y nadie sabe por qué. Si se pierde del lado del control burocrático, terminamos sin las ganancias de productividad que justificaron el experimento.

El equilibrio no es teórico. Se construye con decisiones concretas: dónde poner un campo de frontmatter, qué sección debe ser canónica versus libre, cuándo dar al agente autonomía y cuándo retener priorización. Cada una de esas decisiones inclina la balanza en una dirección u otra. Y la única forma de saber si la balanza está bien es probarla — y nombrar lo que funciona cuando funciona, para que sobreviva al próximo cambio del framework.

El episodio del CHARTER-18, hace dos días, fue una prueba. Funcionó. Lo que escribí hoy fue darle nombre. La siguiente prueba ya tiene candidatos: MCARD, SBOM, ADR vigente vs implementación, Constitution Check ↔ framework bump. Cuatro ejes donde el meta-patrón podría reproducirse si cerramos los gaps de infraestructura. Esperaré a que un segundo dominio empuje uno empíricamente antes de codificarlo. Principio #12 — validación contra un segundo dominio antes de cristalizar — sigue siendo el guardarraíl.

Si estás leyendo esto y trabajas con agentes para desarrollar software, te invito a mirar tu propio aparato documental con estas dos preguntas: ¿qué fuentes están conectadas formalmente, con enlaces explícitos que un agente pueda triangular sin trabajo creativo? y ¿qué tan barato es para el agente señalar algo no pedido cuando detecta una divergencia? Si la respuesta a la primera pregunta es "pocas" y a la segunda es "caro", probablemente estás dejando observaciones emergentes sobre la mesa. Lo cual no es el fin del mundo — pero es exactamente lo que separa un proceso de desarrollo asistido por IA bajo control humano de uno que se nos va de las manos.

StrayMark fw-4.17.0 — Issue #150 · #156 · #161 · PR #160 · tag fw-4.17.0

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. Veintisiete horas para nombrarlos​

El PR #152, que cerró el episodio del Post 9, se fusionó el 14 de mayo a las 21:39 UTC. Trajo fw-4.14.3 y los tres gates canonizados del refresh manual.

El PR #157 — el que este post viene a contar — se fusionó el 16 de mayo a las 00:31 UTC. Veintisiete horas después. Trajo fw-4.16.0 / cli-3.14.0 y, con eso, dos meta-patrones nombrados:

• Pattern 1 — pre-declare SpecKit refresh. Refrescar la spec antes de declarar el siguiente Charter en una cadena.
• Pattern 2 — post-close audit-driven Batch N.4. Amendar un Charter ya cerrado cuando la auditoría externa señala findings post-close, sin abrir un Charter nuevo.

El Post 9 cubrió la disciplina aplicada manualmente sobre CHARTER-18. Este post cubre lo que vino después: los dos patrones nombrados, el documento canónico que los nombra (CHARTER-CHAIN-EVOLUTION.md), el schema de telemetría que los mide, los dos CLI helpers que los scaffold-ean — y, como cierre del arco editorial entero, una hora y diecisiete minutos más tarde, un meta-patrón filosófico que reabsorbe ambos hacia arriba.

Es el último post del arco. El blog que el Post 1 abrió por delante cierra aquí por atrás.

2. Pattern 1 — Pre-declare refresh​

La definición literal, copiada del documento canónico:

"A dedicated refresh PR lands between Charter-N close and Charter-(N+1) declare. It touches only the non-locked sections of the SpecKit artifacts (plan.md, data-model.md, contracts, quickstart.md, research.md)."

Esto es exactamente lo que Sentinel hizo manualmente para CHARTER-18 en el Post 9. La diferencia entre Post 9 y Post 10 es de tipo: el Post 9 documenta el procedimiento; el Post 10 documenta su activación condicionada — cuándo el framework recomienda al adoptante que aplique Pattern 1.

Los criterios de activación son cuantificables, y el documento los nombra sin atenuar:

• El módulo tiene ≥ 3 Charters cerrados sobre la misma spec.
• La media móvil (últimos 3 Charters) del campo agent_quality.r_n_plus_one_emergent_count en la telemetría es mayor a 6.
• No ha aterrizado un refresh PR desde el último branch point.

El umbral > 6 no es arbitrario. Es Sentinel CHARTER-18 convertido en regla: el promedio de hallazgos emergentes (riesgos descubiertos durante el Charter que no estaban declarados en el plan original) durante CHARTER-15, 16, 17 fue exactamente lo que disparó la sensación de que la spec estaba acumulando demasiada deuda. El framework, en lugar de pedirle al adoptante que confíe en su intuición, le da un número que su telemetría puede comparar.

Lo que produce Pattern 1, cuando se aplica:

• Una tabla categorizada en research.md que enumera lo descubierto en los Charters anteriores en cuatro tipos: reusable patterns, code gaps, discipline patterns, empirical corrections.
• Decisiones operacionales explícitas (D1, D2, etc.) si la categorización evidencia trade-offs.
• Citas en el §Context del siguiente Charter, por id, hacia los items integrados.
• Un bloque de telemetría pre_declare_refresh: opt-in en el charter-telemetry.yaml del Charter que recibe el refresh.

La métrica que sostiene el patrón viene de Sentinel CHARTER-18 mismo, citada literal en CHARTER-CHAIN-EVOLUTION.md:

"Sentinel CHARTER-18 was the first Charter in a 7-Charter chain to close cleanly without a mid-flight remediation Charter. estimation_drift_factor: 1.0, pre_work.items_discovered_during_planning: 0, overall_satisfaction: 5/5."

Un solo dominio. N=1. El documento lo dice sin atajos: el patrón está validado empíricamente en Sentinel. Esperar al segundo dominio antes de cristalizarlo más alto.

3. Pattern 2 — Amend-on-emergence​

La definición literal:

"The amendment rides the same execute branch as the original Charter (the branch is still mergeable to main; the amendment commit lands on top)."

La idea: cuando un Charter ya cerrado recibe findings de auditoría externa post-close — critical o high — el framework no obliga a abrir un Charter nuevo. El operador puede amendar el Charter cerrado mientras la rama execute sigue mergeable a main.

La justificación, también literal del documento:

"A new Charter would have created multi-week governance overhead for ~6h of focused engineering."

Esa asimetría — semanas de gobernanza vs. seis horas de ingeniería — es lo que el patrón resuelve. Abrir un Charter nuevo para arreglar cinco findings post-close significa: declarar contexto nuevo, repetir auditoría externa, generar AILOG nuevo, registrar telemetría desde cero. Para una corrección que en código toma una tarde. Pattern 2 dice: no.

Los criterios de activación, también cuantificables:

• Findings Critical/High aparecen post-close, después de la auditoría externa.
• El criterio de cierre del Charter resultó materialmente incumplido por esos findings.
• La superficie del fix es menor a 25 archivos.
• No requiere reapertura arquitectónica (decisiones de diseño que el Charter original asumió como cerradas).

Si los cuatro criterios se cumplen, Pattern 2 aplica. Si alguno falla, hay que abrir Charter nuevo.

Lo que produce, cuando se aplica:

• Un commit de amendment sobre la misma rama execute del Charter original.
• Un AILOG nuevo (no editar el original) con risk_level: high, review_required: true, y un campo amends: que apunta al AILOG original.
• Una sección ## Historical correction (YYYY-MM-DD) en el AILOG original que apunta forward al nuevo. Es archivística: el AILOG original no se reescribe; se enlaza.
• Un bloque de telemetría post_close_amendment: en el charter-telemetry.yaml.

La métrica empírica que sostiene Pattern 2, citada literal:

"Sentinel CHARTER-18 closed 2026-05-15 with audit reports landing 2026-05-15..05-17. Five findings (4 from gpt-5.3-codex, 1 from gemini-2.5-pro) were code-level fixes — DI wiring, retry header parsing, multi-tenant filter, timeout default. The Batch 7.4 amendment closed all five in one cohesive commit (19 files, +2257/-106 lines)."

Un commit, 19 archivos, dos modelos auditores convergiendo en hallazgos similares, cinco fixes. Si hubiera sido Charter nuevo: dos semanas mínimo entre declare, audit externa, y close. En cambio: un amendment en la misma rama, seis horas.

4. Composición, no exclusión​

La pieza más interesante del documento — y, creo, la que cierra mejor el arco — es la sección sobre cómo se relacionan los dos patrones. Cita literal:

"A Charter that received Pattern 1 is more likely to avoid Pattern 2, because the refresh absorbs pre-execution risk that would otherwise surface as post-close findings. But CHARTER-18 needed both — the refresh handled spec-level drift; the amendment handled runtime-level drift the refresh did not reach into."

No son patrones rivales. Son aplicaciones del mismo principio en momentos distintos del ciclo. Pattern 1 absorbe deriva de spec — lo que el plan original ya no describe correctamente. Pattern 2 absorbe deriva de runtime — lo que solo se ve cuando el código corre, los auditores externos lo miran fresco, y emerge desde el código mismo.

Sentinel CHARTER-18 necesitó los dos. La spec refrescada eliminó los hallazgos emergentes que un audit cycle posterior habría tenido que remediar atomicamente; la amendment posterior absorbió lo que el refresh no podía haber predicho — wiring de DI, parsing de headers de retry, un filtro multi-tenant, un default de timeout. Cosas que el plan no podía conocer y que solo emergieron cuando el código existió.

El framework, al nombrar los dos patrones y declarar su composición explícita, hace algo que me importa subrayar: deja constancia de que la disciplina no es lineal. No hay un solo punto de inspección antes de cada Charter; hay un punto antes (Pattern 1) y un punto después (Pattern 2), y ambos pueden ser necesarios en el mismo Charter. La cadena evoluciona; los patrones también.

5. El schema y los helpers​

Lo que fw-4.16.0 añadió al schema de telemetría son dos sub-objetos opcionales en charter-telemetry.schema.v0.json v0.2:

pre_declare_refresh:
  enabled: boolean
  refresh_pr: string | null
  refresh_aidec: string | null
  reusable_patterns_integrated: integer  # ≥ 0
  code_gaps_integrated: integer
  discipline_patterns_integrated: integer
  empirical_corrections_integrated: integer
  operator_decisions_ratified: integer

post_close_amendment:
  applied: boolean
  trigger: external_audit | production_incident | deferred_implementation
  ailog_id: string
  findings_closed: integer
  files_modified: integer
  effort_hours: number

Contadores enteros, no narrativas. La decisión es deliberada: lo que el telemetry schema captura es lo que el agente o el operador pueden contar mecánicamente. Lo que no se puede contar — qué tan profundo era el problema, qué tan astuto fue el fix — vive en el AILOG, no en la telemetría. El schema mide la forma del trabajo; los documentos llevan el contenido.

Y cli-3.14.0 añadió dos helpers, ninguno mutador:

• straymark charter refresh-suggest <module> [--threshold N] — read-only. Lee la telemetría de los últimos tres Charters cerrados del módulo, computa la media móvil de r_n_plus_one_emergent_count, y emite una recomendación: refresh-now, not-needed, o insufficient-data. Exit 0 siempre. Es informacional, nunca CI gate.

• straymark charter amend <CHARTER-ID> --trigger <kind> --ailog-title <title> [--findings-closed N] [--merge-into <PATH>] — scaffolding. Crea un AILOG stub con los campos correctos (risk_level: high, review_required: true, amends: apuntando al original), añade la sección ## Historical correction al AILOG original, y renderiza el bloque YAML de post_close_amendment:. No toca git.

La elección de mantener los dos helpers humildes — uno solo recomienda, el otro solo prepara — es coherente con la decisión A1 del Post 4: "el CLI orquesta pero no invoca APIs". Aquí: el CLI sugiere pero no decide; scaffold-ea pero no muta. El humano sigue siendo el punto donde la disciplina ocurre. El framework solo le pone las herramientas a la mano.

6. Setenta y siete minutos después​

Hay una pieza más que vale la pena registrar antes del cierre del arco. PR #157 se fusionó a las 00:31 UTC del 16 de mayo. PR #160 — el del Post 1, EMERGENT-OBSERVATION-DESIGN.md, fw-4.17.0 — se fusionó a las 01:48 UTC del mismo día. Setenta y siete minutos después.

Lo que pasó en esos setenta y siete minutos es el cierre invertido del arco. El meta-patrón filosófico que el Post 1 nombró — observación emergente compuesta de vínculos formales más permiso cultural para señalar — se cristalizó una hora y diecisiete minutos después de los dos meta-patrones operativos de este post. El meta-patrón filosófico no precede a la disciplina; la sucede. Es la lectura ascendente de la misma evidencia.

CHARTER-CHAIN-EVOLUTION.md lo registra explícitamente en su sección §Related:

"EMERGENT-OBSERVATION-DESIGN.md — the meta-pattern of which Pattern 1 and Pattern 2 are applications (formal cross-referencing + cultural permission to surface)."

Pattern 1 es composición de vínculos formales (la telemetría r_n_plus_one_emergent_count, las citas por id en el §Context, los AILOGs categorizados) con permiso cultural (la regla de que un agente debe señalar deriva entre spec y código cuando la encuentra). Pattern 2 es composición similar (los AILOGs con amends:, la sección Historical correction enlazando forward) con permiso para señalar findings post-close en lugar de absorberlos en silencio. Los dos patrones son aplicaciones del mismo principio cultural+estructural que el Post 1 nombró por encima.

Es un final que me sigue gustando: el blog que abrió diciendo "el agente vio algo que nadie le pidió ver" cierra diciendo, en el episodio anterior por orden cronológico, "aquí están las dos cosas que el agente puede ver bien porque el framework las nombra".

7. Cierre del arco​

Diez posts. Once episodios cubiertos (H-01 a H-13, con varios agrupados). Una decisión editorial — la publicación retroactiva — que el Post 2 introdujo y que los nueve posts siguientes ejercieron sin violar. Un compromiso bilingüe que se mantuvo en cada cierre.

Algunas cosas que aprendí escribiendo el blog y que vale la pena registrar antes de cerrarlo:

1. El patrón nace de la disciplina. La frase ya apareció en el Post 9, pero el arco completo la sostiene. Los meta-patrones de este post no se diseñaron; se extrajeron. Cada hito documentado tuvo primero su episodio operativo y después su nombre.

2. La cadencia no es uniforme. Diecinueve días entre el primer commit (Post 2, 27 enero) y la primera unidad acotada con auditoría externa (Post 3, 25 abril). Cinco horas entre disciplina aplicada y disciplina canonizada (Post 9, 14 mayo). Setenta y siete minutos entre dos meta-patrones y su lectura filosófica (Posts 10 y 1, 16 mayo). El proyecto pasó por todas las velocidades, y el blog las registra todas.

3. El framework no es neutro respecto a su adopter. Sentinel hizo posible que cada patrón se validara empíricamente antes de cristalizarse. El blog no esconde esa procedencia; la subraya como precondición metodológica.

4. Lo que no se nombra, no se ve. El Post 5 lo formuló como visibilidad estructural; el Post 7 lo aplicó a la deuda transversal; el Post 8 lo señaló sobre el outlier de idioma. Es la regularidad más persistente del arco. Existir como artefacto técnico no basta. El nombre activa el artefacto.

El arco que el blog vino a contar — los hitos H-01 a H-13, los cuatro nombres del proyecto, los seis Planes, los Charters first-class, el audit cycle externo, el Issue #113, el rebrand a StrayMark, el TDE, el outlier del audit-prompt, la disciplina manual, y los dos meta-patrones — cierra aquí. Lo que queda en deuda explícita: H-14, la TUI straymark explore (que apareció lateralmente en el Post 8 como herramienta de visibilidad), y los hitos candidatos H-?-A a H-?-E que PLAN-INVESTIGACION.md §1.43-55 listó como pendientes de decisión. Posible segunda tanda futura. Sin promesa.

Una última observación, simétrica al Post 1. Aquel post abrió diciendo: "el agente vio algo que nadie le pidió ver". Lo que el blog cierra registrando, después de diez episodios, es la otra mitad de la frase: el agente vio porque el framework lo había puesto en condiciones de ver. La observación emergente del Post 1 es la prueba; los patrones nombrados de este post son las precondiciones. Cada cosa que el agente señaló durante los cuatro meses que cubre el arco fue posible porque algún episodio anterior había puesto un artefacto, un disparador, un vínculo formal, una superficie visible donde antes no había nada.

El blog termina de contar la historia. El framework sigue.

Anclas: Issue #156. PR #157 — fw-4.16.0 / cli-3.14.0 (fusionado 2026-05-16 00:31 UTC). Documento canónico: CHARTER-CHAIN-EVOLUTION.md. Schema: dist/.straymark/schemas/charter-telemetry.schema.v0.json v0.2. Meta-patrón sucesor: EMERGENT-OBSERVATION-DESIGN.md, fw-4.17.0 (fusionado 2026-05-16 01:48 UTC, 77 minutos después).

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

— Fin del arco H-01 → H-13 del blog StrayMark.

1. Cuatro meses entre la intuición y el estándar​

El 15 de mayo de 2026, a las 19:05 UTC, el PR #155 cerró el framework como fw-4.15.0 / cli-3.13.2. Lo que trajo es un solo archivo nuevo en la lista de directivas que el CLI inyecta: AGENTS.md, en la raíz del repo del adoptante, paralelo a los que ya estaban (CLAUDE.md, GEMINI.md, .github/copilot-instructions.md, .cursorrules, .cursor/rules/straymark.md).

Esto sería trivial si no fuera porque hace exactamente cuatro meses, el 27 de enero de 2026, el primer AIDEC del proyecto — el que el Post 2 cubrió con la anécdota del año tipográfico — había declarado:

"AI agents (Claude, Gemini, Copilot, Cursor) process instructions equally well in any language, so translating their config files provides no functional benefit."

Esa frase, escrita seis horas después del initial commit del proyecto, contenía una intuición que el framework venía operativizando desde entonces: los agentes son un solo público técnico. Mantenían los archivos de configuración en inglés (mientras la documentación humana se traducía a tres idiomas) porque la audiencia "agentes IA" no se beneficiaba de la traducción. Lo que faltaba para cerrar esa intuición era darle un solo lugar al que apuntar, sin tener que clonar el archivo cuatro o cinco veces para cada vendor distinto.

Este post cubre exactamente eso: cómo AGENTS.md — un estándar abierto donado a la Agentic AI Foundation en diciembre de 2025 — completó cuatro meses después la decisión que el primer AIDEC había abierto en enero.

2. La fragmentación que AGENTS.md resuelve​

Entre 2024 y 2026, mientras los CLIs de agentes IA proliferaban, cada uno inventó su propio formato de archivo de instrucciones:

• Anthropic publicó CLAUDE.md con la primera versión de Claude Code.
• Google adoptó GEMINI.md para Gemini CLI.
• GitHub estableció .github/copilot-instructions.md para Copilot CLI.
• Cursor empezó con .cursorrules y migró luego a .cursor/rules/*.md.
• OpenAI usó otro path para Codex CLI; Aider, Devin, Continue, Roo Code, Factory Droids, Sourcegraph Amp, Zed AI, Windsurf, Amazon Q tenían cada uno el suyo.

Un adoptante de StrayMark que usara dos o tres de esos CLIs tenía que mantener dos o tres copias del mismo contenido, sincronizadas a mano, esperando que ninguna divergiera. El framework hasta fw-4.14.x reconocía esa fragmentación en su comando straymark init: inyectaba en los cinco archivos vendor-específicos más comunes. Pero los otros diez o quince CLIs quedaban fuera. El adoptante los manejaba copiando contenido a mano.

A finales de 2025, la comunidad de proyectos open-source que producía CLIs de agentes hizo lo que se hace cuando una fragmentación se vuelve costosa: acordaron un estándar. AGENTS.md en la raíz del repo, leído por todos. La donación a la Agentic AI Foundation (Linux Foundation, diciembre 2025) le dio gobernanza institucional. La especificación es deliberadamente mínima: un archivo Markdown, sin schema impuesto, en una ubicación predecible. Lo que cada CLI hace con ese archivo es asunto suyo; la pregunta canónica — "¿dónde está la configuración de agentes para este repo?" — tiene ahora una sola respuesta.

Para mayo de 2026, la lista de CLIs que leen AGENTS.md incluye (cita literal del cuerpo del PR #155):

"Claude Code, OpenAI Codex CLI, Cursor, Aider, Devin, Sourcegraph Amp, Google Jules, Zed AI, Continue, Roo Code, Factory Droids, GitHub Copilot, Gemini CLI, Windsurf, Amazon Q and others."

Quince CLIs. Algunos siguen leyendo también sus archivos vendor-específicos por compatibilidad histórica. Pero los quince saben buscar AGENTS.md primero.

3. Adoptar sin matar lo propio​

La decisión más interesante de fw-4.15.0 no es adoptar AGENTS.md; eso era inevitable una vez que el estándar tenía masa crítica. Lo interesante es cómo. El cuerpo del PR lo articula sin atenuar:

"Parallel to CLAUDE.md / GEMINI.md: marker block points to STRAYMARK.md, with a minimum-viable body below for readers that cannot follow relative links."

Tres palabras clave: parallel, marker block, minimum-viable body.

Parallel significa que AGENTS.md no reemplaza los archivos vendor-específicos. Coexiste. El framework sigue inyectando CLAUDE.md, GEMINI.md, .cursorrules y los demás. La razón es pragmática: algunos CLIs (notablemente Cursor en su versión legacy) requieren que el contenido completo esté embebido, no detrás de un link relativo. Mantener los archivos hermanos preserva esa compatibilidad sin que cada adoptante tenga que pelear con su CLI específico.

Marker block es la convención que el framework ya usaba en los demás archivos vendor-específicos: un bloque HTML-commented entre <!-- straymark:begin --> y <!-- straymark:end --> que apunta a STRAYMARK.md como source-of-truth. Cualquier straymark update-framework reemplaza solo lo que está entre esos marcadores. Lo que el adoptante haya escrito afuera de ellos — por ejemplo, instrucciones propias del proyecto — se preserva intacto. El framework respeta el archivo del adoptante; solo gobierna su propia sección.

Minimum-viable body es la concesión a los CLIs que no siguen relative links. Debajo del bloque de marcadores, AGENTS.md tiene un cuerpo corto con lo esencial: identidad del agente, requisitos de revisión, checklist pre-commit, snippet de frontmatter regulatorio, categorías de riesgo NIST AI 600-1, reglas de observabilidad, convención de nombrado. Es suficiente para que un agente que no pueda leer STRAYMARK.md opere correctamente; es insuficiente para reemplazar al documento canónico. La asimetría es deliberada: queremos que el agente quiera abrir STRAYMARK.md.

El detalle defensivo del CLI (cli/src/commands/remove.rs:13) cierra el flanco operativo: AGENTS.md se agregó a LEGACY_DIRECTIVE_TARGETS. Si un adoptante pierde su .straymark/dist-manifest.yml y ejecuta straymark remove, el fallback legacy limpia también AGENTS.md en lugar de dejarlo huérfano. Es housekeeping aburrido, pero es la diferencia entre un framework que se desinstala completamente y uno que deja basura.

4. Sin ADR​

Vale la pena nombrar una ausencia. La decisión de adoptar AGENTS.md no tuvo ADR propio.

Es un contraste deliberado con el rebrand a StrayMark del Post 6, que sí tuvo ADR-2026-05-08-001 público con tres alternativas evaluadas y consecuencias enumeradas. Es también contraste con Phase 2 del Post 12, que tuvo una entrada de CHANGELOG densa con justificación arquitectónica. fw-4.15.0 tuvo solo el cuerpo del PR como justificación documental — un cuerpo bueno, con argumento claro, pero no un ADR.

¿Por qué? La respuesta operativa: la decisión se percibió como agregativa, no estructural. Adoptar un estándar abierto que coexiste con los formatos existentes no cambia el modelo del framework; solo lo extiende. No hay alternativa cuyo descarte requiera justificación formal: no adoptar AGENTS.md significaría dejar fuera a 15 CLIs por preferencia estética, y nadie tenía ese argumento que hacer.

Pero hay una lección registrable aquí. El blog ha visto el patrón antes — Phase 2 cierra un loop empírico, el rebrand cambia identidad, los meta-patrones del Post 10 nombran lo que ya estaba — y en cada caso la pregunta "¿esto amerita ADR?" tiene una respuesta distinta. La regla operativa que el framework parece haber adoptado, sin nombrarla, es esta: un ADR se justifica cuando la decisión cierra alternativas costosas y deja registro de las que no se eligieron. fw-4.15.0 no cerró alternativas costosas — solo agregó una capa. Por eso bastó con el PR.

Lo dejo registrado aquí porque vale la pena reconocer que no todo cambio merece ADR, ni todo PR es un documento histórico. La disciplina archivística tiene sus propios criterios.

5. Visibilidad para agentes, dos capas​

Diez días antes de fw-4.15.0, el 9 de mayo, se cerró el Issue #113 — el episodio que el Post 5 documentó como "Charters invisibles para los agentes". El operador había trabajado seis horas con un agente capaz, atento, con el aparato canónico de onboarding cargado, y el agente nunca había propuesto usar un Charter. La conclusión que aquel post canonizó: la visibilidad estructural es responsabilidad del framework, no propiedad del agente.

fw-4.15.0 cubre la otra cara del mismo problema.

El Post 5 trataba de visibilidad estructural interna: cómo aseguramos que un agente que ya está leyendo nuestro repo descubra los conceptos centrales del framework. La respuesta del PR #122 (Post 5) fue multiplicar las superficies internas donde Charter aparece como concepto: STRAYMARK.md §15, directivas CLAUDE.md/GEMINI.md, skills /straymark-*, output de status, templates, puente con SpecKit. Nueve superficies internas.

Este post trata de visibilidad estructural externa: cómo aseguramos que cualquier agente que entra al repo, sin importar su vendor, encuentre el aparato del framework. La respuesta de fw-4.15.0 es adoptar el punto de encuentro canónico que la comunidad eligió. Una superficie externa, leída por quince vendors.

Las dos capas tienen el mismo eje conceptual — un artefacto técnico solo existe para el agente si la superficie lo nombra — pero distinto alcance. Visibilidad interna garantiza que el agente vea los Charters cuando está leyendo STRAYMARK.md. Visibilidad externa garantiza que el agente vea STRAYMARK.md cuando entra al repo. Una capa sin la otra es incompleta.

6. Lo que el adoptante hace al ejecutar update-framework​

La parte operativa del release, citada literal del CHANGELOG:

"straymark update-framework brings the new template and injects AGENTS.md at the project root. The injection follows the same rules as every other directive target: it creates the file if absent, replaces the marker block on subsequent runs, and appends safely when the file pre-exists without StrayMark markers (very common in 2026 — many adopters already hand-maintain an AGENTS.md)."

Tres comportamientos importantes:

1. Si no existe, el CLI lo crea con el template canónico.
2. Si ya existe y tiene marcadores StrayMark, el CLI reemplaza solo el contenido entre marcadores.
3. Si ya existe sin marcadores — caso muy común en 2026, porque muchos adoptantes ya escribían su propio AGENTS.md a mano — el CLI agrega sus marcadores al final del archivo, sin tocar lo que el adoptante había escrito.

Es el mismo respeto archivístico que el blog ya documentó en Posts 3 y 6: el framework gobierna su sección, no el archivo entero. Si el adoptante quiere escribir instrucciones propias del proyecto en su AGENTS.md — políticas internas, convenciones de naming, instrucciones específicas para una codebase particular — esas instrucciones quedan intactas en cada update. El bloque de StrayMark vive en su pequeña frontera marcada, y se actualiza dentro de esa frontera.

La nota del CHANGELOG cierra con una pequeña advertencia operativa que vale la pena registrar: "If your .gitignore excludes AGENTS.md, adjust it before update-framework so the injection lands in version control." Es honesta sobre los edge cases que el framework no puede resolver por su cuenta — la elección del adoptante de ignorar el archivo es soberanía, no error.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. Cuatro meses entre intuición y materialización es lo que toma cerrar bien un loop. El AIDEC de enero contenía la intuición — "los agentes son un solo público". fw-4.15.0 la cerró con un estándar abierto. Entre las dos, el framework iteró sobre arquetipos vendor-específicos hasta que apareció el sustituto universal. La intuición temprana fue correcta; el plazo fue el que la maduración del ecosistema requería.

2. Adoptar un estándar abierto no exige renunciar al formato propio. AGENTS.md coexiste con CLAUDE.md, GEMINI.md, .cursorrules. La decisión no es "uno reemplaza a los demás" sino "uno se suma a los demás cuando aporta". El framework gana visibilidad externa sin perder compatibilidad con CLIs que requieren formatos específicos.

3. No todo cambio amerita ADR. El rebrand a StrayMark cerró alternativas costosas y dejó registro formal de las descartadas. fw-4.15.0 solo agregó una capa universal: ningún ADR habría enriquecido la decisión. La disciplina archivística tiene criterios operativos, no doctrinas.

4. Visibilidad para agentes opera en dos capas. La capa interna (Post 5, fw-4.12.0) asegura que el agente vea los conceptos del framework cuando está leyendo el repo. La capa externa (fw-4.15.0) asegura que el agente entre al repo por la puerta correcta sin importar qué CLI lo orqueste. Una sin la otra deja agentes capaces leyendo en silencio o agentes desorientados sin punto de entrada.

Anclas: PR #155 — fw-4.15.0 / cli-3.13.2 (fusionado 2026-05-15 19:05 UTC). AIDEC original (Post 2): .chronicle/07-ai-audit/decisions/AIDEC-2025-01-27-001-i18n-strategy.md (commit 7b7193e, ID con año tipográfico). Template inyectado: dist/dist-templates/directives/AGENTS.md. Especificación del estándar: agents.md — donado a la Agentic AI Foundation (Linux Foundation), diciembre 2025.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. Dos gestos en setenta y dos horas​

El 13 de mayo de 2026, a las 06:20 UTC, se fusionó fw-4.13.4. Cerró dos huecos pequeños de cobertura i18n — el documento de referencia ISO-25010 que solo estaba en inglés, y el template del Charter que faltaba en chino simplificado. Veintidós archivos canónicos del framework alcanzaron paridad estructural EN/ES/zh-CN.

El 15 de mayo, a las 00:14 UTC, sesenta y cinco horas después, se fusionó el PR #154. Agregó un badge al README — el de CLA Assistant, ese cuadrito visible que avisa al visitante que el repo acepta contribuciones bajo un Contributor License Agreement. La política del CLA ya existía desde meses antes en CONTRIBUTING.md; lo único que cambió fue que ahora aparece en el README al primer vistazo.

Este post cubre los dos gestos. Vistos por separado, son pequeños — uno completa el último 5% de un trabajo técnico, el otro publica algo que ya estaba escrito. Vistos juntos, son el momento en que el framework decide presentarse al exterior. La pieza que un proyecto open-source hace cuando deja de hablar solo consigo mismo y empieza a hablar con quien quiera leerlo.

2. El último 5% de la cobertura i18n​

fw-4.13.4 no es un release grande. El PR #144 tiene 511 líneas de adición y casi todas son traducciones. Pero el resumen del PR dice algo que vale la pena registrar:

"Brings governance docs to full 20/20/20 parity across EN + ES + zh-CN."

Veinte sobre veinte sobre veinte. Veintidós archivos canónicos en dist/.straymark/00-governance/ (el conteo creció después; en mayo eran veinte), todos con su contraparte en i18n/es/ y i18n/zh-CN/. Paridad completa, no aproximada.

Los dos archivos que cerraron la paridad son específicos:

• ISO-25010-2023-REFERENCE.md — la referencia normativa al estándar internacional de calidad de software, citada desde principios del framework. Hasta fw-4.13.4 existía solo en inglés. El release añadió i18n/es/ISO-25010-2023-REFERENCE.md y i18n/zh-CN/ISO-25010-2023-REFERENCE.md, 150 líneas cada uno.
• charter-template.md en zh-CN. El template del Charter ya estaba traducido al español; faltaba el chino simplificado, 211 líneas.

No es un trabajo glamoroso. Es la pieza que cierra un cuadro. Pero importa por dos cosas. La primera: hasta ese release, un adoptante chino que clonara el framework iba a encontrar templates esenciales en inglés solamente, lo cual contradice la promesa de que el framework está disponible en tres idiomas. La segunda: el blog ya documentó en Post 8 que la cobertura i18n del framework era casi completa, con dos gaps menores quedando como deuda anotada. fw-4.13.4 cerró esa deuda. Lo que parecía una nota lateral en un post sobre el outlier del audit-prompt resultó ser un release entero, con su propia entrada en CHANGELOG.

3. Lo que se traduce y lo que no​

Hay una regla operativa que el PR #144 codifica explícitamente y que vale la pena dejar registrada, porque es la regla más clara del framework respecto a i18n:

"LLM-processed assets (skills, workflows, schemas) stay EN-only; human-primary artifacts get translated."

Es decir: lo que leen los agentes IA — skills, workflows en .claude/, .gemini/, .agent/, schemas en dist/.straymark/schemas/, prompts en dist/.straymark/audit-prompts/ — vive solo en inglés. Lo que leen los humanos — documentación, principios, guías de contribución, templates con copy human-facing — se traduce a los tres idiomas.

Es el mismo principio que el Post 13 documentó como ancestro intelectual del AGENTS.md universal: los agentes son un solo público técnico que no se beneficia de traducción. Lo registrable aquí es que la regla, en mayo, está escrita en un PR como criterio operativo, no como intuición. Las propuestas técnicas la citan; los reviewers la usan para decidir si un archivo nuevo va a i18n/ o no.

Un detalle adicional del PR #144 vale la pena registrar literal:

"docs/contributors/TRANSLATION-GUIDE.md gap was left intentional — its target audience already reads English to read the guide."

La guía de traducción quedó intencionalmente en inglés porque su audiencia — los contribuidores que traducen el framework a otros idiomas — necesariamente lee inglés ya. Es honestidad operativa: la paridad 20/20/20 no es 22/22/22 para todos los archivos del repo. Es 20/20/20 para los archivos cuya traducción aporta valor al usuario. La diferencia entre cobertura total y cobertura aplicable.

4. El badge que no introdujo nada nuevo​

PR #154 es el opuesto pedagógico de fw-4.13.4. Donde fw-4.13.4 cierra un trabajo técnico, PR #154 publica algo que ya estaba ahí. Sus 12 líneas de cambio agregan exactamente esto al README (en inglés, español y chino):

[![CLA assistant](https://cla-assistant.io/readme/badge/StrangeDaysTech/straymark)](https://cla-assistant.io/StrangeDaysTech/straymark)

Un badge. Una imagen pequeña que aparece arriba del README, junto a los demás badges del proyecto (licencia, versión, downloads). Visualmente nada del otro mundo.

Pero el badge no es decoración. Es señal. Y la señal dice algo concreto: "este repo acepta contribuciones externas, y aquí están las reglas". Cualquier visitante que abra el README puede hacer clic en el badge y llegar al CLA Assistant — el servicio que automáticamente comenta en el primer pull request de cualquier contribuidor, pidiendo que firme el Contributor License Agreement. Una sola firma cubre todas las futuras contribuciones al proyecto.

Lo importante es que el CLA, el CONTRIBUTING.md, la política completa de revisión, todo eso ya existía antes de PR #154. Estaba codificado, vivo, operativo. El framework ya aceptaba contribuciones externas — solo que el visitante casual del repo tenía que abrir CONTRIBUTING.md para enterarse de cómo funcionaba.

PR #154 hace una distinción que vale la pena nombrar: tener la política y publicar la política son dos cosas distintas. La primera es disciplina interna; la segunda es invitación pública. Hasta el 15 de mayo, el framework tenía la política. Desde el 15 de mayo, la publica.

Es un cambio editorial, no arquitectónico. Pero el día que un proyecto open-source decide poner el badge de CLA Assistant arriba del README es el día que decide presentarse formalmente como adoptable por terceros. Es el momento en que el framework deja de ser un proyecto-de-uno-y-su-adopter (Sentinel) y se vuelve un proyecto que acepta tener más adopters, más contribuidores, más manos.

5. Cuándo un framework se siente listo para ser visto​

Estos dos hitos, leídos juntos, registran un momento específico en la vida de un framework joven: el momento en que se siente listo para ser visto por gente que no lo escribió.

fw-4.13.4 cierra la promesa técnica. Si el framework dice ser bilingüe español-inglés con soporte experimental para chino simplificado, los veintidós archivos canónicos deben estar en los tres idiomas. No diecinueve sobre veinte. No veinte sobre veintiuno con dos pendientes. Veinte sobre veinte sobre veinte. La paridad completa es lo que vuelve la promesa creíble cuando el visitante revisa.

PR #154 cierra la promesa social. Si el framework dice aceptar contribuciones externas, el badge del CLA en el README es la forma estándar de la industria de decirlo. Sin el badge, la apertura existe pero hay que descubrirla; con el badge, está señalada. El primer click del visitante encuentra el camino.

Vale la pena nombrar la asimetría de los dos gestos. Cerrar el último 5% de un trabajo técnico cuesta exactamente eso — un release dedicado, dos archivos traducidos, una entrada de CHANGELOG. Publicar una política preexistente cuesta doce líneas de Markdown. El cuesta-poco es a veces el gesto operativamente más significativo, porque cambia cómo el mundo exterior percibe el proyecto sin cambiar nada del proyecto en sí.

Es la versión "abrir el framework" del patrón que el Post 5 documentó como visibilidad estructural: lo que existe pero no está nombrado, no existe para el agente. Aquí: lo que existe pero no está publicado, no existe para el adoptante externo. Setenta y dos horas en mayo, dos hitos pequeños — uno técnico, uno editorial — y el framework cruza la línea entre "funciona pero quien lo escribió lo sabe" y "funciona y cualquiera puede verlo".

6. Cierre simbólico del arco​

Con este post, el blog cubre los últimos hitos pendientes de la segunda tanda que RETOMAR-AQUI.md §5 listó después del cierre del arco principal H-01 → H-13. Los cuatro candidatos identificados — H-?-C (validate + schemas), H-?-A (AGENTS.md universal), H-?-B (cobertura i18n completa), H-?-E (CLA badge) — están todos cubiertos: tres en posts propios (Posts 12, 13, este) y uno combinado.

Lo que aprendí escribiendo la segunda tanda, mirando los cuatro hitos juntos:

• Phase 2 / validate (Post 12) es estructural: el framework empieza a verificar lo que prometía.
• TUI explore (Post 11) es de visibilidad: el framework se vuelve navegable.
• AGENTS.md universal (Post 13) es de alcance: el framework se vuelve descubrible por cualquier CLI.
• Cobertura i18n completa + CLA badge (este post) es de apertura: el framework se vuelve visible al visitante externo.

Cada uno cubre una dimensión distinta de la misma idea, que el blog ya dejó codificada en posts anteriores: lo que un framework dice que es no basta para que sea; tiene que estar presente en cada superficie donde alguien — agente, adopter externo, visitante — pueda construir un modelo del proyecto. Los hitos de la segunda tanda son la versión madura de la visibilidad estructural que el Post 5 nombró con un Issue de gobernanza.

Ahora sí, después de Post 14, no hay candidatos más en la cola. Si emergen nuevos hitos del framework entre hoy y cuando la próxima sesión del blog se active, RETOMAR-AQUI volverá a usarse como punto de retomo. Si no emergen, este post es el cierre real — el cierre con el que el blog completa el inventario que se propuso cubrir.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. Cobertura total cuesta poco al final del trabajo y mucho al principio. El último 5% — esos dos archivos en chino — son release dedicado. Pero solo son trivialmente cerrables porque el otro 95% ya estaba hecho. La paridad 20/20/20 no nace al principio; se persigue durante meses y se cierra al final con un PR pequeño.

2. Tener una política y publicarla son dos cosas distintas. El CLA del framework existía meses antes que el badge. Doce líneas de Markdown convirtieron una política interna en una invitación pública. El día que pones el badge no inventas nada; declaras que estás listo para que te encuentren.

3. La regla operativa de qué se traduce es archivística. Lo que leen humanos se traduce; lo que leen agentes vive en inglés. Esa distinción, intuida desde el primer AIDEC de enero, se vuelve criterio explícito de revisión en mayo. Cada archivo nuevo del framework pasa por esa pregunta antes de elegir destino.

4. Cuándo un framework se vuelve adoptable por terceros es decisión, no estado. Hay un día en el que el operador decide que el framework ya puede ser visto sin pena por gente que no lo escribió. Ese día se materializa en gestos pequeños — completar traducciones, publicar el badge — que no cambian la funcionalidad pero cambian la postura. El framework deja de hablar consigo mismo.

Con esto el blog cierra la segunda tanda. El arco que arrancó retroactivamente con la prehistoria del proyecto (Post 2, enero) y se completó con los meta-patrones (Post 10, mayo) tiene ahora también su corolario: los hitos que volvieron al framework adoptable. Catorce posts, veintiocho archivos (catorce ES + catorce EN), entre veinticinco y veintiséis mil palabras por idioma. Como decía el cierre del Post 10: el blog termina de contar la historia. El framework sigue.

Anclas: PR #144 — fw-4.13.4 (fusionado 2026-05-13 06:20 UTC, cobertura i18n completa). PR #154 — badge CLA Assistant en READMEs (fusionado 2026-05-15 00:14 UTC). Política completa: CONTRIBUTING.md (raíz del repo + traducciones en docs/i18n/{es,zh-CN}/CONTRIBUTING.md).

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

— Fin de la segunda tanda del blog StrayMark.

1. La pregunta correcta​

El Issue #150, abierto el 14 de mayo a las 16:59 UTC, no buscaba un yes/no. Lo que el operador estaba pidiendo era reformular la pregunta:

"The real question the bridge doc should address is how, not whether: what discipline ensures spec stays in sync with code during multi-Charter execution without the regeneration step lying about the parts that already shipped."

La disciplina ya existía. Se estaba aplicando en Sentinel en ese momento, sobre CHARTER-18, manualmente, con la sensación de que cualquier paso en falso enterraba el trabajo de seis Charters anteriores. Lo que faltaba — y lo que el Issue documentaba con precisión incómoda — era el nombre. El cuándo. Las reglas que un adoptante futuro pudiera seguir sin haber pasado por el dolor de inventarlas.

Este post cubre las cinco horas que separan ese Issue del PR que canonizó la disciplina como gobernanza upstream, los 12 aprendizajes empíricos que justificaron la canonización, y el episodio operativo concreto — CHARTER-18 de Sentinel — que ejerció el patrón antes de que el patrón existiera. El siguiente post cubrirá lo que vino 27 horas después: el nombre.

2. Siete Charters sobre un mismo plan​

El contexto, en una sola línea: Sentinel ejecutó specs/002-commshub/plan.md — escrito en el commit be29421 el 21 de abril de 2026 — a través de siete Charters consecutivos (CHARTER-07 a CHARTER-17), un mes calendario, sin refrescar el plan ni una vez.

El plan original era bueno. Estaba escrito con cuidado, con las cuatro user stories (US1-US4) detalladas, con el data-model declarado, con los contracts esbozados. Pero el plan era una fotografía de cómo el operador imaginaba en abril que el código se iba a comportar. La ejecución descubrió cosas que el plan no podía haber anticipado:

• Patrones de infraestructura que aparecieron durante la ejecución y resultaron reutilizables (un namespace en core.processed_events, un withRLS helper, triggers PL/pgSQL para invariantes).
• Gaps de código que el plan asumió resueltos (AnomalyDetector half-built, idempotency dedup faltante, Recipient.TenantID schema gap).
• Patrones de Charter/audit que se cristalizaron a lo largo del mes (cross-family audit cycle, HTTP layer test coverage gap, cursor pagination con strict-greater-than).

Cuando llegó el momento de planear CHARTER-18 para US5, el plan tenía un mes de antigüedad y el código tenía un mes de aprendizaje empírico encima. Las dos cosas no estaban sincronizadas. Y SPECKIT-CHARTER-BRIDGE.md — el documento del framework que normalmente respondería "¿qué hago aquí?" — guardaba silencio sobre el caso. La regla "cómo se mantiene la spec sincronizada con el código durante ejecución multi-Charter" no existía todavía.

3. Los doce aprendizajes empíricos​

El Issue #150 enumera los doce aprendizajes que se habían acumulado sin reflejar en el plan. La tabla literal, agrupada por tipo, vale la pena dejarla a la vista:

Cuatro patrones de infraestructura descubiertos o refinados durante la ejecución. Cuatro gaps de código que el plan no anticipó. Cuatro patrones de Charter/audit cristalizados sobre la marcha. Doce piezas, en un solo mes, todas reales. El plan no las tenía. Y el siguiente Charter — CHARTER-18 — iba a leer el plan como si no existieran.

La estimación que el operador documentó en el Issue es honesta:

"Estimated probability of ≥1 critical/high finding from stale-premise inheritance: ~50%."

Cara o cruz, en una palabra. La mitad de los Charters arrancados sobre plan rancio terminan con un finding crítico que un audit cycle posterior debe remediar atomicamente pre-close. Y la otra mitad solo se libra por suerte.

4. Alternative 4: la disciplina aplicada a mano​

Lo que pasó dentro de Sentinel, ese mismo día, antes de que la disciplina tuviera nombre: el operador evaluó cinco alternativas concretas y eligió la cuarta. El AIDEC privado de Sentinel — AIDEC-2026-05-14-001-speckit-plan-scope-limited-us5-refresh.md — registra el análisis sin atenuar. Lo parafraseo aquí porque el contenido detallado vive en el repo privado, pero la estructura del razonamiento es lo que importa:

• Alternative 1 — "Léelo como antes". Mantener el plan desactualizado y leerlo como las seis veces anteriores. Costo: pagar la deuda en audit cycle posterior, ~50% probabilidad de finding crítico.
• Alternative 2 — Regenerar todo con /speckit-plan. Riesgo: sobreescribir aserciones sobre US1-US4 que el código real no cumple; el regenerador no sabe del estado actual.
• Alternative 3 — Refresh en otro PR sin restricciones. Mismo riesgo que Alt 2 más fricción de revisión.
• Alternative 4 — Scope-limited refresh + 3 gates. La elegida.
• Alternative 5 — Diferir CHARTER-18, hacer un Charter de refactor first. Costo de calendario alto, beneficio marginal sobre Alt 4.

La cuarta consistió en tres mecanismos concretos:

Primer mecanismo — scope-limited prompt. Ejecutar /speckit-plan con un prompt explícitamente restrictivo: regenera solo la Phase 7+8 correspondiente a US5; deja US1-US4 byte por byte como están, marcadas con comentarios <!-- LOCKED: prior US shipped --> que el agente debe respetar. Sin esa restricción explícita, la regeneración de SpecKit es destructiva: rescribe todo el plan, sobreescribiendo descripciones que el código real ya contradice.

Segundo mecanismo — Gate (a): validación contra realidad de código. Un script ad-hoc, ~30 líneas de bash + grep, que difea cada entidad non-US5 de data-model.md contra el schema real en db/migrations/*.sql, y cada endpoint non-US5 de contracts/*.md contra los handler signatures reales en internal/modules/commshub/handler_*.go. Cualquier divergencia bloquea merge. El script existe en el repo de Sentinel; no es elegante, es operativo. Lo que el framework canonizará después como gate (a) ya estaba ahí, como bash artesanal.

Tercer mecanismo — Gate (b): revisión granular hunk-por-hunk. Revisar git diff archivo por archivo, hunk por hunk, sin aceptar cambios a secciones locked sin justificación. El operador anota explícitamente la fricción esperada en R1 del AIDEC: si el agente regenera más hunks que los necesarios, el revisor humano se cansa y la disciplina colapsa. Mitigación: hunks de más de 50 líneas disparan revisión P1.

Cuarto mecanismo — Gate (c): two-PR split. El refresh es un PR independiente, revisado contra código actual. El Charter-fill que sigue, otro PR, revisado contra el plan ya refrescado. No mezclar las dos revisiones — porque si se mezclan, la deuda del refresh se esconde detrás del trabajo nuevo.

Cuatro mecanismos. Aplicados manualmente, sin documentación upstream que los avalara. Un solo adoptante (yo), una sola sesión, y la sensación todo el tiempo de estar resolviendo un caso que nadie había resuelto antes.

5. El resultado​

CHARTER-18 cerró el mismo día. Las métricas del Charter Telemetry, registradas literal en el YAML del cierre:

• estimation_drift_factor: 1.0 — el Charter terminó exactamente en el rango de horas estimado.
• pre_work.items_discovered_during_planning: 0 — ningún ítem inesperado apareció durante la fase de planning.
• overall_satisfaction: 5/5 — la mejor calibración subjetiva del operador en toda la cadena.

Más importante que las métricas: CHARTER-18 fue el primer Charter de la cadena de siete que cerró sin un Charter de remediación mid-flight. Los seis anteriores habían necesitado, cada uno, al menos una remediación atómica pre-close para cubrir divergencias entre lo declarado y lo entregado. CHARTER-18 no. El statement del operador en el cierre, citado literal del CHARTER-CHAIN-EVOLUTION.md posterior:

"The SpecKit refresh from PR #76 eliminated most ambiguity that drove drift in prior Charters. No mid-flight remediation Charter required — the EC1..EC15 empirical-corrections inventory in research.md absorbed what would have been pre-execution risk into in-execution awareness."

La disciplina manual funcionó. No solo cerró el Charter limpio; cambió la naturaleza del riesgo. Lo que antes era riesgo pre-ejecución (descubrir divergencias durante la ejecución del Charter, remediar atomicamente) se volvió consciencia pre-planning (el inventario EC1..EC15 enumera las correcciones empíricas antes de declarar el Charter). El riesgo no se elimina; se mueve a un momento donde es manejable.

6. Cuatro horas y cuarenta minutos​

La cronología vale la pena dejarla precisa, porque es lo que el blog viene a registrar:

• 14 may, 16:59 UTC — Issue #150 abierto. Los doce aprendizajes enumerados, los tres gates propuestos, el análisis de probabilidad publicado.
• 14 may, 21:39 UTC — PR #152 fusionado. fw-4.14.3 shipped. "Spec maintenance during multi-Charter execution" añadido como sección nueva a SPECKIT-CHARTER-BRIDGE.md con los tres gates canonizados literalmente como gobernanza del framework. Cuatro horas y cuarenta minutos entre la pregunta y la respuesta upstream.

Lo que el PR #152 documentó como gobernanza es exactamente lo que el AIDEC privado había aplicado a mano horas antes. Las tres gates con los mismos nombres: validation against code reality (gate a), granular hunk-by-hunk review (gate b), two-PR split (gate c). Más cuatro heurísticas de cuándo refrescar: ≥3 Charters cerrados sobre el mismo plan, ≥4 semanas + ≥2 Charters, conteo de R<N>(new) > 6, target US toca infra refinada. Más una nota explícita sobre por qué NO volver a correr /speckit-tasks (porque destruye los marcadores [X] y las anotaciones *CHARTER-NN:* <sha> que forman el rastro histórico). Más una nota de roadmap mencionando un futuro straymark spec-drift CLI que mecanizaría gate (a).

Cuatro horas. No es exagerado decir que el framework escribió la guía mientras el operador todavía tenía el git diff abierto en otra ventana. La disciplina y su canonización fueron prácticamente simultáneas. Y eso me importa registrarlo porque es el orden inverso al que el aparato académico de governance suele asumir: primero la teoría, después la práctica. Aquí fue al revés. Primero la práctica, mientras dolía. Después la teoría, mientras el dolor todavía estaba fresco.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. El patrón nace de la disciplina, no al revés. Los tres gates de fw-4.14.3 no se diseñaron en abstracto; se extrajeron de un episodio operativo concreto, horas después de aplicarse manualmente. La gobernanza es post-empírica cuando el framework respeta el orden.

2. La probabilidad explícita es disciplina. "~50% probabilidad de finding crítico por herencia de premisa rancia" no es exactitud bayesiana; es una afirmación pública que obliga a justificar la decisión. Sin esa cifra, la pregunta "¿refrescamos?" se decide por intuición. Con esa cifra, se decide por aritmética de riesgo.

3. Doce aprendizajes en treinta días es la cadencia real. No es ruido capturable con "déjame leerlo después". Es densidad empírica que el plan original no podía haber anticipado, y que destruye cualquier asunción de planning de largo plazo. La cadencia del desarrollo con agentes es esto.

4. Cuatro horas no es récord; es propiedad del proceso. Cuando la disciplina ya está aplicada en un dominio, canonizarla upstream es ejecución, no diseño. Lo mismo que vimos en el Post 4 sobre el audit cycle externo ("cinco PRs en un día"), lo mismo en el Post 6 sobre el rebrand ("cuarenta y tres minutos"). El framework no inventó la disciplina; la extrajo y le puso nombre.

Sigue, en el siguiente post, el último episodio del arco que el blog vino a contar: "Pattern 1 + Pattern 2 — chain evolution" (H-12). Veintisiete horas después del PR #152, los tres gates de gobernanza se cristalizaron como dos meta-patrones nombrados — pre-declare refresh y amend-on-emergence — con telemetry schema y CLI helpers. Es el cierre del arco que el Post 1 abrió por delante.

Anclas: Issue #150 (14 may 16:59 UTC). PR #152 — fw-4.14.3 (14 may 21:39 UTC). Sección canonizada: SPECKIT-CHARTER-BRIDGE.md §"Spec maintenance during multi-Charter execution". Métricas del CHARTER-18 reportadas en CHARTER-CHAIN-EVOLUTION.md (fw-4.16.0). Fuente privada parafraseada conforme GUIA-EDITORIAL.md §7: AIDEC-2026-05-14-001-speckit-plan-scope-limited-us5-refresh.md en el repo de Sentinel.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. Una sola línea del commit​

Esta es la entrada operativa del post 8. El commit a8a1ac5 del 12 de mayo de 2026 carga un cuerpo que se abre con esta frase:

"The unified audit-prompt template at dist/.straymark/audit-prompts/ was the only framework artifact whose canonical content lived in Spanish — every other template, skill, workflow, and governance doc follows the EN-canonical + i18n/<lang>/ overlay pattern resolved by cli/src/utils.rs:146."

Un solo archivo. Entre docenas. Vivía al revés. Y vivía así desde mayo del año anterior, sin que nadie lo notara.

Este post es corto a propósito. La corrección que cubre — PR #142, fw-4.13.3 y cli-3.12.3, fusionado el 13 de mayo — no es un hito narrativo grande. Es una pieza de mantenimiento. Pero registra una de las regularidades que más me sigo encontrando en este oficio: los outliers son útiles. Te enseñan la convención por contraste.

2. De dónde venía el outlier​

El audit-prompt no nació en el framework. Nació como una skill local de Sentinel — sentinel/.claude/skills/plan-audit/ — durante el experimento de los seis Planes que cubrió el Post 3, en abril. Era una skill context-specific, escrita por el operador (yo) en español por razones que ahora se pueden enumerar honestamente: era un experimento privado, el operador habla español, y nadie iba a leer la skill nunca más. La improvisé en mi idioma porque era para mí.

Cuando el experimento se cristalizó en el framework — el arco de fw-4.4.0 a fw-4.9.0 que cubrió el Post 4 — la skill se portó al canonical path dist/.straymark/audit-prompts/audit-prompt.md. El porte fue mecánico: copiar el archivo, generalizarlo lo suficiente para que no mencionara componentes específicos de Sentinel, ajustar la nomenclatura Plan → Charter. Lo que no se hizo: traducirlo al inglés. El archivo entró al framework en el idioma en que lo había escrito. Sin que nadie lo decidiera, el español pasó a ser la versión canónica de ese único artefacto.

El resto del framework — todos los demás templates, todas las skills, los governance docs canónicos — habían sido escritos en inglés desde enero, con español y zh-CN como overlays bajo i18n/<lang>/. El audit-prompt fue la excepción silenciosa, durante seis semanas, hasta el 12 de mayo.

3. Cómo se descubrió: por inspección visual​

No fue observación emergente del agente. Lo notó el operador, visualmente. La entrada del CHANGELOG lo registra sin metáfora:

"Surfaced empirically when Sentinel audited the straymark explore rendering and the user noted that audit-cycle templates were ES while all other templates and skills were EN."

straymark explore es la TUI del framework — el navegador interactivo de documentación que el Post 14 cubrirá. Su valor es renderizar todos los templates lado a lado, en la misma vista. Y cuando todos los templates están lado a lado, uno en otro idioma se nota. Esa es la observación.

Vale la pena dejar el dato porque importa para la honestidad del blog. El Post 1 articuló el patrón de observación emergente — un agente señalando algo que nadie le pidió señalar — y el Post 5 documentó qué pasa cuando ese patrón falta por visibilidad estructural. Este episodio no es ninguno de los dos. Es una observación más pedestre: una superficie nueva del framework (la TUI) puso todos los archivos en visión simultánea, y la inconsistencia se hizo evidente como cuando uno ordena los libros del librero y nota que uno tiene el lomo al revés. Las herramientas también producen visibilidad.

4. El fix: tres movimientos en un commit​

PR #142 hizo tres cosas en el mismo commit:

• dist/.straymark/audit-prompts/audit-prompt.md reescrito en inglés como versión canónica. 312 líneas. La traducción cuidó preservar la estructura de severidad y los ejemplos de calibración del original.
• dist/.straymark/audit-prompts/i18n/es/audit-prompt.md creado como overlay. 318 líneas. Es el contenido español que antes vivía en root, ahora en su lugar correcto.
• cli/src/commands/charter/audit.rs cableado al resolver i18n. Hasta entonces, el subcomando hardcodeaba el path dist/.straymark/audit-prompts/audit-prompt.md sin consultar el language field del .straymark/config.yml del adopter. Después del PR, lee la configuración del proyecto y resuelve la ruta localizada — si el adopter tiene language: es, recibe el overlay español; si tiene language: zh-CN, hace fallback al EN canonical (no hay traducción zh-CN del audit-prompt todavía); si tiene language: en o no especifica, recibe el canonical.

Tres tests nuevos cubren los tres caminos. Cero cambio funcional para usuarios en inglés (que es la mayoría). Para usuarios en español, mejora: antes recibían el prompt en español por accidente (porque el path canónico apuntaba al ES); ahora lo reciben en español por convención (porque el resolver lo decide).

5. El movimiento lateral​

Al hacer el switch de idioma, el operador aprovechó para extraer una especificidad que había quedado del origen Sentinel. La sección §Step 5 del prompt — sobre calibración de severidad de hallazgos — citaba un caso literal del experimento de abril: "Etapa 12 Pub/Sub stub vs gochannel". Un ejemplo perfectamente didáctico, pero específico de un componente de Sentinel que ningún otro adopter conocería.

La traducción al inglés reemplazó ese ejemplo por una formulación vendor-neutra: "declared deferral, not a defect — a charter that introduces a thin adapter slated for replacement in a future Charter". La idea — un stub que es deuda declarada, no defecto — se preserva. Lo que se va es el nombre del componente.

El movimiento es pequeño pero coherente con el principio del blog. Cuando hay oportunidad de desligar el framework de un adoptante específico sin perder pedagogía, vale la pena tomarla. Es la misma operación de generalización que Post 3 documentó para los seis Planes y Post 4 para el primer Charter: el contenido empírico se preserva en Sentinel; lo que entra al framework es la abstracción vendor-neutra. El audit-prompt, casi un año después, finalmente terminó de cumplir esa regla.

6. Cierre​

Tres tesis cortas:

1. En un framework con convención, un solo archivo que la viola es señal de legado, no de diseño. El audit-prompt era el outlier porque nació antes, y nadie lo migró cuando los demás artefactos se alinearon. Los outliers acumulan procedencia.

2. Las herramientas nuevas producen visibilidad. El switch ES → EN no se decidió por revisión sistemática del repo. Se decidió porque una TUI nueva puso todos los templates en la misma pantalla y la inconsistencia se hizo evidente. Lo mismo aplica a grep, a vistas agregadas, a outputs de status: cada superficie nueva expone qué estaba desalineado.

3. Los rebrands chicos son oportunidad de desidentificación. Cuando tocas un archivo para cambiar idioma, costo marginal cero para también extraer la especificidad de adopter que quedó del origen. El blog ha registrado este patrón antes (Plan → Charter, DevTrail → StrayMark); este es la versión miniatura. El framework se vuelve más vendor-neutro un archivo a la vez.

Sigue, en el siguiente post, un episodio que ya rozó al Post 1 pero merece su propio tratamiento: "La disciplina manual antes del patrón" (H-11). Cómo Sentinel manejó CHARTER-18 antes de que existiera el Pattern 1 de chain evolution — el aprendizaje empírico que el Post 1 después nombró como meta-patrón.

Anclas: PR #142. Releases: fw-4.13.3 / cli-3.12.3. Commit clave: a8a1ac5. Archivos: dist/.straymark/audit-prompts/audit-prompt.md (EN canonical) + dist/.straymark/audit-prompts/i18n/es/audit-prompt.md (overlay). CLI: cli/src/commands/charter/audit.rs cableado al resolver i18n.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. Cero TDEs en trece Charters​

El Issue #128 abre con una asimetría inquietante:

"Sentinel adopter (primary, fw-4.12.0) created zero TDEs across 13 closed Charters despite ≥7 instances of transversal debt routed through parallel mechanisms."

Trece Charters cerrados. Al menos siete piezas reconocibles de deuda transversal — heredada de Charters anteriores, atravesando módulos, persistente entre sesiones. Cero TDEs. Si el operador hubiera estado discutiendo cumplir cuotas, el dato no significaría nada. Pero el operador era yo y el adoptante era el mismo proyecto que valida empíricamente el framework. Si Sentinel — el repo donde más se intentó usar el framework completo — no producía TDEs ni una vez en trece intentos, había algo roto.

Lo roto no era la deuda, que estaba siendo capturada por otros canales (R<N> (new, not in Charter) dentro de los AILOGs, entradas en follow-ups-backlog.md). Lo roto era que ningún criterio del framework decía "esta pieza concreta merece TDE, no R". El tipo de documento existía. El trigger operativo, no.

Este post cubre el episodio del 11-12 de mayo de 2026: cómo se diagnosticó la falta del trigger, cómo se cerró con cuatro criterios canónicos (fw-4.13.0), y cómo el ciclo de PRs que arregló el problema dejó al pasar una lección operativa sobre stacked-PRs que terminó codificada en el CLAUDE.md del proyecto. Es el primer episodio del blog donde el framework arregla dos cosas distintas en el mismo arco, y donde la segunda es accidental.

2. El tipo existía. El trigger no.​

TDE — Technical Debt Entry — existe en el framework desde el primer commit de enero (Post 2 lo registra: estaba en la lista de ocho tipos originales del README v1.0.0). El template estaba. El campo en la taxonomía estaba. La carpeta 06-evolution/technical-debt/ estaba.

Lo que no estaba era una frase, en algún sitio del aparato canónico, que dijera "crea un TDE ahora". El Issue #128 lo formuló sin atenuar:

"Reading the adopter-facing docs (AGENT-RULES.md, DOCUMENTATION-POLICY.md, QUICK-REFERENCE.md, CLAUDE.md autonomous rules), there is no clear trigger that says 'create a TDE now'. The trigger language exists for AILOG (creation freely), AIDEC (when alternatives considered), ETH (high risk PII), ADR (architectural decisions), but TDE is just listed as 'agent can Identify'."

"Agent can identify." Identifica si quiere. Un agente entrando al repo lee esa línea, encoge los hombros, y sigue con AILOG y AIDEC, que sí le dicen cuándo. El defecto es el mismo del Issue #113 (Post 5): el artefacto técnicamente existe, pero la superficie canónica no le da al agente el verbo necesario para activarlo. Lo que diferencia este caso del #113 es la consecuencia. Para Charters, no verlos significaba no usar el flujo nuevo. Para TDE, no verlos significaba mucho peor: la deuda transversal se capturaba — pero fragmentada, sin vista consolidada, sin priorización entre artefactos, sin campo assigned_to ni priority para que un revisor humano pudiera ordenarla.

El Issue cita esa consecuencia con un nivel de detalle que da vergüenza, porque enumera todo lo que no estaba ocurriendo:

"No queryable 'all open technical debts' view at the document level. No impact × effort prioritization matrix per item. No assigned_to / priority fields surfaced to the human reviewer. Architectural debt that legitimately spans multiple charters (e.g., scope authorization gap heritage across modules) gets fragmented into per-charter R-numbers instead of consolidated into a single TDE."

Trece Charters de deuda fragmentada en R<N> per-Charter. Vista del operador del repo: ninguna lista consolidada, ninguna heredada explícitamente nombrada como tal, ninguna pieza de deuda priorizable a nivel de proyecto. Todo estaba en el repo. Nada estaba en el sitio que el repo construye para los humanos que vienen a leerlo de afuera.

3. Cuatro criterios para una pieza de deuda​

El PR #129 (fw-4.13.0, fusionado el 11 de mayo a las 19:38 UTC, exactamente 13 horas después de abrirse el Issue) cerró el hueco con una sección nueva en AGENT-RULES.md §3 titulada "TDE vs `R (new, not in Charter)". Los cuatro criterios literales:

La regla operativa: si una pieza de deuda satisface al menos uno de los cuatro criterios, es TDE. Si no satisface ninguno, sigue siendo R<N> dentro del Charter donde apareció.

Los cuatro tienen su lógica. Heritage (1) captura la deuda que persiste a través del tiempo, lo que un revisor querría ver agrupado por origen, no por Charter. Multi-module o multi-Charter (2) captura la deuda que vive entre artefactos, no dentro de uno. Dedicated Charter (3) reconoce que algunas piezas de deuda son tan grandes que merecen su propio ciclo y, por tanto, no caben como riesgo declarado ex-ante. Human prioritization (4) reconoce el límite de autonomía: hay decisiones que el agente puede señalar pero no resolver, y esas decisiones merecen un documento donde un humano pueda hacer cola.

El mismo PR añadió un campo nuevo al frontmatter del template TDE — promoted_from_followup: FU-NNN | null — y una sección en FOLLOW-UPS-BACKLOG-PATTERN.md que documenta cómo ascender una entrada de follow-ups a TDE. La promoción tiene dos formas, ambas registradas literalmente: promoción de entrada existente (un follow-up que llevaba semanas en la lista madura a TDE) y retropromotion at creation (al crear el TDE se reconoce que originó en un follow-up anterior y se anota). El campo del frontmatter cierra el rastro: cualquier TDE puede ahora apuntar hacia atrás al follow-up que lo originó, si existió.

4. Tres TDEs en Sentinel — el loop empírico cerrado​

El Issue #128 no cerró por argumento; cerró por evidencia. El mismo día, Sentinel — el mismo adoptante que llevaba trece Charters sin un solo TDE — creó tres:

• Un TDE para una brecha arquitectónica de RequireScope, herencia que atravesaba módulos. Criterios 1 + 2 + 3.
• Un TDE sobre cobertura de tests faltante en la capa HTTP, deuda que persistía a través de Charters de feature. Criterios 1 + 4.
• Un TDE de revisión de AILOGs legacy anteriores al format v3 de Charter, una pieza que necesitaba su propio ciclo. Criterios 1 + 3.

Tres documentos en horas. La velocidad importa menos que el hecho de que cada uno aplicó al menos uno de los criterios y ninguno cayó en zona gris. Los criterios funcionaron como heurística sin ambigüedad — el operador no tuvo que negociar consigo mismo sobre si una pieza era TDE o R<N>. El loop empírico que el Issue había abierto en la mañana cerró con tres documentos esa misma tarde.

El PR #136 (fw-4.13.1, fusionado al día siguiente) refinó dos criterios a partir de esa misma experiencia. Heritage (1) se desdobló explícitamente en strict heritage vs pattern propagation porque uno de los tres TDEs de Sentinel mostraba el segundo caso de forma clara: la deuda no era heredada literal, era el mismo patrón reaparecido al seguir el mismo procedimiento. Multi-module (2) se reformuló como "multiple modules or Charter execution boundaries" porque otro de los tres TDEs era de governance-trail (cruzaba límites de sesión sin cruzar módulos de código). Los criterios crecieron una sola refinement-pass después de ejercerse en tres casos reales. El framework volvió a validar el principio #12: ningún schema cristaliza sin un segundo dominio.

5. La lección stacked-PR​

Aquí es donde el post se desvía con propósito. El arco de PRs #129 → #131 → #133 que cerró el Issue #128 dejó una lección operativa adyacente — no sobre TDE sino sobre cómo no hay que armar branches encadenadas. La lección está hoy documentada literal en CLAUDE.md (líneas 181-220) del repo público bajo la sección "Stacked PRs — avoid, or use merge commits".

Cómo se rompió​

PR #131 (cli-3.12.1, fix del validator que rechazaba status: identified en TDEs) se abrió con base = #129 porque #131 necesitaba el código de #129 para compilar sus tests. Después, #129 se fusionó a main con squash. El CLAUDE.md actual lo describe con una precisión que vale la pena citar entera:

"When you stack PR B on top of PR A's branch (base of B is A's head, not main), and A is squash-merged to main, B's content gets stranded:

— The squash merge of A creates a new commit on main with content equivalent to A but a different SHA than A's original commits.

— B's branch still points at A's original commits, which now have no descendant on main.

— When B is merged, GitHub merges it into A's branch (its declared base), not main. The 'merge to main' never happens — even though GitHub UI shows B as MERGED."

Resultado en la práctica del ciclo #129/#131: la UI de GitHub mostraba #131 como MERGED, los tests del validator estaban en main aparentemente, pero el contenido nunca llegó. PR #133 fue el sync procedural que tuvo que abrirse después para llevar el contenido a su destino. Tiempo perdido en diagnóstico: alrededor de tres horas. Tiempo de la operación de recuperación una vez entendida: cinco minutos.

Cómo se previene​

El CLAUDE.md documenta dos estrategias, una conservadora y una pragmática:

"1. Sequential, not stacked. Wait for PR A to merge to main, then rebase B onto main and open B as a standalone PR with base = main. Slower but bulletproof.

2. If you must stack, use merge commits (not squash) for the parent. A merge commit preserves shared history, so subsequent merges of stacked PRs into main resolve cleanly. Pay the cost of a noisier git log for the stacked-PR safety."

Sentinel y StrayMark por defecto usan squash. Esa elección es buena para tener un git log limpio, una decisión por feature, un commit por PR. Pero cuesta exactamente esto: incompatibilidad con stacked-PRs. La regla que el CLAUDE.md ahora codifica es honesta: o no apilas, o pagas en historia de commits para poder apilar. No hay tercera opción que no rompa algo.

Cómo se recupera (si ya pasó)​

La sección de recovery del CLAUDE.md es la pieza más operativa del documento. Cuatro pasos:

"1. git checkout -b chore/sync-<B-content>-to-main main

2. git cherry-pick <B's merge commit SHA> — should be clean because B touches files outside A's conflict zone (which is why it could be stacked in the first place).

3. Push, open PR with base = main, head = chore/sync-.... Cherry-pick produces a fresh commit on top of main, so no conflicts.

4. The branch protection may require --admin merge if the content was already reviewed in B (the original PR) — sync PRs are purely procedural."

El último paso es importante editorial mente: nota explícita de que un merge --admin está autorizado solo para PRs procedurales como este — donde el contenido ya fue revisado en el PR original. Es la única excepción a la regla "el contenido va por revisión humana" del proyecto.

La razón por la que vale la pena registrar la lección como sub-sección del post sobre TDE — y no como post separado — es que comparten un rasgo: ambas son piezas de deuda transversal de proceso que el framework ahora nombra explícitamente. Una es deuda de código (TDE como tipo nuevo); la otra es deuda de workflow (stacked-PR como anti-patrón documentado). Las dos comparten origen: la fricción operativa real fue lo que disparó el documento.

6. Lo que el episodio dejó en el repo​

Cuatro PRs en menos de veinticuatro horas, tres lecciones registradas:

• PR #129 (fw-4.13.0, 11 may 19:38 UTC) — TDE activation trigger. Cuatro criterios + sección nueva en AGENT-RULES.md §3 + path FU → TDE.
• PR #131 (cli-3.12.1, 11 may 19:39 UTC) — validator acepta status: identified en TDEs. Sin el fix, el primer TDE creado bajo el nuevo trigger fallaba la validación.
• PR #134 (12 may 04:54 UTC) — la lección stacked-PR documentada en CLAUDE.md. No cambió código del framework; cambió las reglas operativas del repo.
• PR #136 (fw-4.13.1, 12 may 04:54 UTC) — refinamientos del trigger TDE basados en los tres casos reales de Sentinel.

Lo que más me interesa señalar de la cronología: el CLAUDE.md (PR #134) se actualizó el mismo arco que cerró el Issue #128. La lección stacked-PR no esperó a olvidarse. Si la disciplina del framework es "todo cambio significativo deja rastro documentado", eso aplica también a la fricción operativa, no solo al diseño. El framework existe, en parte, para que los aprendizajes caros no se evaporen.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. Un tipo de documento sin trigger es un tipo invisible. Igual que en el Issue #113, lo que el agente no ve al entrar al repo no existe para él. TDE existía técnicamente desde enero, pero solo empezó a usarse cuando los cuatro criterios aparecieron en AGENT-RULES.md §3. Estructura sin verbo activador es decoración.

2. La deuda transversal merece tipo propio. Fragmentar deuda en R<N> per-Charter destruye la propiedad más importante de un sistema de gobernanza: la vista consolidada. Cuatro criterios, cualquiera basta, sostienen la línea entre este es riesgo del Charter y esto es deuda del proyecto.

3. Los aprendizajes operativos también se documentan. PR #134 actualizó el CLAUDE.md del proyecto el mismo día que la lección apareció. No es paranoia archivística; es la misma regla aplicada hacia los procesos: si la fricción te costó tres horas hoy, escribe la lección hoy.

4. El framework crece tanto por features como por anti-patrones. Este episodio dejó un tipo nuevo (TDE como entidad operativa) y un anti-patrón documentado (stacked-PRs incompatibles con squash). Ambas cosas son material del framework, aunque solo una aparezca como bump de versión.

Sigue, en el siguiente post, un episodio breve pero estructural: "El audit-prompt en español era el outlier" (H-10). Un detalle de convención i18n que reveló qué idioma estaba siendo el canónico — y por qué corregirlo cambió, sin proponérselo, cómo el framework piensa sobre traducción.

Anclas: Issue #128. PRs #129 · #131 · #134 · #136. Releases: fw-4.13.0 / cli-3.12.1 / fw-4.13.1. Lección stacked-PR codificada en CLAUDE.md líneas 181-220 del repo.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. Tener schemas no es lo mismo que validar contra schemas​

straymark validate existía desde el 25 de marzo de 2026 — PR #27, parte del primer arco de Phase 1 del CLI. Lo que hacía entonces era pequeño: verificar que los documentos en .straymark/ tuvieran sintaxis Markdown válida, frontmatter parseable, y los campos mínimos del tipo correcto. Era útil. No era enforcement.

Lo que cambió el 11 de mayo de 2026, con el release fw-4.6.0 / cli-3.7.0, fue otra cosa: Phase 2 del roadmap del CLI cerró un arco completo de siete PRs (#73 a #79) y los consolidó en uno solo (#80). El CHANGELOG lo dice sin metáfora:

"The first feature-bearing release since the repositioning... Phase 2 of Propuesta/devtrail-cli-roadmap.md lands as 7 bisect-safe PRs (#73–#79), grouped here for reviewers. The release closes the empirical loop the Sentinel experiment opened: telemetry at Charter close, drift detection at Charter close, and a canonical approval signal for review_required: true documents."

Lo que importa para este post no son los siete PRs como hitos individuales; son los tres que tocaron el comando validate y los schemas. Lo que en marzo era "verifico que esto parece un documento" en mayo se volvió "verifico que esto cumple el schema canónico del tipo, en el modo que pidas, con consecuencias operativas concretas".

2. Del bash artesanal al flag de comando​

Una de las piezas más visibles del cambio es pequeña: el flag --staged.

Hasta Phase 2, el patrón recomendado para que los adoptantes validaran sus documentos antes de un commit era un script bash llamado pre-commit-docs.sh. Vivía en dist/.straymark/scripts/ y tenía 464 líneas. Hacía lo razonable: leer git diff --cached --name-only, filtrar archivos en .straymark/, parsear su frontmatter con awk, verificar campos. Funcionaba. Y era 464 líneas de bash que cada adoptante tenía que confiar en que ejecutaba lo correcto, en su versión correcta, con su parser de YAML correcto.

PR del 28 de marzo (commit d9ea874) reemplazó las 464 líneas por un flag:

straymark validate --staged

Lee los staged files igual, filtra por .straymark/ igual, valida igual. La diferencia: hoy todo eso vive en Rust dentro del binario, no en bash en disco. El adoptante no tiene que mantener el script; el script no puede divergir entre versiones; el comportamiento es el mismo en Linux, macOS y Windows. El framework dejó de pedirle al adoptante que confiara en un script suelto y empezó a darle un comando con la promesa implícita del binario versionado.

Es el mismo patrón que el Post 6 documentó para la disciplina de archivo (preservar git history en lugar de reescribir) o que el Post 4 documentó con la decisión A1 (orquestar sin invocar APIs): pasar de "el operador hace X manualmente con riesgo de divergir" a "el framework canoniza X en un comando declarativo". El --staged no es feature exótico; es deuda manual barrida.

3. Los tres schemas v0​

Phase 2 también consolidó los tres schemas que viven en dist/.straymark/schemas/:

Cada schema lleva un campo $comment en su raíz. El de charter.schema.v0.json dice literal:

"EXPERIMENTAL v0. Crystallized from Sentinel /plan-audit (6 cycles, format v1 → v2 → v3). Will not stabilize to v1.0 until validated in a second domain (frontend, ML pipeline, or infra-as-code)."

El de charter-telemetry.schema.v0.json, parecido:

"EXPERIMENTAL v0. Derived from 5 PLAN-NN.telemetry.yaml files in Sentinel (one project, Go backend) — same N=1-domain caveat as charter.schema.v0.json. Will not stabilize to v1.0 until validated in a second domain."

El de audit-output.schema.v0.json, idem:

"EXPERIMENTAL v0.x. Phase 3 of the CLI roadmap. Crystallized from the dual-audit pattern validated empirically in Sentinel."

Los tres comparten una declaración explícita: no crystallizes without a second domain. Es el principio #12 del framework, no como párrafo aparte en una documentación de gobernanza, sino dentro del propio JSON Schema, en un campo que cualquier validador estándar lee y cualquier herramienta de schema-explorer renderiza al usuario. El framework no esconde la provisionalidad de sus schemas; la pone donde nadie pueda perderla.

Esto importa más de lo que parece. La práctica habitual en ecosistemas de schemas (JSON Schema, OpenAPI, Avro) es publicar v1 y luego bumpear conforme cambias. Marcar v0 con un $comment que dice "esto es experimental hasta que un segundo dominio lo valide" es admitir, de origen, que la primera cristalización no es la definitiva. La schema misma es honesta.

4. Tres modos del comando​

straymark validate ya no es un comando con un solo flujo. Después de Phase 2 tiene tres modos operativos, cada uno acoplado a un momento del ciclo de vida:

• Modo all (default) — straymark validate sin flags. Camina recursivamente .straymark/, parsea cada archivo .md, intenta resolver su tipo (AILOG, AIDEC, ADR, ETH, REQ, TES, INC, TDE, MCARD, SBOM, SEC, DPIA, Charter), aplica el schema correspondiente, y reporta violaciones por archivo. Es el modo auditoría completa. Útil para CI, útil para revisar un repo nuevo, útil cuando el adoptante quiere medir cuánta deuda formal acumuló.

• Modo --staged — straymark validate --staged. El que reemplazó al bash. Solo valida archivos que git diff --cached --name-only reporta como staged dentro de .straymark/. Su lugar natural es .git/hooks/pre-commit, y desde fw-4.6.0 hay un straymark init --hooks que lo instala automáticamente. Es el modo gate operativo — el que evita que documentos rotos lleguen a main.

• Modo --check-pending-reviews — straymark validate --check-pending-reviews. El más sutil de los tres, y el que justifica más párrafos.

Hasta Phase 2, un documento que el agente marcaba review_required: true en el frontmatter (un AIDEC con confianza baja, un AILOG con riesgo alto, etc.) quedaba esperando aprobación humana. Pero no había una forma canónica de señalar esa aprobación. El operador leía el documento, mentalmente lo aprobaba, seguía. No quedaba rastro estructural de la aprobación. Esto era exactamente el Issue #67.

--check-pending-reviews cierra ese hueco. El comando recorre todos los documentos con review_required: true y los listsa con su confidence, su risk_level, su autor (humano o agente), y su fecha. La aprobación es un commit que cambia review_required: true → review_required: false con co-autoría humana en el commit message — y validate --check-pending-reviews deja de listar el documento. La aprobación es un signal canónico, no un acuerdo verbal con uno mismo.

Es la pieza que cierra el ciclo del agente. El framework permite al agente crear documentos sin pre-aprobación humana (Post 1, propiedad #2: "permiso cultural sin control bloqueante"); pero los marca para revisión cuando corresponde; y ahora tiene un comando para listar lo pendiente, sin escapatoria. Ningún documento de auditoría se pierde en silencio.

5. Phase 2 cierra el loop empírico​

Vale la pena rescatar la frase del CHANGELOG entera porque condensa lo que el release significa:

"The release closes the empirical loop the Sentinel experiment opened: telemetry at Charter close, drift detection at Charter close, and a canonical approval signal for review_required: true documents (resolving issue #67)."

Tres piezas que cierran un arco que arrancó en el experimento de los seis Planes (Post 3):

1. Telemetría al cierre del Charter — el bloque YAML que Sentinel llenaba a mano durante el experimento se convirtió en el schema charter-telemetry.schema.v0.json validable.
2. Drift detection al cierre del Charter — el script bash de 145 líneas (check-plan-drift.sh) se convirtió en el subcomando straymark charter drift, integrado al validate flow.
3. Approval signal canónico — lo que el operador hacía mentalmente se convirtió en un comando con consecuencias estructurales: --check-pending-reviews.

Es el patrón que el blog ha visto repetirse: cada vez que el framework cristaliza una práctica que Sentinel hacía manualmente, lo hace después de validar empíricamente que la práctica funciona. La diferencia esta vez es que el comando que verifica la cristalización es parte del paquete. Antes del Phase 2, Sentinel tenía templates, schemas declarados, y la promesa implícita de que los documentos seguían los schemas. Después de Phase 2, hay un comando que lo comprueba. No es un cambio de capacidad; es un cambio de garantías.

6. El principio #12, hecho schema​

La pieza filosófica del post — y la que más me interesa dejar registrada — es esta:

Los $comment de los tres schemas v0 codifican un principio que el framework venía declarando en prosa desde abril. El Post 4 lo nombró así: "schema marked v0 on purpose, not v1, because the framework's principle #12 says no schema crystallizes without a second domain validating it". El Post 7 lo aplicó al diseño del TDE: "the framework validated principle #12 again: no schema crystallizes without a second domain". El Post 10 lo aplicó a Pattern 1 y Pattern 2: "the document says so without shortcuts: the pattern is empirically validated in Sentinel. Wait for the second domain before crystallizing it higher".

Phase 2 hace algo distinto. No declara el principio; lo escribe dentro del schema mismo, en un lugar que cualquier consumidor del schema va a leer. El $comment no es marketing; es protocolo. Cualquier validador de JSON Schema 2020-12 lo expone; cualquier IDE que parsea el schema lo muestra. Es la primera vez que el framework formaliza la provisionalidad de sus formalizaciones.

Si quisiera resumirlo en una sola frase: el framework valida lo que tiene, sabiendo que lo que tiene es provisional, y deja eso por escrito en el lugar donde la validación ocurre. Validar lo provisional es disciplina. Cristalizar prematuramente y validar lo cristalizado es teología.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. Tener schemas no es lo mismo que validar contra schemas. El primer paso es declarativo; el segundo es operativo. Phase 2 hizo el segundo, no el primero. La diferencia entre los dos modos del framework — "tengo la promesa" vs. "tengo el comando que la comprueba" — es lo que determina si el adoptante puede confiar en lo declarado.

2. El patrón "bash artesanal → flag de comando" es estructural. El --staged no es feature aislado. Es la versión Phase 2 del mismo patrón que Post 4 documentó para el audit cycle externo, que Post 10 documentó para los CLI helpers de chain evolution: imperativo verboso → declarativo legible → versionado. Cada vez que el framework barre un script bash por un flag, sube una capa de garantías.

3. El --check-pending-reviews cierra el ciclo del agente. Lo que Post 1 nombró como permiso cultural sin pre-aprobación se completa aquí: el agente puede crear, pero los documentos marcados para revisión no se pierden — el comando los lista hasta que un humano los apruebe con un commit explícito. Sin ese signal, el permiso cultural del Post 1 sería negligencia.

4. Provisionalidad declarada > formalización prematura. Los $comment de los schemas v0 hacen el principio #12 protocolo, no doctrina. Cualquier herramienta que consuma el schema sabe que la formalización es provisional. Es la honestidad estructural más fuerte que puede tener un framework joven: validar lo que tiene, sin pretender que lo tenido es definitivo.

Anclas: PR #27 — versión original de validate (marzo 2026). Phase 2: PRs #73 a #79 + PR #80 — fw-4.6.0 / cli-3.7.0 (fusionado 2026-05-11). Schemas: dist/.straymark/schemas/{charter,charter-telemetry,audit-output}.schema.v0.json. Issue #67 — origen del --check-pending-reviews.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. Seis horas para no verlo, cinco minutos para verlo​

El Issue #113 abre con una de esas frases que, cuando uno la lee de regreso meses después, suena obvia y al mismo tiempo costó mucho llegar:

"Time to detect: ~6 hours of session work; never autonomously surfaced. Time to resolve once user prompted: ~5 minutes."

Seis horas trabajando con un agente capaz, atento, con todo el aparato canónico de onboarding del framework cargado — STRAYMARK.md, la constitución del proyecto, el checklist de CLAUDE.md, las skills /straymark-* disponibles, /straymark-status ejecutado al inicio — y nunca, en seis horas, el agente sugirió usar un Charter. Cuando se lo pedí directamente, el flujo se incorporó en cinco minutos. La asimetría no es de capacidad. Es de visibilidad.

Este post cubre un episodio corto y específico: el Issue #113, abierto el 7 de mayo de 2026, tres días después de que Charters se cristalizaran como entidad de primera clase del framework (fw-4.4.0, 2 de mayo). Es el contrapeso natural del primer post del blog. Aquel post nombró una propiedad que apareció cuando todo estaba en su sitio. Este post documenta lo que pasa cuando una pieza estructural existe pero no está en la superficie que el agente lee primero.

2. El experimento accidental​

El setup no estaba pensado como experimento. Era un proyecto real: un greenfield en Rust, suite CLI+TUI, en su primera versión v0.1. El agente era Claude Opus 4.7 con ventana de 1M tokens, suficiente para tener todo el repo en contexto sin tener que paginar. El flujo era el canónico de SpecKit: /speckit-specify, /speckit-plan, /speckit-tasks, y entre tasks e implement debía aparecer — en teoría — la idea de cortar en Charters.

El Issue lo formula con precisión casi fría:

"A capable, attentive agent following the canonical project onboarding (DEVTRAIL.md, the project constitution, CLAUDE.md checklist, available /devtrail-* skills, /devtrail-status) did not autonomously identify Charters as a workflow concept during plan/tasks generation, even though the project clearly fit their use case (multi-session implementation, multi-phase tasks, audit value)."

(El Issue todavía usa DEVTRAIL.md porque, recordando la cronología, el rebrand a StrayMark estaba siendo merged casi al mismo tiempo. La nomenclatura mixta es residuo del calendario, no descuido.)

El proyecto cumplía cada una de las condiciones donde un Charter es la unidad correcta: implementación multi-sesión, varias fases, valor de auditoría. El agente hizo todo bien — leyó la constitución, ejecutó status, identificó skills disponibles, generó un plan de SpecKit razonable — y nunca conectó con Charters. Como si el concepto no existiera. Para él, en su modelo del repo, no existía.

Lo más incómodo del Issue, mirado desde mayo, es que el agente no falló por incapacidad. Falló porque el framework, sin proponérselo, le había construido un mapa en el que los Charters no aparecían marcados.

3. Nueve gaps que convergen en uno​

Cuando el operador (yo) abrió el Issue y se sentó a auditar por qué había pasado, el problema no era una cosa. Eran nueve. Y todas eran versiones del mismo defecto:

Nueve fallas y un solo defecto: el Charter existía como artefacto técnico (schema válido, comando funcional, template portado de Sentinel), pero no estaba nombrado en ninguno de los lugares donde el agente construye su modelo mental del proyecto al entrar.

El agente lee el STRAYMARK.md y la constitución para entender de qué trata el proyecto. Si Charter no aparece, no está. El agente revisa qué skills tiene disponibles para usar. Si no hay /straymark-charter-new, no está. El agente corre /straymark-status para entender qué tipos de archivo viven en el repo. Si la salida no menciona Charters, no están. Cada superficie por la que el agente pasa al onboarding repite el mismo silencio. Y la suma de silencios convence al agente de que el concepto no es parte de este proyecto.

4. Por qué este episodio importa más allá del Issue​

Vale la pena hacer una pausa aquí, porque este es exactamente el episodio que el meta-patrón de fw-4.17.0 — el patrón de observación emergente — necesitaba haber existido antes para poder formularse.

Una semana después de #113, en EMERGENT-OBSERVATION-DESIGN.md, el framework nombró dos propiedades cuya composición produce que el agente note cosas que nadie le pidió notar: vínculos formales entre artefactos (originating_charter, originating_ailog, originating_spec en frontmatter), y permiso cultural para señalar disonancias entre fuentes. Esas dos propiedades, compuestas, producen que el agente lea el AILOG, cuente las entradas R<N>(new, not in Charter), y señale el delta sin que nadie se lo pida.

Pero hay un prerrequisito que esa formulación da por sentado: que el agente vea los Charters al entrar al repo. Si los Charters no están en la superficie visible, ningún vínculo formal entre artefactos puede componerse en observación emergente — porque uno de los términos de la composición no existe para el agente.

El Issue #113 es el episodio que documentó esa precondición desde la inversa. Fw-4.17.0 nombró el patrón cuando estaba presente; fw-4.12.0 (cinco días antes) cerró la brecha que impedía que estuviera presente en absoluto. Sin el Issue #113 y su corrección, el meta-patrón no tendría dónde apoyarse. El framework no señala lo que no ve, y no ve lo que la superficie no nombra.

5. La respuesta: multiplicar superficies​

El PR #122 (fw-4.12.0, 9 de mayo) cubrió los nueve gaps con una sola estrategia operativa: nombrar Charter en cada lugar donde el agente construye su modelo del proyecto. Las cifras del PR son honestas: +1211 líneas, −92 líneas, 36 archivos modificados, casi todo documentación y plantillas. No hubo refactor de código. Hubo redistribución de visibilidad.

Cambios principales, agrupados:

• En el documento canónico (STRAYMARK.md): una sección nueva dedicada al Charter como concepto (§15), más filas en las tablas de §6/9/10/11/13 que listaban tipos de documento sin Charter.
• En las directivas de agentes (CLAUDE.md, GEMINI.md, copilot-instructions.md): un trigger explícito que enseña al agente cuándo sugerir un Charter, no solo cuándo crearlo si se le pide.
• En las skills: nueva /straymark-charter-new (versiones Claude, Gemini, agnóstica). /straymark-status actualizada para listar Charters activos.
• En el CLI: bloque Charters añadido a la salida de straymark status, para que el agente que ejecuta el comando lo vea entre los signals iniciales.
• En los templates: movidos a un subdirectorio dedicado dist/.straymark/templates/charter/, ya no mezclados con templates de otros tipos.
• Documento nuevo: SPECKIT-CHARTER-BRIDGE.md (171 líneas, EN/ES/zh-CN). Hace explícito el puente entre el plan.md de SpecKit y el Charter de StrayMark — los cuatro criterios para que una feature de SpecKit produzca uno o varios Charters, los tres casos donde no aplica, las cuatro heurísticas de granularidad, el enlace de frontmatter originating_spec ↔ originating_charter ↔ originating_ailog.

El epílogo de SPECKIT-CHARTER-BRIDGE.md registra el caso que originó todo el cambio sin metáfora:

"Cited the empirical context (issue #113): Greenfield Rust CLI/TUI suite, Claude Opus 4.7 onboarding via canonical entry points. Charters were eventually adopted (2 Charters: foundation + MVP) only after explicit user prompt — confirming the gap was systemic, not session-specific. This document removes the gap."

The gap was systemic, not session-specific. Esa frase es la lección operativa del Issue. No fue un agente distraído un día; era el framework el que no le hablaba al agente sobre Charters en ningún lugar donde el agente miraba.

6. Lo que aprendí sobre visibilidad estructural​

La lección, escrita en prosa y no en tabla:

Crear un artefacto en un framework no es lo mismo que hacerlo visible para los agentes que trabajan en repos del framework. Son dos pasos. El primero — esquema, comando, template, ejemplos — es el paso visible: queda en el CHANGELOG, sale en el release, se ve en el git log. El segundo — anclar el artefacto en cada superficie por donde el agente entra al repo — es invisible: nada del segundo paso aparece como feature en sí; son referencias cruzadas, líneas en checklists, items en outputs, secciones en docs. Pero el segundo paso es el que decide si el primero existe para el agente.

El framework gobierna agentes que leen el repo desde fuera de la sesión donde se creó el artefacto. Cada agente que entra al repo construye su modelo mental desde cero, leyendo los documentos canónicos, las skills disponibles, los outputs de status. Si el artefacto no está nombrado ahí, no existe en su modelo. Y un modelo sin el artefacto no propone usarlo, no audita su ausencia, no señala disonancias relacionadas. La capacidad técnica del agente es irrelevante si la superficie del repo no le da el sustantivo correcto al entrar.

Eso es lo que ahora llamo, internamente, visibilidad estructural. No es una propiedad del agente. Es una propiedad del repo, y por extensión, una responsabilidad del framework: cada vez que cristaliza un concepto nuevo, tiene que multiplicar las superficies donde ese concepto se nombra. Una sola superficie — el schema, el comando, el template — no alcanza. Son nueve, mínimo, y son las nueve del Issue #113.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. Existir como artefacto no es lo mismo que ser visible para el agente. Charters tenían schema, comando, template, ejemplos — y aun así eran invisibles. La diferencia entre los dos estados son las nueve superficies del Issue #113.

2. Seis horas vs. cinco minutos. Un agente capaz puede pasar horas sin detectar lo que, una vez nombrado, le toma minutos integrar. La asimetría no diagnostica al agente; diagnostica al repo.

3. La visibilidad estructural es responsabilidad del framework. Cuando cristaliza un concepto, no termina en el comando que lo crea. Termina cuando el concepto está nombrado en cada superficie donde el agente construye su modelo del repo: documento canónico, directiva, skill, status, template, puente con otros frameworks.

4. Sin visibilidad estructural no hay observación emergente. Las propiedades que después hicieron posible que un agente señalara disonancias entre fuentes — vínculos formales + permiso cultural — necesitan, como precondición, que los artefactos sean visibles desde el primer momento del onboarding. El Issue #113 documenta qué pasa cuando esa precondición falta.

Sigue, en el siguiente post, un episodio adyacente al de este: el rebranding a StrayMark (H-08). El Issue #113 se resolvió en el mismo arco temporal que el rename de DevTrail a StrayMark, y los dos comparten algo que vale la pena nombrar — la responsabilidad de que un framework declare con claridad su identidad, hacia sus agentes y hacia sus adopters.

Anclas: Issue #113 (abierto 2026-05-07). PR #122 — fw-4.12.0 (fusionado 2026-05-09). Documento generado por el PR: SPECKIT-CHARTER-BRIDGE.md.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. El rename que no buscaba el concepto​

El ADR 2026-05-08-001 se abre con una frase que, para cualquiera que haya leído el Post 2 de este blog, suena ajena:

"The decision is motivated by legal certainty over the trademark rather than by product strategy or user feedback."

Los tres renames de enero (Chronicle → Monimen → DevTrail) fueron búsqueda apurada del concepto. Cada uno ratificaba una intuición distinta sobre qué era el producto. Ninguno tenía ADR; los commit messages eran toda la justificación documental que existió.

El cuarto rename, el de mayo, es de otra naturaleza. No nace de buscar al concepto. Nace de una investigación de conflicto de trademark — comisionada vía sesión de Claude.ai a inicios de mayo — que arrojó "legal uncertainty about trademark ownership as the project gained adopters". En enero el proyecto tenía cero adopters y los renames podían improvisarse. En mayo el proyecto tenía un adoptante (Sentinel), 286 descargas del crate, dos issues abiertos, y un manifesto público que prometía gobernanza estructurada. El umbral para improvisar otro rebrand ya había sido cruzado.

Este post cubre tres cosas: la decisión disciplinada que se tomó el 8 de mayo, el arco operativo de cinco PRs en cuarenta y tres minutos del día siguiente, y los residuos que aparecieron dos días después. Y, por dentro, una distinción más sutil: cuándo un rebrand es solo de superficie y cuándo, sin proponérselo del todo, cambia también la identidad.

2. El primer rename disciplinado​

Lo nuevo del 8 de mayo es la forma. Esta vez había:

• Una investigación previa. No se decidió rebrand y luego se justificó; primero hubo un conflicto detectado y luego, en consecuencia, la decisión.
• Un ADR público. Tres alternativas consideradas explícitamente (mantener "DevTrail" y aceptar el riesgo; branding híbrido legacy + nuevo en paralelo; reset a v0.1.0 bajo StrayMark como "proyecto nuevo"). Las tres descartadas con argumento literal.
• Un cálculo temporal. El propio ADR enmarca el costo así: "The rename window narrows over time — every new adopter increases the cost of changing later... The legal risk dominates. Acting now, with one self-owned adopter, is materially cheaper than acting later under pressure."

La razón por la que el cálculo importa es estructural. Si el rebrand hubiera esperado dos meses más — hasta que apareciera el segundo adopter, o el tercero — el costo de migración se habría multiplicado. Cada repo adopter habría tenido que ejecutar el mv .devtrail .straymark, actualizar sus CLAUDE.md/AGENT.md, regenerar sus pipelines. Con un solo adopter (el propio operador), el costo era contenido y revertible. Lo que el ADR llama "acting now is materially cheaper" es exactamente eso: el rebrand fue una operación de minimización de deuda futura, no una decisión de marketing.

Hay un eco no buscado con el Post 2. Aquel cerró con la frase "probablemente no vuelva a haber rebranding". Este post, escrito desde mayo, sabe que sí lo hubo. La diferencia entre prometer y ratificar es que el cuarto rename, a diferencia de los tres primeros, fue forzado por circunstancias externas que ningún operador puede prever — un conflicto de trademark — y se enfrentó con la disciplina que enero no tenía.

3. In scope, out of scope — la pieza maestra del ADR​

La sección del ADR que da forma al resto del post es la que distingue qué se renombra y qué se preserva. Citada literal:

"In scope (the 'live state' of the project): all identifiers in source code, Cargo metadata, source-of-truth path, 30 skill/workflow files, public documentation, CI workflows, GitHub repository name."

"Out of scope (immutable history, preserved verbatim): all commits, commit messages, and git history; all tags published before this ADR; all release titles and bodies of releases published before; all prior CHANGELOG.md sections."

Esa distinción es la armadura del rebrand. Lo live — paths, comandos, URLs, assets de release, README — se renombra de un golpe. Lo historic — git log, tags devtrail-cli@3.10.0, sections previas del CHANGELOG, issues cerrados — se preserva literal. El proyecto no se reescribe hacia atrás.

Es la misma disciplina archivística que el Post 3 documentó para el rename Plan → Charter, ahora aplicada al rebrand operativo del framework completo. Lo expreso en una tabla porque ayuda a verlo:

La continuidad de versiones es la prueba más visible. El siguiente release no fue 0.1.0 ni 1.0.0; fue fw-4.11.0 y cli-3.11.0. La numeración declara, sin metáfora, que el proyecto es el mismo proyecto.

4. Cinco PRs, cuarenta y tres minutos​

El 9 de mayo, entre las 06:05 y las 06:48 UTC, se fusionaron cinco PRs en cadena:

El orden es deliberado y va de afuera hacia adentro: primero la ley (ADR), después el código interno, después lo que ven los adopters (docs), después la distribución (CI), finalmente el hecho consumado (release). Esta secuencia tiene una lectura archivística: cuando alguien dentro de seis meses revise git log en orden cronológico, primero verá la decisión, después la implementación. La causalidad queda en el repo.

Vale la pena nombrar una pieza del arco que rompió el plan original. El ADR había contemplado nueve PRs distintos (uno por capa lógica). En la práctica, los tests del CLI dependían de paths hardcoded — include_str!("../../dist/.devtrail/...") — y romper el path sin actualizar los tests al mismo tiempo dejaba CI en rojo. El plan se compactó a cinco porque las capas estaban acopladas técnicamente, no porque la disciplina conceptual fallara. La nota del PR #115 lo registra sin atenuar: "The consolidation was forced by tight coupling: tests use include_str! on dist/.devtrail/ paths."

Cuarenta y tres minutos para un rebrand que tocó alrededor de doscientos sesenta archivos. La cadencia solo es posible porque el ADR había cerrado todas las decisiones antes de tocar código. El principio #6 del framework — "cuando la propuesta es bien escrita, la implementación es ejecución, no diseño" — encontró otro caso de validación, parecido al del audit cycle externo del Post 4.

5. Por qué StrayMark sí cambia algo más que el nombre​

Hasta aquí el ADR es claro: el rebrand es de superficie, la identidad conceptual se preserva. Pero hay un matiz que vale la pena nombrar.

El PR #120 — fusionado horas después del arco principal, el mismo 9 de mayo — añadió al README la sección "Why StrayMark?". No es código; es un manifesto. Y dice cosas que ningún documento previo del proyecto había articulado:

"Code is just the fossil trace of a mental battle. Real engineering happens in the chaos of decisions, calculated risks, and the paths you chose not to take. Traditionally, all that human trail is discarded as stray marks (accidental smudges) in a project's history. At Strange Days Tech, we believe those marks are the signal, not the noise."

La elección del nombre, vista desde el manifesto, no es arbitraria. Las stray marks — las marcas erráticas, las trazas accidentales que la mayoría de proyectos descartan — son exactamente lo que el framework arrastra a primer plano: AIDECs, AILOGs, TDEs, Charters. Lo que en cualquier proyecto convencional sería ruido descartable, en este proyecto es la materia prima de la auditoría. El nombre encarna la tesis del producto en una forma que DevTrail nunca lo hizo. DevTrail era un recorrido neutro; StrayMark es una afirmación.

El manifesto cierra con tres líneas que después se volvieron lo que un editor llamaría tagline operativo:

"Capture the noise. Weave the signal. Humanize the machine."

Aquí está la pequeña tensión interesante del rebrand. El ADR dice que solo cambió la superficie; el manifesto del mismo día sugiere que también se articuló — quizás por primera vez con claridad — la identidad. No es contradicción: el momento del rebrand operativo fue aprovechado para escribir lo que ya estaba en el proyecto pero no se había nombrado todavía. La identidad no cambió. Se hizo legible.

6. Lo que quedó pendiente​

Aun con ADR público y arco disciplinado, "completo" sigue siendo aproximación.

Dos días después del rebrand, mientras Sentinel preparaba su siguiente ciclo de auditoría externa, el agente señaló tres clases de residuos. La cronología — captura honesta en CHANGELOG.md como erratas inline — vale la pena dejarla a la vista:

• PR #137 (11 may, 22:55) — Skill directories órfanos. El rebrand reescribió el campo name: dentro de cada SKILL.md, pero no renombró los directorios de las tres plataformas (.gemini/skills/devtrail-*, .claude/skills/devtrail-*, .agent/workflows/devtrail-*.md). Treinta artefactos órfanos: nombre nuevo, ruta vieja. Gemini CLI lo reportó como diez warnings de conflicto al arrancar.
• PR #138 (11 may, 23:32) — Charter paths legacy. Tres artefactos del framework seguían referenciando docs/charters/ después de que fw-4.12.0 migró el path canónico a .straymark/charters/. Lo más grave: el hook pre-pr.sh estaba gated en [ ! -d docs/charters ], lo cual hacía exit 0 silencioso para cualquier adopter post-4.12.0. El drift check llevaba siete meses instalado pero no-op.
• PR #139 (12 may, 12:02) — Instaladores rotos. install.sh e install.ps1 aún apuntaban a REPO=StrangeDaysTech/devtrail, BINARY=devtrail, asset name devtrail-cli-v*. El README — ya rebranded — apuntaba a la nueva URL. Resultado: cualquier usuario que copiara el comando del README desde el 9 de mayo recibía un 404 de GitHub al ejecutar el instalador. El producto estuvo roto en producción durante setenta y dos horas.
• PR #140 (12 may, 16:49) — Micro-residuo. La línea uno de .gitignore decía aún # DevTrail - .gitignore. Más una entrada nueva para Aparador/ en patterns internos.

La lección no es que la disciplina fue insuficiente. Es que la disciplina no previene residuos — los hace encontrables, documentables, y reparables en errata inline pública. Los tres primeros renames (enero) probablemente tuvieron residuos equivalentes; nunca los catalogamos porque no había hábito documental. El cuarto rebrand los catalogó. Es el primer rebrand del proyecto que admite, en el repo público y en el CHANGELOG mismo, que el operario no atrapó todo a la primera.

El detalle más incómodo — los instaladores rotos por setenta y dos horas — es el que más me importa registrar. Si en lugar de un adopter solo (el operador) hubiera habido un equipo, esa ventana habría afectado a usuarios reales. Acting now, with one self-owned adopter, was materially cheaper, says the ADR. Eso es exactamente lo que esa frase compraba: el derecho a equivocarse durante setenta y dos horas sin lastimar a nadie.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. No todos los renames son del mismo tipo. Los tres de enero buscaban al concepto; el de mayo defendía al proyecto contra deuda futura legal. Solo el de mayo podía hacerse con ADR público, porque solo el de mayo nacía de evidencia externa y no de intuición interna.

2. La distinción superficie vs. identidad pertenece al documento, no a la retórica. El ADR mismo declara qué se renombra y qué se preserva. Esa lista — paths sí, git log no; release titles sí, tags previos no — es la armadura del rebrand. Sin esa lista explícita, "rebrand" significa cualquier cosa.

3. La identidad puede hacerse legible aunque no cambie. El manifesto "Why StrayMark?" no inventó lo que el proyecto era; lo articuló por primera vez con claridad. El rebrand operativo fue aprovechado para escribir lo que ya estaba en el código pero no había salido al README. La identidad no se reescribió, se publicó.

4. La disciplina no previene residuos; los hace encontrables. Cuatro PRs errata dos días después no son falla del rebrand; son evidencia de que el rebrand fue lo suficientemente honesto como para admitir qué se le escapó. Los tres renames de enero probablemente tuvieron equivalentes; nunca aparecieron documentados.

Sigue, en el siguiente post, un episodio que conecta directamente con el último punto: TDE como mecanismo para nombrar deuda transversal (H-09). El primer caso real que el framework usó para articular cómo evidenciar la deuda — y que dejó una lección dura sobre stacked-PRs que merece su propio párrafo cuando llegue ahí.

Anclas: ADR 2026-05-08-001. Arco nuclear: PRs #114 · #115 · #116 · #117 · #118. Manifesto: PR #120. Residuos: PRs #137 · #138 · #139 · #140. Release: fw-4.11.0 / cli-3.11.0.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. Cuando la disciplina amenaza con volverse ceremonia​

A finales de abril, Sentinel cerró su cuarto Charter del mes con una sensación que, escrita, suena un poco patética: la auditoría externa funcionaba — Copilot 9.25, Gemini 9.5, el drift script con cero falsos positivos — pero cada cierre me hacía abrir tres archivos a mano, copiar tres prompts a tres ventanas distintas, esperar respuestas, copiar tres YAMLs de calibración de vuelta al archivo de telemetría, y verificar a ojo que los hashes coincidían. Cuarenta minutos de copy-paste por Charter, sobre un trabajo que tomaba dos horas. La disciplina estaba funcionando; el ritual estaba volviéndose un problema.

La propuesta audit-skills-design.md, escrita el 3 de mayo, lo nombró sin atenuar:

"Si en cada cierre el operador tuviera que mover datos manualmente entre archivos, el throughput colapsaría y la disciplina dejaría de ser fricción virtuosa para volverse ceremonia. Lo que se pueda automatizar de forma reversible debe automatizarse; los documentos quedan para auditoría humana ex-post."

Este post cubre tres días — del 2 al 6 de mayo de 2026 — en los que dos arcos paralelos terminaron a la vez. Uno: el Charter dejó de ser práctica artesanal y se volvió entidad de primera clase del CLI. Dos: el audit cycle externo dejó de ser ritual manual con prompts ad-hoc y se volvió comando canónico (con una decisión arquitectónica contraintuitiva detrás que merece su propio párrafo).

2. Lo que Sentinel ya hacía, y lo que StrayMark no tenía​

La propuesta del 3 de mayo lo dice con una frase que se queda corta de elegante pero precisa exactamente lo que estaba pasando:

"Sentinel tiene los skills, StrayMark no."

Lo que Sentinel tenía: sentinel/.claude/skills/plan-audit/ y plan-audit-review/ — skills locales que generaban un prompt, calibraban la respuesta al regreso, y la fusionaban en la telemetría. Funcionaban. Llevaban seis ciclos validándose. Pero estaban acoplados a paths Sentinel-específicos (docs/plans/, internal/modules/, go vet) y al vocabulario "Plan", que ya había sido renombrado a Charter una semana antes.

Lo que StrayMark no tenía: nada equivalente. El framework hasta abril era documentación + skills + un CLI con init, update, remove. La unidad que en Sentinel se llamaba Plan — la unidad acotada, declarada ex-ante, auditada ex-post — no existía como artefacto del CLI. Existía como práctica.

El arco de fw-4.4.0 (2 de mayo) y de fw-4.7 → 4.9 (3-5 de mayo) consiste, casi al pie de la letra, en portar lo que Sentinel hacía a mano hacia comandos genéricos que cualquier adoptante del framework pueda invocar. La tabla de migración, copiada del cli-roadmap.md, es honesta sobre el origen:

El CHANGELOG de fw-4.4.0 lo enmarca sin metáfora: "Crystallizes the Charter pattern — bounded, auditable units of work declared ex-ante and validated ex-post — that emerged from the 6-cycle Sentinel /plan-audit experiment." La cristalización es el punto. Lo que en abril era costumbre con script bash, en mayo es comando con schema validable.

3. Qué pasa cuando algo se vuelve "entidad de primera clase"​

PR #65 (fw-4.4.0 / cli-3.6.0, 2 de mayo) hace tres cosas concretas:

• Crea el comando straymark charter new. Auto-incrementa el número (NN-slug.md), pre-popula el origen (originating_ailogs si nace de un AILOG previo; originating_spec si nace de un SpecKit plan.md), y soporta el flag --type X|S|M|L para fijar la escala desde el primer momento.
• Introduce charter-template.md portado del TEMPLATE.md v3 de Sentinel. Lleva embebidas las seis convenciones que el experimento de abril fue cristalizando ciclo a ciclo: separación Local/Production checks, esfuerzo en tiempo (no en story points), sub-secciones estructuradas, documentación de riesgos R<N>, cierre con reconciliación post-merge vía AILOG, y auto-checklist drift.
• Publica dist/.straymark/schemas/charter.schema.v0.json — el schema marcado como v0 deliberadamente, no v1, porque el principio #12 del framework dice que ningún schema cristaliza sin un segundo dominio que lo valide. Sentinel es un dominio. Falta el segundo.

PR #68 (3 de mayo) hace algo que parece pequeño pero importa: el atomic Charter closure pattern, format v4. En Sentinel, el paso "actualizar el Plan-doc post-merge si el AILOG documenta divergencias" existía como nota en el TEMPLATE pero no tenía gatillo sistemático. En la práctica, eso significaba que cuando había diferencia entre lo declarado y lo entregado, el operador (yo) confiaba en la memoria para reconciliar el documento — y la memoria fallaba. El drift quedaba en el repo días, a veces semanas, hasta que el siguiente ciclo lo descubría. Format v4 vuelve la reconciliación un paso obligatorio del cierre, no una nota al margen.

PR #69 (mismo día) cierra un detalle de fricción: la numeración manual. Antes había que decidir si el siguiente Charter era 11 o 12; ahora straymark charter new lee el directorio y propone el siguiente número. UX puro. Pero es la clase de fricción que, sumada sobre veinte Charters, decide si el framework se usa o se abandona.

Los tres PRs salieron en el mismo commit storm de un domingo y un lunes. Esa cadencia es deliberada: una vez que el patrón se cristaliza, los detalles UX hay que cerrarlos junto, no en bumps separados que dejen al adoptante con una mitad del flujo.

4. Tres releases en un día​

Lo que vino después — fw-4.7.0, fw-4.8.0, fw-4.9.0 — son releases consecutivos del audit cycle externo. La propuesta audit-skills-rollout.md registra el ritmo sin disimular:

"Fase 1 ejecutada en 1 día calendar (5 PRs secuenciales el 3 de mayo de 2026), substancialmente más rápido que la estimación de 1.5-2 semanas focused. El throughput se debe a que el diseño en audit-skills-design.md ya tenía las decisiones cristalizadas (D1/D2/D3) y la heurística arborist con graceful-degradation explícita — no hubo decisiones pendientes durante la implementación. Sirve como evidencia operativa adicional para principio #6 (cuando la propuesta es bien escrita, la implementación es ejecución, no diseño)."

El audit cycle externo concreto consiste en tres comandos encadenados:

1. straymark charter audit prepare <CHARTER-NN> — genera prompts canónicos para auditores externos a partir del Charter cerrado, su AILOG asociado, y el diff de archivos tocados. Output: tres archivos .prompt.md en audit/<CHARTER-NN>/{copilot,gemini,claude}.prompt.md.
2. (El humano lleva esos prompts a su auditor de elección, recibe respuestas, las pega de vuelta.)
3. straymark charter audit collect <CHARTER-NN> — toma las respuestas, valida cada una contra el schema de auditoría, fusiona calibraciones en la telemetría del Charter, y produce un summary con la convergencia (o divergencia) entre auditores.

Decisión D1 de la propuesta es la que sostiene todo lo demás:

"Las skills delegan vía Bash(straymark charter audit *) a la implementación canónica. Plantillas viven solo en dist/.straymark/audit-prompts/. Cero drift posible entre skill y CLI."

Hay solo un lugar donde los prompts viven, una sola implementación del flow, y las skills (Claude, Cursor) lo invocan vía Bash. Es un patrón humilde — el CLI es la fuente única — pero evita lo que en cualquier framework con dos surfaces (skill + CLI) termina siendo el problema crónico: que el skill y el CLI digan cosas distintas según quién los actualizó la última vez.

5. Por qué el CLI orquesta pero no invoca APIs​

Esta es la decisión más rara de mayo, y la que más me costó tomar. Está documentada literal en cli-roadmap.md §0 como "decisión arquitectónica A1":

"A1 (Phase 3): orchestration-only, no HTTP API clients en v0. El roadmap §5.4 originalmente sugería 'soportar OpenAI/Google/Anthropic en v0' con manejo de API keys. La realidad implementada es que el CLI prepara prompts, valida outputs contra schema, e integra con telemetría — pero NO invoca APIs. El operador pega los prompts en su auditor de elección manualmente."

El razonamiento, también literal:

"Implementar 3 clientes HTTP es 1-2 semanas + mantenimiento perpetuo cuando cambian las APIs (premature para una v0 experimental); el patrón humano-en-el-loop coincide con /plan-audit de Sentinel; cumple principio #10 ('no es un LLM gateway'); cierra RFC #82 por diseño. Los HTTP clients se reabren en v1 cuando un adoptante real lo justifique con datos."

Tres argumentos, cada uno con peso propio.

El primero es pragmático. Tres clientes HTTP — OpenAI, Anthropic, Google — son entre una y dos semanas de implementación, más mantenimiento permanente cada vez que alguno de los tres cambia algo. Para un comando que en su forma manual ya estaba funcionando empíricamente en Sentinel, ese es un costo absurdo. Es ingeniería para resolver un problema que ningún adoptante había pedido resolver.

El segundo es de continuidad. Lo que Sentinel validó en abril fue precisamente el patrón humano-en-el-loop: el operador pega el prompt en Copilot/Gemini/Claude a mano, lee la respuesta, la pega de vuelta. El experimento de los seis Planes que dio origen a este arco completo nunca invocó APIs. Si el CLI ahora invocara APIs por su cuenta, estaría sustituyendo el patrón validado con uno no validado, sin razón empírica.

El tercero es de identidad. StrayMark no es un LLM gateway. El principio #10 del framework lo dice explícitamente. Hay docenas de productos que sí lo son — LangChain, LiteLLM, LiteLLM Proxy, OpenRouter, todos los wrappers — y son útiles para lo que hacen. StrayMark hace otra cosa: estructura la disciplina alrededor del trabajo que se hace con esos modelos, sea cual sea el modelo. Que el CLI invoque o no invoque APIs cambia lo que el framework es; mantenerlo orchestration-only mantiene la identidad limpia.

La parte que más me importa del párrafo: "Los HTTP clients se reabren en v1 cuando un adoptante real lo justifique con datos." La decisión no se cerró por dogma; se difirió por umbral de evidencia. Si en seis meses un adoptante demuestra que el flow humano-en-el-loop le rompe el throughput, los HTTP clients aterrizan. Hasta entonces, la fricción manual de los cuarenta segundos que toma pegar el prompt en otra ventana es trivial comparada con el costo de mantener tres SDKs vivos.

6. Lo que el framework decidió no automatizar​

Vale la pena cerrar con la otra cara de la misma decisión. La propuesta audit-skills-design.md dice:

"Lo que se pueda automatizar de forma reversible debe automatizarse; los documentos quedan para auditoría humana ex-post."

La primera mitad explica los tres releases de mayo: prompts generados automáticamente, calibraciones fusionadas automáticamente, drift detectado automáticamente. La segunda mitad — "los documentos quedan para auditoría humana ex-post" — explica qué se decidió mantener manual a propósito.

Lo que el framework no automatiza:

• La lectura del AILOG por parte del operador antes de cerrar el Charter. El comando straymark charter audit prepare genera los prompts, pero el operador tiene que abrir el AILOG y leerlo. Si automatizáramos eso — un agente que lee, resume, decide — perderíamos el momento de juicio humano que justifica que el Charter exista.
• La decisión de aceptar o rechazar la auditoría externa. El CLI fusiona las calibraciones en la telemetría, pero no actúa sobre ellas. Si un auditor califica el Charter con un 4, el Charter no se reabre automáticamente: el operador decide si reabrir, si argumentar, si declararlo acceptable-with-known-debt. Esa decisión es la disciplina; automatizarla la destruiría.
• La invocación de los modelos. Como ya argumenté arriba: la pausa donde el operador copia el prompt es exactamente donde decide qué modelo usar, qué prompt ajustar, si la pregunta tal cual está formulada le parece justa. Esa pausa es feature, no bug.

El criterio que recorre las tres es uno solo: automatizar lo que sea reversible y mecánico; preservar como manual lo que sea juicio. Cuarenta segundos de copy-paste no son demasiados si compran que el juicio sigue siendo humano.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. Una práctica que funciona empíricamente no necesita ser reinventada para canonizarse. Sentinel hizo el trabajo de validación en abril; mayo solo lo trasladó al framework. La cristalización es traslado, no diseño desde cero.

2. Cuando la propuesta está bien escrita, la implementación es ejecución. Tres releases en un día solo son posibles cuando todas las decisiones quedaron cerradas antes de tocar código. El principio #6 lo dice más prosaicamente, pero esto es lo que significa.

3. No todo lo automatizable debe automatizarse. La decisión A1 — el CLI orquesta pero no invoca APIs — es la versión técnica de una decisión filosófica: el humano-en-el-loop no es legacy del que hay que deshacerse, es feature que sostiene la disciplina.

4. La identidad del framework se define tanto por lo que hace como por lo que no hace. "No es un LLM gateway" es una de las pocas frases del principio #10 que vale la pena recordar literal. Lo que StrayMark hace lo hace bien porque hay muchas cosas que se niega a hacer.

Sigue, en el siguiente post, el episodio metodológico que conecta con el inicio mismo del blog — Issue #113: Charters invisibles para los agentes — donde el framework descubre que crear comandos y schemas no basta si la superficie del repo no le habla al agente. Es el contrapeso natural a este post: aquí hablamos de lo que se canonizó; allá hablamos de lo que no se vio.

Anclas: PRs #65 · #68 · #69 (Charters first-class). Propuestas audit-skills-design.md · audit-skills-rollout.md · audit-cli-flow.md · cli-roadmap.md (decisión A1 §0). Releases fw-4.4.0 → fw-4.9.0.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. Una nota al pie que dice mucho​

En la propuesta charter-telemetry.md, escrita el 30 de abril de 2026, hay una nota terminológica al inicio:

"Lo que este documento llama 'Charter' se llamó 'Plan' en el experimento Sentinel (PLAN-01..06). Los datos empíricos citados abajo se refieren a esos Plans históricos por su nombre original; el shape del schema y los ejemplos prospectivos usan el nombre going-forward 'Charter'."

Es una nota al pie, técnica, sin drama. Pero registra el momento exacto en que el artefacto cambió de nombre — y, más interesante, registra una decisión de archivo que el blog también respeta: lo que se llamó Plan en su momento se sigue llamando Plan en los registros originales. Reescribir el nombre hacia atrás sería falsificar el rastro.

Este post cubre dos cosas que pasaron en cinco días: el primer experimento sistemático del framework — los seis Planes de Sentinel, ejecutados entre el 25 y el 28 de abril — y el rename que vino después, el 30. No son dos eventos separados. Uno trajo al otro.

2. Seis Planes en el papel, cinco en la realidad​

El experimento se diseñó con seis Planes (PLAN-01 a PLAN-06) y se ejecutó con cinco. PLAN-04 nunca corrió: quedó como un catálogo de siete features diferidas, una lista de cosas que se quería hacer pero que el ciclo de pruebas no alcanzaba a cubrir. Es honesto decirlo así, porque el propio documento que valida la tesis (thesis-validation.md) lo registra abiertamente en su tabla resumen:

Cinco Planes, cuatro escalas distintas: tres XS, una S, una M. Dominios deliberadamente heterogéneos — un deploy operativo, dos endpoints administrativos, un bump de contrato, una feature de backend con lógica de configuración. No era un benchmark sintético. Era el código real de Sentinel del 25 al 28 de abril, partido en unidades acotadas y auditado pieza por pieza con tres modelos (Copilot, Gemini, Claude) actuando como auditores externos.

El sexto Plan no haberse ejecutado importa por dos razones. La primera es la obvia: el experimento se quedó sin tiempo. La segunda es más interesante: PLAN-04 era el único Plan grande del lote — siete features acumuladas, sin acotamiento natural. Que justamente ese Plan fuera el que no entró ya estaba diciendo algo sobre el tamaño que podía tolerar el formato. Los Planes pequeños sí; los Planes-roadmap, no. Esa lección se canonizó después, sin que nadie tuviera que escribirla: los Charters de StrayMark hoy son "unidades acotadas, de horas a días, una rama", no roadmaps trimestrales.

3. El experimento iteró sobre sí mismo​

Cinco Planes ejecutados produjeron tres formatos distintos. No fue por capricho; fue porque cada ciclo dejó al descubierto algo que el formato anterior no capturaba.

• v1 — los tres primeros Planes (01, 02, 03) corrieron con un formato originario. Se identificaron cinco patrones recurrentes en los AILOGs de auditoría, pero ninguno estaba formalizado en una plantilla. Existían como costumbre, no como contrato.

• v2 — para PLAN-05, esos cinco patrones se materializaron en TEMPLATE.md, más una sección "Format conventions" en el README. Doc-only: nada ejecutable todavía. La hipótesis: si el formato es explícito, los auditores externos convergen mejor. El propio AILOG-020 lo dice sin adorno: "Los patrones internos que llevan tiempo aplicándose pero no tienen nombre quedan invisibles a auditores externos. Nombrarlos formalmente convierte la práctica en señal pública."

• v3 — para PLAN-06, se sumó un patrón nuevo (auto-checklist drift) y, esta vez, tooling ejecutable: scripts/check-plan-drift.sh, ~145 líneas de bash que validan si la entrega real coincide con lo declarado en el Plan. Por primera vez el formato dejó de ser solo prosa y empezó a tener un verificador.

Lo que me interesa señalar aquí es la forma de la curva. v1 capturó práctica latente. v2 le puso nombre. v3 le puso un programa que la chequea. Es el arco completo de cualquier estandarización útil — y lo recorrimos en cinco Planes, no en cinco años.

Es también la primera evidencia concreta de algo que dos meses después se nombraría explícitamente como Pattern 1 (pre-declare refresh) y Pattern 2 (amend-on-emergence) en CHARTER-CHAIN-EVOLUTION.md. Lo que ahí se canonizó como meta-patrón empezó aquí, en abril, como costumbre sin nombre.

4. La evidencia más dura: auditores externos convergiendo​

El supuesto más cargado de la tesis era: "notas estructuradas reducen modos de falla, y se nota cuando auditores externos miran". La forma de probarlo: enviar el output de cada Plan — los archivos modificados, el AILOG, el Plan-doc bajo TEMPLATE — a tres auditores que no participaron en el desarrollo (Copilot, Gemini, y un análisis crítico de Claude) y comparar las calificaciones agregadas.

El número que thesis-validation.md reporta para PLAN-05 (el primer Plan bajo v2 y bajo escala M) es claro:

"Mejor calibración combinada de auditores en 5 ciclos (Copilot 9.25, Gemini 9.5). Hipótesis acumulada confirmada: TEMPLATE v2 + AILOGs ricos reducen el espacio de ambigüedad para auditoría externa."

Dos modelos heterogéneos, instrucciones diferentes, convergiendo en torno a 9.3 sobre 10 — sobre el Plan más grande del lote, además, no el más chico. Eso es señal, no ruido. Y se replicó al ejercitar el check-plan-drift.sh de v3:

"PLAN-05 (con drifts conocidos): script reporta 3 omitted files: evaluator_test.go (F4), repository.go (F1/R6), statuscenter/service.go (F5) — exactamente los 3 drifts que Copilot+Gemini capturaron en sus auditorías. Cero falsos positivos."

El script automatizado y los dos auditores externos coincidieron exactamente en qué archivos del Plan habían quedado a deber. No es un argumento sobre que el script sea inteligente — es bash y grep, no podría ser más tonto. Es un argumento sobre que el formato del Plan, ya formalizado, hace que cualquier inspector (humano, agente, script) vea las mismas cosas. La disciplina estructurada no requiere inteligencia para auditarse: requiere claridad.

5. Lo que el experimento no demostró​

Esta es la sección que más me interesa que quede registrada, porque es donde se prueba si el blog está dispuesto a ser honesto.

thesis-validation.md se diseñó explícitamente para romper la tesis, no para defenderla. La primera línea del documento dice:

"Este documento confronta esa tesis con datos. No la defiende; intenta romperla. El objetivo es que un lector que no compró la tesis pueda, leyendo solo este texto, decidir si la evidencia disponible la sostiene, la matiza o la refuta."

El veredicto final, con los seis supuestos de la tesis enfrentados a la evidencia, es éste:

Tres supuestos validados completos, dos parciales, uno sin evidencia, cero refutados. El supuesto sobre aprobaciones no binarias se quedó sin probar porque Sentinel es un proyecto de un solo responsable; haría falta un equipo real con varios firmantes para ejercitarlo. Y la firma criptográfica — Sigstore, hash-chaining, las garantías técnicas de un append-only log — no se ejercitó porque ningún Plan tocó esa parte del flujo. Eso queda en el documento como gap explícito, no como afirmación al aire.

Lo que el experimento no demostró importa más que lo que sí demostró. Si en lugar de cinco veredictos honestos hubiéramos publicado seis verdes, el blog sería marketing. La forma de evitarlo es decir, sin atenuar: aquí hay supuestos sobre los que no tenemos evidencia, y un proyecto de un solo operador no puede generarla. Otros la generarán; el framework irá madurando con esos datos.

6. Por qué Plan se volvió Charter​

El rename del 30 de abril no fue de marketing. La razón está escrita literal en WHAT-IS-A-CHARTER.md:

"GitHub SpecKit already uses the word 'plan' (/speckit.plan, plan.md) for a different artifact, and the nominal collision generated friction in adopter docs that combine both flows."

SpecKit ya tenía un plan.md. StrayMark también. En la documentación de un adopter que usara ambos, plan significaba cosas distintas en párrafos contiguos. El rename existió para arreglar esa colisión.

Pero detrás del pragmatismo hay un matiz que sí vale la pena nombrar. Los dos artefactos son distintos, y la distinción es estructural:

Lo que SpecKit llama plan se parece más a un ADR con esqueleto arquitectónico. Lo que StrayMark llama Charter se parece más a una task-card con verificación contractual y anclaje de auditoría. Son artefactos complementarios, no competidores; eso lo hace explícito SPECKIT-CHARTER-BRIDGE.md después, en mayo. Pero la nomenclatura tenía que dejar de chocar antes de que se pudiera hablar de complementariedad.

La parte que me parece importante destacar es la decisión adyacente: los registros históricos de Sentinel — los AILOGs, las telemetrías, el check-plan-drift.sh, las carpetas sentinel/docs/plans/ — conservan el nombre Plan. El propio WHAT-IS-A-CHARTER.md lo argumenta así:

"Sentinel's historical records (Plans 01–06, sentinel/docs/plans/, sentinel/scripts/check-plan-drift.sh, AILOGs and YAML telemetries PLAN-NN.telemetry.yaml) preserve the original name — they are empirical evidence of a specific moment in time, and rewriting history would falsify the record."

Rewriting history would falsify the record. Esa frase es, para mí, el verdadero corazón del rename. El framework existe para preservar rastro, no para reescribirlo. Cuando el artefacto cambió de nombre, el cambio fue prospectivo: a partir del 30 de abril, los nuevos se llaman Charters. Los viejos, los del experimento, siguen siendo Planes. La inconsistencia es deliberada, y la inconsistencia es la evidencia.

El otro acoplamiento del 30 de abril — la propuesta de telemetría — vino el mismo día por razones que ahora resultan obvias: si el patrón emergente merecía un nombre nuevo, también merecía medición estructurada. El schema charter-telemetry.schema.v0.json, con sus campos sobre tiempo invertido, drifts detectados, escala, dominio, es la maquinaria que ejecuta hoy lo que en Sentinel todavía se medía a mano en YAML. Plan se renombró a Charter el mismo día en que se decidió empezar a contar Charters.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. El experimento se diseñó para romperse, no para confirmarse. "No la defiende; intenta romperla" — eso fue, literal, la consigna del documento que validó la tesis. Cualquier blog técnico que se respete tiene que tolerar esa formulación.

2. Cinco Planes ejecutados, de seis diseñados, en cuatro días. El que no se ejecutó (el más grande, un roadmap de siete features) fue, sin querer, la primera evidencia de qué tamaño tolera la unidad. Hoy los Charters son acotados por contrato. En abril, lo eran por accidente.

3. El formato evolucionó dentro del experimento mismo: de costumbre, a plantilla, a script. Los cinco Planes produjeron tres versiones del formato. La curva de v1 → v2 → v3 es la curva de cualquier estandarización útil — solo que comprimida.

4. El rename fue de pragmatismo, no de marketing. Y la preservación histórica fue de principio. Plan siguió llamándose Plan en Sentinel, donde así se llamó. Charter empezó a usarse de abril para adelante. El framework no reescribe su propio archivo: por eso vale la pena rastrearlo.

Sigue, en el siguiente post, dos hitos cercanos que codifican capacidades cualitativamente nuevas: Charters como entidad de primera clase (PR #65, fw-4.4.0) y el audit cycle externo multi-modelo (audit-skills-design, audit-cli-flow, releases fw-4.7 → fw-4.9). Es donde el experimento de Sentinel se convirtió en funcionalidad de CLI.

Anclas: propuestas thesis-validation.md y charter-telemetry.md (ambas 2026-04-30). Definición canónica del Charter: WHAT-IS-A-CHARTER.md. Schema operacional: dist/.straymark/schemas/charter-telemetry.schema.v0.json.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

1. La herramienta que dos semanas después reveló el outlier​

El Post 8 de este blog cubrió un episodio muy específico: el descubrimiento del único archivo del framework cuyo idioma canónico era el español. El operador no lo encontró por inspección sistemática; lo encontró ejecutando straymark explore --lang es durante una preparación de auditoría y notando, visualmente, que un template estaba escrito al revés respecto a los demás. La frase de aquel post fue:

"Una nueva superficie del framework (la TUI) puso todos los archivos en visión simultánea, y la inconsistencia se hizo evidente como cuando uno ordena los libros del librero y nota que uno tiene el lomo al revés."

Este post cubre la herramienta. La TUI straymark explore nació casi tres semanas antes del descubrimiento que reveló — el 25 de abril de 2026 en cli-3.4.0 — y maduró en cuatro releases más, todos cerrados en menos de 48 horas. No es un post sobre código. Es un post sobre una pieza específica de tooling que ratifica una tesis que el blog ya nombró antes: las herramientas nuevas producen visibilidad sin proponérselo.

2. Por qué un TUI en un framework de Markdown​

A finales de abril de 2026, el framework tenía algo así como cincuenta archivos Markdown gobernados — PRINCIPLES.md, AGENT-RULES.md, DOCUMENTATION-POLICY.md, QUICK-REFERENCE.md, SPECKIT-CHARTER-BRIDGE.md, plus templates en dist/.straymark/templates/, plus audit prompts, plus las versiones en tres idiomas de cada uno (i18n/es/, i18n/zh-CN/). Todo en disco, todo navegable con find y cat, todo perfectamente accesible.

Y, al mismo tiempo, todo invisible. Para un adoptante que clonaba el framework por primera vez, la primera pregunta no era "¿dónde está la regla N?". Era "¿qué hay aquí?". Y un ls recursivo no responde esa pregunta — la abruma. Un grep requiere saber qué buscar. Un editor abre un archivo a la vez. El framework había llegado al tamaño donde su propia superficie se había vuelto opaca.

straymark explore nació exactamente para resolver eso: una superficie navegable que respondiera "¿qué hay aquí?" en tres segundos. No un IDE; no un sistema de docs estilo Read-the-Docs; no un site estático. Un TUI — terminal user interface — que se ejecuta sobre el repo del adoptante, indexa los archivos canónicos del framework, los muestra agrupados por categoría, y permite leerlos con un visor de Markdown coloreado dentro de la terminal.

La decisión de hacer TUI y no web está alineada con dos cosas que el blog ya argumentó. Primero, el principio #10 del Post 4 — "StrayMark no es un LLM gateway" — generaliza a "StrayMark no es lo que ya hace otra cosa". No competimos con MkDocs ni con Material for MkDocs. Segundo, la decisión A1 del mismo Post 4: orchestration-only. El TUI no requiere servidor, no requiere build paso, no requiere conexión: corre sobre el repo del adoptante, donde ya está el framework. Es la pieza más humilde que podía resolver el problema.

3. Lo que entró en cli-3.4.0​

El PR #57 del 25 de abril, fusionado como cli-3.4.0, hizo tres cosas concretas:

• Introdujo el comando straymark explore. Layout de dos paneles cuando la terminal tiene 100 columnas o más: navegación a la izquierda (30%), documento a la derecha (70%). Paneles más estrechos colapsan a un solo panel para terminales angostas. Status bar al pie con los atajos relevantes.
• Indexó los archivos canónicos del framework en una jerarquía navegable: governance docs (AGENT-RULES.md, DOCUMENTATION-POLICY.md, ...), templates (dist/.straymark/templates/), audit prompts, y los directorios del adoptante (docs/charters/, .straymark/07-ai-audit/, ...). Cada nodo expansible con Enter.
• Cableó el resolver i18n. La opción --lang <code> permite ejecutar straymark explore --lang es y obtener todos los governance docs en español si hay traducción disponible. Si no la hay, fallback silencioso al canónico EN. La descripción literal del commit:

"Wire language config and a new --lang flag through the explore TUI so framework governance docs are served from i18n/<lang>/ when a translation exists, falling back silently to English otherwise."

La parte del resolver i18n importa más que el TUI en sí. Hasta cli-3.4.0, el helper resolve_localized_path lo usaba solo straymark new (para resolver qué template inyectar al adoptante en el idioma correcto). El PR #57 lo extrajo a cli/src/utils.rs:146 como helper compartido, de modo que una sola definición de cómo se resuelven los overlays i18n/<lang>/ sostiene tanto el comando new como el comando explore. El comportamiento queda predecible para el adoptante: si traduce un template a i18n/es/, el TUI lo va a mostrar igual que la generación lo va a usar. Sin sorpresas.

El renderizado del Markdown usa pulldown-cmark para el parser y los widgets de ratatui para pintar. Sintaxis coloreada, code blocks con borde, tablas con bordes redondeados, headings indentados según nivel. No es ostentoso; es legible.

4. Cuatro refinamientos en treinta y seis horas​

Lo que pasó entre el 25 y el 27 de abril es lo que el Post 9 nombró meses después como propiedad del proceso: cuando la propuesta es bien escrita, la implementación es ejecución. Cuatro PRs más, cerrados en menos de 36 horas, llevaron el TUI de "funciona" a "está terminado":

La velocidad del arco repite el patrón. Los cinco PRs de fw-4.11.0 que cubrió el Post 6 (rebrand a StrayMark) se cerraron en cuarenta y tres minutos. Los tres releases del audit cycle externo que cubrió el Post 4 se cerraron en un día. La curva del TUI es parecida: el diseño quedó claro en el PR #57, y los refinamientos vinieron cuando el operador empezó a usar el comando con frecuencia y notó las fricciones.

La anécdota que vale la pena dejar registrada es el cli-3.5.2: las teclas l y h que eliminó eran aliases vim — el operador las usa de hábito muscular en su editor. Pero cuando se introdujo el language switcher en mayúsculas (L) horas antes, la l minúscula y la L mayúscula compartían la misma tecla física, y la transición visual era confusa. La solución fue eliminar los aliases no documentados: el ortografía completa (j/k/g/G) se mantiene; las abreviaturas que duplicaban funciones desaparecen. Es un detalle UX pequeño que ilustra cómo las decisiones del TUI van afinando contra el uso real, no contra teoría de UX.

5. Lo que la TUI reveló dos semanas después​

Aquí el post recoge el hilo del Post 8 desde el otro extremo. Lo que cli-3.4.0 añadió al framework no fue solo un comando de navegación; fue una superficie de visualización simultánea. Es decir: antes del TUI, los archivos del framework existían pero se leían uno a uno. Después del TUI, podían verse todos a la vez, agrupados, etiquetados, en el mismo modo de presentación.

Eso cambia lo que el operador puede notar.

El 12 de mayo, dos semanas y media después del merge de cli-3.4.0, el operador ejecutó straymark explore --lang es antes de un ciclo de auditoría externa. Llegó al grupo de "audit prompts". Lo abrió. Y notó algo que llevaba existiendo un año: el audit-prompt.md en root del directorio estaba escrito en español, mientras todos los demás archivos canónicos del framework tenían inglés en root y overlays i18n/es/. Un solo archivo, al revés respecto a la convención.

El detalle no se descubrió por revisión sistemática. Se descubrió por contraste visual. Es exactamente lo que el Post 8 §3 codificó como tesis:

"Las herramientas nuevas producen visibilidad."

El TUI no causó el outlier — el outlier existía desde el primer commit que portó el skill plan-audit de Sentinel al framework canónico (Post 3 lo registra). El TUI tampoco buscó el outlier; no es una herramienta de detección de inconsistencias. Lo único que hizo fue poner todos los archivos en la misma pantalla, en el mismo modo de presentación, y permitir que el ojo humano notara lo que había estado ahí desde el principio. La conclusión que me interesa registrar es estructural: cualquier framework que pase de cincuenta archivos canónicos necesita una superficie de visualización simultánea, no porque la superficie sea pedagógicamente importante en sí, sino porque sin ella ciertas regularidades del repo se vuelven inobservables.

6. Pequeñas decisiones técnicas que importan​

Tres detalles del diseño del TUI que vale la pena dejar registrados, todos coherentes con principios del framework que el blog ya nombró:

Feature flag tui. El Cargo.toml del CLI declara el TUI como dependencia opcional (ratatui + crossterm + pulldown-cmark viven detrás del flag tui, habilitado por defecto). Un adoptante que solo quiere init, update, validate puede compilar el binario sin TUI con cargo build --no-default-features. Cierra una sub-decisión arquitectónica que se repite en el framework: dar valor al adoptante por defecto, pero permitirle elegir un binario más liviano cuando el TUI no aporta nada al flow.

Lazy-load de documentos. El DocIndex mantiene un HashMap<PathBuf, Document> que se llena al abrir cada nodo, no al arrancar. Para un repo con cien archivos governance, esto significa que straymark explore arranca en menos de 200ms y solo lee disco cuando el operador pulsa Enter. La decisión es trivial técnicamente; lo no trivial es que se tomó conscientemente. El TUI no compite con un IDE; compite con un cat. Tiene que sentirse igual de inmediato.

History stack para hipervínculos. Cuando un documento del framework menciona a otro (e.g., AGENT-RULES.md §3 refiere a DOCUMENTATION-POLICY.md §6), el TUI permite saltar al referenciado con un clic — y volver al anterior con Esc. Internamente hay una pila de navegación que restaura el scroll position del documento anterior. Es la pieza que convierte la lectura del framework de "abro un archivo, lo cierro, abro otro" a "sigo una conversación entre documentos sin perder el hilo". La cantidad de cross-references que el framework tiene hoy — entre principios, agent rules, schemas, templates — hace que esta navegación sea estructuralmente importante, no cosmética.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. Un framework que pasa cierto tamaño necesita una superficie de visualización simultánea. No es ergonomía; es condición para que ciertas regularidades del repo sean observables. El Post 8 documentó la consecuencia; este post documenta la herramienta.

2. El TUI no causa los descubrimientos; los permite. El outlier del audit-prompt existía desde mayo del año anterior. Lo único que cambió en abril fue que apareció una pantalla donde se podía ver junto a sus pares. La herramienta no opina sobre el contenido; cambia las condiciones bajo las cuales el ojo humano puede notar regularidades.

3. Cuando el diseño está claro, la implementación es cuestión de horas, no de sprints. Cinco PRs en treinta y seis horas — language-aware, live switcher, OS detection, i18n del panel, cleanup de keybindings — solo son posibles porque el diseño quedó cerrado en el PR #57. Es el mismo patrón de los Posts 4, 6 y 9.

4. La decisión técnica más interesante puede ser una flag de compilación. El feature flag tui declara explícitamente que el TUI es opcional, que el framework sigue funcionando sin él, que el adoptante decide. Esa humildad arquitectónica es la diferencia entre un CLI que asume cómo el adoptante trabaja y un CLI que se ofrece donde puede ser útil.

Con este post el blog cubre el hito H-14 que la primera tanda dejó como deuda explícita. Los hitos candidatos restantes que PLAN-INVESTIGACION.md §1.43-55 registró — AGENTS.md universal inject, cobertura i18n completa, straymark validate como capa formal, CLA assistant — siguen disponibles para futuras tandas. Sin promesa de cadencia, pero registrados.

Anclas: PR #57 — cli-3.4.0 (language-aware explore, 25 abr 2026). PRs #60 · #61 · #62 · #63 — refinamientos cli-3.5.0 a cli-3.5.2 (25-26 abr 2026). Código: cli/src/tui/ (15 archivos). Doc adopter: docs/adopters/CLI-REFERENCE.md §straymark explore.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.

Nota editorial: este es el primer post publicado de forma retroactiva en el blog. La date del frontmatter corresponde a un momento dentro del arco que el post narra, no al día en que se escribió. El blog completo se está construyendo así, hacia atrás, desde el episodio que motivó empezar a escribirlo (emergent-observation-design, 2026-05-16). No tiene sentido fingir lo contrario.

1. El día siguiente​

El 28 de enero de 2026, a las 17:29 hora del centro, este commit entró al repo:

chore: rebrand Chronicle to Monimen

Un día. Veintinueve horas, para ser exacto, después del initial commit del proyecto. El framework apenas existía y ya estaba cambiando de nombre.

Lo cuento en pasado, pero esto pasó hace tres meses. Y hace tres meses, dos cambios de nombre después, todavía no se llamaba StrayMark. El proyecto que hoy se vende como Documentation Governance for AI-Assisted Software Development arrastra una prehistoria corta y desordenada que vale la pena nombrar antes de seguir adelante.

2. Cinco eventos, cuatro meses​

Tres renames en tres días. Después una pausa de un mes entero. Después el rebrand de la organización con CLI Rust incluido. Después otra pausa de dos meses. Después StrayMark, esta vez con ADR público anclando la decisión.

Detalle que me parece honesto subrayar: el commit del 28 de enero (Chronicle → Monimen) no se marcó como BREAKING CHANGE. El del 29 de enero (Monimen → DevTrail) sí. "BREAKING CHANGE: Complete rebrand from Monimen to DevTrail", dice el body del commit. La diferencia es pequeña pero reveladora: el segundo rename se sintió más definitivo. Lo fue por dos meses.

3. Lo que no se mueve​

Esta es la sección que me interesa más. El proyecto cambia cuatro veces de nombre en cuatro meses. La idea, no.

El README del initial commit — el que vivía en el repo cuando se llamaba Enigmora Chronicle Framework — abre con esta línea:

Documentation Governance for AI-Assisted Software Development

Es la misma línea que abre el README de StrayMark hoy. Cuatro nombres, un slogan.

Más adentro, el mismo README v1.0.0 enuncia la tesis del proyecto en un bloque de cita explícito:

"No significant change without a documented trace."

Esa frase, hoy, es el Principio #1 del framework. Está en PRINCIPLES.md §1 — Total Traceability. La redacción cambió ligeramente al traducirse al español, pero el peso de la afirmación quedó intacto: ningún cambio significativo sin rastro documentado.

Los ocho tipos de documento que listaba el README v1.0.0 — REQ, ADR, TES, INC, TDE, AILOG, AIDEC, ETH — siguen vivos. Después se agregaron otros (MCARD, SBOM, SEC, DPIA), pero ninguno desplazó a los originales. La taxonomía de enero se sostuvo.

El nombre se mueve cuatro veces, la idea no. Lo que cambió en esos cuatro meses no fue el qué, sino la etiqueta que servía para nombrarlo.

4. El AIDEC con año tipográfico​

Hay una anécdota pequeña que me sigue gustando.

El primer documento estructurado del proyecto — el primer AIDEC, el documento que en la propia taxonomía del framework registra una decisión tomada con asistencia de un agente — es AIDEC-2025-01-27-001-i18n-strategy.md. Está en el commit 7b7193e, agregado a las 18:01 del 27 de enero de 2026, seis horas después del initial commit.

El ID dice 2025. El commit es de 2026.

El propio documento que sentó la convención de identificadores tipo [TYPE]-[YYYY-MM-DD]-[NNN] tiene un error tipográfico en el año. El framework arrancó imperfecto y nadie lo corrigió a tiempo. Si alguien clona el repo y mira al ID de ese AIDEC con cuidado, lo notará — y verá también que el commit que lo introdujo está fechado correctamente. Es la mejor evidencia que tengo de que la disciplina de auditoría es algo que llega después; no nace con el repo.

Pero más interesante que el error es lo que decide ese AIDEC. La pregunta que se planteó José en enero, con asistencia de Claude Opus 4.5, era: ¿cómo internacionalizamos un framework que existe para los humanos pero cuya configuración la leen agentes? La respuesta, en la sección de justificación del propio AIDEC:

"AI agents (Claude, Gemini, Copilot, Cursor) process instructions equally well in any language, so translating their config files provides no functional benefit."

La decisión que tomó ese documento — traducir lo que leen humanos (documentación, plantillas), mantener en inglés lo que leen agentes (CLAUDE.md, GEMINI.md, .cursorrules) — fue una intuición temprana sobre que el framework tiene dos audiencias distintas. Hoy el blog mismo ratifica esa intuición: bilingüe español/inglés para los humanos que lo lean, mientras las skills y prompts que orquestan agentes siguen viviendo solo en inglés. Tres meses después, sigue siendo la decisión correcta.

5. El nacimiento del CLI — y el número que faltó​

5a. El día que el proyecto se volvió software​

El 1 de marzo de 2026, a las 19:05, entró el commit c7e9026:

"feat: rebrand to Strange Days Tech, add CLI scaffolder, restructure repo"

Hasta ese día, el proyecto era prosa. Eran templates, skills, reglas de gobernanza, y un montón de Markdown que dependía de que el operador (yo) los copiara a mano dentro de los repos donde quería usarlos. Había un script bash llamado copy-devtrail.sh. Era de juguete.

Ese commit del 1 de marzo introdujo cli/Cargo.toml y cli/src/main.rs. El primer CLI se llamó devtrail-cli, versión 2.0.0, y tenía tres comandos:

enum Commands {
    Init { path: String },
    Update,
    Remove { full: bool },
}

init, update, remove. Tres operaciones. El resto vino después: status, repair, validate, new, compliance, metrics, analyze, audit, explore. Pero los tres originales siguen ahí, casi sin tocar.

Lo importante del commit no son los tres comandos: es que ese día el proyecto dejó de ser un cuerpo de documentación que vivía en su propio repo y empezó a ser una herramienta ejecutable que se instalaba en otros repos. La frontera entre "proyecto de gobernanza documental" y "framework con tooling" se cruzó ese domingo de marzo. Es más importante que cualquiera de los renames que vinieron antes.

Es también, por cierto, el día en que el proyecto se mudó de cuenta en GitHub: de enigmora/devtrail a StrangeDaysTech/devtrail. La organización pasó de llamarse Enigmora a Strange Days Tech, S.A.S., en el mismo commit que estrenó el CLI. Renames simultáneos: el del producto (de Monimen a DevTrail) había ocurrido en enero; el de la empresa, en marzo. Dos capas separadas de identidad moviéndose en distintos relojes.

(Una nota lateral, importante para el cuidado del archivo: la co-autoría con un agente — ese Co-Authored-By: Claude Opus X.Y que aparece en commits — no nace en marzo. El initial commit del 27 de enero ya viene firmado por Claude Opus 4.5. La transparencia de co-autoría con IA fue regla desde la primera línea de código. Lo que cambia el 1 de marzo no es la práctica, es la escala: el CLI es el primer artefacto donde la co-autoría produce código ejecutable, no documentación.)

5b. El número que faltó​

Hay un detalle del versionado del framework que se entiende mejor mirando git tag:

fw-2.0.0
fw-2.1.0
fw-4.0.0
fw-4.1.0
...

No hay fw-3.x.x. El proyecto saltó deliberadamente del 2 al 4.

El salto se sincroniza con el commit 21e03b2, del 27 de marzo de 2026, cuyo cuerpo describe el cambio así:

"Reposition DevTrail from 'documentation helper' to 'ISO 42001-aligned AI governance platform' across all user-facing docs. Lead with regulatory urgency (EU AI Act Aug 2026) and compliance value proposition."

Hasta marzo, DevTrail se presentaba como ayudante de documentación. A partir de ese commit, se presentó como plataforma de gobernanza de IA alineada con ISO 42001. El cambio de número (2 → 4, saltando el 3) marcó la magnitud del cambio de tesis. Fue una decisión consciente: una versión mayor no alcanzaba para señalar la diferencia.

Y aquí es donde la prehistoria empieza a tener sentido retrospectivo. La intuición que estuvo en el repo desde enero — la idea de un sistema de registro robusto, normativo, alineable con estándares de gobernanza — solo se nombró explícitamente en marzo. Lo veremos con más claridad en la próxima sección, al hablar del segundo nombre.

6. Sobre los nombres​

Tres de los cuatro renames no tienen ADR. La justificación vive solo en los commit messages, y a veces ni siquiera ahí: el commit chore: rebrand Chronicle to Monimen no dice por qué Monimen. El siguiente, chore: rebrand Monimen to DevTrail, tampoco dice por qué DevTrail. La práctica del ADR como artefacto disciplinado llegó después; en enero el nombre cambiaba con un commit y la justificación se evaporaba en la conversación que la había producido.

Pero algo de etimología sí podemos rescatar.

• Chronicle (27 ene). Registro histórico. Bitácora. El nombre habla por sí: lo que se hace con un chronicle es anotar lo que sucedió, en orden, para que se pueda revisar después. No hay ADR pero la palabra carga su propio sentido.

• Monimen (28 ene). Este es el único nombre cuya intuición sí recuerdo y vale contar. Monimen surgió como juego de palabras a partir de Monumento (Monument en inglés). La analogía que motivó la sugerencia: las normas que ya entonces se intuían — AIDEC, AILOG, alineables con la incipiente normativa ISO 42001 — representaban una estructura sólida, duradera. Un monumento es algo que se erige para durar; un pilar de referencia inamovible para una comunidad. Eso quería ser el framework. El sufijo cortado — Monimen en vez de Monument — buscaba darle al término un toque más ágil, más de software, menos de mármol. Duró 25 horas. Pero la intuición no se perdió: lo que en marzo terminó nombrándose explícitamente como ISO 42001-aligned AI governance platform es la versión madura de ese mismo impulso. Monimen era un nombre con la tesis correcta y la lengua equivocada.

• DevTrail (29 ene). El recorrido del developer. Menos solemne que Monimen, más concreto. El commit lo marcó BREAKING CHANGE — lo cual, mirado desde mayo, tiene una ironía: el rebrand más definitivo de los primeros tres fue precisamente el que duró tres meses y medio antes de ser sustituido.

• StrayMark (8-9 may). La marca, la seña que queda. Pero ese rebrand pide su propio post: ya hay ADR público (2026-05-08-001), un arco de cinco PRs nucleares (#114-#118), y un manifesto "Why StrayMark?" en el README que merece tratamiento aparte. Aquí solo lo cierro como el rebrand que vino con disciplina documental detrás.

Lo importante no es la etimología en sí. Es que cada nombre ratifica una intuición distinta sobre qué es el producto: bitácora (Chronicle), pilar normativo (Monimen), recorrido del developer (DevTrail), marca residual (StrayMark). Cuatro nombres son cuatro hipótesis sobre el concepto. La búsqueda termina cuando el concepto se estabiliza — y solo entonces el nombre puede quedarse quieto.

7. Cierre​

Lo que aprendí del proceso, en cuatro tesis:

1. No buscábamos un nombre. Buscábamos al concepto. Los cuatro renames son evidencia de búsqueda, no de indecisión. El concepto se fue afilando a través de los nombres que probaba.

2. Tres de cuatro renames sin ADR. La práctica del ADR como artefacto disciplinado llegó después. En enero todavía no había hábito. Eso no es deuda: es honestidad sobre el ritmo. Los hábitos de gobernanza son el resultado de querer registrar lo que ya estaba pasando, no la precondición para empezar.

3. El proyecto se volvió software el 1 de marzo de 2026. Antes, era prosa. El CLI Rust es la frontera. Cualquier discusión sobre StrayMark como framework tiene que reconocer que hay un antes y un después de ese commit.

4. Probablemente no vuelva a haber rebranding. Pero el blog no lo promete. El proyecto es honesto sobre su propia mutabilidad, y prometerlo sería traicionar la primera tesis del primer post.

Cuando empecé a escribir este blog, hace dos semanas, no tenía intención de cubrir la prehistoria. La idea era hablar de Charters, de observación emergente, de las cosas que el framework hoy hace. Pero el blog mismo es un acto retroactivo — nace porque algo me sorprendió lo suficiente como para empezar a escribir. Y una vez que decidí escribir hacia atrás, fue inevitable llegar a enero. A los tres renames en tres días. Al AIDEC con año tipográfico. A Monimen.

Sigue, en el siguiente post, el primer experimento metodológico real del framework: los seis Planes de Sentinel y el día que Plan se renombró a Charter. Ahí empieza la historia que el blog vino a contar.

Anclas: commits 7c58b6d · 0b772bc · 25ab7a4 · 7b7193e · c7e9026 · 21e03b2. README original: git show v1.0.0:README.md.

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.