fn_registry/.claude/commands/equal.md

description, argument-hint

description	argument-hint
Espejo de requisitos: Claude reformula con detalle la última tarea pedida (objetivo, alcance, entregables, supuestos, criterios de aceptación, fuera de alcance y dudas) para confirmar alineación antes de ejecutar. No ejecuta nada.	[opcional: matiz o foco a tener en cuenta al reformular]

/equal — confirmar alineación reformulando la tarea pedida

Mecanismo de espejo de requisitos. Cuando el usuario invoca /equal, NO ejecutas la tarea: devuelves tu interpretación detallada y estructurada del encargo más reciente, para que el usuario confirme o corrija antes de que empieces a trabajar.

El objetivo es eliminar el malentendido silencioso: prefieres gastar un turno reflejando lo que crees que se te pide que arrancar en la dirección equivocada.

Qué hacer al invocarse

1. Identifica la tarea más reciente que el usuario te ha pedido en la conversación actual: la última petición de trabajo real, no el /equal en sí ni un comando de utilidad anterior. Si hay $ARGUMENTS, úsalos como matiz o foco adicional al reformular (p. ej. "céntrate en el alcance" o "asume que es solo el backend"), no como la tarea nueva.

2. Reformula esa tarea de forma detallada y estructurada, con estas secciones (omite una sección solo si es genuinamente no aplicable, no para abreviar):

   • Objetivo — qué se quiere conseguir, en una o dos frases claras. El "para qué", no solo el "qué".
   • Alcance / qué incluye — los trozos concretos de trabajo que entiendes incluidos. Lista, no párrafo.
   • Entregables — qué archivos, cambios, salidas o artefactos concretos vas a producir.
   • Supuestos — lo que estás asumiendo por defecto al no estar dicho explícitamente (stack, ubicación, convenciones, datos, alcance temporal). Hazlos visibles para que el usuario los pueda tumbar.
   • Criterios de aceptación — cómo sabremos que está bien hecho. Condiciones verificables, no deseos vagos. Cuando aplique, golden + edge + caso de error (alineado con dod_quality.md).
   • Fuera de alcance — lo que NO vas a hacer, para acotar expectativas y evitar scope creep.
   • Dudas / ambigüedades a confirmar — preguntas concretas sobre lo que no está claro. Numéralas para que el usuario pueda responder por número. Si no hay dudas reales, dilo explícitamente ("sin dudas bloqueantes").

3. Cierra pidiendo validación: una línea clara del tipo "¿Alineado? Corrige lo que no cuadre y arranco." No empieces a trabajar hasta que el usuario confirme.

Caso sin tarea previa

Si no hay una petición de trabajo clara que reformular (la conversación está vacía de encargos, o lo último fueron solo comandos de utilidad / charla), NO inventes una tarea. Dilo directamente y pide al usuario que describa qué quiere hacer, ofreciéndole la misma estructura como guía de qué información es útil (objetivo, entregables, criterios).

Reglas duras

• No ejecutas la tarea. /equal solo refleja y pregunta. Nada de editar archivos, lanzar comandos de trabajo ni delegar a subagentes para "ir avanzando".
• No inventes requisitos. Lo que no se ha pedido va a Supuestos (marcado como asunción) o a Dudas (como pregunta), nunca colado como hecho.
• Refleja lo que se pidió, no lo que crees que debería pedirse. Si detectas una mejora obvia, propónla como una duda al final, no la incorpores al objetivo.
• Sé concreto. Evita reformulaciones genéricas que valdrían para cualquier tarea. Cita los detalles reales del encargo (nombres de archivos, rutas, tecnologías, cifras que el usuario mencionó).
• Mantén el comando simple: es un reformulador de requisitos, no un planificador de implementación ni un generador de tareas.

Ejemplo de salida

Para una petición previa como "añade un endpoint /health al servicio de deploy que devuelva 200 y la versión":

## Objetivo
Añadir un health check HTTP al deploy_server para poder verificar de forma
programática que el servicio está vivo y saber qué versión corre.

## Alcance / qué incluye
- Nuevo handler GET `/health` en el servidor HTTP de deploy_server.
- Respuesta 200 con un cuerpo JSON que incluya la versión del binario.
- Registro de la ruta en el router existente.

## Entregables
- Cambio en el código del servidor de `apps/deploy_server/` (handler + ruta).
- Sin migración de BD (no toca schema).

## Supuestos
- La versión a devolver es la que ya expone el binario (no hay que crear un
  sistema de versionado nuevo).
- Formato de respuesta JSON `{"status":"ok","version":"x.y.z"}`.
- Sin autenticación en `/health` (endpoint público de liveness).

## Criterios de aceptación
- Golden: `GET /health` con el servicio arriba → 200 + JSON con `version`.
- Edge: la versión se lee correctamente aunque el binario se compile sin tag.
- Error: si un subsistema crítico no está listo, devuelve 503, no 200 falso.

## Fuera de alcance
- Readiness check de dependencias remotas (VPS, SSH).
- Métricas / observabilidad más allá del 200.

## Dudas / ambigüedades a confirmar
1. ¿`/health` debe comprobar algo real (DB, disco) o basta con responder vivo?
2. ¿La versión sale de un ldflag de build, de un fichero, o de constante?
3. ¿Puerto y router son los que ya usa `deploy_server serve`?

¿Alineado? Corrige lo que no cuadre y arranco.

El ejemplo es ilustrativo del formato y el nivel de detalle; el contenido real sale siempre de la tarea concreta que el usuario haya pedido en la conversación.