Las tres plantillas de Charter (charter-template.md base, i18n/es, i18n/zh-CN) piden en el paso 3 del cierre:
Move the row in .straymark/charters/README.md to ## Closed and reference the PR.
Ese archivo no lo crea el CLI, ni straymark init ni charter new. En nuestro adoptante (ri-ceiba) nunca ha existido, así que 21 de nuestros 36 charters arrastran un paso de cierre que no se puede ejecutar.
Cómo se detectó
No lo detectó nadie leyendo el procedimiento en dos años de uso. Lo encontró un auditor externo (qwen3-8-max) durante la auditoría del CHARTER-34, comprobando uno por uno los pasos de cierre declarados:
El paso 3 del cierre del Charter referencia .straymark/charters/README.md, que no existe en el repositorio. La instrucción viene de la plantilla y aparece en todos los charters; el índice no existe en este adoptante, así que el paso no es ejecutable tal como está escrito.
En nuestra review consolidada quedó MISATTRIBUTED: la observación es correcta pero pertenece a la plantilla del framework, no al Charter auditado.
Por qué importa más de lo que parece
Un paso inejecutable dentro de un procedimiento se convierte en un paso que se omite en silencio. Y una vez que alguien aprende a saltarse el paso 3 sin consecuencias, deja de distinguirlo de los pasos que sí importan — el drift check post-merge, el closed_at, el no borrar el archivo. El coste no es el índice ausente: es la erosión del hábito de ejecutar el procedimiento entero.
Lo que hicimos localmente
Corregir las tres plantillas para que el paso sea condicional y honesto (nuestro PR #256):
3. **Update the Charter index, if this project keeps one.** The authoritative status lives in the
Charter's own frontmatter and is queried with `straymark charter list`. A `README.md` index under
`.straymark/charters/` is **optional and not created by the CLI**: if your project maintains one,
move the row to `## Closed` and reference the PR. If it doesn't, this step does not apply — say so
in `## Closing notes` rather than leaving it silently unexecuted.
Decidimos deliberadamente no crear el índice, por dos razones:
straymark charter list ya expone esa información desde el frontmatter, que es la fuente de verdad. Un índice manual la duplicaría.- Un índice de 36 charters mantenido a mano es exactamente el documento que se desactualiza. Nuestro repositorio ya tiene seis casos registrados de documentación que parecía vigente y no lo era; uno de ellos indujo conclusiones falsas en tres auditorías consecutivas.
Lo que proponemos aguas arriba
Tres opciones, en el orden en que las preferiríamos:
- Adoptar la redacción condicional en las tres plantillas. Coste cero, resuelve el caso para todos los adoptantes que no mantengan índice.
- Que
straymark init cree el índice y que charter close lo actualice. Coherente con el paso tal como está escrito hoy, pero añade un artefacto que hay que mantener sincronizado — y el CLI tendría que ser quien lo mantenga, no el operador.
- Retirar el paso y apuntar a
charter list. Es lo más simple, pero pierde el caso de los adoptantes que sí quieran un índice legible fuera del CLI.
Nos quedamos con la 1 localmente. Si el framework adopta otra, la reaplicamos.
Nota sobre la corrección local
Vive en .straymark/templates/, que entendemos puede sobrescribirse en la próxima update-framework. Si el framework no incorpora el cambio, tendremos que reaplicarlo tras cada actualización — que es el motivo de reportarlo en vez de quedarnos con el parche.
Versión: fw-4.42.0 / cli-3.39.x · Adoptante: ri-ceiba (StrangeDaysTech)
Relacionado: #424 (también salió de la misma cadena de charters)
Las tres plantillas de Charter (
charter-template.mdbase,i18n/es,i18n/zh-CN) piden en el paso 3 del cierre:Ese archivo no lo crea el CLI, ni
straymark initnicharter new. En nuestro adoptante (ri-ceiba) nunca ha existido, así que 21 de nuestros 36 charters arrastran un paso de cierre que no se puede ejecutar.Cómo se detectó
No lo detectó nadie leyendo el procedimiento en dos años de uso. Lo encontró un auditor externo (
qwen3-8-max) durante la auditoría del CHARTER-34, comprobando uno por uno los pasos de cierre declarados:En nuestra review consolidada quedó MISATTRIBUTED: la observación es correcta pero pertenece a la plantilla del framework, no al Charter auditado.
Por qué importa más de lo que parece
Un paso inejecutable dentro de un procedimiento se convierte en un paso que se omite en silencio. Y una vez que alguien aprende a saltarse el paso 3 sin consecuencias, deja de distinguirlo de los pasos que sí importan — el drift check post-merge, el
closed_at, el no borrar el archivo. El coste no es el índice ausente: es la erosión del hábito de ejecutar el procedimiento entero.Lo que hicimos localmente
Corregir las tres plantillas para que el paso sea condicional y honesto (nuestro PR #256):
Decidimos deliberadamente no crear el índice, por dos razones:
straymark charter listya expone esa información desde el frontmatter, que es la fuente de verdad. Un índice manual la duplicaría.Lo que proponemos aguas arriba
Tres opciones, en el orden en que las preferiríamos:
straymark initcree el índice y quecharter closelo actualice. Coherente con el paso tal como está escrito hoy, pero añade un artefacto que hay que mantener sincronizado — y el CLI tendría que ser quien lo mantenga, no el operador.charter list. Es lo más simple, pero pierde el caso de los adoptantes que sí quieran un índice legible fuera del CLI.Nos quedamos con la 1 localmente. Si el framework adopta otra, la reaplicamos.
Nota sobre la corrección local
Vive en
.straymark/templates/, que entendemos puede sobrescribirse en la próximaupdate-framework. Si el framework no incorpora el cambio, tendremos que reaplicarlo tras cada actualización — que es el motivo de reportarlo en vez de quedarnos con el parche.Versión: fw-4.42.0 / cli-3.39.x · Adoptante: ri-ceiba (StrangeDaysTech)
Relacionado: #424 (también salió de la misma cadena de charters)