theconfluence.show

Datos del sistema Confluence Show (HRC): varios exchanges (Binance, y desde 2026 también KuCoin, Hyperliquid y el FX/CFD de Ultima por MetaTrader), cada uno con sus mercados, con ~50 familias de indicadores computadas sobre velas, trades, libro de órdenes, funding y OI. Cómo trabajar aquí: - Empieza por `list_markets` y `data_coverage`. `list_markets` trae el catálogo de EXCHANGES (`exchanges`: id, monedas, intervalos grabados, qué familias NO puede servir cada uno, si es perp o CFD) y los mercados de Binance con su TIER. Toda herramienta de mercado acepta `exchange` (vacío = Binance; `kucoin`, `hyperliquid`, `ultima`…) y la moneda es la misma en todos (`BTC`, `EURUSD`). El TIER de un activo de Binance decide qué existe: tier 1 = todas las capas; tier 2 = velas + trades (CVD, delta, footprint, perfiles) sin libro profundo; tier 3 = sólo velas + funding/OI. En los demás exchanges manda `missing_families` de su entrada en `exchanges`. Una familia ausente no es "señal en cero", es dato que no se graba. - `market_snapshot` da el dossier que el propio coach usa (precio, régimen, zonas con score/grade, setups, funding/OI, reacción en zona). Es el punto de partida barato para cualquier pregunta sobre el estado de un mercado. - `bundle_fields` da acceso selectivo a cualquiera de las ~117 capas del bundle. - `signal_events` da los eventos que se van disparando, cada uno con su `known_at` (el instante en que el sistema PUDO saberlo). Para validar una hipótesis, filtra siempre por `known_at` y mide hacia delante desde ahí: usar un evento antes de su `known_at` es mirar al futuro. - `history` y `sql` leen el archivo Parquet (días UTC cerrados) sin tocar la base de datos en vivo. Ahí es donde se miden hipótesis sobre histórico. Toda vista lleva la columna `exchange` (`binance`, `kucoin`…) y `history` acepta `exchange`; `data_coverage` dice desde qué día hay archivo de cada exchange (los nuevos empiezan el día que se encendieron, no antes). - `stats` da las tablas ya medidas por el sistema: win-rate con posterior bayesiano por tipo de estructura, por día/hora, y por clase de zona. - Los recursos `hrc://about` (qué es este servidor y cómo autenticarse) y `hrc://markets` (mercados servidos, en vivo) se leen SIN token, igual que este catálogo. Coste: la máquina de producción va justa (2 vCPU). Sin `start`, `end` ni `span_ms`, las herramientas de bundle piden LA MISMA ventana que el chart y el prewarm (1m: 48 h, 5m: 72 h, 15m y mayores: 7 días) — con esa ventana un activo de la lista caliente sirve su bundle desde caché y uno de fuera sale de la estantería (precalculado por cobertura), aunque pedirlo lo pone a rehacerse en el prewarm, así que hay que pedirlo con `allow_cold=true`. Los mercados de los DEMÁS exchanges salen siempre de la estantería (ninguno está en la lista caliente) y no exigen `allow_cold`: su edad viene en `bundle_age_ms`. CUALQUIER otra ventana (un `span_ms`, un `end` en el pasado) es una clave que nadie calienta: se computa en frío, tarda minutos, le quita CPU al directo y puede pasarse del timeout — y las capas que dependen de la ventana (AMT, perfiles, VWAP anclado) pueden dar valores distintos a los del chart. El `meta` de cada respuesta lo dice: `hot_window` (true = la ventana del chart), `bundle_age_ms` (cuánto hace que se computó lo servido; 0 = la ventana exacta de esta vela) y `bundle_skew_ms` (cuánto más nueva era la ventana pedida). Las respuestas grandes vienen recortadas con `truncated: true` — acota en vez de pedir más. Esta superficie es de LECTURA. No escribe, no opera, no envía órdenes.