Convenciones

El tamaño no es esfuerzo

XS, S, M, L (--tamano) seleccionan la profundidad documental — cuáles de los documentos son obligatorios — no el tiempo que llevará:

XS — cambio menor: una página con el pedido, el cambio, las tareas, las pruebas y la aprobación, y una conversación hasta el PR (/kb-cambio). Una aplicación, hasta 3 tareas y 5 archivos; si crece, kb escalar.
S — corrección: captura → implementa → prueba → entrega.
M — el ciclo completo.
L — ciclo completo más manual de usuario.

Para cuánto vas a entregar y cuánto costará, kbspec mide: ver Pronóstico por flujo.

Reglas que más se preguntan

Sin sesión abierta no se toca ningún expediente — todo lo demás se responde normal.
Un requerimiento a la vez por carpeta; dos en paralelo = dos ventanas.
Después de aprobar el requerimiento, todo cambio es control de cambios; después de entregar, todo es ticket nuevo.
La §2 del análisis técnico —módulo anfitrión y archivos de referencia— es obligatoria: es lo que hace que el código nuevo no desentone.

El lenguaje del negocio

Las convenciones de arriba las acuerda el equipo entre personas. Esta la lee el agente, antes de responder:

kb glosario --agregar "excepción" \
    --es "el permiso temporal para salirse de una política de riesgo" \
    --no "incidente: la excepción se pide antes, el incidente se reporta después"

Vive en aplicaciones/GLOSARIO.md, se llena durante el análisis —un término por vez, cuando aparece una palabra que un recién llegado no entendería— y no admite dos definiciones del mismo término. Dos definiciones son peor que ninguna.

Sirve para dos cosas, y la segunda no es obvia:

Que la conversación sea corta y precisa. «Hay un problema con la cascada de materialización» dice lo mismo que tres líneas de explicación.
Que cueste menos. El modelo piensa con las palabras que tiene: un vocabulario corto y exacto baja los tokens de cada turno, y los turnos son lo que mueve el consumo.

La tercera columna es la que evita el error caro

--no —«con qué NO hay que confundirlo»— parece un adorno y es lo contrario. Casi todas las confusiones de un glosario son entre dos estados o entre dos acciones:

Término	Qué es	No confundir con
`devolver`	el supervisor la manda de vuelta a Borrador con una nota	`rechazar`: devolver deja el caso vivo
`En revisión`	ya la envió la sucursal y la tiene el supervisor	`En vigencia`: en revisión todavía no autoriza nada

Dos palabras del negocio que el código trata igual se confunden una sola vez, y sale mal en producción. Por eso la desambiguación viaja con el término a todos lados: al contexto que se reinyecta en cada compactación, y al brief del prototipo de comportamiento — que es justo donde los estados importan.

Los primeros términos entran al contexto al arrancar la sesión. Si el equipo tiene más de los que entran, kbspec dice cuántos quedaron afuera en vez de recortarlos en silencio.

La cuarta columna dice qué palabra no usar

«No confundir con» explica la diferencia; «Evitar» la vuelve verificable. Son las palabras que el equipo NO usa para ese término: un sinónimo que en el dominio quiere decir otra cosa, o una palabra genérica que esconde la del negocio.

kb glosario --agregar "pase de negocio" --evitar "release, entrega"

Desde ahí, kb validar avisa dónde aparecen en la solicitud, el requerimiento, el análisis, el plan y la descripción del PR —no cuenta lo citado, el código ni los enlaces—, y el agente las recibe al arrancar como «no digas». Es un aviso, no una compuerta: la palabra puede estar bien usada, y eso lo decide quien lo lee. Un glosario de tres columnas se sigue leyendo igual; la cuarta se agrega sola la primera vez que se usa.

La referencia completa, con la tabla de excepciones, viaja con el framework en CONVENCIONES.md.