El hook capturaba /rename y bloqueaba el prompt, impidiendo que el comando NATIVO
/rename de Claude Code renombrara la sesion. Ahora el hook guarda el nombre para
FleetView (.rename del goal) y NO bloquea, asi el built-in tambien actua. Elimina
commands/rename.md (competia con el built-in y lo tapaba).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- goal_autogen.sh: genera 3 emojis representativos del objetivo (haiku) junto al
goal+DoD, guardados en goals/<id>.json.
- goal_tracker.sh: comando meta /rename (y rename:) para nombrar la terminal;
se guarda en goals/<id>.json .rename.
- commands/rename.md: slash command /rename.
- statusline.sh: persiste el % de contexto por sesion en runtime/<id>.json para
que FleetView lo muestre.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Simplifica el modelo segun feedback:
- El OBJETIVO (target) es el identificativo de la terminal: se genera una vez y
NUNCA cambia automaticamente. goal_refine deja de tocarlo.
- goal_refine ahora ajusta SOLO el DoD para mantenerlo coherente con los prompts.
- Se elimina la deteccion de cambio de tarea y el icono de alerta ⚠️ (campo alert
ya no se escribe ni se lee; queda inocuo en JSONs antiguos).
- Se elimina el comando 'recalcular' y goal_refine.sh modo force.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Los comandos del usuario objetivo:/dod:/recalcular/pausa ahora bloquean el prompt
en UserPromptSubmit con {"decision":"block","reason":...}: el hook ejecuta su
efecto, el usuario ve una confirmacion breve, y el prompt NO llega al modelo — el
agente no genera respuesta y sigue idle con su tarea. Antes estos comandos se
procesaban como un turno normal e interrumpian al agente. Los prompts normales se
siguen pasando al modelo (texto plano como contexto) y acumulan/refían el objetivo.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El objetivo y el DoD dejan de quedarse congelados en el primer prompt:
- goal_tracker acumula cada prompt sustantivo del usuario en .prompts y lanza
goal_refine.sh (background, haiku) para mantener objetivo y DoD coherentes con
TODO lo pedido (action refine), o dejarlos igual (action same).
- goal_refine marca alert=true (action switch) cuando el ultimo prompt introduce
una tarea completamente distinta del objetivo: senal de que la terminal mezcla
tareas (principio: una terminal = una tarea). No cambia el objetivo, solo avisa.
- statusline muestra ⚠️ en rojo antes del objetivo cuando alert=true.
- Comando 'recalcular' (recalcula/replantea): fuerza regenerar objetivo+DoD desde
los prompts y limpia la alerta (para cuando el cambio de tarea es intencional).
- goal_autogen inicializa .prompts con el primer prompt.
Coste: 1 haiku/prompt sustantivo en background (ademas del haiku de reposo del
Stop), solicitado para mantener la coherencia. No bloquea el turno.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El Stop worker recibe ahora el DoD de la tarea y lo usa como criterio para
distinguir hecho de pendiente_revision/en_pausa: marca 'hecho' unicamente si el
resultado descrito cumple el DoD punto por punto y esta verificado. Si el DoD no
se cumple del todo, cae en pendiente_revision (resultado para revisar) o en_pausa
(avance parcial). Si no hay DoD definido, mantiene el criterio anterior sobre el
objetivo. Hace el estado 'hecho' mucho mas preciso.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cuando una terminal no tiene objetivo y el usuario envia su primer prompt
sustantivo (>=12 chars), goal_tracker lanza goal_autogen.sh en background (no
bloquea el turno). El script infiere con ask_llm (haiku) un objetivo corto y un
DoD corto a partir del prompt y crea el goal JSON con phase=planificando. Los
prompts triviales (saludos, ok) no generan nada (el modelo responde {}). El
statusline lo muestra en el siguiente refresco. El usuario puede sobrescribir a
mano con objetivo:/dod: o borrar con objetivo: clear.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Los dos estados activos que no tenian disparador ahora se asignan de forma
determinista en el PostToolUse:
- planificando: al usar TodoWrite / ExitPlanMode / EnterPlanMode.
- puliendo: al editar (Edit/Write/MultiEdit/NotebookEdit) cuando la fase actual
ya era testeando o puliendo, es decir retoques finales sobre algo ya probado.
Una edicion normal (sin testeo previo) sigue siendo haciendo; volver a testear
saca de puliendo.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Nuevo estado de reposo 'preguntando' (❓ esperando respuesta), distinto de
pendiente_revision: lo usa el Stop worker cuando la respuesta termina con
preguntas concretas al usuario en vez de dejar un resultado para revisar.
- DoD corto opcional junto al objetivo: se fija con "dod: <texto>" ("dod: clear"
lo borra) y se muestra atenuado con 🏁 tras el objetivo. Re-fijar el objetivo
preserva el DoD existente.
- Comando "pausa" (prompt) marca la fase en en_pausa. Es la alternativa manual a
Ctrl-C: Claude Code no dispara ningun hook al interrumpir un turno (el Stop
hook solo corre en finalizacion normal; feature pedido, sin implementar), asi
que no es posible detectar la interrupcion automaticamente.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El statusline solo se re-ejecutaba al cambiar los mensajes, asi que el estado de
reposo que el Stop hook escribe ~2s despues (en background) no se reflejaba hasta
que el usuario interactuaba. Se anade refreshInterval=2 para que el harness re-
ejecute el statusline cada 2s tambien estando idle, mostrando el valor final sin
necesidad de escribir y sin bloquear el turno.
Para que el refresco continuo no sea caro en repos grandes, el bloque git se
cachea por directorio con TTL de 6s (el estado git no cambia estando parado); los
ticks idle reusan el cache (~0.1s vs ~0.33s recomputando). El goal file (la fase)
se lee siempre fresco.
Se revierte el intento previo de Stop sincrono (bloqueaba ~2s el control).
Nota: Claude Code no soporta acotar el refresco a una ventana (p.ej. 10s y
parar); refreshInterval es continuo.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El Stop hook ahora pone en_pausa de forma sincrona si la fase estaba en un
estado activo (investigando/haciendo/testeando/puliendo), antes de lanzar el
worker haiku en background. Evita que el statusline se quede mostrando el ultimo
estado activo (p.ej. 'investigando' por un 'git log' final) durante los ~2s que
tarda la clasificacion de reposo. El provisional no toca el historial; el worker
escribe el reposo final (hecho/pendiente_revision/bloqueado/en_pausa) + history.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Separa el ciclo de trabajo en dos grupos con la fuente adecuada para cada uno:
- ACTIVO (mientras se trabaja): lo marca el hook PostToolUse de forma
determinista, sin LLM, segun la herramienta usada — Read/Grep/Glob ->
investigando; Edit/Write -> haciendo; Bash con tests -> testeando; Bash de
lectura (ls/cat/git status...) -> investigando; mcp fn_search/show/... ->
investigando. Refleja en tiempo real lo que hace el asistente.
- REPOSO (al parar y ceder el control): lo resuelve el Stop hook con ask_llm
(haiku) -> hecho / pendiente_revision / bloqueado / en_pausa. Al parar nunca
queda en un estado activo.
Cambios:
- goal_phase_active.sh: nuevo hook PostToolUse (mapa herramienta -> fase activa).
- goal_phase_worker.sh: ahora solo produce estados de reposo; se elimina el modo
prompt. Mantiene el gate (resuelve reposo solo si hubo trabajo o se venia de
activo) y el historial.
- goal_tracker.sh: deja de lanzar clasificacion LLM en el prompt (redundante);
vuelve a fijar objetivo desde el prompt + informar estado.
- statusline.sh: nuevo estado en_pausa (en pausa); set de fases reordenado.
- settings.json: registra el hook PostToolUse.
Resultado: 1 sola llamada haiku por turno (Stop); el estado activo es gratis y
refleja las acciones reales en vez de la intencion del prompt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- statusline.sh: muestra los ultimos 7 estados previos como emojis atenuados
(DIM) separados por │, entre el objetivo y la fase actual. El historial se
guarda en el goal JSON (campo .history), colapsando estados consecutivos
repetidos, hasta 12 entradas.
- goal_phase_worker.sh: dos modos. 'stop' (tras la respuesta del asistente, con
filtro de trabajo real) y 'prompt' (tras el prompt del usuario, clasifica la
intencion para feedback inmediato). Nuevo veredicto 'sin_cambio' para
preguntas/charla que no implican cambio de actividad; ante la duda, no toca.
Ambos modos mantienen el historial.
- goal_tracker.sh: en cada prompt con objetivo activo lanza el worker en modo
prompt (background) ademas del Stop hook.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cada terminal muestra su objetivo (color estable por session_id) y la fase de
trabajo actual, para distinguir sesiones y saber cuando algo esta hecho.
- statusline.sh: linea 0 con objetivo (izq, color por sesion) + fase (der) con
el separador estandar; 9 fases (investigando, planificando, haciendo,
testeando, puliendo, iterando, pendiente_revision, bloqueado, hecho) con icono,
color y etiqueta. Purga de goal files de sesiones muertas (>7 dias).
- hooks/goal_tracker.sh (UserPromptSubmit): fija el objetivo leyendo el prompt
del usuario ("objetivo: ...", "objetivo: clear" lo borra); si no, informa el
estado actual al modelo.
- hooks/goal_phase_eval.sh (Stop): al terminar el turno lanza el worker en
background, sin bloquear.
- hooks/goal_phase_worker.sh: clasifica la fase con ask_llm (haiku, API directa,
nunca claude -p) usando la peticion del usuario + la ultima respuesta del
asistente. Solo reevalua si el turno tuvo trabajo real (tool_use); en charla
pura no toca la fase ni gasta llamada.
- settings.json: registra los hooks UserPromptSubmit y Stop.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
agent
egutierrez