Adaptando el método a un broker sin API (RACIONAL)¶
Página crítica — el video usa entities/alpaca con API nativa, pero el usuario opera vía entities/racional que no expone API. Este análisis delinea cómo mantener el resto del sistema y reemplazar la capa de broker con automatización de Chrome.
Diferencia de arquitectura¶
| Layer | Video (con Alpaca) | Usuario (con RACIONAL) |
|---|---|---|
| Strategy | LLM decide trades | igual |
| Research | Perplexity / WebFetch | igual |
| Memory | Files .md | igual |
| Scheduler | Claude Code Routines | igual |
| Broker I/O | HTTP REST a Alpaca API | Chrome automation + confirm humano |
| Portfolio state | Alpaca API (/positions) |
Scraping de UI + archivos locales |
Opciones de automatización para broker-UI¶
A) Human-in-the-loop (recomendado para start)¶
- Agent prepara la orden (ticker, cantidad, tipo, precio).
- Agent publica notificación: "orden candidata: comprar 10 SPY @ market, razón: …".
- Usuario aprueba con un click en la notificación o replying en chat.
- Usuario ejecuta la orden manualmente en RACIONAL UI.
- Usuario confirma ejecución → agent actualiza trade_log.
Ventaja: no autoejecuta, cero riesgo de scripting bug. El agente es asesor, no trader. Desventaja: requiere al usuario disponible. No escala a high frequency.
B) Semi-automático con confirm¶
- Agent usa Chrome automation (Puppeteer/Playwright/Claude-in-Chrome) para llegar hasta el punto de "Submit".
- Pausa y pide confirmación humana final.
- Humano solo clickea "Submit" → se registra via scraping.
Menos manual que A, pero más frágil.
C) Full automation¶
- Puppeteer/Playwright hace todo el flujo incluyendo submit.
- Riesgos críticos: doble ejecución, órdenes no confirmadas, UI cambia y orden sale mal, ToS violado.
- NO recomendado para el experimento inicial. Solo considerar cuando el resto del sistema esté estable y haya logs robustos.
Tracking externo de portfolio¶
Sin API, necesitamos duplicar el estado del portfolio:
memory/positions.md— el agente mantiene su versión del portfolio.- Reconciliación periódica: usuario exporta PDF/CSV de RACIONAL → script parsea → diff contra
positions.md→ alertar discrepancias. - Cadencia: al menos end-of-day, idealmente al cerrar cada posición.
Métricas sin API¶
Sin trade log automático, el agente NO puede calcular Sharpe/drawdown sólo. Opciones:
- Usuario pega statement mensual → agent lo parsea → actualiza
metrics.md. - Scraping de la UI de RACIONAL para pnl mensual.
- Servicios de terceros (TradeLog, Koyfin) que importan statements de brokers chilenos — investigar si RACIONAL es compatible.
Riesgos clásicos del approach sin API¶
- Login expirado: sesión caduca, agente no lo nota, pierde oportunidades.
- 2FA: cada intento de login falla esperando código SMS/auth app.
- Anti-bot: broker detecta comportamiento robotico, bloquea.
- UI cambia: rediseño rompe selectores.
- ToS: algunos brokers prohíben scripting. Verificar ToS RACIONAL.
- Order rejection silenciosa: orden aparece enviada pero broker la rechaza por margin/liquidez/etc.
Recomendación de fases¶
- Fase 0 (ahora): entender RACIONAL. Gaps de entities/racional se cierran primero.
- Fase 1: opción A (human-in-the-loop). Agente asesora, user ejecuta.
- Fase 2: conciliación automática del portfolio (scraping del holdings page).
- Fase 3: opción B (semi-auto con confirm final) si la experiencia de fase 1 fue buena.
- Fase 4: opción C solo si hay métricas sólidas y se entendió el ToS.
Relaciones¶
- Central a: entities/racional, entities/puppeteer-playwright.
- Complementa: concepts/paper-trading-rollout (paper → HITL → semi → full).
- Dependencias: scrape de RACIONAL UI, ToS RACIONAL.
Gaps¶
- Reglas del ToS RACIONAL respecto a scripting — alta prioridad.
- Estabilidad de la UI de RACIONAL (frecuencia de rediseños).
- ¿Existen statements en CSV/PDF descargables de RACIONAL? ¿Con qué granularidad?
- Benchmarks de reliability: Puppeteer vs Playwright vs Claude-in-Chrome para sesiones persistentes >1h.