ultrareview: remote runner devuelve [] pese a candidatos intermedios cuando el hook SessionStart falla; solicitud de guardas para diffs sobredimensionados y error handling

Contexto

Lancé /ultrareview sobre main con un diff grande (384 archivos, +11.495 / -17.111). La UI intermedia mostró progreso real (13 candidatos: 1 confirmado, 1 refutado, el resto en verificación), pero la task-notification final llegó con findings: []. La vista previa mostró además este error del entorno:

bash: /root/.claude/hooks/session-start-autoresearch.sh: No such file or directory

Entorno local

• Fedora Silverblue. HOME=/var/home/<usuario> (no /home/...).
• Hook SessionStart configurado con ~/.claude/hooks/session-start-autoresearch.sh.
• Ruta real del hook: /var/home/<usuario>/.claude/hooks/session-start-autoresearch.sh.

Hipótesis (aportadas por mí como usuario, no confirmadas por Anthropic)

Las siguientes son conjeturas propias basadas en los síntomas observados; puede haber causas adicionales o distintas que solo el equipo de Claude Code pueda verificar con los logs del runner:

1. HOME distinto a /root: el runner remoto parece ejecutar como root con HOME=/root, por lo que ~ resuelve a /root/.claude/, que no existe. Mi config vive en /var/home/<usuario>/.claude/.
2. Fallo en cascada del hook: sospecho que el error del SessionStart pudo abortar o envenenar el pipeline, perdiendo findings intermedios ya confirmados en la UI.
3. Scope excedido: con >10k líneas de diff es plausible que además se superara el presupuesto interno del runner (tokens/tiempo), aunque esto es especulación por mi parte.

Expectativa

• Que el runner respete el HOME real del usuario, o que los hooks con rutas no existentes no aborten la verificación.
• Que los findings intermedios confirmados no se descarten al cerrar el run.
• Transparencia sobre el motivo del [] final (cancelación, timeout, fallo silencioso, etc.).

Peticiones

1. Code review del propio ultrareview remoto. Revisar el path de ejecución para entender por qué un hook fallido convierte candidatos confirmados en findings: [], y documentar el contrato de hooks en entorno remoto (¿qué HOME?, ¿qué usuario?, ¿qué hacer si un hook no existe?).
2. Guarda de diffs sobredimensionados. Un proceso tan costoso en tokens/computación no debería lanzarse a ciegas. Propuestas:

• Pre-chequeo del tamaño del diff y advertencia en la UI antes de consumir cuota (\"este diff excede X; ¿trocear por directorio?\").
• Modo automático split-by-directory o split-by-commit cuando se supera un umbral.
• Estimación de coste (tokens/tiempo) previa al arranque.

1. Error handling real en procesos caros. Cuando el runner falla a mitad de camino:

• Devolver un estado explícito (failed, cancelled, timeout) en vez de un completed con findings: [] que induce a pensar que no hay hallazgos.
• Persistir los findings parciales ya confirmados en lugar de descartarlos.
• Exponer logs/stderr del runner al usuario para diagnóstico (hoy solo vi el error del hook por la UI intermedia).
• No consumir la cuota (\"Free ultrareview 1 of 3\") si el run termina en error de entorno ajeno al diff.

Reproducir

• Fedora Silverblue (HOME bajo /var/home/…), hook SessionStart con ruta ~, lanzar /ultrareview sobre un diff grande (>300 archivos).