Meltemi

El método es una herramienta, no un peaje

Una especificación no es papeleo que le debes al proceso. Es lo que permite que un rumbo claro impulse a cualquier número de agentes, de cualquier fabricante, sin que tengas que reexplicar tu intención en cada sesión — y lo que hace su resultado revisable en vez de solo verosímil.

El bucle

Todo cambio recorre el mismo arco corto. Lo trivial toma la vía rápida —todos los artefactos de una vez—, nunca la vía nula.

1 · Proponer

Una idea se convierte en un cambio con nombre: por qué importa, qué toca y qué deja fuera a propósito.

2 · Diseñar

Las decisiones que vale la pena defender, cada una con las alternativas que se rechazaron y por qué. Aquí una sugerencia del agente se gana su lugar o lo pierde.

3 · Deltas de spec

Requisitos escritos como comportamiento testeable, expresados como deltas contra las capacidades que ya tienes —añadida, modificada, retirada— en vez de un documento reescrito en su sitio.

4 · Tareas

Una secuencia lo bastante pequeña para revisarse, con cada tarea apuntando al requisito que la justifica.

5 · Verificar

Cada escenario queda ligado a un test o a una verificación documentada. Nada se pliega mientras un requisito no esté verificado ni exceptuado con su razón explícita.

6 · Archivar

Los deltas se pliegan a la verdad viva y el cambio pasa a ser histórico. La verdad es lo que el código hace ahora, no lo que alguien planeó una vez.

Requisitos capaces de romper un build

Los requisitos se escriben en una forma acotada —un disparador, una condición, un debe— para que un escenario se lea igual para una persona y para el nombre de un test. Un requisito cuyos escenarios no pueden fallar es un deseo, y Meltemi lo trata como tal.

La trazabilidad es mecánica, no aspiracional: un commit por tarea, el commit nombrando su cambio y su tarea, y cada línea de código rastreable hasta el requisito que la originó.

Dónde encajan los agentes

El método es el mismo si escribes el cambio tú o si lo delegas. Meltemi proyecta la constitución, el rumbo de producto y la especificación activa al contexto que recibe el agente, para que argumente dentro de tus restricciones en vez de inventarse las suyas. Después sostiene las puertas: permisos que decides tú, worktrees aislados por tarea, checkpoints antes de cada turno y un diff que revisas antes de que nada se aplique.

Varios agentes pueden competir por la misma tarea en worktrees separados y tú eliges el resultado. De eso trata el rumbo: no le importa qué vela atrape el viento.

Lee las fuentes íntegras

Nada de esto sustituye a los documentos primarios, y este sitio no los parafrasea hasta convertirlos en una segunda verdad: