Arranque y seguimiento automáticos · 17 octubre 2026
Qué queda preparado
El servidor arrancará el ensayo de selección de monedas cuando cumpla todos los controles. Oscar no necesita volver a pedirlo, pulsar un botón ni dejar el Mac encendido. La autorización es únicamente para dinero ficticio.
La pregunta sigue siendo la misma: ¿elegir las monedas con más fuerza durante dos semanas aporta más, después de gastos, que repartir entre todas las elegibles? Ambas carteras empiezan con 10.000 EUR ficticios, igual exposición y restricciones. No hemos encontrado todavía una estrategia validada para invertir dinero real.
Cómo avanzará solo
- Cada hora comprueba datos, identidad, reglas, costes, registro previo, código, espacio y programación. No basta con esperar siete días: los controles deben pasar.
- Cuando todo esté completo, sella los datos y reserva el siguiente lunes a las 01 UTC, siempre con al menos 24 horas de margen. La fecha no se puede retroceder.
- Desde esa fecha mantiene las dos carteras, su caja y posiciones. Decide cada lunes, simula ejecución el martes y registra una valoración diaria. El escenario de retraso adicional ejecuta el miércoles. Conserva los ocho escenarios previstos.
- Muestra en el panel capital, ganancia o pérdida, referencia, diferencia, costes, curva y fecha de actualización. Todas las cifras son provisionales.
- Un reinicio recupera el último día confirmado, sin añadir otra vez el capital. Una cotización ausente no se inventa: queda la abstención o el tramo no evaluable.
- Fallos de integridad, espacio o programación dejan una pausa persistente visible. No hay reanudación automática que permita saltarse un fallo.
- Al completar 364 días cierra el periodo de observación. Queda pendiente evaluar los criterios estadísticos registrados. No promueve a real ni declara éxito por tener una ganancia positiva.
La hora de la decisión simulada es 01 UTC. El proceso corre al minuto 25, utilizando solo datos cuyo momento de disponibilidad permite usarlos a la hora de decisión. Los libros de ejecución se capturan a las 00:59:15 UTC los martes y miércoles.
Lo que falta ahora
La muestra exige cien franjas válidas y siete fechas UTC por moneda en la última semana, con comisiones actuales y evidencia íntegra. La cobertura temporal no puede completarse antes del 22 de octubre. El primer lunes posible sería el 26 de octubre, 01 UTC (02:00 en Madrid), condicionado a todos los controles y al margen de 24 horas. No es una fecha confirmada ni una promesa de rentabilidad.
La cifra actual se consulta en el panel y en el estado fechado. El programa no reduce los requisitos si una moneda tiene pocos datos o costes altos.
Verificación y conservación
298 pruebas del motor correctas, incluidas migraciones en PostgreSQL desechable. Pruebas específicas: impedir lanzamiento con cualquiera de los siete controles fallido; recuperación tras corte; no duplicar depósito ni experimento; pausa persistente; detección de cambios de código y archivos; cierre sin nueva decisión; igualdad económica con el simulador anterior en los ocho escenarios. Son pruebas técnicas, no resultados de inversión. Análisis estático correcto del motor y los nuevos controladores. Tres pruebas adicionales del panel comprueban espera sin beneficios inventados, resultados con curva, pausa y datos atrasados.
Las entradas y cada día del diario se guardan comprimidos, por huella, enlazados al día anterior. Los lotes de liquidez de más de 14 días se archivan sin pérdida y se verifican antes de retirar su copia de trabajo. Se reservan al menos 5 GiB libres en el servidor compartido; recuperación automática limitada a siete días. Un bloqueo del captador pospone la compactación, sin eliminar datos.
Versiones y límites
La hipótesis 23, versión 1.2, quedó registrada sin experimento. Su instalación identificó que Python 3.10 del host no admite datetime.UTC. Se conserva esa entrega y se corrige con timezone.utc en la versión 1.2.1, antes de cualquier ensayo. El motor continúa usando Python 3.12. Ningún parámetro económico se ha elegido o modificado por rendimientos. Las versiones 1.0/1.1 y los estudios anteriores siguen intactos. El seguimiento mensual de Bitcoin sigue siendo otra observación.
Protocolo completo 1.2.1. El seguimiento automático no resuelve por adelantado la incertidumbre estadística, los cambios futuros de identidad ni incidencias externas: los deja registrados. La evaluación formal y cualquier reparación de una pausa requieren revisión; ningún resultado autoriza compras reales.
Comprobación en el servidor
Corte 17/10/2026 00:33 Madrid: arranque armado; único control pendiente, costes. 24 mercados, mínimo 14 franjas válidas y una fecha UTC; cero mercados admitidos aún. Datos, mínimos, registro, código, espacio y temporizadores pasan. Servicio completo invocado y terminado correctamente; programación horaria activa y habilitada. Este corte acredita la ejecución controlada, no todavía el próximo ciclo horario.
Hipótesis 24 (1.2.1), registrada antes de cualquier ensayo. Base: 24 hipótesis, 39 experimentos anteriores, cero órdenes y cero intenciones reales. No se ha creado un experimento nuevo ni se ha reservado aún una fecha. La incidencia de permisos de la carpeta nueva se resolvió antes del registro y su marcador se conserva como historial de instalación; no queda una pausa activa. El motor principal no se reinició.