hwipit/plugin

Hwip Auto — Modo de Trabajo Autónomo con Tiempo Limitado

Trabaja de forma autónoma durante un presupuesto de tiempo fijo: explora → planifica → implementa → verifica → confirma, una unidad a la vez. El usuario dirige desde su teléfono mediante botones de hwip_ask; cuando no responde, continúas con un valor predeterminado seguro en lugar de detenerte. Toda la ejecución ocurre en una sola respuesta — terminar tu turno finaliza el modo.

Precondiciones — rechazar inicio si no se cumplen

• Un hook ID está configurado — hookId en ~/.hwip/config.json (lo que escribe hwip install), o la variable de anulación HWIP_HOOK_ID. El contexto de SessionStart termina con Mode: two-way (notify + ask) cuando lo está; Mode: one-way significa que no hay canal de dirección — rechaza y señala al usuario /hwip-config.
• No silenciado. Si /hwip-mode informa NOTIFICATIONS: muted, rechaza: el modo autónomo sin notificaciones es trabajo desatendido sin dirección. Sugiere /hwip-mode unmute.
• Invocación explícita del usuario. Nunca autoactives este modo porque una tarea "parezca larga". El usuario lo elige con /hwip-auto ....

Argumentos

/hwip-auto [duración] [descripción de la tarea...]

• duración — 2h, 90m, 1h30m, o un número simple que significa minutos. Por defecto: 1h. Límite entre 10m y 8h.
• tarea — todo lo que sigue a la duración. Si se omite, se deduce de la conversación hasta ahora; si no hay ninguna, propón 2–3 tareas candidatas en la pregunta inicial (por ejemplo, corregir pruebas fallidas, limpiar advertencias de lint, una revisión de TODO).

Configuración

1. Registra la fecha límite (un archivo de estado sobrevive a la compactación de contexto — vuelve a leerlo siempre que no estés seguro del tiempo restante):

   HASH=$(printf '%s' "${CLAUDE_PROJECT_DIR:-$(pwd)}" | cksum | cut -d' ' -f1)
   STATE_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/hwip"
   mkdir -p "$STATE_DIR"
   MINUTES=120   # parseado del argumento de duración
   DEADLINE=$(( $(date +%s) + MINUTES * 60 ))
   printf '%s %s\n' "$DEADLINE" "$MINUTES" > "$STATE_DIR/auto-$HASH"
   date -r "$DEADLINE" 2>/dev/null || date -d "@$DEADLINE"   # macOS | Linux
   

2. Protección de rama protegida — nunca trabajes directamente en main/master/develop:

   BRANCH=$(git branch --show-current 2>/dev/null)
   case "$BRANCH" in
     main|master|develop) git checkout -b "auto/$(date +%Y%m%d)-<slug-tarea>" ;;
   esac
   

3. Descubre el verificador antes de escribir cualquier código: las comprobaciones deterministas del proyecto (comandos de test / lint / typecheck / compilación de package.json, Makefile, configuración de CI). Estos son la puerta de entrada para cada commit. Si el proyecto no tiene ninguno, indícalo en la pregunta inicial y trata "el código compila/ejecuta" como la puerta de entrada mínima.

4. Pregunta inicial — un hwip_ask antes de tocar nada:

   • title: "Modo auto: ()"
   • body: plan de 2–3 líneas + qué verificador controla los commits + el nombre de la rama
   • actions: [{id:"start", label:"Iniciar", style:"primary"}, {id:"stop", label:"Cancelar"}] (si la tarea era ambigua, reemplaza "Iniciar" con 2–3 botones de tareas candidatas)
   • placeholder: "ajusta el plan o alcance..."
   • timeout: 180, fallback: "start" (o el candidato recomendado)

   Las respuestas de texto libre modifican el plan; stop cancela el modo (elimina el archivo de estado).

El Bucle

Divide la tarea en unidades: los fragmentos más pequeños verificables y confirmables de forma independiente (~15–45 min cada uno). Luego, por cada unidad:

1. Verificación de tiempo (antes de comenzar cada unidad):

   HASH=$(printf '%s' "${CLAUDE_PROJECT_DIR:-$(pwd)}" | cksum | cut -d' ' -f1)
   read -r DEADLINE MINUTES < "${XDG_STATE_HOME:-$HOME/.local/state}/hwip/auto-$HASH"
   echo "restante: $(( (DEADLINE - $(date +%s)) / 60 ))m de ${MINUTES}m"
   

   Si el tiempo restante está por debajo del umbral de cierre — 10% del presupuesto, al menos 5 minutos — no inicies una nueva unidad; ve a Cierre.

2. Explora → planifica la unidad (lee primero el código relevante; sin ediciones a ciegas).

3. Implementa la unidad.

4. Verifica con las comprobaciones deterministas. Verde es la única señal de aprobación — "parece correcto" no es un verificador, y nunca debilites ni elimines una prueba fallida para llegar a verde. En caso de fallo, corrige y vuelve a verificar, como máximo 3 intentos; si aún está rojo, revierte los cambios de la unidad (git checkout -- <archivos> / git stash) para que el árbol se mantenga limpio, regístrala como saltada y continúa.

5. Confirma la unidad verde con un mensaje convencional claro. NO hagas push.

6. Latido — después de un commit, un breve hwip_notify ("✅ — m restantes"), pero como máximo uno cada ~15 minutos; agrupa unidades pequeñas. Los bloqueos son la excepción: envía un notify con priority: "high" en cuanto aparezca uno.

Repite hasta que las unidades estén completas o se alcance el umbral de cierre.

Protocolo de Preguntas — nunca te detengas, nunca destruyas

Las preguntas durante la ejecución pasan por hwip_ask (nunca AskUserQuestion, nunca texto plano — se aplican las reglas 3/10 de CORE_RULES):

• Pon el valor predeterminado recomendado primero, indica en el cuerpo que continúa automáticamente al agotarse el tiempo, establece timeout: 180 (hasta 600 para decisiones realmente grandes) y fallback al id de ese valor predeterminado.
• Registra cada decisión que se resolvió por fallback — el informe final las lista para que el usuario pueda auditar lo que se decidió sin su intervención.
• Cualquier respuesta es una instrucción directa: aplícala inmediatamente. Una respuesta stop (o un finalizador de sesión en texto libre) significa cerrar ahora.
• Las acciones irreversibles o hacia el exterior nunca son elegibles para fallback: push, PR/publicar, desplegar, eliminar datos, eliminar esquemas, operaciones forzadas, cualquier cosa fuera del árbol de trabajo. Para estas, el fallback DEBE ser skip — al agotarse el tiempo, saltas la acción y la anotas, no la realizas. Solo un toque de botón explícito la autoriza.

Cierre

1. Termina o revierte la unidad en curso (misma regla de 3 intentos — nunca dejes el árbol rojo o sucio).
2. Elimina el archivo de estado: rm -f "${XDG_STATE_HOME:-$HOME/.local/state}/hwip/auto-$HASH".
3. Informe final en el texto de tu respuesta: unidades completadas (con hashes de commit), unidades saltadas y por qué, cada decisión resuelta por fallback, y lo que queda.
4. Pregunta final:
   • actions: [{id:"extend", label:"+30m"}, {id:"review", label:"Revisar"}, {id:"done", label:"Terminar", style:"primary"}]
   • timeout: 300, fallback: "done"
   • extend → escribe una nueva fecha límite (+30m) al archivo de estado y vuelve a entrar al bucle; review → recorre el diff; done → finaliza.

Si Algo Sale Mal

• Sin hook ID (Mode: one-way) — las herramientas bidireccionales no están disponibles; el modo automático no puede ejecutarse. Ejecuta /hwip-config para configurarlo.
• Archivo de estado faltante durante la ejecución (por ejemplo, el directorio de estado fue limpiado): trata la fecha límite como ahora — cierra en lugar de adivinar cuánto presupuesto queda.
• El usuario escribe en el terminal durante la ejecución: ese mensaje es entrada de dirección, igual que una respuesta de hwip_ask. Aplícalo y continúa con el bucle.
• El verificador es inestable (el mismo comando alterna verde/rojo sin cambios): no desperdicies intentos en repeticiones — repórtalo como un bloqueo mediante hwip_notify (priority: "high") y pasa a la siguiente unidad.