El sistema autónomo de inversión multi-estrategia, de punta a punta: por qué existe, cómo gana plata sin predecir el mercado, y cómo se construye.
Análisis comercial y financiero, el concepto y el espíritu de la herramienta, y las decisiones de diseño. Sin una línea de código.
Por qué la mayoría de los bots pierde plata — y qué hace distinto a FARO.
Ese fue el pedido. Perfil de inversor arriesgado, 10% del patrimonio, base en Argentina, acceso a Binance, exchanges locales y broker bursátil.
La respuesta honesta empieza por una mala noticia: los bots que "ganan todos los días" prediciendo el mercado pierden plata en más del 90% de los casos retail. Los mercados son no-estacionarios: lo que un modelo aprendió el trimestre pasado deja de valer el próximo. La buena noticia: existe otra categoría de estrategia que no necesita predecir nada.
"Creo que BTC va a subir" → comprar → rezar. Necesita tener razón sobre el futuro. Señales, momentum, predicción con IA: todo cae en esta categoría, y la evidencia retail es lapidaria.
"El mismo dólar vale distinto en dos lugares" o "el mercado me paga una tasa por sostener una posición neutra". No importa si el mercado sube o baja: la ganancia viene de una ineficiencia medible hoy.
Las ineficiencias existen por fricciones reales: regulación, apalancamiento ajeno, fronteras, costos de mover capital. Mientras la fricción exista, la ineficiencia paga. Y Argentina — con su historia cambiaria — es una fábrica de fricciones.
El valor de FARO no está en una estrategia secreta. Está en cuatro virtudes que un humano no puede sostener y una máquina sí:
Los mercados que nos interesan operan 24/7. Las ventanas de arbitraje duran minutos y aparecen a las 3 AM de un domingo. El que llega primero, cobra.
Ni FOMO ni pánico ni "una más y me voy". El sistema ejecuta la regla, registra la evidencia y sigue.
El tope por operación, la pérdida máxima diaria y la reserva de capital no son intenciones: son verificaciones de software previas a cada orden.
Cada observación, señal y resultado queda registrado. Esa memoria alimenta las decisiones, el aprendizaje y el reporte fiscal.
Cuánto invertir, cuándo entrar, cuándo salir y cuándo no hacer nada: todo es un parámetro que el inversor define y puede cambiar — el código implementa mecanismos, la configuración define políticas.
Pasar de conservador a agresivo es cambiar números en un panel, no reescribir software. El apetito de riesgo es un dial del inversor.
Cada operación registra qué regla la disparó, con qué parámetros y con qué resultado. La pregunta "¿por qué hiciste esto?" siempre tiene respuesta exacta.
Este principio reaparece en cada decisión técnica de la Parte 2: configuración versionada con marcha atrás, auditoría inmutable, y un módulo de aprendizaje que sugiere cambios pero jamás los aplica solo.
Los cuatro conceptos financieros que sostienen todo el sistema, con números.
Si el dólar digital (USDT) cotiza distinto en dos plataformas argentinas, comprarlo donde está barato y venderlo donde está caro simultáneamente fija una ganancia sin exposición al precio. La clave operativa: tener capital pre-posicionado en ambas puntas (pesos en A, USDT en B) para que las dos órdenes salgan en el mismo instante. Después se rebalancea con calma.
ganancia_neta = spread − fee_compra − fee_venta − rebalanceo_prorrateado
# con fees de 0,1–0,5% por punta ⇒ umbral mínimo ~0,8% neto
# y ganancia mínima absoluta: USD 5 por ventana (si no, no vale el riesgo operativo)
La advertencia honesta: el cruce ejecutable real (mejor precio comprable vs. mejor vendible) pasa la mayor parte del tiempo cerrado. Las ventanas se abren con volatilidad, saltos del dólar y fines de semana — por eso la vigilancia 24/7 no es un lujo, es la condición de entrada.
Una posición delta-neutral combina una compra y una venta del mismo activo en mercados distintos, de modo que las subas y bajas se cancelan entre sí. Lo que queda es el flujo que la estructura paga.
Comprás 0,01 BTC al contado (spot) y simultáneamente vendés 0,01 BTC en futuros perpetuos. Si BTC sube 10%, ganás en spot lo que perdés en el futuro. Si baja 10%, al revés. Tu posición neta vale lo mismo.
En la tasa de financiación (funding rate): cada 8 horas, los especuladores apalancados que apuestan a la suba le pagan una tasa a quien sostiene el lado corto. Vos sos ese lado — sin riesgo direccional.
¿Y por qué la mayoría pierde igual? Por ejecución, no por concepto: no contabilizan los fees de entrada y salida, no monitorean el delta en tiempo real, entran sin mirar la profundidad del libro y pagan slippage, y mueven capital entre exchanges en el momento de operar. Cada una de esas causas de fracaso es un requisito de diseño de FARO.
El riesgo real del motor: funding negativo prolongado (el flujo se invierte). Respuesta: señal de salida automática tras N períodos negativos. Se sale y listo.
Colocar pesos a tasa fija (Lecaps, cauciones) rinde en dólares cuando la tasa supera con margen a la devaluación del período. En 2026 el número fue elocuente: ~18% en USD acumulado en el primer semestre, con Lecaps al 31–37% TNA contra inflación esperada del ~21%.
Un salto cambiario brusco licúa meses de tasa en días. En junio 2026, el dólar se movió +2% en tres ruedas. Por eso el carry es táctico: se entra con margen, se sale con disciplina.
El dólar cripto opera 24/7 y anticipa al dólar financiero (que cierra a las 17 y los fines de semana). FARO lo vigila como alarma de salida: cuando el cripto salta, la señal llega antes que el diario.
| Fuente | Quién paga | Por qué paga | Riesgo principal |
|---|---|---|---|
| Funding / basis | Especuladores apalancados | Quieren exposición sin capital; pagan tasa por sostenerla | El flujo se invierte (se sale) |
| Carry en pesos | El Tesoro argentino | Necesita financiarse; paga tasa real positiva | Salto cambiario |
| Renta estructural USD | Mercados de derivados / Tesoro de EE.UU. | El cash-and-carry tokenizado y los T-bills reparten su flujo | Protocolo / contraparte |
| Arbitraje de plazas | La fricción regulatoria | Mover dinero entre plazas argentinas tiene costos y demoras | Operativo / contraparte |
Cada fila es un "motor" del sistema. El Módulo 3 los recorre uno por uno con sus números y condiciones.
Cada fuente de rentabilidad como módulo independiente, con su interruptor, sus números y sus condiciones.
Mecánica: compra spot + venta simultánea en perpetuos, delta-neutral, cobrando el funding cada 8 horas. 100% automatizable, sin depender de terceros protocolos.
10–30% anual en USD. Riesgo bajo-medio. Rol: motor central — genera el flujo base en cualquier dirección del mercado.
Saldos pre-fondeados en ambas patas, fees amortizadas en el cálculo, delta monitoreado en tiempo real, buffer de liquidación del 30% en la pata de futuros.
Lecaps y cauciones vía broker cuando la tasa supera con margen (≥8 pts) la devaluación esperada. 15–25% anual USD si el tipo de cambio acompaña. La alarma de salida la da el dólar cripto en tiempo real — ventaja exclusiva de tener el Motor 4 corriendo. Riesgo medio: el salto cambiario.
El capital que no está desplegado va a un menú jerarquizado de renta USD: (1º) T-bills regulados vía Wallbit — sweep sin retención del 30% del IRS; (2º) sUSDe, el cash-and-carry tokenizado (9,4% actual / 11,8% prom. 90d) y tasa fija Pendle PT (~11%); (3º) lending CeFi tipo Nexo — evaluado y relegado: tasa similar a sUSDe pero personalizada e inverificable por API, top rates solo manteniendo 10% en su token (rompe la neutralidad) y riesgo de contraparte categoría Celsius/BlockFi. Reglas duras: sin apalancamiento, jamás looping, sin tokens de lealtad.
USDT/USDC/DAI cotizan distinto en cada plataforma argentina (Binance P2P, Lemon, Ripio, Buenbit, Belo, LetsBit...). Los bots internacionales no pueden operar CVUs argentinas — esta fricción es nuestra. La fuente de datos es la API pública de CriptoYa: toda la matriz compra/venta en un request.
0,5–2% por ventana, intermitente: el mercado pasa la mayor parte del tiempo en equilibrio y se abre con volatilidad, saltos del dólar y fines de semana. Es un complemento excelente y un motor único insuficiente — el sistema lo sabe y lo trata así.
Cuando el conjunto de resultados de un evento se puede comprar por menos de lo que paga el ganador, la diferencia es ganancia asegurada. Un estudio académico midió USD 40M extraídos en un año solo en Polymarket. La trampa: las ventanas duran segundos y la plataforma ya combate el arbitraje de latencia con fees dinámicas. Entra en modo observación: si la medición demuestra que llegamos a tiempo, pasa a producción. Si no, se descarta con datos.
Neobanco con cuenta en EE.UU. y API REST pública verificada: scopes granulares read/trade sin ningún endpoint de egreso externo (cumple "sin retiro" por diseño), trades de acciones/ETFs, y GET /rates que expone el tipo de cambio implícito ARS→USD con timestamp. Custodio Alpaca; el sweep remunerado eliminó la retención del 30% del IRS. Aprobado: pata regulada del M3 + par "wallbit_implícito" en el M4 desde Fase 1 (key solo-read). Parcial: el riel ARS por CVU aún no está en la API (la dolarización automática del M2 queda con alerta accionable). Spec: SPEC-11.
Un diseño se define tanto por lo que deja afuera. Trece opciones evaluadas, cinco rechazadas con nombre y apellido.
| Opción | Tentación | Por qué no |
|---|---|---|
| Looping apalancado (renta USD ×2) | 15–20%+ anual | Asimetría mala: pocos puntos extra contra liquidación total en un crash. Riesgo sistémico señalado por el propio sector. |
| Arbitraje triangular intra-exchange | Matemática elegante | Ventanas de milisegundos capturadas por firmas HFT con infraestructura imposible de igualar. |
| MEV (arbitraje on-chain) | El "santo grial" DeFi | Guerra de microsegundos contra operadores millonarios. Atractivo en teoría, inviable en esta escala. |
| Surebets deportivas | Arbitraje garantizado | Las casas cierran las cuentas ganadoras en semanas. Vida útil menor al costo de desarrollo. |
| Airdrop farming | Las fortunas de 2021–24 | Los filtros anti-abuso desplomaron la rentabilidad por hora. Oportunismo puntual, no un sistema. |
El filtro común de supervivencia: ventaja concreta (estructural, geográfica o tecnológica) + riesgo acotable por configuración. Lo que no pasa ese filtro, no entra — por más lindo que sea el número.
El blindaje que convierte un experimento en una herramienta: scoring, estados, frenos y límites.
El sistema califica cada oportunidad combinando retorno neto, liquidez, repetibilidad, riesgos operacional y de contraparte, facilidad de salida, cumplimiento y la salud histórica del motor — con pesos que define el inversor. El puntaje gradúa la autonomía:
*La ejecución automática solo existe si el inversor habilitó ese modo, dentro de los límites duros, y el puntaje jamás puentea al guardián de riesgo: son dos verificaciones en serie, no alternativas.
Esta idea — adoptada del contraste con un diseño independiente del mismo sistema — convierte la pregunta binaria "¿opero o no?" en una escala de confianza medible y configurable.
El sistema vive en estados explícitos: OBSERVE → PAPER → MANUAL_APPROVAL → AUTO_LIMITED es la progresión de confianza (cada paso requiere evidencia y aprobación humana). Y desde cualquier estado se puede caer a dos frenos:
Ante anomalía (pérdida del día > 2%, datos dudosos, reloj desincronizado, plataforma caída, depeg): cancela órdenes abiertas, pasa a solo lectura, sigue observando. Si la causa se resuelve, retoma solo.
Ante algo grave (pérdida semanal > 5% o mensual > 10%, descuadre de saldos entre ledger y exchange, configuración corrupta): todo se detiene y solo una persona puede reanudarlo, con confirmación explícita.
Toda transición queda registrada: estado anterior, nuevo, causa y origen. Frenar es siempre seguro; acelerar nunca es automático.
| Límite | Valor inicial | Qué protege |
|---|---|---|
| Capital asignado | 10% del patrimonio | El otro 90% nunca está en juego |
| Máximo desplegado / reserva | 70% / 30% | Siempre hay liquidez para salir o rebalancear |
| Tope por operación / sin confirmar | USD 500 / USD 200 | Ningún error individual duele de verdad |
| Tope por plataforma / activo / stable | 25% / 20% / 40% | La quiebra de un tercero no compromete el sistema |
| Pérdida diaria / semanal / mensual | 2% / 5% / 10% | Tres redes: el día frena, la semana y el mes detienen todo |
| Permiso de retiro de fondos | NO EXISTE | Ni un bug ni un robo de credenciales pueden vaciar cuentas |
Cada orden pasa por el guardián de riesgo antes de existir. Si excede un límite, la orden no se crea — y el rechazo también queda registrado, porque los "no" del sistema son datos.
Sobre la memoria del ledger, un módulo de aprendizaje propone mejoras con evidencia — nunca inventa estrategias ni predice precios. Tres niveles:
"Bajar el umbral de 0,8 a 0,7 habría capturado 14 ventanas por ~USD 38, según costos medidos." Estadística sobre datos propios.
El capital fluye gradualmente hacia los motores con mejor resultado realizado — dentro de pisos y techos configurados.
Detecta cambios de régimen y pausa motores. Es la única acción automática permitida: frenar siempre es seguro.
Cada propuesta llega al panel con su evidencia e impacto estimado; el inversor aprueba o rechaza con un toque, y el propio módulo construye un track record medible (¿cuántas de sus sugerencias aprobadas terminaron bien?) antes de ganar cualquier autonomía. La salud por motor (0-100, calculada de resultados reales) cierra el círculo: salud baja → recomendar pausa; salud alta → sugerir más capital.
Cómo se gana la confianza: con compuertas verificables, nunca con entusiasmo.
| Fase | Qué hace | Compuerta para avanzar |
|---|---|---|
| 1 · Observar | Mide el mercado sin operar ni usar credenciales | 14 días de serie continua que cuantifican cuántas oportunidades reales hay y de qué tamaño |
| 2 · Simular | Opera en papel contra precios y libros reales | PnL simulado positivo y consistente con lo observado |
| 3 · Capital chico | USD 500–1.000 reales, solo motores 1 y 3 | 30 días de PnL real ≈ simulado, conciliación diaria perfecta |
| 4 · Escalar | Suma motores y capital, uno por vez | Evidencia por motor; el M5 entra último, si validó latencia |
| 5 · Aprender | Activa el módulo de sugerencias | ≥ 60 días de historia por motor a calibrar |
| Riesgo | Mitigación de diseño |
|---|---|
| Quiebra de un exchange (estilo FTX) | Tope del 25% por plataforma + conciliación diaria + retiros manuales planificados |
| Depeg de una stablecoin | Tope del 40% por stable + monitoreo de peg + SAFE_MODE automático |
| Funding negativo prolongado | Señal de salida tras N períodos; el M3 absorbe el capital mientras tanto |
| Salto cambiario en pleno carry | Alarma del dólar cripto 24/7 + margen de entrada exigido + tamaño acotado |
| Cierre de cuenta bancaria por movimientos cripto | CVUs dedicadas, frecuencia controlada, rebalanceo programado |
| Impuestos mal gestionados | Cada venta es un hecho imponible registrado; el ledger exporta el detalle para el contador |
| Bug propio que opera de más | Guardián de riesgo previo a toda orden + idempotencia + límites en tres horizontes |
Y el meta-riesgo: el exceso de confianza. Por eso ninguna fase se saltea, ningún motor escala sin evidencia, y el botón rojo siempre está a un toque de distancia — en el panel, en Telegram y en la terminal.
Arquitectura, algoritmos, modelo de datos, cockpit y deploy. Lo que hay que saber para construir FARO — y para construirlo con Claude Code.
Dónde vive cada pieza y por qué.
Conexiones WebSocket vivas 24/7 contra Binance, estado en memoria, el ecosistema Python/CCXT completo, PostgreSQL local, reconciliación ordenada y debugging simple. Una instancia t3.small dedicada en sa-east-1 — jamás compartida con producción de la empresa.
Serverless de ejecución corta: límites de CPU por invocación, sin procesos persistentes, runtime JS/WASM sin CCXT. Forzar el bot ahí es pelear contra la plataforma. Donde sí brilla: el cockpit (Pages + Access) y, a futuro, webhooks livianos.
# topología en una línea
[Operador] ──WireGuard──▶ [EC2: faro.service + Postgres + API:8420 solo wg0]
[Operador] ──HTTPS+Access──▶ [Cloudflare Pages: cockpit] ──túnel──▶ API
[EC2] ──egress HTTPS/WSS──▶ Binance · CriptoYa · Telegram · (Polymarket obs.)
pg_dump | zstd a S3 con restore probado./etc/faro/faro.env (0600), jamás en el repo ni en la config. Logs sin secretos ni balances totales.Un proceso asyncio, motores supervisados y un tick que nunca improvisa.
| Módulo | Responsabilidad |
|---|---|
core/config | Modelos pydantic del YAML completo; recarga en caliente atómica; versiones con checksum y rollback; en Fase 1 rechaza modo: real al arrancar |
core/scheduler | Un job async por motor con su ciclo; max_instances=1: un tick lento jamás se solapa |
core/riskguard | Verificación de límites previa a toda orden (F3+); stateless: lee config + ledger |
scanners/* | Un scanner por motor; contrato común fetch() → Observación; I/O detrás de interfaces mockeables; sin lógica de negocio |
engine/evaluator | Función pura (observación, params, estado) → eventos — toda la matemática vive acá, testeable con fixtures |
engine/scoring | Normaliza eventos heterogéneos al score 0-100 con los pesos de config |
ledger/* | Repositorios SQLAlchemy async; idempotencia por clave natural; agregaciones del cockpit |
notify/telegram · api/* | Alertas con rate-limit y comandos con whitelist · FastAPI v1 con Bearer |
async def tick(motor: Motor): cfg = config.actual() # snapshot inmutable if estado_global.frena() or not cfg[motor].activo: return obs = await motor.scanner.fetch() # I/O — único punto de red await ledger.observaciones.guardar(obs) # idempotente (motor, ts_ciclo) eventos = evaluator.evaluar(obs, cfg[motor], signals.estado(motor)) for ev in eventos: ev.score = scoring.calcular(ev, cfg.scoring) # 0-100 op = await ledger.oportunidades.aplicar(ev) # + config_version_id await notify.señal(op) # dedup interno # F3+: decisión → riskguard.check() → executor.enviar(intent)
Concurrencia: cada motor es una corrutina supervisada — su excepción lo lleva a degradado (backoff + alerta) sin tocar al resto. Un watchdog vigila el último tick de cada uno. Fallar cerrado: timeout reintenta y degrada; payload inválido descarta el tick; config corrupta mantiene la vigente; DB caída bufferea acotado y pausa si desborda.
El principio rector hecho código: validación estricta, versiones inmutables, máquina de estados.
# config.yaml (extracto) — el criterio completo del inversor capital: tope_por_operacion_usd: 500 max_desplegado_pct: 70 # reserva permanente del 30% riesgo: perdida_diaria_maxima_pct: 2 # ⇒ SAFE_MODE perdida_semanal_maxima_pct: 5 # ⇒ KILLED scoring: umbral_alerta: 70 · umbral_manual: 80 · umbral_auto: 90 pesos: { retorno_neto: 0.25, liquidez: 0.15, ... } # suman 1.0 — validado motores: funding_binance: { activo: true, modo: observacion, umbral_entrada_apr_pct: 12 }
real.config_version_id.OBSERVE → PAPER → MANUAL_APPROVAL → AUTO_LIMITED # progresión: gate + humano ↘──────────↘────────↘──────────↙ SAFE_MODE # pérdida diaria · clock drift · racha API · depeg # cancela órdenes, solo-lectura, PUEDE auto-recuperarse ↓ si la causa escala KILLED # pérdida semanal/mensual · mismatch conciliación · config corrupta # JAMÁS se reanuda sin humano + confirmación
Implementación: enum + tabla de transiciones válidas; cada cambio inserta en system_state_log (anterior, nuevo, causa, origen). Los disparadores son verificaciones al inicio de cada tick y en el pipeline de ejecución. Tests obligatorios: transiciones inválidas rechazadas, KILLED irrecuperable sin acción humana, SAFE_MODE auto-recuperable solo cuando el healthcheck de la causa sana.
Las fórmulas exactas que disparan señales — el evaluador como función pura.
# cadencia real del par (8h / 4h / 1h) desde exchange info intervalos_dia = 24 / horas_intervalo apr_bruto = funding_rate * intervalos_dia * 365 * 100 # fees ida+vuelta amortizadas en el horizonte mínimo de tenencia (default 7 días) fee_total = taker_spot*2 + taker_perp*2 apr_neto = apr_bruto - fee_total * (365 / horizonte_dias) # señal con persistencia anti-ruido abrir = apr_neto ≥ umbral_entrada, sostenido N ciclos, con profundidad_libro ≥ mínimo para el monto (ambas patas) cerrar = apr_neto ≤ umbral_salida (misma persistencia) o funding negativo ≥ periodos_configurados
La profundidad se mide sumando niveles del libro hasta cubrir el monto en spot y perp; el precio efectivo resultante alimenta el modelo de slippage de la Fase 2. Todo esto vive en el evaluador: función pura, fixtures, cero I/O.
# CriptoYa: totalAsk/totalBid ya incluyen el fee del exchange; # fees_por_exchange_pct ajusta residuales medidos ask_A = totalAsk_A * (1 + fee_extra_A/100) bid_B = totalBid_B * (1 - fee_extra_B/100) spread_neto = (bid_B / ask_A - 1) * 100 # matriz completa: ∀ (A,B) A≠B por moneda + cruces stable-vs-stable intra-exchange señal si spread_neto ≥ ventana_minima and ganancia_est ≥ 5 USD ganancia_est = monto_referencia * spread_neto/100
El ciclo (60 s) registra la matriz completa en cada pasada, no solo las señales: la historia de cuándo y cuánto se abre el mercado es el insumo de la compuerta de Fase 1 ("¿cuántas ventanas > 0,8% hubo y cuánto duraron?" debe responderse con una query). Los motores no se llaman entre sí: el M2 lee el dólar cripto del M4 a través del ledger.
La fuente de verdad y la capa que hace comparables las oportunidades.
| Tabla | Rol |
|---|---|
observaciones | serie cruda por motor — UNIQUE (motor, ts_ciclo) |
oportunidades | señales con score, subscores y config_version_id |
config_versions / config_audit | política versionada + diffs inmutables |
system_state_log / risk_events | transiciones FSM + eventos de riesgo persistidos |
venues | plataformas con healthcheck (widget on/off) |
order_intents → trade_executions | F2/F3: intención con idempotency_key UNIQUE → ejecución con slippage real y PnL |
recomendaciones / strategy_health | F5: sugerencias con evidencia + salud por motor |
Lo que filtra o agrega es columna indexada; el resto viaja en JSONB versionado.
Reprocesar un tick es un no-op; reintentar una orden con la misma intent no duplica nada.
Auditoría, estados y recomendaciones solo aceptan INSERT: el "update" es un registro nuevo.
El evaluador de cada motor emite métricas heterogéneas (APR, spread, edge). La capa de scoring las mapea a subscores 0-100 documentados: retorno_neto contra percentiles históricos del propio ledger; liquidez como profundidad vs. monto; repetibilidad como frecuencia histórica de esa oportunidad; salud_estrategia desde el StrategyHealthScore (neutro en 50 hasta la Fase 5).
Tres canales, una sola fuente de verdad.
GET /v1/estado · /motores · /oportunidades
GET /v1/metricas/diarias · /observaciones/serie
GET /v1/config · /config/audit
POST /v1/pausa · /reanudar · /config/reload
PATCH /v1/motores/{m} # on/off — única mutación F1
# F5: GET/POST /v1/recomendaciones[/{id}/aprobar]
Errores RFC-7807; 423 si se intenta mutar con freno activo; OpenAPI publicado — el cockpit genera su cliente desde ahí. Dos tokens con scopes: admin y observador.
Whitelist dura de chat. Alertas accionables de cada señal, resumen diario 21:00, y los comandos críticos: /estado, /pausa, /reanudar, /kill (con confirmación), /limites, /oportunidades, y en fases reales /aprobar <id>. Rate-limit y agrupación de ráfagas: nunca 20 alertas en un minuto.
| Versión | Fase | Vistas |
|---|---|---|
| v0 | 1 | Inicio (estado + tarjetas de motor), Oportunidades, Métricas de observación, Config, Alertas (risk_events) — y el botón de PAUSA en todas |
| v1 | 2–3 | Vista Decisión: rendimiento TWR con cada cambio de política marcado sobre la curva ("¿qué política estaba activa cuando mejoró?"), capital apilado por motor vs. total asignado, tendencias 7/30d, comparador de dos rangos = dos políticas |
| v2 | 5 | Box de acciones sugeridas: cada propuesta con evidencia e impacto, Aprobar/Rechazar con un toque, track record del módulo visible, banner de pausas defensivas con "Reactivar (humano)" |
Técnica: Astro SSG + islas mínimas con refresh de 30 s, chart.js, sin framework de estado — los datos viven en la API. Habilitar AUTO_LIMITED o trading real exige doble confirmación en la UI. Design tokens: navy #0E1B2C · teal #0FA3A3 · gold #D9A441 · alert #A8362A.
systemd, compuertas verificables y los playbooks para cuando algo se rompe.
[Service] User=faro Group=faro # usuario de sistema sin shell EnvironmentFile=/etc/faro/faro.env # 0600 — secretos fuera del repo ExecStart=/opt/faro/.venv/bin/python -m faro --config /etc/faro/config.yaml Restart=on-failure RestartSec=5 MemoryMax=1G NoNewPrivileges=yes ProtectSystem=strict
deploy/install.sh idempotente: usuario, venv, migraciones, unit, arranque. update.sh: pull → install → migrate → restart → verificación de salud./v1/estado; fallo ⇒ restart + alerta.risk_events abiertos.El bootstrap como ADN: cómo se traduce todo este curso en un repo que se construye solo (casi).
faro/ ├── CLAUDE.md # 7 principios inquebrantables ├── MODEL.md # el contexto de negocio (Parte 1) ├── SETUP-EC2.md # la instancia, paso a paso ├── config/config.example.yaml ├── specs/SPEC-01..10 + ROADMAP.md └── docs/ARQUITECTURA.md + RUNBOOK.md
Primer prompt: "Leé CLAUDE.md, MODEL.md y docs/ARQUITECTURA.md. Implementá specs/SPEC-01. No avances sin que los criterios de aceptación pasen."
Si el curso deja una sola idea, que sea esta: la ventaja no está en una estrategia secreta — está en la disciplina de un sistema que vigila siempre, ejecuta sin emociones, respeta sus límites y recuerda todo.