SignalDashPro - Handoff (Estado Operativo)#

Este documento existe para que, si cambias de maquina o abres otra sesion de ChatGPT, puedas retomar el estado del proyecto sin perder contexto.

No contiene secretos. Las credenciales y llaves viven en archivos .env gitignored (ver env/.env.example).

Estado vigente (2026-04-10) - vNext documental activo#

Deploys recientes en CT110 (backend/frontend/docs) ejecutados con verificación autenticada MATVARD en verde.
Runtime MATVARD alineado a SOLUSDT para validación operativa (playbook SOLUSDC mantiene unidad canónica + runtime_symbol).
Ajuste aplicado a estrategia autopilot:matvard_advanced_shadow (perfil strict menos restrictivo) para reducir dominancia de no_signal en shadow.
Endpoint /ops/strategy/performance corregido para agregar kpis_matvard desde autopilot:matvard_advanced_shadow.
Frontend mejorado en UX amigable: header/nav global, dashboard, control-tower y matvard con jerarquía visual y accesos rápidos consistentes.
Canon documental vNext consolidado en:
docs/matvard/IMPLEMENTATION_PLAN_VNEXT_SAM.md
docs/matvard/MATVARD_RUNTIME_CONTRACT.md
docs/matvard/PLAYBOOK_SOLUSDC_REAL.md
docs/TODO.md
Legacy y material histórico consolidado en:
docs/archive/2026-04-09_new_day_reset/
docs/matvard/archive/
Deploy y verificación operativa recientes:
smoke autenticado MATVARD disponible en scripts/check_matvard_auth_endpoints.sh
deploy con verificación autenticada integrada en scripts/ct110_deploy_release.sh

Nota: los bloques inferiores se conservan como trazabilidad histórica.

Estado operativo vigente (2026-04-04)#

Release CT110 activo (Frontend/Analytics UX Fixes y Ajuste de Riesgo): 20260404.
Frontend Analitica actualizado: dividida la función "Buscar simbolo activo" en dos acciones explícitas ("Actividad en Símbolo Actual" e "Ir al Símbolo Más Activo") para evitar la confusión de cambios inesperados de activo en pantalla.
Endpoint de Analytics (GET /analytics/overlay-activity) usado de base.
Se recomienda hard refresh (Cmd+Shift+R) para los usuarios.
Backend estrategía PAXG: Ajuste a calibración realista (P75). AUTOPILOT_PAXG_MAX_VOLATILITY_PCT movido de 0.159 a 0.15 y AUTOPILOT_PAXG_MIN_VOL_RATIO de 4.54x a 1.5x para evitar el filtro P99+ subóptimo de rechazo que cortaba demasiado volumen.

Estado operativo anterior (2026-03-29)#

Release CT110 activo: 20260329T173605Z-3480a1fb.
MATVARD canónico: autopilot:paxg_matvard_v1_shadow (deep_profile_live).
Ingesta real de microestructura Binance activa (trade/depth/kline_1m).
Endpoint técnico activo: GET /ops/strategy/matvard/microstructure-health.
Hard-stop MATVARD activo por calidad:
provider_error_rate_24h=0.0%
fallback_rate_24h=0.0%
coverage_pct_24h=92.5373% (umbral requerido: 95%)
resultado: hard_stop=ON (sin promoción live todavía).
Marzo (hasta 2026-03-29): live core 15 trades, win_rate 33.33%, PnL -0.625519 USDT.

Referencia canónica inmediata:

docs/matvard/IMPLEMENTATION_PLAN_VNEXT_SAM.md
docs/matvard/MATVARD_RUNTIME_CONTRACT.md
docs/matvard/PLAYBOOK_SOLUSDC_REAL.md

🗄️ HISTÓRICO DE DATOS EN BD — Política Diaria (2026-03-18)#

Estado: ✅ Completado backfill inicial 1 año PAXGUSDT M15

Datos en PostgreSQL (pgad.perlatec.net):

Timeframe	Total	Desde	Hasta	Estatus
M15	35,040	2025-03-18	2026-03-18	✅ 1 año completo
D1	1,036	2023-05-18	2026-03-18	✅ 3 años
H1	1,877	2025-12-30	2026-03-18	✅ ~3 meses

Política: Todos los datos históricos de cada día deben estar sincronizados en la BD diariamente.

Cómo mantener actualizado:

Script de sincronización:

cd /path/to/SignalDashPro
set -a && source env/.env.binance && set +a
.venv/bin/python scripts/backfill_paxg_m15_history.py \
    --symbol PAXGUSDT \
    --interval 15m \
    --days 365

Automatización sugerida (cron en CT110):

# Ejecuta cada medianoche UTC para traer datos del día anterior
0 0 * * * cd /opt/signaldashpro/current && \
          set -a && source env/.env.binance && set +a && \
          .venv/bin/python scripts/backfill_paxg_m15_history.py \
          --symbol PAXGUSDT --interval 15m --days 30 >> /var/log/backfill.log 2>&1

Lo que hace el script:
Descarga M15 desde Binance API (últimos --days especificados).
Inserti datos nuevos en tabla candles (PAXGUSDT, M15).
Es idempotente: re-ejecutar no duplica (upsert por constraint único (symbol, timeframe, timestamp)).
Tarda ~60-90s para 365 días (36 ventanas × 1000 velas/ventana).

Scripts relacionados:

scripts/backfill_paxg_m15_history.py — Backfill M15 desde Binance (puede usarse para cualquier símbolo/intervalo).
scripts/db_health_check.py — Verifica salud de BD y conteos de candles.

Ventaja operativa:

Backtests locales en BD (sin depender de Binance API en tiempo real durante backtests).
Consistencia: mismos datos locales vs. en laboratorio → backtests verificables.

Estado actual (2026-03-17)#

Filtros de volatilidad/volumen deployados (2026-03-17 22:45 UTC):

✅ CODE CHANGES:

backend/services/strategies/paxg_mean_reversion.py:
Agregada función _historical_volatility() para cálculo de Vol% (30 períodos)
Agregadas condiciones de filtro en generate_signal() para BUY/SELL
Diagnostics mejorados en detalles de señal (muestran por qué se skipean entries)
Parámetros nuevos: max_volatility_pct, min_vol_ratio
backend/routers/settings.py:
Agregados AUTOPILOT_PAXG_MAX_VOLATILITY_PCT y AUTOPILOT_PAXG_MIN_VOL_RATIO a AUTOPILOT_KEYS
Valores por defecto: 0.159% y 4.54x (basados en root-cause analysis)

✅ RUNTIME DEPLOYMENT:

AUTOPILOT_PAXG_MAX_VOLATILITY_PCT = 0.159 (manual mode)
AUTOPILOT_PAXG_MIN_VOL_RATIO = 4.54 (manual mode)
Aplicación confirmada en live API

Validación pre-deploy (90d backtest):

Sin filtros: 31 trades, 35.5% WR, -2.03% PnL ❌
Con filtros: 12 trades, 58.3% WR, +1.67% PnL ✅
Mejora: +22.8pp WR, +3.70pp PnL, +188% Profit Factor
Reportes: storage/reports/PAXG_LOSS_ANALYSIS_2026-03-17.md + PAXG_FILTER_VALIDATION_2026-03-17.json

Parámetros del runtime ahora (2026-03-17):

✅ AUTOPILOT_PAXG_BB_PERIOD = 25 (optimizado, validado)
✅ AUTOPILOT_PAXG_RSI_OVERSOLD = 30 (optimizado, validado)
✅ AUTOPILOT_PAXG_MAX_VOLATILITY_PCT = 0.159 (nuevo filtro, validado)
✅ AUTOPILOT_PAXG_MIN_VOL_RATIO = 4.54 (nuevo filtro, validado)
✅ AUTOPILOT_ALLOW_SELL = true (full trading enabled)
✅ TRADE_MANAGER_ENABLED = true (full trading enabled)

Comportamiento esperado post-deploy:

Mejor calidad de entries (evitar volatilidad alta + requerir volumen)
Win-rate mejorada de 35.5% → 58.3% esperado
Menos trades totales pero más rentables (transformó pérdidas en ganancias)
PnL esperado: De -2.03% → +1.67% con filtros (validado en backtest)

Ajuste operativo anterior aplicado (USDT-only runtime):

✅ AUTOPILOT_SYMBOLS=PAXGUSDT (manual).
✅ AUTOPILOT_ALLOW_SELL=true (NOW - revertido de false).
✅ TRADE_MANAGER_ENABLED=true (NOW - revertido de false).
✅ TRADE_MANAGER_AUTO_RUN=true (NOW - revertido de false).

Verificación en cola (runtime real):

Última actualización: 2026-03-17T22:45Z UTC (filters deployed).
Sistema operativo con parámetros optimizados + filtros validados.

Estado actual (2026-03-15)#

Auditoría General Completada:

✅ Servicios saludables (deploy-backend/frontend/docs + current-db activos).
✅ Binance Demo auth operativa (SMOKE por timer cada 30 min).
✅ Market sync y jobs core activos (execution_queue, market_sync, data_pipeline, goal_monitor).
✅ Autopilot habilitado y activo (AUTO_RUN=true, M15, paxg_mean_reversion, PAXGUSDT).
✅ News 30d con 100% impact scored.
⚠️ Performance 7d negativa: 4 trades cerrados, 0 wins, pnl aprox -1.22458 USDT.
⚠️ Incidencia detectada/corregida: Permission denied en scripts/check_binance_demo_auth.sh (chmod aplicado).

Estrategia ORO (PAXGUSDT) Activada:

Tipo: mean-reversion, M15, 2% notional.
Targeting: pullback a MA14/MA21 con 2x TP y tight risk.
Horario: Mon-Fri 07:00-21:00 UTC.
Estado: ACTIVO en runtime (validado en settings/autopilot).

Próximos Pasos Inmediatos:

Desplegar env actualizado a CT110.
Recrear backend para recargar AUTOPILOT_* envs.
Monitorear /ops/p0/readiness y /ops/strategy/performance (PAXGUSDT debe mostrar entries).
Revisar primeras 24h: gate effectiveness, potential_win_rate, realized PnL.

Actualización operativa (2026-03-15, timeframe process UX):

Nuevo endpoint de lectura para recomendaciones de timeframe PAXG: GET /ops/reports/paxg-timeframe/latest (toma base en storage/reports/paxg_timeframe_walkforward_binance.json).
Shadow Tests ahora muestra un panel resumido y humanizado con:
baseline recomendado,
candidato shadow,
decision rapida promote/watch.
El objetivo es facilitar decision operativa sin leer JSON crudo del reporte.

Sistema Post-Auditoría (2026-03-10)#

Hallazgos Detallados#

Autopilot Deshabilitado (Causa Root)#

Env .env.binance.demo.month tenía AUTOPILOT_SYMBOLS=PAXGUSDT pero faltaban:
AUTOPILOT_ENABLED=true
AUTOPILOT_AUTO_RUN=true
AUTOPILOT_SIGNAL_TIMEFRAME=M15
AUTOPILOT_FAST_MA=14, AUTOPILOT_SLOW_MA=21
Control flags: AUTOPILOT_MIN_VOL_REL, AUTOPILOT_MAX_SPREAD_PCT, etc.
Resultado: 0 señales en 7 días.
Backend logs clean: ningún error, solo inactividad esperada.

Strategy Performance (Antes)#

closed_trades: 0
by_symbol: [] (vacío)
gates_effectiveness.blocked: 80 (PAXGUSDT=76 por "no_risk_policy_available")

Correcciones Aplicadas#

✅ Habilitado AUTOPILOT_ENABLED=true + AUTO_RUN=true.
✅ Configurado M15 timeframe, MA(14,21), allow_sell=true.
✅ Risk: 2% notional, 2x TP, tight spread/volume filters.
✅ Documentación actualizada (README + HANDOFF).

Estrategia ORO (PAXGUSDT) Detalles#

Modo: paxg_mean_reversion (pullback a media móvil).
Conjetura técnica: oro tiende a revertir de extremos locales; MA14/MA21 sirven como atractores.
Sizing: 2% notional (ej. 4546 USDT demo → ~90 USDT por orden).
Riesgo: SL a candle low (M15), TP a 2x distance.
Horario: Mon-Fri 07:00-21:00 UTC (cobertura NY/London).
Filtros: max spread 1%, min rel volume 0.5, allow_sell activo (exit over entry).

Monitoreo Post-Deploy#

# Verificar env cargado (5 min post-recreación)
docker exec current-backend-1 env | grep AUTOPILOT

# Ver primeras señales (esperar cierre M15)
curl http://127.0.0.1:8096/signals/queue?symbol=PAXGUSDT  \
  -H "Authorization: Bearer $TOKEN"

# P0 readiness (frequency_min_signals debe cambiar)
curl http://127.0.0.1:8096/ops/p0/readiness \
  -H "Authorization: Bearer $TOKEN" \
  | jq '.frequency_min_signals.items'

# Performance real time (actualizándose cada orden)
curl "http://127.0.0.1:8096/ops/strategy/performance?days=1" \
  -H "Authorization: Bearer $TOKEN" | jq '.by_symbol'

Actualizaciones recientes:

Consolidacion de cambios en git + nube:
commit/push master: 2b44f5b3.
alcance: OpenAI runtime settings cifrado, fallback LLM macro/news, hardening deploy CT110, snapshot runtime settings.
Deploy CT110 reproducible desde HEAD:
release activo: /opt/signaldashpro/releases/20260304T100941Z-2b44f5b3.
symlink actual: /opt/signaldashpro/current -> .../20260304T100941Z-2b44f5b3.
contenedores recreados: deploy-backend-1, deploy-frontend-1, deploy-docs-1.
Auditoria post-deploy:
backend local CT110: http://127.0.0.1:8096/status => 200.
smoke auth en CT110: storage/logs/ops/web-auth-smoke-20260304T102113Z.log => checks frontend_login/api_status/api_auth_login/api_auth_me/... en 200.
endpoint OpenAI runtime validado con auth bearer:
- POST /auth/login => 200
- GET /settings/ai/openai => 200 (has_api_key=true, key_source=runtime, model=gpt-4.1-mini).
Observacion de edge:
desde esta red de administracion, https://api.sdp.perlatec.net/status devolvio 502 (OpenResty) durante la verificacion externa, mientras CT110 interno estuvo sano.
conclusion: degradacion probable en capa proxy/edge externa (no en backend CT110).
OpenAI runtime monitoring integrado:
smoke periodico nuevo:
- script: scripts/run_openai_runtime_smoke.py
- wrapper CT110: deploy/ops/openai_runtime_smoke.sh
- systemd: deploy/systemd/signaldashpro-openai-runtime-smoke.{service,timer}
endpoint backend:
- GET /ops/openai-runtime-smoke/latest
GET /ops/p0/readiness ahora incluye:
- operation_7d.openai_runtime_smoke + breach openai_runtime_smoke_degraded cuando aplica.
notify_external_alerts.py ahora evalua runtime OpenAI:
- --openai-runtime-alerts-enabled
- --openai-runtime-max-age-minutes
- --openai-runtime-require-runtime-key
UI /ops incluye tarjeta OpenAI Runtime (Auth/API) para estado rapido.
Extension aplicada (misma linea de trabajo):
Dashboard integra tarjeta OpenAI Runtime (Auth/API) para observabilidad del cockpit principal.
notify_external_alerts.py incorpora autocase de OpenAI runtime por repeticion:
- nuevos flags/env ALERT_OPENAI_RUNTIME_AUTO_CASE_ENABLED|MIN_REPEATS|OWNER|PRIORITY|DUE_HOURS.
- persistencia de racha/firma en alert_state.json + creacion de CaseReview deduplicado por firma.
GET /ops/data/freshness agrega macro_events.primary_sla_24h (F1 SLA de feed macro primario).
deploy/ops/alerts.sh forwardea nuevas flags OpenAI runtime auto-case.
validacion local: pytest focalizado 17 passed, npm --prefix frontend run build OK.
ajuste adicional de señal de mezcla LLM:
- macro_llm_pct solo puede brechar cuando macro_primary_expected=true.
- en modo MACRO_PROVIDER=openai (fallback controlado), se evita falso warn por dependencia macro 100% LLM.
- cambio propagado a:
- GET /ops/data/freshness
- GET /ops/data/freshness/history
- backend/services/ops_automation.py (daily brief + auto-case LLM mix)
punto 2 resuelto de forma estructurada:
- endpoint nuevo GET /ops/strategy/m15-optimizer.
- usa datos reales de gates opportunities para cuantificar:
- no_signal y no_trade_signal_contradiction (evaluado + potential_win_rate).
- entrega:
- suggestions (ajustes concretos de params runtime),
- shadow_templates para pruebas A/B en M15 sin tocar producción.
- Dashboard muestra resumen en card Rendimiento y Oportunidades (M15 Optimizer).
UI /control-tower: se corrigió la confusión de zona horaria: en tablas rotuladas como UTC se muestra UTC real, y en Gate se muestra UTC + Local (para que sea evidente la diferencia con la hora del navegador).

Actualizacion (2026-02-21):

LLM adviser operativo en shadow con resumen 24h en /ops y /control-tower.
Enforcement controlado activo en autopilot:
AI_LLM_ADVISER_ENFORCEMENT_MODE=reduce_size_only
AI_LLM_ADVISER_REDUCE_SIZE_MULT=0.5
aplica solo a entradas BUY y nunca bloquea salidas SELL.
UX/UI mejorada para operacion:
paneles con legibilidad movil en /control-tower y /ops
filtros de timeline persistentes.

Actualizacion (2026-02-26):

Login web estabilizado:
se corrigieron problemas de foco/click/input en /login (aislamiento visual de la pagina y estilos explicitos).
/auth/login y /auth/me usan timeout/retry en frontend para fallos transitorios de proxy/API.
el frontend ya no invalida sesion por errores 5xx/red al bootstrap (/auth/me), solo por 401/403.
Monitoreo sintetico de acceso web:
scripts/notify_external_alerts.py incluye alerta web_access (frontend /login, API /status, CORS OPTIONS /auth/login).
UI muestra tarjeta Web Access (Login/API) en /dashboard y /ops.
Fix de falso Degraded por hairpin NAT: /ops/web-access/check hace fallback interno (frontend:3000, 127.0.0.1:8096) cuando los fetch publicos fallan desde el contenedor.
Helper de deploy CT110 (scripts/ct110_deploy_release.sh) endurecido:
fases largas build/up + health y verify endpoints corren por SSH no interactivo (menos cuelgues de TTY).
soporta perfiles --verify-profile=fast|prod y archivos deploy/verify.endpoints*.
ahora genera logs de auditoria por corrida:
- log_file=/tmp/ct110_deploy_<ts>.log
- phase_log=/tmp/ct110_deploy_phase_<ts>-<sha>.log (start/ok/fail por fase).
validado en corridas reales hasta [6/6] Done.
Workbench de analisis (continuidad):
Cohort Explorer con compare A/B nativo backend (POST /analytics/cohorts/compare) + breakdowns (symbol/source/status/session/reason) y exports JSON/CSV.
CaseReviews persistidos con findings/actions y triage operativo (overdue/high-open, owner quick actions).
Analisis guarda snapshots de compare A/B (localStorage, tags, busqueda, export).
CaseReview ahora puede guardar artifacts de compare (case_review_artifacts, MVP backend + UI en Analisis).

Nota operativa (DB):

El modelo case_review_artifacts requiere tabla nueva en la base de datos para funcionar plenamente.
Si en CT110 no existe aun, los endpoints /analytics/case-reviews/{id}/artifacts* devolveran error SQL hasta aplicar migracion/manual CREATE TABLE.
Antes de usar artifacts en produccion, verificar existencia de tabla en Postgres CT107.

Runbook rapido (CaseReview Artifacts + deploy smoke)#

Deploy backend+frontend con helper:
scripts/ct110_deploy_release.sh --health-timeout-seconds=180 --verify-profile=prod backend frontend
Validar release y salud:
readlink -f /opt/signaldashpro/current
curl -sS http://127.0.0.1:8096/status
Smoke funcional en UI (/analytics):
seleccionar trade A/B en Cohort Explorer
Guardar compare en CR
verificar listado Artifacts cohort_compare en CR#...
probar exp, edit, x
Smoke CaseReviews (/case-reviews):
quick actions (in_progress, done)
quick owner (claim, clear) con owner rapido
presets de triage (Guardar preset, aplicar, borrar)

Actualizacion (2026-02-27):

Deploy validado en CT110 con commit e3d8048:
release: /opt/signaldashpro/releases/20260227T092032Z-e3d8048
helper: [6/6] Done
verify endpoints (fast): /status=200, /ops/queue/health=401, /ops/anomalies/summary=401.
logs:
- /tmp/ct110_deploy_20260227T092032Z.log
- /tmp/ct110_deploy_phase_20260227T092032Z-e3d8048.log
Auth middleware endurecido (backend/auth.py):
token invalido/expirado ya responde 401 limpio ({"detail":"token_invalid|token_expired"}) sin traceback en logs.
Workbench UX aplicado y desplegado:
Analisis: snapshots cohort con pin/favorite, orden, filtro por tag, quick-link go, export CSV enriquecido.
CaseReviews: artifacts con orden, chips tag:* y quick-link go a Analisis.
Dashboard/Ops: presets owner triage (guardar/aplicar/borrar).
Limpieza de espacio ejecutada en CT110:
docker image prune -f + docker builder prune -f
root pasó de 77% a 51%.

Actualizacion (2026-03-01):

Deploy CT110 backend+frontend exitoso con release:
/opt/signaldashpro/releases/20260301T142512Z-0d6ce98
helper: scripts/ct110_deploy_retry.sh --max-attempts=4 --initial-backoff-seconds=20 --verify-profile=prod backend frontend
resultado: attempt 1/4 OK, [6/6] Done.
verificacion endpoints:
- /status=200
- /analytics/case-reviews=401
- /analytics/case-reviews/actions=401
- /analytics/case-reviews/actions/summary=401
- /ops/queue/health=401
- /ops/anomalies/summary=401
- /ops/autopilot/f2-tuning=401
logs:
- /tmp/ct110_deploy_20260301T142512Z.log
- /tmp/ct110_deploy_phase_20260301T142512Z-0d6ce98.log
Runbook de deploy actualizado:
usar scripts/ct110_deploy_retry.sh por defecto cuando haya resets SSH intermitentes.
Ops productivo actualizado:
endpoint nuevo GET /ops/strategy/performance (KPIs + breakdown por symbol/source/close_reason).
endpoint nuevo GET /ops/strategy/performance/delta (delta 24h vs 24h previa).
seccion nueva en UI /ops: Rendimiento de estrategia.
endpoint nuevo GET /ops/trace/trade/{trade_id} para diagnostico puntual end-to-end.
endpoint nuevo GET /ops/traceability/coverage para KPI de trazabilidad (decision -> queue -> execution -> live_trade).
traceability/coverage ahora incluye breakdowns by_symbol/by_source/by_session.
endpoint nuevo GET /ops/traceability/degradation para detectar degradacion por ventanas consecutivas.
/ops agrega seccion Traceability Coverage con missing_samples y boton cargar traza (drill-down directo a /ops/trace/trade/{id}).
/ops agrega tarjeta/tabla de Traceability Degradation (7x24h) para semaforo operativo semanal.
ops_automation.write_daily_brief agrega auto-case opcional por degradacion:
- OPS_TRACEABILITY_AUTO_CASE_ENABLED=true habilita crear CaseReview.
- OPS_TRACEABILITY_AUTO_CASE_MIN_CONSECUTIVE ajusta minimo de consecutivos.
- dedupe por caso abierto con label auto-traceability-degradation.
/ops agrega seccion Traceability Auto-Cases (7d) con links directos a CaseReviews filtrado y CR puntual.
/ops agrega claim owner rapido en Traceability Auto-Cases: toma owner quick/filter y lo aplica a acciones abiertas del CR.
/ops extiende auto-cases con triage rapido:
- claim aplicado solo a acciones open.
- accion claim + in_progress en un clic.
- feedback por fila (saving/ok/error) para confirmar patch operativo.
/ops agrega ownership cockpit en auto-cases:
- confirmacion global con link directo a CaseReview tras claim.
- toggle solo sin owner (filtra casos con acciones open sin owner).
- resumen por fila open/sin owner + refrescar owner.
- persistencia de filtro en URL/localStorage:
query param ac_unowned=1

Actualizacion (2026-03-03):

Deploy CT110 backend+frontend+docs exitoso:
release: /opt/signaldashpro/releases/20260303T195043Z-e8279c69
helper: scripts/ct110_deploy_retry.sh --max-attempts=4 --initial-backoff-seconds=20 --verify-profile=prod backend frontend docs
resultado: attempt 1/4 OK, [6/6] Done.
verificacion endpoints:
- /status=200
- /analytics/case-reviews=401
- /analytics/case-reviews/actions=401
- /analytics/case-reviews/actions/summary=401
- /ops/queue/health=401
- /ops/anomalies/summary=401
- /ops/autopilot/f2-tuning=401
logs:
- /tmp/ct110_deploy_20260303T195043Z.log
- /tmp/ct110_deploy_phase_20260303T195043Z-e8279c69.log
redeploy con bloque historial+auto-case+caps finos:
- release: /opt/signaldashpro/releases/20260303T203420Z-e8279c69
- logs:
- /tmp/ct110_deploy_20260303T203420Z.log
- /tmp/ct110_deploy_phase_20260303T203420Z-e8279c69.log
Observabilidad de dependencia LLM en Ops completada:
GET /ops/data/freshness agrega source_mix_24h para macro_events y market_news (total, llm_count, primary_count, llm_pct).
respuesta incluye llm_fallback_mix (status + breaches) cuando la dependencia LLM excede umbrales.
nuevo historial GET /ops/data/freshness/history (hours, bucket_minutes) para ver tendencia/buckets de % LLM.
nuevos umbrales por env:
- OPS_DATA_FRESHNESS_LLM_MIX_MIN_SAMPLE=5
- OPS_DATA_FRESHNESS_MAX_MACRO_LLM_PCT=60
- OPS_DATA_FRESHNESS_MAX_NEWS_LLM_PCT=60
- query param llm_mix_min_sample (default 5) para evitar ruido de muestra baja.
Budget diario LLM para fallback:
macro fallback: MACRO_LLM_DAILY_MAX_EVENTS=120.
macro fallback por currency: MACRO_LLM_DAILY_MAX_EVENTS_PER_CURRENCY=40.
news macro digest: NEWS_MACRO_LLM_DIGEST_DAILY_MAX_ITEMS=120.
news macro digest por symbol: NEWS_MACRO_LLM_DIGEST_DAILY_MAX_ITEMS_PER_SYMBOL=40.
al exceder cap diario, el ingestor omite ese dia y deja warning en logs.
Frontend /ops:
tarjeta Feed Freshness ahora muestra macro_llm% y news_llm% + breaches activas.
Ops Automation (write_daily_brief) agrega bloque LLM Fallback Mix (24h) y auto-case opcional:
OPS_LLM_FALLBACK_MIX_AUTO_CASE_ENABLED
OPS_LLM_FALLBACK_MIX_AUTO_CASE_PRIORITY
OPS_LLM_FALLBACK_MIX_AUTO_CASE_OWNER
OPS_LLM_FALLBACK_MIX_AUTO_CASE_DUE_HOURS
Auditoria local:
backend: python3 -m pytest -q => 147 passed.
frontend: npm run build => OK.

Actualizacion (2026-03-02):

Deploy CT110 backend+frontend exitoso con release:
/opt/signaldashpro/releases/20260302T065957Z-0d6ce98
helper: scripts/ct110_deploy_retry.sh --max-attempts=3 --initial-backoff-seconds=20 --verify-profile=prod backend frontend
resultado: attempt 1/3 OK, [6/6] Done.
logs:
- /tmp/ct110_deploy_20260302T065957Z.log
- /tmp/ct110_deploy_phase_20260302T065957Z-0d6ce98.log
Post-deploy audit (CT110):
servicios backend/frontend/docs en estado Up.
/status OK.
timers activos: signaldashpro-alerts, signaldashpro-daily, signaldashpro-storage-backup, signaldashpro-openai-pricing, signaldashpro-trade-smoke, signaldashpro-weekly-report.
endpoints protegidos (/analytics/*, /ops/*, /jobs/status, /binance/status) responden 401 sin token/sesion, comportamiento esperado con auth endurecido.
Operacion adicional:
Dashboard incluye resumen rapido de bulk history para auto-cases.
nuevo smoke autenticado local scripts/run_web_auth_smoke.py para validar login + auth/me + jobs/ops/analytics con bearer.
Deploy posterior frontend/docs:
release: /opt/signaldashpro/releases/20260302T071304Z-0d6ce98
helper: scripts/ct110_deploy_retry.sh --max-attempts=3 --initial-backoff-seconds=20 --verify-profile=prod frontend docs
logs:
- /tmp/ct110_deploy_20260302T071304Z.log
- /tmp/ct110_deploy_phase_20260302T071304Z-0d6ce98.log
- key ops_auto_cases_only_unowned_v1
- boton copiar enlace vista para compartir estado de auto-cases (section + ac_unowned).
- endpoint agregado GET /ops/traceability/auto-cases/ownership para resumen/alertas ownership por caso.
- acciones bulk en UI: claim visibles y claim+progress visibles.
- export CSV de auto-cases filtrados y columna Ultima accion.
Dashboard ahora muestra metrica de auto-cases (open/sin owner/overdue) y link rapido a /ops?section=traceability-auto-cases&ac_unowned=1.
Ops/Gates ahora permite crear case directo desde top casos bloqueados.
Control Tower -> Timeline agrega toggle Detalle completo para ver resumen completo inline y mejora de contraste en texto de detalle.
Control Tower -> Timeline persistencia de Detalle completo en URL (tl_full) + localStorage/favoritos/json.
Deploy adicional validado:
release: /opt/signaldashpro/releases/20260301T144126Z-0d6ce98
logs:
- /tmp/ct110_deploy_20260301T144126Z.log
- /tmp/ct110_deploy_phase_20260301T144126Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T150456Z-0d6ce98
logs:
- /tmp/ct110_deploy_20260301T150456Z.log
- /tmp/ct110_deploy_phase_20260301T150456Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T152541Z-0d6ce98
logs:
- /tmp/ct110_deploy_20260301T152541Z.log
- /tmp/ct110_deploy_phase_20260301T152541Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T153241Z-0d6ce98 (frontend timeline detalle completo + contraste).
logs:
- /tmp/ct110_deploy_20260301T153241Z.log
- /tmp/ct110_deploy_phase_20260301T153241Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T160213Z-0d6ce98 (backend+frontend; traceability coverage + persistencia tl_full).
logs:
- /tmp/ct110_deploy_20260301T160213Z.log
- /tmp/ct110_deploy_phase_20260301T160213Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T163116Z-0d6ce98 (backend+frontend; traceability by_symbol/by_source/by_session + missing-samples drill-down en Ops).
logs:
- /tmp/ct110_deploy_20260301T163116Z.log
- /tmp/ct110_deploy_phase_20260301T163116Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T164234Z-0d6ce98 (backend+frontend; alerta de degradacion de trazabilidad por ventanas consecutivas + panel en Ops).
logs:
- /tmp/ct110_deploy_20260301T164234Z.log
- /tmp/ct110_deploy_phase_20260301T164234Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T165712Z-0d6ce98 (backend; auto-case opcional en daily brief por degradacion de trazabilidad).
logs:
- /tmp/ct110_deploy_20260301T165712Z.log
- /tmp/ct110_deploy_phase_20260301T165712Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T172822Z-0d6ce98 (frontend; panel de auto-cases de trazabilidad en Ops).
logs:
- /tmp/ct110_deploy_20260301T172822Z.log
- /tmp/ct110_deploy_phase_20260301T172822Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T181921Z-0d6ce98 (frontend; auto-cases claim only-open + claim+in_progress + feedback por fila).
logs:
- /tmp/ct110_deploy_20260301T181921Z.log
- /tmp/ct110_deploy_phase_20260301T181921Z-0d6ce98.log
tests frontend:
- nuevo E2E frontend/e2e/ops-auto-cases.spec.ts para auto-cases (unowned filter + claim flows).
release: /opt/signaldashpro/releases/20260301T182812Z-0d6ce98 (frontend; ownership cockpit en auto-cases).
logs:
- /tmp/ct110_deploy_20260301T182812Z.log
- /tmp/ct110_deploy_phase_20260301T182812Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T190524Z-0d6ce98 (frontend; persistencia ac_unowned en URL/localStorage).
logs:
- /tmp/ct110_deploy_20260301T190524Z.log
- /tmp/ct110_deploy_phase_20260301T190524Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T200804Z-0d6ce98 (frontend; boton copiar enlace vista en auto-cases).
logs:
- /tmp/ct110_deploy_20260301T200804Z.log
- /tmp/ct110_deploy_phase_20260301T200804Z-0d6ce98.log
release: /opt/signaldashpro/releases/20260301T203110Z-0d6ce98 (backend+frontend; ownership cockpit v2 + dashboard metrica auto-cases).
logs:
- /tmp/ct110_deploy_20260301T203110Z.log
- /tmp/ct110_deploy_phase_20260301T203110Z-0d6ce98.log

Actualizacion (2026-03-02, P0 readiness):

Backend:
endpoint nuevo GET /ops/p0/readiness con snapshot consolidado P0.2-P0.5:
- frecuencia minima (AUTOPILOT_SIGNAL_TIMEFRAME + entradas 7d por simbolo),
- noticias TE + cobertura impact_score (30d),
- operacion 7d (market_sync por simbolo, queue_failed_24h, web_auth_smoke),
- momentos efectivos (AUTOPILOT_ALLOW_HOURS_UTC, modo auto, recomendaciones tuner).
Frontend:
Dashboard: tarjeta P0 Readiness (2-5).
Ops: tarjeta y seccion dedicada P0 Readiness (2-5) para drill-down de breaches.
Tests/build locales:
backend/tests/test_ops_p0_readiness.py (nuevo) en verde.
npm run build (frontend) en verde.

Fase activa y riesgos abiertos#

Fase activa (roadmap F0-F6):

F0 completada (base operativa + observabilidad + alertas LLM).
F1 iniciada (macro/intermarket), aun pendiente de cerrar.

Riesgos abiertos prioritarios:

Macro/intermarket incompleto: en CT110 el plan FMP actual no incluye calendario macro (402 en economic-calendar), por eso MACRO_AUTO_RUN=false.
Regimen/no-trade: falta enforcement formal de contradiccion de señales para reducir entradas en contexto invalido.
Degradacion/autopausa: falta activacion de umbrales semanales de drift con modo defensivo automatico.
Feed freshness parcial: mantener alertas de news/alignment sin ruido de macro cuando macro esta deshabilitado.

Referencia de plan:

TODO.md -> "Plan por fases (checklist maestro)"
PROJECT_GUIDE.md -> seccion 7.1

URLs publicas (Reverse proxy)#

Frontend: https://sdp.perlatec.net
API: https://api.sdp.perlatec.net
(Opcional) Docs: https://docs.sdp.perlatec.net o puerto interno :8001 segun NPM

Home/entrada:

/ redirige a /dashboard (Cockpit).

Checks desde cualquier PC:

curl -sS https://api.sdp.perlatec.net/ | head
curl -sS https://api.sdp.perlatec.net/binance/status | head
curl -sS -H 'Origin: https://sdp.perlatec.net' \
  'https://api.sdp.perlatec.net/binance/account?nonzero_only=true' | head

Nota: si el navegador te muestra errores viejos (CORS/500) pero curl responde bien, casi siempre es cache del frontend. Prueba hard refresh (Ctrl+Shift+R) o ventana incognito.

Infra actual (Proxmox / LXC)#

Host Proxmox (PVE): 185.209.230.42 (UI: :8006)
Subred interna CTs: 192.168.100.0/24

Contenedores relevantes:

CT 110 (192.168.100.10): SignalDashPro (Docker Compose)
Frontend: :3000
Backend: :8096
Docs (mkdocs): :8001
CT 107 (192.168.100.7:5432): PostgreSQL (externo al stack)
CT 103 (192.168.100.2): Nginx Proxy Manager (NPM) expone 80/443 al exterior

Detalles operativos y NAT/firewall: operational/proxmox.md.

Tiempo (UTC)#

CT110 y CT107 usan Time zone: UTC (para que timers/logs sean consistentes).
NTP corre en el host Proxmox (servicio chrony). En LXC, systemd-timesyncd se salta por condicion de contenedor.
Nota UI: el frontend siempre renderiza en zona local del navegador; por eso es importante que las pantallas operativas indiquen si un timestamp es UTC o Local.

Dónde esta corriendo el codigo (CT110)#

Código (release activo) en CT110: /opt/signaldashpro/current
current es un symlink a un release inmutable:
/opt/signaldashpro/current -> /opt/signaldashpro/releases/<timestamp>-<sha>
Compose en CT110: /opt/signaldashpro/current/deploy/docker-compose.ct110.yml
En este repo tambien existe: deploy/docker-compose.ct110.yml

Nota de docker compose:

El compose usa env_file: ../env/.env.binance.demo.month para backend.
En CT110 el env vive fuera del repo (gitignored) y se comparte entre releases:
Shared env: /opt/signaldashpro/env/.env.binance.demo.month
Link en release: /opt/signaldashpro/current/env/.env.binance.demo.month -> /opt/signaldashpro/env/.env.binance.demo.month
storage/ tambien se comparte entre releases:
Shared storage: /opt/signaldashpro/storage
Link en release: /opt/signaldashpro/current/storage -> /opt/signaldashpro/storage
Importante: el compose lee variables del archivo .env en el mismo directorio del compose.
En CT110 debe existir: /opt/signaldashpro/current/deploy/.env -> ../.env

Estado Autopilot (CT110) - Baseline actual#

Objetivo: operar intradía Spot Demo con riesgo acotado y trazabilidad.

Configuración runtime validada (2026-03-15):
AUTOPILOT_MODE=paxg_mean_reversion
AUTOPILOT_SIGNAL_TIMEFRAME=M15
AUTOPILOT_AUTO_RUN=true
AUTOPILOT_PROFILE=balanced
AUTOPILOT_SYMBOLS=PAXGUSDT
AUTOPILOT_ALLOW_SELL=false
AUTOPILOT_ORDER_NOTIONAL_PCT=0.02
Ventana de trading Binance (Spot Demo):
BINANCE_TRADE_DAYS=1,2,3,4,5
BINANCE_TRADE_START_HOUR_UTC=7
BINANCE_TRADE_END_HOUR_UTC=21

Deploy rapido en CT110 (sin tocar NPM)#

Notas de acceso:

DNAT 185.209.230.42:2202 -> CT110:22 existe, pero en la práctica no siempre permite login por password (depende de hardening/sshd). Si falla, usa el host Proxmox por :22 y ejecuta pct exec 110 ....
El repo en GitHub puede estar privado: bajar el tar.gz por URL desde CT110 puede dar 404 sin token. El flujo estable es git archive local + scp al host + pct push al CT.

Flujo recomendado (release inmutable via tarball):

En tu PC (con acceso al repo), crear tarball del commit:

cd /Users/dmx83/Repos/SignalDashPro
TS=$(date -u +%Y%m%dT%H%M%SZ)
SHA=$(git rev-parse --short HEAD)
OUT=/tmp/signaldashpro-${TS}-${SHA}.tar.gz
git archive --format=tar.gz -o "$OUT" HEAD

Subirlo al host Proxmox (PVE) y empujarlo al CT110:

# recomendado antes del deploy si CT110 viene justo de espacio
./scripts/ct110_release_gc.sh 6

# al host (PVE)
scp -P 22 "$OUT" root@185.209.230.42:/tmp/

# en el host (PVE)
pct push 110 /tmp/signaldashpro-${TS}-${SHA}.tar.gz /root/src.tgz -perms 0644

En el CT110 (via pct exec), extraer al release, linkear persistencias, activar y reiniciar servicios:

pct exec 110 -- bash -lc "
  set -euo pipefail
  TS=${TS}
  SHA=${SHA}
  REL=/opt/signaldashpro/releases/\${TS}-\${SHA}
  mkdir -p \"\$REL\"
  rm -rf \"\$REL\"/*
  tar -xzf /root/src.tgz -C \"\$REL\"

  # Important: the repo includes a tracked `storage/` dir, so we must remove it
  # before symlinking, otherwise `ln -s` will create `storage/storage -> ...`.
  rm -rf \"\$REL/storage\"
  ln -sfn /opt/signaldashpro/storage \"\$REL/storage\"
  mkdir -p \"\$REL/env\"
  ln -sfn /opt/signaldashpro/env/.env.binance.demo.month \"\$REL/env/.env.binance.demo.month\"

  # compose env wiring (usa el env persistente)
  ln -sfn /opt/signaldashpro/env/.env.compose \"\$REL/.env\"
  mkdir -p \"\$REL/deploy\"
  ln -sfn /opt/signaldashpro/env/.env.compose \"\$REL/deploy/.env\"
  # Nota: docker-compose.* usa `SDP_ENV_FILE` para ubicar el env real del backend.
  # En CT110 mantenerlo en el env persistente:
  #   echo 'SDP_ENV_FILE=/opt/signaldashpro/env/.env.binance.demo.month' >> /opt/signaldashpro/env/.env.compose

  ln -sfn \"\$REL\" /opt/signaldashpro/current

  cd /opt/signaldashpro/current/deploy
  docker compose --env-file ../.env -f docker-compose.ct110.yml up -d --build
  docker compose --env-file ../.env -f docker-compose.ct110.yml ps
  curl -fsS http://127.0.0.1:8096/status | head
"
**BACKTEST ANUAL EJECUTADO (23:40 UTC 2026-03-17):**
- Ejecutado backtest de 1 año completo (365 días M15, balance $1000, PAXGUSDT)
- Calibración: filtro original 4.54x vol_ratio era percentil 99+ (inviable); ajustado a 1.5x (P75)
- Resultados: 257 trades, 26.8% WR, +124.62 PnL (+12.46%), PF=1.23, DD=7.43%
- Reporte: `/storage/reports/paxg_1y_with_filters_final_2026_03_17.json`
- Nota: Runtime actual mantiene 0.159% vol, 4.54x ratio (valores extremos); considerar update a 0.15%, 1.5x en próximo ciclo

Comandos tipicos:

cd /opt/signaldashpro/current

# Si CT110 tiene credenciales Git configuradas (opcional):
# git status
# git pull
#
# Si NO hay credenciales Git (modo recomendado por ahora):
# se sube un tarball del commit y se hace switch de release via symlink.
#
# Hotfix rapido (cuando solo es 1-2 archivos):
# scp de los archivos al release activo + rebuild del servicio afectado.

# Rebuild/restart
cd deploy
docker compose --env-file ../.env -f docker-compose.ct110.yml up -d --build

# Logs
docker compose --env-file ../.env -f docker-compose.ct110.yml ps
docker compose --env-file ../.env -f docker-compose.ct110.yml logs -f --tail=200 backend

Checklist post-deploy (CT110):

cd /opt/signaldashpro/current/deploy
ls -la .env   # debe apuntar a ../.env
curl -fsS http://127.0.0.1:8096/status | head
curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8096/binance/account?nonzero_only=true  # suele ser 401 si AUTH_ENABLED=true

Troubleshooting: CT110 sin espacio (Docker build falla)#

Sintoma tipico:

failed to copy files: ... no space left on device
o docker system df falla por no poder crear tmp en /var/lib/docker/tmp/...

Diagnostico rapido:

df -h /
du -sh /var/lib/docker || true

Mitigacion (agresiva, pero segura para este proyecto):

No usa volúmenes docker persistentes en CT110 (persistimos en /opt/signaldashpro/storage), asi que podemos limpiar cache/images sin miedo.

docker builder prune -af
docker image prune -af
docker container prune -f
docker volume prune -f
rm -rf /var/lib/docker/tmp/* || true
df -h /

Luego reintentar rebuild:

cd /opt/signaldashpro/current/deploy
docker compose --env-file ../.env -f docker-compose.ct110.yml up -d --build

Automatizacion 24/7 (systemd)#

En CT110 se instalo automatizacion via systemd timers para operacion 30 dias.

Timers (CT110):

signaldashpro-daily.timer: runner diario spot demo (policies + DB health + checks HTTP + evidencia).
signaldashpro-trade-smoke.timer: orden spot controlada diaria (Mon-Fri) para validar ejecucion real.
signaldashpro-alerts.timer: auditoria local de alertas (notify_external_alerts.py) con salida a logs + estado persistido.
signaldashpro-storage-backup.timer: backup diario de storage/ (tar.gz) con retencion de 14.
signaldashpro-weekly-report.timer: genera reporte semanal (MD/JSON).

Scripts:

/opt/signaldashpro/current/deploy/ops/daily.sh
/opt/signaldashpro/current/deploy/ops/trade_smoke.sh
/opt/signaldashpro/current/deploy/ops/alerts.sh
/opt/signaldashpro/current/deploy/ops/storage_backup.sh

Outputs:

logs: /opt/signaldashpro/current/storage/logs/ops/
evidencia JSON: /opt/signaldashpro/current/storage/logs/evidence/
backups storage: /opt/backups/signaldashpro/
reportes semanales: /opt/signaldashpro/current/storage/reports/weekly/

Consola web (Ops)#

Para ver todo el estado desde el navegador (sin Slack/Teams), usa la pagina /ops en el frontend (menu Soporte -> Ops).

La pagina consume endpoints del backend bajo /ops/* y muestra:

ultima evidencia diaria + warnings de DB,
reporte semanal,
logs de timers.

Nuevo panel de control operativo:

Frontend /control-tower (menu Analisis) para estado consolidado:
modo IA actual,
ultimo research gate (incluyendo walk-forward),
jobs backend,
cola de señales reciente,
noticias de mercado (24h),
brief diario,
timeline consolidada 24h (/ops/timeline/latest).

Seguridad (opcional):

Si defines OPS_READ_TOKEN en el backend, los endpoints /ops/* pasan a requerir el header X-Ops-Token.
La pagina /ops permite pegar el token y lo guarda en localStorage (solo para tu navegador).

Comandos utiles:

systemctl list-timers --all | grep signaldashpro
systemctl status signaldashpro-daily.service signaldashpro-alerts.service signaldashpro-storage-backup.service
journalctl -u signaldashpro-daily.service -n 200 --no-pager

Backups DB (CT107)#

En CT107 se instalo un backup diario de la BD via systemd:

timer: signaldashpro-db-backup.timer
script: /usr/local/bin/signaldashpro-db-backup.sh
output: /var/backups/signaldashpro/db-*.dump (retencion 14)

Troubleshooting rapido#

502 Bad Gateway desde afuera (openresty):
Casi siempre es NPM apuntando al upstream equivocado.
En NPM, api.sdp.perlatec.net debe forwardear a http://192.168.100.10:8096.
sdp.perlatec.net debe forwardear a http://192.168.100.10:3000.
Error CORS en el browser:
El API debe responder Access-Control-Allow-Origin: https://sdp.perlatec.net.
Backend soporta CORS_ALLOW_ORIGINS (comma-separated).
Validar preflight:

curl -sS -D- -o /dev/null -X OPTIONS \
  'https://api.sdp.perlatec.net/binance/account?nonzero_only=true' \
  -H 'Origin: https://sdp.perlatec.net' \
  -H 'Access-Control-Request-Method: GET' | sed -n '1,40p'

/binance/account devuelve 400/500:
Revisar que existan BINANCE_API_KEY y BINANCE_API_SECRET en el env que esta usando el backend.
Ver logs del container backend.
Ejecutar smoke rapido:

chmod +x scripts/check_binance_demo_auth.sh
scripts/check_binance_demo_auth.sh \
  --base-url=https://sdp.perlatec.net/api/proxy \
  --email=admin@sdp.perlatec.net \
  --password='***'

Si responde -2014 o -2015, rotar key demo en https://demo.binance.com/en/my/settings/api-management.
Rotacion de API key Demo (runbook corto):
Actualizar env/.env.binance.demo.month con BINANCE_API_KEY y BINANCE_API_SECRET nuevos.
Subir env a CT110: /opt/signaldashpro/env/.env.binance.demo.month.
Recrear backend para recargar env_file:

cd /opt/signaldashpro/current
docker compose --env-file /opt/signaldashpro/env/.env.compose up -d --force-recreate backend

Verificar que el container cargo la key nueva:

docker exec current-backend-1 env | grep 'BINANCE_BASE_URL\|BINANCE_API_KEY'

Re-ejecutar scripts/check_binance_demo_auth.sh y confirmar SMOKE_OK.
Para automatizar chequeo continuo en CT110 (cada 30 min):

cd /opt/signaldashpro/current
bash deploy/systemd/install_ct110_timers.sh
systemctl status signaldashpro-binance-demo-auth-smoke.timer --no-pager

Logs del ultimo smoke:

tail -n 120 /opt/signaldashpro/current/storage/logs/ops/binance-demo-auth-smoke-latest.log

Alerta opcional por webhook cuando falle el smoke:

# En /opt/signaldashpro/env/.env.compose
BINANCE_DEMO_AUTH_ALERT_WEBHOOK_URL=https://hooks.example.net/signaldashpro/binance-demo-auth
BINANCE_DEMO_AUTH_ALERT_TIMEOUT_SEC=8
BINANCE_DEMO_AUTH_ALERT_ON_SUCCESS=false

El payload incluye source, timestamp_utc, host, outcome, reason, base_url, log_tail.
Timers fallan con Permission denied al ejecutar scripts:
Verifica que los scripts tengan bit ejecutable:

ls -la /opt/signaldashpro/current/deploy/ops/*.sh
chmod +x /opt/signaldashpro/current/deploy/ops/*.sh
systemctl reset-failed signaldashpro-daily.service signaldashpro-storage-backup.service signaldashpro-alerts.service
systemctl start signaldashpro-daily.service signaldashpro-storage-backup.service

Backend:
POST /auth/login devuelve access_token (JWT HS256).
Si AUTH_ENABLED=true, la API requiere Authorization: Bearer <token> en casi todos los endpoints.
Bootstrap inicial (solo si no existen usuarios): AUTH_BOOTSTRAP_EMAIL + AUTH_BOOTSTRAP_PASSWORD.
Frontend:
/login guarda el token en cookie SDP_AUTH y localStorage SDP_AUTH_TOKEN.
La navegacion se bloquea sin cookie (middleware de Next).
Ops timers:
Si AUTH_ENABLED=true, los timers usan OPS_AUTH_EMAIL/OPS_AUTH_PASSWORD para loguearse antes de chequear endpoints.

Repo limpio (artefactos)#

storage/ es runtime (logs, evidencia, reportes, datasets/modelos) y no se versiona.

Nota: variables criticas para orden real en Spot Demo#

En el env del backend (gitignored) para spot demo:

BINANCE_BASE_URL=https://demo-api.binance.com
BINANCE_MARKET_TYPE=spot
BINANCE_TRADING_ENABLED=true
BINANCE_SIMULATION_MODE=false
API key de Demo se genera en https://demo.binance.com/en/my/settings/api-management.
Documentacion Spot Demo: https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info.
No persistir BINANCE_API_KEY/BINANCE_API_SECRET en markdown; solo en env gitignored.
Los dumps, DBs de pruebas y HTML/JSON legacy de OpenAPI no se suben a git.

Si abres otra sesion de ChatGPT (prompt recomendado)#

Copia/pega esto en una sesion nueva:

Estoy trabajando en /Users/dmx83/Repos/SignalDashPro.
Hay un deploy corriendo en Proxmox (PVE 185.209.230.42). SignalDashPro esta en CT110 (192.168.100.10) con Docker Compose:
- backend :8096, frontend :3000, docs :8001
NPM corre en CT103 (192.168.100.2) y expone:
- https://sdp.perlatec.net -> 192.168.100.10:3000
- https://api.sdp.perlatec.net -> 192.168.100.10:8096
Postgres esta en CT107 (192.168.100.7:5432).
Lee HANDOFF.md y proxmox.md para el estado actual. No commits de secretos; los .env estan gitignored.
Objetivo: dejarlo 30 dias corriendo en Binance demo/testnet y mejorar operacion/observabilidad.

Update 2026-03-02 (P0 hour-edge + smoke)#

Backend/ops:
GET /ops/p0/readiness harden:
- te_source_not_seen solo si la ventana es RSS-only (google_news_rss) para evitar falso negativo cuando TE guarda publisher en source.
- modo auto de AUTOPILOT_ALLOW_HOURS_UTC ahora usa fallback CFG_AUTO::<SYMBOL>::AUTOPILOT_ALLOW_HOURS_UTC y publica auto_hours_scope + auto_hours_by_symbol.
Frontend /ops:
En seccion P0 Readiness (2-5) se agrego accion Aplicar Hour-Edge Auto que llama POST /autopilot/tune (14d, TF efectivo, symbols del snapshot P0), con feedback y recarga.
E2E:
frontend/e2e/ops-coverage.spec.ts ahora cubre presencia/uso del control Aplicar Hour-Edge Auto.
Smoke nuevo:
script scripts/smoke_p0_readiness.sh (login admin o OPS_READ_TOKEN) para validar payload/status de GET /ops/p0/readiness.
Ejecucion real contra https://api.sdp.perlatec.net validada OK (status warn, tf=M15, hour_mode=auto).

Update 2026-03-02 (Ops hour-edge observability)#

Backend Ops:
GET /ops/autopilot/tune/latest: auditoria de cambios recientes CFG_AUTO::* con latest_hour_edge.
GET /ops/autopilot/hour-edge/effectiveness: compara trades cerrados in-hours vs out-hours (muestra, PnL medio, delta) por simbolo y total.
Frontend Ops:
nuevas tarjetas Hour-Edge Efectividad (14d) y Ultimo AutoTune.
nueva seccion Hour-Edge Efectividad con tabla por simbolo.
QA:
backend test nuevo: backend/tests/test_ops_hour_edge_effectiveness.py.
E2E nuevo: frontend/e2e/ops-hour-edge-apply.spec.ts.

Update 2026-03-02 (Hour-edge cockpit + daily brief)#

Dashboard:
la tarjeta P0 Readiness (2-5) ahora muestra KPIs de hour-edge en la vista principal:
- status, delta avg pnl, out-sample, ultimo tune y actor.
objetivo: detectar desde /dashboard si el ajuste de horas efectivas esta mejorando o degradando.
Daily brief:
scripts/run_ops_daily_brief.py agrega seccion Hour-Edge (14d) y guarda metricas en JSON:
- hour_edge_status, hour_edge_delta_avg_pnl, hour_edge_trades, hour_edge_out_allowed_sample, hour_edge_latest_tune_at, hour_edge_latest_tune_actor.
fuentes API usadas:
- GET /ops/autopilot/hour-edge/effectiveness
- GET /ops/autopilot/tune/latest
Experimento controlado:
nuevo helper scripts/run_hour_edge_experiment.py para abrir/cerrar ventana de prueba de horas efectivas sin tocar .env.
--enable:
- login admin (OPS_AUTH_EMAIL + OPS_AUTH_PASSWORD),
- lee snapshot actual de AUTOPILOT_ALLOW_HOURS_UTC,
- aplica mode=manual con merge de --probe-hours,
- guarda estado previo en storage/logs/ops/hour-edge-experiment-state.json.
--disable:
- restaura mode/manual_value previo desde state file.

Update 2026-03-02 (Ops opportunities + execution health + assistant)#

Backend Ops:
GET /ops/gates/opportunities-report:
- reporte operativo de oportunidades perdidas con breakdown por reason/symbol/session.
GET /ops/execution/health:
- semaforo E2E de queue -> execution -> live_trade (fill rate, full-chain, stale processing, open trades antiguos).
GET /ops/postmortems/assistant-summary:
- resumen asistido 30d con highlights + recomendaciones priorizadas (sin enforcement automatico).
Frontend:
/ops agrega:
- tarjeta Execution Health (7d),
- seccion Reporte de Oportunidades Perdidas (7d),
- seccion Postmortem Asistido (30d).
/dashboard amplifica P0 Readiness con contexto de execution health, oportunidades de gates y overdue de postmortem.
/control-tower (timeline news) mejora lectura con resumen corto y CTA explicito a noticia completa.
UI/legibilidad:
frontend/src/app/globals.css endurece contraste de texto secundario y mejora placeholders/inputs para sesiones largas.

Update 2026-03-02 (Daily brief + external alerts expansion)#

backend/services/ops_automation.py (write_daily_brief) ahora persiste y publica en markdown:
gates_opportunities_7d,
execution_health_7d,
postmortem_assistant_30d.
scripts/run_ops_daily_brief.py queda alineado con los endpoints nuevos y agrega esas secciones en el brief local.
scripts/notify_external_alerts.py agrega alerta nueva de oportunidad perdida en gates:
fuente: GET /ops/gates/opportunities-report.
env/flags: ALERT_GATES_OPPORTUNITY_ENABLED, ALERT_GATES_OPPORTUNITY_MIN_EVALUATED, ALERT_GATES_OPPORTUNITY_MAX_POTENTIAL_WIN_RATE_PCT.

Update 2026-03-02 (Gates drill-down + auto-case escalation)#

Dashboard (/dashboard):
bloque nuevo Gates Opportunity Drill-down (7d) en Operacion Hoy con:
- pWin, wins/evaluated, breaches,
- top casos bloqueados (top_lost_cases) y enlaces directos a:
- /analytics?symbol=...&q=...
- /control-tower?tl_kind=news&tl_symbol=...
- /news?symbol=...
Alertas externas (scripts/notify_external_alerts.py):
alerta gates enriquecida con top_case + links de drill-down.
escalacion automatica opcional:
- crea CaseReview + CaseReviewAction cuando la misma firma de alerta se repite N ciclos.
- nuevos env/flags:
- ALERT_GATES_OPPORTUNITY_AUTO_CASE_ENABLED
- ALERT_GATES_OPPORTUNITY_AUTO_CASE_MIN_REPEATS
- ALERT_GATES_OPPORTUNITY_AUTO_CASE_OWNER
- ALERT_GATES_OPPORTUNITY_AUTO_CASE_PRIORITY
- ALERT_GATES_OPPORTUNITY_AUTO_CASE_DUE_HOURS
deduplicacion por firma para evitar creacion repetida del mismo caso.

Update 2026-03-02 (Alerts timer observability sin webhook)#

deploy/ops/alerts.sh ya no sale silenciosamente cuando no existe webhook configurado.
ahora ejecuta notify_external_alerts.py --dry-run y deja artefacto en:
- storage/logs/ops/alerts-<timestamp>.log
permite verificar salud del pipeline de alertas (auth, evaluacion de capas, dedupe) antes de conectar Slack/Teams.
CT110:
se cargaron OPS_AUTH_EMAIL + OPS_AUTH_PASSWORD en /opt/signaldashpro/env/.env.compose.
validado signaldashpro-alerts.service con generacion real de alerts-*.log sin 401.

Update 2026-03-02 (Slack/Teams removidos)#

scripts/notify_external_alerts.py deja de depender de SLACK_WEBHOOK_URL / TEAMS_WEBHOOK_URL.
ahora procesa alertas localmente, las emite por log y persiste estado en storage/alerts/alert_state.json.
--dry-run ya no guarda estado (solo evidencia en log).
deploy/ops/alerts.sh simplificado:
siempre ejecuta notify_external_alerts.py y deja artefacto storage/logs/ops/alerts-*.log.
sin ramificacion por webhook.

Update 2026-03-02 (Market sync signal quality + weekly ops audit)#

scripts/notify_external_alerts.py:
market sync ahora usa GET /ops/p0/readiness (operation_7d.market_sync) como fuente principal.
fallback al endpoint legacy de velas solo si el endpoint de P0 no responde.
objetivo: eliminar falsos positivos de stale por orden de velas.
Dashboard (/dashboard):
nueva tarjeta Salud de Feed con:
- stale count/lag por simbolo en market_sync,
- edad de macro/news/alignment,
- enlaces rapidos a /ops y /market.
Auditoria semanal:
nuevo scripts/run_ops_weekly_audit.py (JSON + MD).
deploy/ops/weekly_report.sh ahora ejecuta:
- run_weekly_report.py
- run_ops_weekly_audit.py --backend-url http://127.0.0.1:8096

Update 2026-03-02 (CT110 release + alert thresholds wiring)#

Deploy CT110 actualizado a:
/opt/signaldashpro/releases/20260302T193313Z-283307f3 (backend).
/opt/signaldashpro/releases/20260302T204624Z-4969b3a0 (refresh docs/hand-off, backend/frontend en estado Up).
deploy/ops/alerts.sh toma variables ALERT_* desde .env y las pasa por CLI a notify_external_alerts.py:
--llm-min-coverage-pct
--market-sync-max-lag-minutes
--gates-opportunity-auto-case-* (owner/prioridad/repeticiones/due).
Verificacion operativa en CT110:
log storage/logs/ops/alerts-20260302T193809Z.log generado OK.
resumen de corrida: market_sync=0, sin errores de auth (401).

Update 2026-03-02 (Analytics queue overlay hardening)#

Analisis (/analytics) mejora capa Queue:
filtro nuevo Queue status: all/failed/filled/active/with_execution/retry.
toggles por tipo de evento: Queue created, Queue attempt, Queue processed.
persistencia en preferencias de replay/UI.
Timeline operativo en Analisis agrega eventos recientes:
queue_failed y execution_issue (ademas de kill-switch/freshness/alerts/F2/pricing).
codigos de lectura rapida: QX, EX, PW, AN, F2, KS.
Deploy CT110 frontend:
/opt/signaldashpro/releases/20260302T210231Z-b0c6c4d1.

Update 2026-03-02 (Analytics timeline filters + replay scope + weekly traceability audit)#

Analisis (/analytics):
Timeline operativo con filtros de tipo + solo errores.
Query params shareables: op_tl_kind, op_tl_err.
accion copiar enlace timeline.
replay con selector de fuente:
- trade_window (foco en trade seleccionado),
- visible_range (sesion completa del rango visible del chart).
query param de replay: rp_scope.
Auditoria semanal (scripts/run_ops_weekly_audit.py):
agrega traceability_coverage (7d) desde /ops/traceability/coverage.
emite recomendacion si cobertura de cadena end-to-end cae o la severidad no es ok.
Deploy CT110 consolidado:
/opt/signaldashpro/releases/20260303T073444Z-93e2f8a6 (backend+frontend+docs).

Update 2026-03-03 (Ops timeline counters/export + dashboard weekly traceability)#

Analisis (/analytics):
Timeline operativo ahora muestra contadores por severidad (error/warn/ok) en la vista activa.
accion nueva exportar csv del timeline filtrado para auditoria rapida offline.
Dashboard (/dashboard, tarjeta Operacion Hoy):
bloque Trazabilidad semanal (7d) basado en GET /ops/traceability/coverage.
presenta % full_chain, ratio full_chain/trades, severidad, missing_samples y brechas resumidas.
enlaces rapidos a Ops -> Traceability y Ops -> Auto-cases.
Deploy CT110:
/opt/signaldashpro/releases/20260303T075032Z-e2217825 (frontend+docs, verify prod en verde, backend reutilizado sin rebuild).

Update 2026-03-03 (Macro insights enrichment + dashboard visibility)#

Backend macro enrichment:
nuevo servicio backend/services/macro_enricher.py con salida estructurada (JSON estricto) y fallback heuristico.
nueva tabla macro_event_insights para persistir enrichment por evento (macro_event_id unico), con:
- importance_level, category, volatility_expectation, confidence_score.
- impact_score, surprise_score, regime_signal.
nuevos endpoints:
- POST /market-data/macro/enrich
- GET /market-data/macro/insights
- GET /market-data/macro/insights/summary
nuevo modo auto-run del enrichment desde job macro:
- MACRO_ENRICH_AUTO_RUN
- MACRO_ENRICH_LIMIT
- MACRO_ENRICH_ONLY_HIGH_IMPACT
Dashboard (/dashboard, Operacion Hoy):
bloque nuevo Macro Insights (7d) con:
- estado (OK/WARN/DANGER), total de eventos, % high-risk,
- top monedas por high_risk_pct e impact_avg.
Validacion local:
backend tests: backend/tests/test_macro_enrichment.py + backend/tests/test_macro_events.py (4 passed).
frontend build (next build) en verde.
Deploy CT110:
release: /opt/signaldashpro/releases/20260303T151054Z-50b154b9 (backend+frontend, verify prod en verde).
logs:
- /tmp/ct110_deploy_20260303T151054Z.log
- /tmp/ct110_deploy_phase_20260303T151054Z-50b154b9.log

Update 2026-03-03 (Ops macro module + timeline drill-down)#

Ops (/ops) agrega seccion Macro Insights (7d):
id: ops-macro-insights (deep-link ?section=macro-insights).
filtro por currency con estado en URL (mi_currency).
tabla de eventos enriquecidos (impact_score, regime_signal, detalle corto).
accion manual ejecutar enrichment (usa POST /market-data/macro/enrich).
tarjeta resumen en cabecera de ops con % high-risk y estado agregado.
Control Tower (/control-tower, timeline news):
nuevo link ver Macro Insights en chips desktop/mobile y en modal de noticia.
ruta generada: /ops?section=macro-insights[&mi_currency=...].
CT110 env persistente actualizado:
MACRO_ENRICH_AUTO_RUN=true
MACRO_ENRICH_LIMIT=30
MACRO_ENRICH_ONLY_HIGH_IMPACT=true

Update 2026-03-03 (Macro LLM fallback para vacios de proveedor)#

backend/services/macro_ingestor.py:
nuevo modo MACRO_PROVIDER=openai para ingesta macro via OpenAI.
fallback automatico a LLM cuando TE/FMP fallen o no tengan API key, si MACRO_LLM_FALLBACK_ENABLED=true.
prompt estricto JSON + ventanas por fecha (MACRO_LLM_WINDOW_DAYS, default diario).
eventos persistidos en macro_events con provider=openai_macro_estimated y raw_payload auditado.
configuracion nueva:
MACRO_LLM_FALLBACK_ENABLED (bool),
MACRO_LLM_MODEL (default recomendado gpt-4.1-mini),
MACRO_LLM_WINDOW_DAYS (1..7),
MACRO_LLM_MAX_EVENTS_PER_DAY (1..50).
integracion backend:
MacroIngestor ahora recibe tambien settings.llm.
tests:
backend/tests/test_macro_ingestor_llm_fallback.py (fallback por key faltante + parser JSON fenced).

Update 2026-03-03 (News macro digest fallback via OpenAI)#

backend/services/news_ingestor.py:
nuevo fallback opcional openai_macro_digest para generar market_news cuando hay huecos de feeds externos.
ingesta por dia/rango con salida JSON estricta (prompt profesional y objetivo).
dedupe estable por URL sintetica: openai://macro-digest/<day>/<symbol>/<hash>.
resumen incluye metadata auditada (source/model/confidence/impact).
NewsIngestor ahora recibe tambien settings.llm para usar OpenAI cuando aplica.
configuracion nueva:
NEWS_MACRO_LLM_DIGEST_ENABLED
NEWS_MACRO_LLM_DIGEST_DAYS
NEWS_MACRO_LLM_DIGEST_MAX_ITEMS_PER_DAY
NEWS_MACRO_LLM_DIGEST_MODEL
tests:
backend/tests/test_news_ingestor_llm_digest.py
CT110 env persistente:
NEWS_MACRO_LLM_DIGEST_ENABLED=true
NEWS_MACRO_LLM_DIGEST_DAYS=3
NEWS_MACRO_LLM_DIGEST_MAX_ITEMS_PER_DAY=6
NEWS_MACRO_LLM_DIGEST_MODEL=gpt-4.1-mini

Update 2026-03-03 (OpenAI runtime key en Configuracion, cifrada en DB)#

Backend:
nuevo servicio backend/services/secret_store.py para secretos runtime cifrados (Fernet, version v1:).
clave de cifrado:
- preferida: APP_SECRETS_MASTER_KEY,
- fallback: derivada de AUTH_JWT_SECRET.
storage:
- runtime_settings.key=SECRET_ENC::OPENAI_API_KEY (ciphertext, nunca plaintext).
nuevos endpoints admin-only:
- GET /settings/ai/openai
- POST /settings/ai/openai (api_key, clear_api_key, model, apply_now, reason).
main.py agrega hot-apply para runtime LLM:
- resuelve key/model efectivo (runtime > env),
- actualiza settings.llm y reconstruye servicios dependientes de LLM sin restart.
Frontend:
Cuenta -> Configuracion (/settings) agrega bloque OpenAI API (runtime):
- guardar/limpiar API key,
- ajustar modelo,
- aplicar cambios inmediatamente (apply_now).
la UI solo muestra estado (has_api_key, key_source), no muestra la key.
Tests:
backend/tests/test_settings_openai_runtime.py
- admin-only enforcement,
- verificacion de guardado cifrado (sin plaintext en DB).
Tooling:
nuevo script scripts/runtime_settings_snapshot.py para export/import de runtime_settings:
- por defecto redacted (omite valores sensibles),
- opcion --include-secrets para incluir ciphertext de SECRET_ENC:: cuando se requiera restore exacto.

Update 2026-03-03 (Hardening deploy + clave maestra persistente)#

CT110:
APP_SECRETS_MASTER_KEY validado en /opt/signaldashpro/env/.env.compose (presente, no CHANGEME).
Deploy script hardening:
scripts/ct110_deploy_release.sh
- HEALTH_TIMEOUT_SECONDS default sube a 240 para arranques lentos.
- health-check usa lectura de http_code (tolerante a resets transitorios).
- verificacion de endpoints agrega reintentos por endpoint (VERIFY_RETRY_SECONDS, default 20).

Update 2026-03-05 (M15 timeline + alerta warn sostenido + thresholds estrictos)#

Backend (/ops/strategy/m15-promotions):
payload ampliado con:
- summary.rolled_back, summary.total_rollbacks,
- items[].rolled_back, items[].rollback,
- timeline[] con eventos promotion/rollback.
Dashboard (/dashboard, card M15 Optimizer):
tabla Timeline promote/rollback para ver ciclo completo y deltas WR/DD.
acciones operativas: Promover, Rollback ultima promotion, Audit promotions now.
bloque M15 automation (status/breaches + ages de autopromote y maintenance).
Alerting:
scripts/notify_external_alerts.py integra alerta nueva:
- [M15 Automation Alert] cuando /ops/strategy/m15-automation-status permanece en warn por N repeticiones.
deploy/ops/alerts.sh propaga flags:
- --m15-automation-alerts-enabled
- --m15-automation-min-repeat
CT110 (env persistente /opt/signaldashpro/env/.env.compose):
OPS_M15_AUTOPROMOTE_STALE_MINUTES=60
OPS_SHADOW_MAINT_STALE_MINUTES=1440
ALERT_M15_AUTOMATION_ENABLED=true
ALERT_M15_AUTOMATION_MIN_REPEAT=2
Release activa validada:
/opt/signaldashpro/releases/20260305T090031Z-8ea4ee87

Update 2026-03-26 (Recovery timers CT110: Binance smoke + M15 autopromote)#

Estado detectado:
signaldashpro-binance-demo-auth-smoke.service fallaba con rc=126 (Permission denied al ejecutar scripts/check_binance_demo_auth.sh).
signaldashpro-m15-autopromote.service fallaba con 401 Unauthorized contra POST /ops/strategy/m15-optimizer/promote-best.
Causa raíz:
wrapper de smoke dependía del bit ejecutable del script objetivo.
wrapper de m15 autopromote solo intentaba AUTH_BOOTSTRAP_*; en runtime CT110 se usa OPS_AUTH_*.
Hotfix aplicado en repo y sincronizado en CT110:
deploy/ops/binance_demo_auth_smoke.sh
- ahora invoca bash scripts/check_binance_demo_auth.sh.
deploy/ops/m15_autopromote.sh
- agrega fallback a OPS_AUTH_EMAIL/OPS_AUTH_PASSWORD si faltan AUTH_BOOTSTRAP_*.
Verificación manual post-fix (CT110):
systemctl start signaldashpro-binance-demo-auth-smoke.service -> status=0/SUCCESS.
systemctl start signaldashpro-m15-autopromote.service -> status=0/SUCCESS.
binance-demo-auth-smoke-latest.log termina en SMOKE_OK (LOGIN_OK, STATUS_HTTP=200, ACCOUNT_HTTP=200).
m15-autopromote-*.log reciente: {\"ok\": true, \"applied\": false, \"status\": \"no_candidate\"}.
systemctl --failed sin unidades signaldashpro en fallo.