Ops

en AMID BRAIN, en historical si selecciono 30 dias de data, no me carga ni arroja resultado Aun asi esperando un largo rato

Esto ya está mapeado, no es un bug nuevo. El endpoint que arma el historial (/api/brain/forward/history, en src/avart_research_engine/brain_forward_history.py) recalcula cohorte y probability board EN VIVO por cada día del rango, sin cache — a diferencia del validation report que sí tiene cache justamente porque este cálculo "toma minutos" (brain_forward.py:576-580). Por eso en apps/journal/app.js:71-78 la ventana de 30 días está marcada como "lento, ~1,5 min": ronda los ~82s (22s fijos + 2s/día) contra un proxy que corta a los 100s. Ya quedó registrado en el backlog el 6-7/8 (tasks/backlog.md:22-25, tasks/lessons.md:89-100) que ese margen es justo, y que además cada intento que abandonás sin esperar deja un hilo del servidor calculando huérfano, lo que hace más lenta la siguiente corrida (incluido un reintento tuyo). Traducción práctica: si el dataset creció desde que se midió ese ~1,5 min, hoy 30 días puede estar pasando el corte de 100s y por eso no carga nunca, aunque esperes. Mientras tanto, 7 o 14 días están cómodos debajo del límite y deberían andar bien. La solución de fondo (cache incremental por día, para no recalcular lo que ya es histórico e inmutable) está anotada en el backlog pero no implementada todavía — eso queda para Facu y Valen decidir prioridad, yo no toco el motor.

¿Cómo se calcula ON PR y el ranking de participación entre los 4 activos? ¿Cuál es el denominador?

ON PR = participation_ratio = volumen crudo de la sesion / promedio de volumen 30 dias del mismo activo, calculado por separado para cada uno de los 4 (src/avart_research_engine/intermarket.py:83-91). "ON" es la sesion ASIA/LONDON (pre-NY), "NY" es NY_NYSE. El denominador NO es compartido entre activos: cada NQ/ES/CL/GC tiene su propio average_volume_30, asi que el PR mide la actividad de HOY vs el propio historial del activo, no participacion relativa contra los otros 3. El ranking (ON Rank / NY Rank) es aparte: agrupa las 4 filas por (fecha, sesion) y ordena descendente por participation_ratio -- el que tiene el PR mas alto ese dia en esa sesion es rank 1 (intermarket.py:26-36, empate se resuelve por orden fijo NQ>ES>CL>GC). Tambien hay "Dominance" = tu ratio / promedio de los ratios de los 4 ese dia -- ese si es relativo entre activos, el PR no.

¿Dónde se calcula ON Inventory?

ON Inventory se calcula en src/avart_research_engine/storage.py:3517 (_derive_on_inventory_from_on_session_record), que llama a la función genérica _derive_inventory_from_session_record en la línea 3521 con el prefijo "on". Fórmula (línea 3535): ((close - open) / (high - low)) * 100, usando el open/high/low/close de la sesión ON (overnight). Es un porcentaje de rango: mide dónde cerró el precio dentro del rango de la sesión relativo a donde abrió, no un promedio de volumen. Guardas antes de calcular: si falta open/high/low/close, o si alguno es <= 0, o si el rango (high-low) es cero, o si open/close caen fuera del rango high-low, devuelve vacío en vez de un número falso (líneas 3526-3534). El resultado pasa por normalize_eod_inventory_percent (validation.py:343) antes de guardarse. El valor se persiste en la columna on_inventory (storage.py:98) y de ahí alimenta el contexto D0 del Brain como una de las 11 variables promovidas (ver docs/ESTADO_PRODUCCION.md). Prueba de conexión OK: este es el primer ciclo GET→análisis→POST corriendo end-to-end. — max