kdd-definir

DEFINIR (KDD): cerrar la definicion de un proyecto antes de PLAN

knowledge/metodologia-ejecucion.md arranca en PLAN, que asume que ya existe un "pedido" convertible en tareas atomicas. Esta skill cubre el paso anterior: cuando el proyecto todavia no esta elegido, o esta elegido pero su forma (arquitectura, alcance, stack) todavia no cerro. Sin este paso, un usuario sin idea clara termina escribiendo el primer task contract sobre una base que cambia por debajo a las dos tareas.

Que produce

Un unico artefacto: DEFINITION.md en la raiz del proyecto (plantilla: TEMPLATE-DEFINITION.md). Estructura fija (no se cambia salvo pedido explicito del usuario):

1. Que es — una frase.
2. Arquitectura (si aplica) — componentes y como se comunican entre si; si hay un core reusable + interfaces/pieles, decirlo asi de explicito.
3. Capacidades objetivo — sin fasear salvo que el usuario lo pida.
4. Por que es un caso valido / motivacion real — que problema resuelve y para quien, no solo "sirve para probar el metodo".
5. Fuera de alcance — explicito, en negativo (que decisiones NO se toman aca porque son de implementacion).

Reglas duras

• NUNCA escribas codigo de produccion, ni contratos CCDD, ni specs/CONTRACT-NN-*.md. Eso es de otra fase, con otro proceso (oraculo congelado por tarea, delegacion a un agente efimero).
• NUNCA inventes el proyecto por el usuario. Si no tiene idea, propone 2-3 candidatos CONCRETOS anclados en lo que sabes de sus intereses o restricciones reales -- nunca ideas genericas de relleno.
• Si el usuario menciona una restriccion real (ej. "esto es de un cliente, no lo puedo usar de ejemplo", "esto lo hice solo porque podia, no porque lo necesitaba") tratala como restriccion dura para el resto de la conversacion -- no la ignores ni la repitas.
• NUNCA asumas una decision de arquitectura o stack cuando hay mas de una opcion razonable con tradeoffs reales. Presenta las opciones CON el tradeoff concreto de cada una (que se gana, que se pierde o rompe), nunca una lista neutra sin postura.
• Cuando una pregunta del usuario revela una decision de arquitectura implicita (ej. "puedo agregar X tambien?"), explicitala como tal -- nombra la decision, muestra las consecuencias concretas de cada camino -- antes de que el usuario elija, no despues.
• Pregunta una decision genuina a la vez (o un batch corto si son independientes entre si) -- nunca un cuestionario largo de una vez.
• Cuando el usuario dice "cerremos la definicion" (o equivalente): sintetiza TODO lo discutido en el DEFINITION.md, sin agregar nada nuevo que no se haya hablado en la conversacion. Confirma que cerro antes de darlo por terminado.