spawn_fleet_agent pre-crea ~/.claude/goals/<sid>.json con solo
{role, parent_orchestrator} antes del primer prompt. goal_tracker.sh usaba
'el archivo existe' como proxy de 'objetivo definitivo', así que para esos
ejecutores nunca lanzaba goal_autogen: el goal quedaba vacío para siempre y el
statusline (LINE0) y FleetView mostraban '(sin objetivo)'.
Fix: 'definitivo' ahora exige .goal NO vacío (no solo que el archivo exista).
Cuando el archivo existe pero sin goal (ejecutor spawneado), se fija un goal
provisional PRESERVANDO role/parent_orchestrator y se lanza autogen, que lo pisa
con el definitivo. No regresiona el caso definitivo ni el primer-prompt sin
archivo (verificado con 3 casos).
El hook goal_refine.sh regeneraba el campo .dod del goal.json llamando a
ask_llm.py (haiku) en background en CADA UserPromptSubmit de CADA sesion.
Con muchas sesiones de la flota activas esto amplificaba el rate-limit
compartido de la organizacion (una request API por turno por agente).
El .dod movil no lo consume nadie: el parser de la flota
(functions/infra/list_claude_fleet.go, struct goalFile/readGoal) solo lee
goal/phase/emojis/rename/dod_contract/dod_status/role. El criterio que
clasifica la flota (RECLAMA/DICE_TERMINADO/ESTANCADO) es dod_contract +
dod_status, escrito por set_dod_contract.py sin LLM y consumido por
ClassifyFleetTermination. Ese sistema queda intacto.
Cambios:
- goal_refine.sh: convertido en no-op (exit 0) documentado.
- goal_tracker.sh: retirado el disparo de goal_refine + la acumulacion de
.prompts que solo lo alimentaba; mensaje GOAL-TRACKER actualizado.
El objetivo+DoD inicial los sigue generando goal_autogen.sh una sola vez
por terminal (junto con goal/emojis, que si se usan). El usuario ajusta el
DoD a mano con 'dod: ...'. Resultado: cero llamadas LLM por prompt.
El rename de la terminal en FleetView se hace ahora con alt+r dentro de
la TUI, que escribe el campo .rename del goal directamente. Se elimina el
slash command rename.md y la nota del hook lo documenta, dejando libre el
built-in /rename de Claude Code para renombrar la sesión.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- /rename escribe el nombre en FleetView (.rename del goal). NO renombra el titulo
de la sesion de Claude Code: el built-in /rename usa estado interno y no re-lee
el transcript, asi que un evento ai-title no cambia el prompt bar (comprobado).
- objetivo provisional: el primer prompt fija un goal placeholder hasta que haiku
genera el definitivo, para que el statusline no quede vacio.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
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>
- 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>
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>
integrador
egutierrez