flriancu/claude-code-setup

Inicio de requisitos

El usuario resuelve las decisiones explícitamente y de forma económica al principio, luego construye en pasos revisados. Una construcción de una sola vez incorpora suposiciones que luego debe deshacer. La deliberación larga y silenciosa antes de que haya algo por escrito también le molesta ("no hace falta una sola vez, ¿por qué pensar tanto? redactemos un documento con fases"). Así que ponga las preguntas y un plan sobre papel rápidamente, y deje que él dirija.

1. Recopilar, brevemente

• Lea lo proporcionado: archivos, carpetas, enlaces, imágenes, chats anteriores y notas de memoria, el README del repositorio. Anote lo que ya está decidido para no volver a preguntarlo.
• Si una entrada aún falta ("enlace entrante", "la foto llegará más tarde"), comience las preguntas de todos modos y marque cuáles dependen de ella.
• No escriba código ni modifique archivos todavía. No delibere largamente: las preguntas son la herramienta de pensamiento.

2. Hacer preguntas numeradas

• Una lista numerada, agrupada por tema cuando hay muchas. Cada pregunta es una línea con las opciones que ve y su recomendación predeterminada, por ejemplo: 3. Ubicación de instalación: ¿C: o D:? Recomendado: D:, ya que C: está casi llena.
• El usuario responde de forma concisa por número ("1. ambas 2. actualizar 3. ok"). Mapee cada respuesta cuidadosamente. "ok" o "de acuerdo" acepta su valor predeterminado; "anterior" y "posterior" se refieren al orden de sus opciones; un número omitido significa "tú decides, dime qué elegiste".
• Cubra lo que importa para este esfuerzo: objetivo y audiencia; alcance y no-objetivos explícitos; entradas y salidas (formatos, ubicaciones); restricciones (plataforma, herramientas permitidas o prohibidas, licencias, uso sin conexión, hardware); nivel de calidad y prueba de aceptación ("¿cómo sabremos que funciona"); comportamiento ante fallos (qué sucede cuando cada parte falla en cualquier momento: un bloqueo, una conexión perdida, un corte de energía, un nodo de varios que se cae); fidelidad (qué no debe alterarse nunca); dónde viven las cosas (repositorio, rutas, remoto); entrega (quién recibe qué, con qué frecuencia).
• Realice una segunda ronda más corta solo para las respuestas que abrieron nuevas preguntas. Deje de preguntar una vez que las incógnitas restantes tengan valores predeterminados seguros, y enumere esos valores predeterminados en su lugar.

3. Escribir el contrato: REQUIREMENTS.md

Colóquelo en la raíz del proyecto, creando la carpeta si el proyecto es nuevo. Manténgalo simple, corto y con fecha:

# Requisitos de <Proyecto>

Acordado <AAAA-MM-DD>. Este archivo es el contrato; los cambios se registran aquí con una fecha.

## Objetivo
## Audiencia y uso
## Alcance
## No-objetivos
## Decisiones
- D-01 <decisión> (<fecha>)
## Requisitos funcionales
- FR-01 ...
## Restricciones y requisitos no funcionales
- NFR-01 ...
## Verificación
Una fila por requisito: cómo se verifica y dónde reside la evidencia.
| ID | Método (prueba / inspección / análisis / demostración) | Evidencia (caso de prueba, script, archivo) |
## Preguntas abiertas

Los identificadores estables (D-xx, FR-xx, NFR-xx) permiten que trabajos, commits e informes posteriores los citen. Registre las respuestas del usuario en sus propios términos; no las parafrasee para hacerlas más fuertes o más débiles.

Asigne a cada requisito un método de verificación y una ubicación de evidencia. Los cuatro métodos son los estándar de la ingeniería de requisitos (ISO/IEC/IEEE 29148). Prefiera una prueba. Cuando un requisito solo pueda verificarse mediante inspección o análisis ("sin llamadas directas al hilo del SO", "sobrecarga de planificación inferior a 100 microsegundos por nodo"), escriba la comprobación como un script que guarde su salida como evidencia, para que la prueba pueda reejecutarse en lugar de reargumentarse.

4. Escribir el plan: fases

Colóquelo junto a los requisitos en PLAN.md, o en una sección "Fases" cuando el proyecto sea pequeño. La fase 0 suele ser la configuración, o un piloto que prueba primero el supuesto más arriesgado. Para cada fase, proporcione el objetivo, los pasos, el entregable, cómo se verifica y los ID de requisitos a los que sirve. Mantenga las fases lo suficientemente pequeñas para revisarlas de una sola vez, y diga que el plan se ajustará sobre la marcha.

Luego deténgase. Informe los dos archivos en unas pocas líneas y recomiende la primera fase.

5. Ejecutar a petición, una fase a la vez

• Ejecute solo las fases que el usuario nombre ("ejecutar fase 0", "ejecutar fases 0 y 1", "adelante").
• Al final de cada fase, informe lo que se hizo, la evidencia de que funciona (comandos ejecutados, salidas, resultados de pruebas), qué se desvió del plan y por qué, y qué viene después. Marque la fase como completada en el plan.
• "comprobación de progreso" significa: fase actual, qué está hecho, qué se está ejecutando, qué está bloqueado.
• Un nuevo deseo que cambie el alcance va a REQUIREMENTS.md con su fecha antes de construirlo. Una decisión revertida se registra como una reversión; la línea anterior permanece.
• Corrija errores encontrados en el camino cuando el usuario lo haya indicado; de lo contrario, enumérelos.
• Cuando la última fase esté completa, o cuando el usuario lo solicite, realice una pasada de brechas: requisitos contra código, pruebas, documentación y evidencia. Reporte cada brecha con su ID de requisito, corríjalas una por una a petición, y vuelva a ejecutar los scripts de evidencia.
• No haga commit ni push después de cada paso. Proponga un commit cuando una fase esté completa; haga push solo cuando se lo pidan.

Variantes

• Decisiones sin código (una compra, una elección de herramienta): mismas preguntas, luego una comparación breve contra los criterios acordados en lugar de los dos archivos.
• Contenido de otra persona (el libro de un autor, los datos de un cliente, grabaciones): agregue un requisito de fidelidad al principio. Ningún contenido cambia silenciosamente; cada cambio se propone, se marca y se informa para su aprobación.