lenneTech/grilling-decisions

Examinar Decisiones Abiertas

Entrevista al usuario sin descanso sobre un plan, ticket o diseño hasta alcanzar un entendimiento compartido. El propósito es la alineación antes de que comience el trabajo: un cambio construido sobre una suposición errónea cuesta toda la implementación, más la revisión, la verificación en el navegador y la fusión que le siguen. Una pregunta hecha por adelantado cuesta un clic; la misma pregunta hecha a mitad de la implementación cuesta el cambio de contexto del usuario y detiene la ejecución hasta que regrese.

No tomes ninguna acción sobre el tema del examen hasta que el usuario confirme que el entendimiento es compartido.

El bucle

1. Investiga cada hecho por ti mismo (ver Hechos vs decisiones). Llega a la entrevista ya conociendo el código.
2. Traza el árbol de decisiones. Cada decisión abierta se ramifica en las decisiones que dependen de ella.
3. Resuelve lo que el ticket y la evidencia resuelven. Trabaja cada decisión abierta a través de las cinco partes de un resumen de decisión. Lo que el ticket establece claramente se registra en sus palabras; un vacío que la evidencia deja con exactamente una opción se registra con su Beleg:; todo lo demás permanece abierto para el usuario (Resolver o preguntar).
4. Vuelve a verificar cada pregunta restante contra las fuentes antes de que salga (Volver a verificar antes de preguntar). Una pregunta que las fuentes ya responden le cuesta al usuario una decisión que nunca necesitó tomar.
5. Pregunta la frontera como una ronda. La frontera es cada decisión abierta cuyos prerrequisitos ya están resueltos: las preguntas que puedes hacer ahora sin adivinar una respuesta que aún no has escuchado. Una pregunta que depende de otra pregunta aún abierta en esta ronda pertenece a una ronda posterior.
6. Presenta cada pregunta con su resumen. El resumen termina con tu recomendación, para que el usuario decida en un clic con los hechos a la vista, sin leer el código primero ni componer un diseño desde cero.
7. Vuelve a calcular la frontera después de cada ronda: las decisiones resueltas la empujan hacia afuera, desbloquean preguntas que dependían de ellas y, a menudo, retiran preguntas o las aclaran lo suficiente como para resolverlas a partir de la evidencia. Vuelve a verificar y preguntar en la siguiente ronda.
8. Detente cuando la frontera esté vacía: cada rama visitada, nada queda asumido en silencio. Escribe el registro de decisión y deja que el usuario lo confirme.

Resolver o preguntar

El ticket (o el plan o especificación que se está examinando) es la orden y tiene prioridad: lo que establece claramente se implementa tal como está escrito, con la mayor exactitud posible. Los tickets a menudo son imprecisos, se contradicen u olvidan cosas, y esos son los puntos que se deciden. Cuantas menos decisiones tenga que tomar el usuario, mejor, y cada una que no esté clara es suya. El resumen de decisión traza la línea: escríbelo para cada decisión abierta antes de que se le pregunte a alguien, y deja que su resultado coloque el punto en uno de tres casos.

1. El ticket lo responde claramente: impleméntalo como está escrito. El punto está resuelto y marcado [Ticket <ID>], también cuando una característica vecina lo hace de manera diferente o tú hubieras elegido otra cosa. No se le pregunta a nadie.

2. El ticket es impreciso, se contradice u omite una consecuencia: el usuario decide. Pregunta con el resumen cuando su redacción se pueda interpretar de dos maneras o deje abierto lo que significa "hecho"; cuando la descripción, los comentarios, los criterios de aceptación y el diseño no estén de acuerdo; cuando su imagen del código actual no coincida con lo que el código muestra; o cuando seguirlo literalmente rompería algo que no menciona (comportamiento del que dependen otras características, seguridad, datos existentes). Lo que significa el ticket es decisión del usuario, así que estos van a él incluso cuando te inclines por una opción.

3. El ticket no dice nada: resuelve el vacío cuando la evidencia no sea ambigua; de lo contrario, pregunta. Resuélvelo tú mismo cuando solo una opción se sostenga:

• otra fuente indica la respuesta (un documento vinculado, el diseño, los documentos del proyecto), o el código maneja este caso exacto de una manera establecida (ruta:línea),
• nada en las fuentes o el código apunta en la otra dirección,
• ninguna otra opción tiene una ventaja que alguien pueda considerar razonablemente superior, y
• no tiene consecuencias duraderas (modelo de datos, migración, permiso predeterminado, un contrato que otro módulo o equipo consume). Estos van al usuario siempre que el ticket esté en silencio, por muy segura que sea tu propia lógica.

Registra un vacío resuelto como una Annahme con su evidencia en una línea Beleg: (Registro de decisión); el usuario lo ve al confirmar el registro y puede anularlo allí. Cualquier otro vacío va al usuario con el resumen, y también cualquier punto del que no estés seguro: la duda sobre si un punto está claro significa que no lo está.

Volver a verificar antes de preguntar

Una pregunta que llega al usuario le pide que decida, así que antes de que salga una ronda, regresa a las fuentes con sus preguntas en mente. La primera lectura buscaba los requisitos; esta busca la respuesta a una pregunta específica, y encuentra lo que una lectura general pasa por alto: una respuesta profunda en un hilo de comentarios, un segundo marco en el diseño, un criterio de aceptación que solo funciona de una manera.

1. Vuelve a leer el ticket completo, con las preguntas de la ronda en mente: descripción, criterios de aceptación, cada comentario y respuesta (no solo los más nuevos), y las imágenes en ellos.
2. Busca en las otras fuentes los términos de cada pregunta, en alemán e inglés y con sinónimos (la entidad, campo, rol, pantalla o estado del que se trata): tickets padres, subtickets y vinculados, documentos adjuntos, comentarios y documentos de decisiones anteriores, cada marco y estado del diseño, los flujos, los documentos del proyecto.
3. Busca una respuesta que se siga de lo que ya está fijado: otro criterio de aceptación que funcione con una sola opción, una decisión tomada anteriormente en este examen, una prueba o validación que ya fije un comportamiento que el ticket deje sin cambios.

Luego clasifica cada pregunta nuevamente según Resolver o preguntar: una respuesta que el ticket establece claramente la resuelve como está escrito; una respuesta en otra fuente puede resolver un vacío, con su Beleg:; una contradicción que la nueva verificación encontró sigue siendo una pregunta, ahora con ambas citas. Solo una pregunta que sobrevive entra en la ronda, y la parte 3 de su resumen nombra lo que cubrió la nueva verificación, para que el usuario vea que la pregunta es real.

Resumen de decisión

Cinco partes en este orden, cada una respondida a partir de la evidencia que recopilaste en esta sesión: el código tal como está en la rama, las fuentes tal como se leen hoy.

1. Ist-Stand im Code: lo que el código hace hoy donde aterriza la decisión, con ruta:línea. Para algo que aún no existe, dilo y nombra dónde buscaste. Cuando el ticket describe el comportamiento actual de manera diferente a como lo muestra el código, indica ambos: esa brecha suele ser la verdadera pregunta.
2. Geplante Änderung: qué se cambia, añade o elimina, cómo y por qué (el criterio de aceptación o fuente que lo exige). Separa lo que ya está fijado de la bifurcación que resuelven las opciones.
3. Ticket und Quellen: lo que el ticket, sus comentarios, tickets y documentos vinculados, el diseño y los documentos del proyecto dicen sobre este punto, el ticket primero, citado textualmente entre „…“ con la fuente entre paréntesis (ticket y sección, fecha del comentario, título del documento, nodo de Figma, CLAUDE.md:<línea>). Cita la oración que importa, no el párrafo. Cuando las fuentes no estén de acuerdo, cita cada lado. Cuando ninguna fuente aborde el punto, dilo y enumera lo que cubrió la nueva verificación: ese silencio es por qué es una pregunta.
4. Optionen: de dos a cuatro, las mismas que ofrece la pregunta, cada una con lo que significa concretamente, su ventaja, su desventaja y su impacto: archivos y módulos tocados, datos existentes, otros roles o consumidores, pruebas, esfuerzo y si es difícil de deshacer más adelante. Una opción que el framework ya incluye es una de ellas.
5. Empfehlung: la opción que elegirías y por qué, argumentada a partir de las partes 1 a 3.

Mantén cada parte en una a tres líneas: el resumen es el contexto para una decisión, no un informe. Escribirlo es también la prueba de Resolver o preguntar: cuando la parte 3 encuentra una cita que responde el punto, o la parte 1 muestra que el código ya lo decide, el punto está resuelto y sale de la ronda.

**F1 Comportamiento de eliminación de facturas**

1. **Ist-Stand im Code:** `InvoiceService.delete()` elimina físicamente mediante `deleteOne` (`projects/api/src/server/modules/invoice/invoice.service.ts:88`), pero hasta ahora no se llama en ningún lado. `Payment.invoice` hace referencia a la factura (`payment.model.ts:31`). En el proyecto hay ambos patrones: `Order` elimina de forma suave mediante `deletedAt` (`order.service.ts:54`), `Customer` de forma física (`customer.service.ts:71`).
2. **Geplante Änderung:** Los administradores obtienen una acción de eliminar en la lista de facturas (CA 3): nuevo endpoint `DELETE /invoices/:id`, botón en `InvoiceList.vue`. Está fijado quién puede eliminar; está abierto si el registro desaparece.
3. **Ticket und Quellen:**
   - „Los administradores deben poder eliminar facturas erróneas.“ (DEV-1234, Descripción)
   - „Eliminar solo para administradores.“ (DEV-1234, Comentario del 02.10.2026)
   - Las fuentes no dicen si las facturas eliminadas deben conservarse (verificado: descripción, 3 comentarios, nodo Figma 12:345, `docs/`).
4. **Optionen:**
   - **A Eliminación suave** mediante `deletedAt`, como en `Order`. Ventaja: el historial y las referencias de `Payment` siguen siendo válidos. Desventaja: cada consulta necesita el filtro. Impacto: cambian el modelo, el servicio y tres consultas de listas; no hay migración, el campo es opcional.
   - **B Eliminación física**, como en `Customer`. Ventaja: sin campo adicional, sin filtro. Desventaja: la factura desaparece para siempre. Impacto: las referencias de `Payment` quedan sin destino y necesitan su propio tratamiento.
5. **Empfehlung:** A, porque los pagos hacen referencia a la factura y una factura eliminada ya no sería rastreable de otra manera.

El ticket está en silencio, el proyecto tiene ambos precedentes y la elección da forma al modelo de datos, por lo que este vacío va al usuario. Si la descripción hubiera dicho „Las facturas eliminadas permanecen guardadas y solo se ocultan“, el ticket lo habría resuelto: Eliminación suave, implementado como está escrito, marcado [Ticket DEV-1234], sin pregunta. Si un comentario hubiera exigido lo contrario, la contradicción habría ido al usuario, con ambas citas en la parte 3.

Formato de ronda

Usa AskUserQuestion: una llamada por ronda, hasta cuatro preguntas, cada una con su opción recomendada primero y el sufijo (Recomendada), la descripción de cada opción con su impacto en una línea. La entrada "Otro" proporcionada automáticamente lleva respuestas de texto libre. Cuando la frontera tenga más de cuatro preguntas, pregunta las más upstream primero; sus respuestas suelen retirar algunas de las restantes.

Coloca los resúmenes de la ronda en el mismo mensaje que la llamada, justo antes, numerados para que coincidan (P1, P2, …), para que el usuario los lea con las preguntas abiertas.

Una pregunta que solo recopila un hecho que solo el usuario posee (lo que observó, qué cuenta usó) o una elección de flujo de trabajo (ejecutar una revisión, cómo fusionar) no necesita resumen: sus etiquetas de opción llevan lo que importa.

Sin AskUserQuestion (chat simple, un ejecutor no interactivo), imprime la ronda en ese mismo formato y espera las respuestas.

Hechos vs decisiones

Encontrar hechos es tu trabajo. Preguntar al usuario por algo que podrías haber leído es lo que hace que una entrevista parezca un interrogatorio, y la respuesta que obtienes de la memoria es menos confiable que la que está en el repositorio.

Investígalo tú mismo	Decide (resuelve a partir de la evidencia, o pregunta)
Qué roles permite ya un servicio (@Restricted, @Roles, securityCheck)	Qué roles deberían estar permitidos
La forma actual de una entidad, DTO o tipo generado (types.gen.ts, sdk.gen.ts)	Si se añade, renombra o reemplaza un campo
Si ya existe un endpoint, página o composable	Si extenderlo o construirlo al lado
Lo que realmente dicen el ticket, sus comentarios y el nodo de Figma vinculado	Lo que significa el ticket donde es ambiguo
Cómo resolvió una característica vecina el mismo problema	Si esta característica debe seguir ese precedente
Qué pruebas cubren las rutas afectadas hoy	En qué costuras deben estar las nuevas pruebas
Si el defecto descrito aún se reproduce	Cuál es el comportamiento correcto en su lugar

Recurre a Leer, Grep, Glob, el MCP de Linear y el MCP de Figma antes de recurrir a una pregunta. Cuando una búsqueda sea amplia, envía un subagente para ella y no te bloquees: una búsqueda en ejecución es un prerrequisito no resuelto, por lo que solo las preguntas posteriores a ella esperan, y el resto de la frontera se pregunta ahora.

Calidad de la pregunta

• Sondea los bordes, no el camino feliz. Vacío, nulo, muy grande, concurrente, no autorizado, sin conexión. El camino feliz es la parte en la que todos ya están de acuerdo.
• Superficie las consecuencias que sobreviven al ticket: un modelo de datos difícil de migrar más tarde, un permiso predeterminado que se convierte en el precedente, un contrato que otros equipos consumirán.
• Un nuevo proyecto nest-server resuelve su base de datos en esta ronda. A menos que el ticket o una sección ## Database en la raíz CLAUDE.md la nombre, la base de datos y el motor SQL son una pregunta (sobreviven a todos los tickets), informada por el procedimiento en generating-nest-servers → reference/choosing-a-database.md: la señal de las fuentes en la parte 3, el paso decisivo en la parte 5, y para MySQL / MariaDB lo que el proyecto cede. Un nuevo módulo con sus propios datos permanece en la base de datos del proyecto sin pregunta; se convierte en una solo cuando las fuentes apuntan a otra base de datos (híbrido). La respuesta confirmada va al registro de decisión y, como ## Database, a la raíz CLAUDE.md.
• Cubre lo que la implementación detendría de otro modo. Antes de cerrar, recorre mentalmente el trabajo planificado una vez (modelos, endpoints, permisos, estados de UI, pruebas) y pasa cada punto donde de otro modo harías una pausa por Resolver o preguntar. Eso es lo que hace que la ejecución posterior esté libre de preguntas.

Cuando el usuario no está disponible

Una decisión poco clara pertenece al usuario, por lo que una que bloquea nunca se responde en su nombre

…

[truncado para traducción]