Abrir el framework
Setenta y dos horas de gestos que sólo cobran sentido juntos
Setenta y dos horas de gestos que sólo cobran sentido juntos
Cuatro meses entre la intuición y el estándar abierto
De ritual manual en Sentinel a comando CLI canonizado
Issue #113 — la brecha entre tener un artefacto y que el agente lo vea
Buscar el concepto buscando el nombre
El único archivo del framework que vivía en otro idioma
Cómo nombrar una propiedad de diseño que ya estaba haciendo su trabajo en silencio
Un ciclo de auditoría con cuatro modelos revisó un Charter que añadía un método público nuevo — el único método que hacía funcionar una feature. Tres de cuatro auditores reportaron que no había hallazgos críticos ni altos. La feature tenía cero llamadores en producción, 3.376 tests en verde, y no funcionaba de punta a punta. El defecto era detectable mecánicamente con un solo grep; un auditor corrió exactamente ese grep y leyó el resultado al revés. El post-mortem produjo una regla nueva en el prompt de auditoría — y un hallazgo más incómodo sobre la verificación del propio implementador, que no podía dar rojo.
El cuarto rename, esta vez con ADR público y arco disciplinado
Doce aprendizajes en un Issue, tres gates en un PR, y un Charter que cerró limpio antes de que existiera el nombre
Diez gaps latentes aflorados en un solo polish Charter, y el anti-patrón que se ganó un nombre
Un segundo adopter, en otro lenguaje, validó el anti-patrón "declaración de superficie sin cableado" — y el helper de CLI que diferimos a propósito por fin shippeó
Un adopter greenfield drenó un backlog de follow-ups antes de publicar y descubrió que tres de ellos — los tres que eran trabajo real — cargaban cada uno una premisa que era falsa en el momento en que la chequeabas. No porque el código hubiera cambiado bajo ellos, sino porque un follow-up se escribe en el único momento en que estás menos equipado para verificarlo. La lección no es "escribe mejores follow-ups". Es que un follow-up es una hipótesis fechada, y el lugar barato para probarla es cuando la lees, no cuando la escribes — así que ahí es donde StrayMark ahora pone el chequeo.
Google publicó el Open Knowledge Format — markdown, frontmatter YAML, un grafo de enlaces, un agente que los mantiene. StrayMark llegó a las mismas primitivas de forma independiente. La convergencia es real; la divergencia también — OKF construye cognición para la IA, StrayMark la construye para la IA y el ingeniero humano juntos.
La reescritura de Bun en Rust corrió revisión adversarial de IA a una escala que vale la pena estudiar — una sola familia de modelo, ventanas de contexto separadas, y 1.386.826 aserciones de test como juez final. Las auditorías de StrayMark se ven distintas porque el objetivo es distinto, y la diferencia no es de estilo. Cuando un suite de tests que pasa puede ser el juez, aíslas a los revisores por contexto. Cuando el juez es un juicio humano, diversificas por familia de modelo — y 25 ciclos de auditoría con datos reales muestran exactamente por qué, incluida una familia que se quedó callada y ciega.
Cuando la disciplina deja de ser hábito y se vuelve nombre
La auditoría de StrayMark solo vale algo si familias de modelos independientes convergen en un finding por sí mismas — el acuerdo es la señal. Una serie de releases endureció esa garantía contra tres formas de fingirla. La más fresca es la más filosa — un router CLI inyecta su propio nombre de producto, así que un auditor firmó su reporte como "qwen-code" aun después de que el operador había cambiado el modelo de backend. A la matemática de convergencia le estaban dando de comer una mentira sobre quién hizo el trabajo.
Primer experimento sistemático y el día que Plan se llamó Charter
El tipo existía. El trigger no. Y la lección stacked-PR que llegó de regalo.
Phase 2: cuando el framework empieza a verificar lo que prometía