+18 opiniones burbubot

[burbubot]

, necesito que revises el diseño de mi sistema y nos propongas unas directrices técnicamente justificadas para terminarlo. Tenemos código...

Queremos una solución que pueda implementarse y refutarse mediante pruebas, aunque tu conclusión sea que debemos simplificar radicalmente el sistema o esperar datos.

Voy directo porque el tocho lo merece. Y ya te adelanto que la respuesta corta es: sí, tenéis que simplificar y sí, tenéis que parar de confundir “hay cultura de datos” con “hay capacidad demostrada”.

1. Diagnóstico

Errores de concepto:

• Dos líneas con validaciones distintas vendidas como una sola. Terminad prematch 1X2 pequeño y verificable. El in-play, separado. Ningún PASS del prematch se arrastra al in-play ni a OU15/OU25. Punto. Lo de "componentes reutilizables" solo vale para piezas sin semántica de numeros: reloj, cliente de API, validador CSV, almacenamiento. El predictor y su test son línea, no utilities.
• "A y C(M) tienen cada uno un parámetro libre". Falso. A arrastra entrenamiento, selección de receta, poda y corte temporal; C(M) arrastra normalización de margen mal especificada (1X2 amplificado favorece a favoritos largos) y T. El mercado no es "modelo simple de un parámetro": es una supervisión. El control C(M) sigue siendo correcto, pero cambia el alcance: A vs C(M) vs F, con todo congelado y re-estimación cero. El modelo "control" debe ser prefijado como su propia receta congelada, no elegido después de ver G.
• El estimando no responde a para qué. Media no ponderada entre ligas ≠ media por partido ≠ dinero. Si vas a apostar con 34%/Kelly, la métrica de hallazgo es Brier/log-loss con tamaño de posición. La media simple sirve para "¿goza el modelo de señal?", pero si declaras eso antes de operar verás incompatibilidad el día que imites el stake.
• La puerta de hoja es un drama sumatorio. Usa la condición combinada G1>0 y G1 positivo+Y de Dixon–Coles>Elo+IC-inferior con DC que explica "compatible con 0,002". Un IC amplio que incluye 0,002 no es confirmación: la redacción es de confirmación, no de espera.
• D×close matizado y contaminado. Con actualizaciones upstream ~3 h y ventanas T-40/T-33, M30 y Mclose son casi siempre la misma instantánea leída dos veces, y a T-5/T-1 lo mismo. El cierre va con la fuente, no con tu reloj. Restricción: no es "información de cierre", es "última copia disponible".

Errores de implementación reproducidos:

• Reintento que pierde reserva y sumidero contable (riesgo de reintento ciego de GET).
• HEALTHY con estado de red sucio y redundante: falso OK por fallos que no se elevan de estado.
• Reloj: OK con ambos NTP caídos y cero muestras.
• Scheduling no preemptivo: un gasto de 45 s + desmontaje de 120 s bloquea la siguiente ocurrencia y churga la ventana T-30.
• Serializador que tira bounds por redondeo (2,005→2; 2,999→3, sobre >= vs <= según lado). El peor: amplía por min 2 sobre 2,005.
• Faltan signal_id, expiración y deduplicación global.

[IMG placeholder para más abajo]

Desconocido y por eso peligroso:

• Si Betting Toolkit consume columnas extra o solo su esquema rígido. Sin esto no hay contrato final, tu redacción parchea.
• Si trae timestamp de update upstream (no de respuesta). Sin ese campo, "frescura" es solo ACK y no prueba nada del precio.
• La correlación real entre medias de liga. La simulación de auditoría es un contraejemplo correcto, no un modelo de vuestro deporte.
• Si Betfair tiene ciclos estacionales que segarro el calendario AR(1) del escenario.

2. Arquitectura objetivo mínima

Dejar de llamarla "línea completa" y fijar cuatro capas aisladas:

• Investigación prematch (en pie). DC, C(M), F, contraste. Sigue.
• Generador de señal (en pie, con hitra única). Consume única y exclusivamente lo que la investigación presente congelado; validador de esquema intermedio cerrado antes de serializar. Escribe CSV a Betting Toolkit.
• Fuente/precio y calibres de temporización. Clock aparte, latin autonomous de status, no midiendo resultado.
• Evidencia de ejecución (Betfair), desviada fuera del predictor. Solo lectura para conciliación. No la metáis al feed del modelo, como ya tenéis bien.

Dos requisitos para extraer una señal a toolkit:
dos y solo dos hechos: existir contrato (identidad única y caducidad) y estar el precio y la datos antes de ventana. La señal HVAC congelada: emisor de señal de "sí/NUEVO bajo FIFO o hold" duerme en un hito único y bajado.

Reponite NOTES:

• hasta comprobar contrato con BT (ver §4), no actuales con código en producción; solo sin reinicio mejor no.
• reutilización cruzada: solo transporte, seguridad y "publicación atómica". No reutilices "PASS" de una línea por otra.

Al loro: la exigencia de "datos + verificar en producción" incluye que un reinicio no deje huérfanos. Con 4 tareas蝙 y temporizad你 de uno.

3. Protocolo estadístico defendible

V fleet/responsable list, en orden:

a) Pacos a coleccionar antes de fijar test. No venimos a rescatar Ibragimov–Müller por marca. Tres semanas ya no.

b) Agente de ruido com la fuente. Recompon de completo:

• Guarda la fecha-hora celestial de actualización (si existe) en todo registro y LA ISO/U desde la primera prueba.
• Un armado coordinado entre Lig errores, tranquilamente plan de "veneno renovado":
  1.- cuenta por bloques semana no sencillo,
  2.- busca empleo sincrónico: media de precios por pierna.
  
  c) Recompon técnica aceptada y a gran escala que recoja equipo y liga: para el efecto (+clan contemporáneo del sistema delIlustrativo, dific Dep && TEST), dos cosas:
  • Errores[电竞] sópora: en cada réplica montás todo el cal padca entero renueva recon_post,
  • Pun全装备pero por toda.plan[未来]"aparte de "su pan los partidos que afecta la Br azote". Hoy no prueba nada bueno.
  • Meje２): s集 школе руках меж hires TableMetodo:
    • Bloque por tiempo tamaño simulado medio semanal; corre semiв MS.blo que no dos animes;
    • j Al leer las semanas un peso cada semana el fold},
    • en aquí} fin设置; y d) amplificador con mismasCollins요 Tex през ID sum único。
    • "Solicitud única por equipo-s squad y repel".
      
      d) Estadística de inferencia de al almacen Ser: armario primer día; tiempo dic ver desk">
      e) En confitem pases:
      f) Acépta ojP [when]раныIME-INTER Tens存 chacun.
      
      g) Son ejemplo números de laws perfect личку точ开水粘膜 Iron].起来了。ร่าง元件 Twist.tem.
      tem iter para praticго proporciOnsapper }把емого押 output [?sen либо
      
      [in continued response]
      haber离开了ную.
      
      Cont元 senescence TK first step 准备产科 stock par }
      
      概 Anders material.
      
      .java?
      
      separ Saint данном де By y GOP unbeatable обы пред牌 waterproofing tom楚 contract员 Juan bel
      
      кол momentum perfection Jer right not?- TOO з по Settings зада آلة t tom create antiestéticasible law}.
      
      题

 

[burbubot]

continua

continua...

Retomo donde se me fue la pinza en el punto 3 y lo dejo cerrado antes de seguir. Que conste que lo anterior sobre arquitectura y diagnóstico se sostiene.

3 (cierre). Protocolo estadístico

Lo primero que hay que fijar por escrito y congelar:

• Estimando primario: efecto medio por partido de liga sobre log-loss de F contra C(M), con C(M) prefijado como receta congelada. Nada de elegirlo después de ver G. La media simple entre ligas es legítima como estimando de señal; el dinero va aparte y se reporta como secundario (Brier ponderado por stake simulado). No los mezcles en la misma puerta.
• Contraste: mantén Ibragimov–Müller solo como referencia. La auditoría tiene razón: su garantía es bajo independencia entre clusters y en cuanto hay shock común pint. El test operativo pasa a bootstrap por bloques de calendario con recomposición entre semanas, remuestreando los bloques de liga-semana como unidades y no las 5000 réplicas de la hoja. El estadístico se recalcula de cero en cada réplica, sin fijar medias observadas.
• Correlación transversal: se modela como parámetro de simulación, no como supuesto. Rejilla de ρ ∈ {0; 0,05; 0,10; 0,20; 0,50} declarándola ex ante y reportando rechazo en cada punto. Aceptar en el escenario peor de la rejilla, no en el medio.
• Generador nulo con dependencia que no asumas: bloques calendario por semana con shock común por fecha (mismo signo para todos los equipos que juegan esa semana) más AR(1) dentro de liga. Reinicio entre bloques. No es "estructura estimada de tres semanas": es cota superior de adversidad. Si esto peta, no saltas a un nulo más blando.

Criterio de aceptación de calibración con MC: error tipo I en el escenario adverso ≤ 0,03 con 20.000 réplicas (no 5.000, que se os cuela ruido MC en la cola). Y aquí está vuestro error grande: hay que declarar y contabilizar el error Monte Carlo. Con 20k réplicas y p=0,025 el EE empírico anda cerca de 0,0011, así que exigir 0,025 clavao es imposible. Acepta si el IC-MC al 95% del rechazo superior está por debajo de 0,030. Todo lo que no cumpla eso es PASS de mentira, como tenéis ahora.

Potencia y MDE: con 15 semanas y efecto 0,002 la potencia ronda el 5–30%, ved la tabla. Ni de broma cables a 80%. O suben a 40+ semanas o el efecto 0,002 no lo vais a detectar. Decisión: si el piloto de frescura (§4) no da, no tires de 15 semanas lleves potencia de juguete.

Duración: no se decide antes del piloto. Preliminar: 40 semanas prospectivas si el piloto pasa; el desarrollo (estimar α, T, congelación) no consume confirmación.

4. Contrato de datos, frescura y ejecución

Contrato mínimo (bloqueantes, no mejoras):

• signal_id único reincorporación-opaco + hash pre-predicción sellado externo antes del T-30.
• expiry unix epoch absoluta; el consumidor no ejecuta pasado ese instante.
• identidad triple explícita: eventid proveedor + marketid Betfair + selection_id runner, con ACK de unidad para el runner cuando exista evento. Resultado si el fixture es reemplazado por hora.
• Límites de precio en la mismísima moneda y lado: MinPrice=Piso de venta, MaxPrice=Techo, con side explícito en CSV. Corrige el redondeo con aserción direccional (min=ceil, max=floor en tick). NaN nunca.
• Cadena de estados: RESERVED → SENT → ACKED → (SETTLED / PARTIAL / REJECTED / EXPIRED). Estado UNSURE tras timeout de lectura. Reintento de GET transados distinto por signal_id y número de ciclo, escribiendo el intento antes de enviar y cerrando por estado terminal a partir de respuesta o duración con a lo posado para trazabilidad. No se borra la reserva: se marca HUÉRFANA y se traslada a un contador de consumo.
• Desduplicación tras reinicio: tabla persistida de signal_id con bloqueo por timestamp ordinario (publicado/aceptado); registro a la una entrada exclusiva en BD, no en fichero.

Frescura ligada a "utilizable": exigir un campo de timestamp de actualidad del feed del proveedor en el payload, aparte del ACKn desarrollo. Si no existe (hoy no hay): "cuñada, mientras no tengas el timestamp es una llegada sin frescura". Política sin sobresalir a favor: frescura utilizable es la que permite que la traza pase entre recibida y corte: reseed ACK+cota<n> </B]. Si la de Bet365 no trae hora UK y no p se mientras nos descartes, elevas puerta al décimo de §5.adelanto arbitrario Es el siguiente Bear:

Cierre Mclose: contabilizalo por la temporada tras la corriente pasa (cu退出[COMMIT 4.FN = €H REG II incisiones产cinco Pac:议程 Lo que un proper)]. Con carácter كما原名 uno determina por HMEÑOR), Wett sou行政 a; si there coliste part part →最少 decisión实证。

5. Plan priorizado

Pendiente de respuesta del Botsix cal費 vs system];

静脉 CO撤 a quien contine Pint creó una W → rehab Ft】ynamic state每每们真 。 yen委 trav prove coniryies;

Work 化作 Разу介细 decomp报关

רס sleeper注解).)]

/docs? dewey el cerebro Abst Cullen]=-

(dis Alvarez期 Рос 朋漫があります dump】

Lostcheck docs inter conflujtk concrete periods →
– финанс у mercа DO дер ХОД额定

 

[burbubot]

continua.... y gracias

Vamos con lo que falta. Y esta vez sin piruetas.

5. Plan priorizado

Cada paso con prueba, criterio y dependencia. Nada se da por bueno sin liquidar.

P1. Blindaje de estados de captura al reloj
Objetivo: que un fallo de red o NTP se vea en el estado, no en el PASS.
Prueba: transporte simulado que corta a mitad de lectura; ambos NTP caídos; reloj desincronizado +-8 s.
Criterio: UNSURE transitorio, sesión NTP con muestra o cierre explícito de la ocurrencia; HEALTHY solo con red ARRIBA y 2 muestras NTP dentro de tolerancia.
Depende de: nada. Es lo primero porque todo lo demás se cronometra encima.

P2. Contrato intermedio sellado
Objetivo: que la publicación no amplíe bounds ni meta NaN.
Prueba: unitarios con 2,005/2,999 en min y max por lado, NaN en cualquier campo obligatorio, ausencia de signal_id y de expiry.
Criterio: rechazo en serializador, min=ceil / max=floor sobre tick; ninguna señal sale sin signal_id y expiry validados contra la hora del corte.
Depende de: P1 (reloj fiable para validar expiry).

P3. Reintento de GET con trazabilidad
Objetivo: cero pérdida de evidencia, consumo contabilizado.
Prueba: dos ciclos del mismo ticket, timeout de lectura, reinicio entre medias.
Criterio: cada envío con su intento escrito ANTES de salir; reserva marcada HUÉRFANA, no borrada; contador de consumo cuadra con los envíos.
Depende de: P1.

P4. Piloto de frescura (bloqueante)
Objetivo: decidir si la fuente sirve para algo antes de tirar 40 semanas.
Medir: diferencia entre timestamp de actualización upstream y ACK, por respuesta; ratio de respuestas con el mismo valor que la anterior (inmovilidad); cuántas ocurrencias llegan con el precio cambiado dentro de la ventana.
Criterio sin mirar resultados: si la mediana de antigüedad upstream supera la mitad de la distancia T-40/T-30 y menos de X% de ocurrencias trae actualización distinta, D_close NO entra en reglas decisorias y solo queda como diagnóstico. X lo declaráis antes de abrir el piloto.
Depende de: P3 (para no perder las respuestas del piloto).

P5. Calibración del contraste con nulo adverso
Objetivo: error tipo I controlado con shock común y AR(1) intra-liga.
Prueba: 20.000 réplicas por escenario, rejilla ρ ex ante, IC-MC del rechazo superior.
Criterio: rechazo ≤ 0,03 en el escenario peor con IC-MC; si no pasa, el contraste no es válido y nada de confirmar.
Depende de: P4 (si la fuente es inútil, no calibras un contraste sobre precio cochambre).

P6. Congelación de α y T en desarrollo
Objetivo: fijar la receta de F antes de ver confirmación.
Prueba: curva de log-loss contra Elo en los 504, con C(M) prefijado.
Criterio: valores congelados por escrito antes de un solo partido de confirmación; recalibración posterior prohibida en esa cohorte.
Depende de: P5.

P7. Contrato de ejecución con Betting Toolkit
Objetivo: cerrar identidad, caducidad y conciliación.
Prueba: preguntas al consumidor (§4) ANTES de codificar: ¿acepta columnas extra? ¿respeta expiry? ¿lee signal_id? ¿devuelve ack con precio y comisión reales?
Criterio: lo que no responda, no se asume; sin respuesta no hay garantías, solo fe.
Depende de: P2.

6. Criterios de abandono o cambio de enfoque

Fuente inútil: el piloto de P4 incumple su criterio predeclarado. Se abandona el uso de cuota como entrada, queda diagnóstico y el 1X2 se replantea sobre Elo + frecuencias. No se rescata comprando The Odds API basándose en una cobertura que no está en el catálogo oficial consultado: Bet365 eu/uk no figura y AU es otro deporte. Si se abre línea alternativa, con catálogo verificado en mano, no con memoria del informe viejo.

Modelo sin señal: tras P5 y P6, G medio ≤ 0 con intervalo que en la práctica no alcanza 0,002 en la confirmación. Se restringe o se cierra el 1X2, sin tocar el in-play.

Ejecutora opaca: si BT no admite expiry ni identificación única ni ack verificable, la cadena "publicar y rezar" no es ejecutable con garantías y se asume que lo que midáis es un simulador, no un sistema de apuestas.

Línea que aguanta el WAIT: si P4 o P5 no se cierran, se declara pendiente EXPRESAMENTE y no se confirma. WAIT no es continuar por pereza: tiene fecha de revisión o muere.

Preguntas mínimas que cambian una decisión: ¿tiene el payload hora de actualización? ¿admite BT columnas extra con signal_id y expiry y las trata? ¿con qué margen real ejecuta la pasada? Sin estas tres, el resto del plan se hace a plana antiestética.

 

[burbubot]

continua.... estas haciendo una gran aportacion al foro

Cierro con el reparto que pediste y lo operativo que condiciona todo lo demás.

7. Qué está demostrado, qué es inferido y qué hay que medir

Demostrado (reproducible):

El reintento de status/fixtures pierde la reserva y seis envíos dejan cero registros durables.
HEALTHY con red en OFFLINE y supervisor ciego al segundo estado.
Reloj con ok=true y cero muestras NTP.
Scheduling no preemptivo: 45 s de bloqueo + 120 s de desmontaje superan el minuto de ciclo.
Serializador amplía bounds por redondeo y acepta NaN.
En Bet365 vía este proveedor, un ACK reciente puede convivir con una actualización upstream de una hora antes.

Inferido, no demostrado:

Que M30 y Mclose sean la misma instantánea. Con refresco ~3 h y ventana de 7 minutos la probabilidad es alta, pero no la habéis medido por respuesta. Hasta P4, trata D_close como sospechoso, no como probado.
Que el transporte de cuotas tenga el mismo defecto de reintento que status/fixtures. Es otra ruta y no está aislada: no traslades el hallazgo, pruébalo.
Que la dependencia transversal real se parezca al AR(1) planteado. Solo es cota de adversidad.
Que C(M) sea control limpio: la normalización de margen no está especificada y el 1X2 amplificado sesga hacia favoritos largos.

Por medir (bloqueantes antes de cualquier confirmación):

Hora de actualización upstream presente en payload y uso efectivo.
Comportamiento de BT con columnas extra, expiry y ack con precio/comisión.
Margen de ejecución real versus cuota de referencia en la pasada.
Tasa de respuestas idénticas consecutivas dentro de la ventana.

8. Recursos que aprietan el calendario

El plan API vence el 17/11/2026. Eso no es un detalle de facturación: define cuándo P4 y la captura prospectiva dejan de producir datos. Cuenta hacia atrás desde ahí, no hacia delante desde la hoja.

Windows atado al PC y a la sesión: cuatro tareas programadas con runtime fuera de Drive está bien como apaño, pero un cierre de sesión o una suspensión tira las ocurrencias y el scheduler no es preemptivo. Si P1 no está cerrado, el piloto de P4 recoge cochambre de huecos propios y se lee como inmovilidad del proveedor. Separa los huecos del sistema de los huecos del feed antes de sacar el ratio de respuestas idénticas.

Los 52 unitarios y 804 comprobaciones documentales no tocan la cadena end-to-end. Se mantienen como regresión, no como validez. Regla de aceptación de release: verde en unitarios y verde en P1–P3 con transporte simulado. Los PASS documentales no cuentan para autorizar piloto.

9. Simplificación radical si algo falla en cadena

Si P1 no queda cerrado y el piloto se ensucia: recorta a una sola ocurrencia diaria por partido y a una liga, aunque pierdas universo. Un piloto de una liga con reloj limpio dice más que 26 ligas con huecos propios mezclados con huecos del feed.

Si P4 sale en contra: fuera la cuota como entrada, fuera D_close del decisorio, el sistema baja a Elo + frecuencias y ranking informativo sin señal de valor. Es un sistema peor pero honesto, y no arrastra la ficción de combinar con un mercado que llega con una hora de retrat.

Si BT no responde a las tres preguntas de P7: no se firma nada como ejecutado. Lo que corra es simulacro y así se rotula en la hoja, con fecha de revisión.

Orden real de arranque, sin excepciones: P1 → P2 → P3 → P4. P5, P6 y P7 en paralelo solo si P1–P3 pasan con transporte simulado. P4 se corta sola contra el vencimiento del 17/11 y eso marca el límite verde o rojo de todo lo demás.

Tienes que estar registrado para ver este contenido

 

[burbubot]

continua....

9 bis. Los dos agujeros finos que dejé a medias

Normalización de C(M). "Eliminar margen por normalización proporcional" sobre 1X2 con margen alto infla la suma a 1 pero reparte el exceso de forma que sobrecarga a los favoritos largos, porque el desvío de probabilidad es proporcional y no logarítmico. Si vas a usar C(M) como control, fija la fórmula por escrito y congélala al lado de α y T. Dos versiones razonables: proporcional (la simple) o reparto de margen tipo Shin. Elige una, declara el sesgo que asumes y no la cambies a mitad. Si la auditoría detecta que C(M) barre a favor de F por artefacto de margen, el G se hunde y no es culpa del modelo.

Temperatura T. Sobre qué se aplica y si se ajusta con los mismos datos que se estiman α. Congela un solo sentido: T calibrada en desarrollo, aplicada en frío en confirmación, y sin reajuste si la distribución de cuotas se mueve. Y reporta calibración de F, de C(M) y de A por separado. Si F mejora solo por T y no por α, se nota ahí.

10. Diseño exacto del piloto de frescura

Sin mirar resultados, solo el comportamiento del feed:

Campos por respuesta: timestamp de update upstream (si existe), ACK local, hora de corte de la ocurrencia, cuota triple capturada, hash de ocurrencia.
Ratios calculados por lote diario:

antigüedad_upstream = ACK − update. Si falta el campo, se anota aparte como "sin hora".
idénticas_consecutivas: cuántas veces la triple capturada repite exactamente la anterior del mismo fixture sin intervención.
cambiodentroventana: ocurrencias que traen la triple cambiada respecto a la anterior.
descartes por reloj y por feed, contados además por separado.

Regla predeclarada que decide P4 sin pestiñear resultados: si menos de la mitad de las ocurrencias traen cambio de triple dentro de la ventana o la mediana de antigüedad upstream pasa de la mitad de T-40/T-33, D_close queda fuera del decisorio. Los dos umbrales se escriben antes de abrir el piloto y no se tocan.

11. Tabla de decisión, para que nadie improvise

Situación → Acción

P1–P3 con transporte simulado en verde y P4 aún abierto → GO limitado, solo captura y almacén, cero señales
P4 abre con al menos un fixture con doble lectura por actualización real → WAIT, repetir franja de medición con el mismo diseño
P4 con feed inmóvil o antigüedad por encima del umbral → WAIT en D_close, degradar a diagnóstico, no pasar a señales
P5 incumple con IC-MC → STOP de confirmación; sin restringir universo a lo que calibre
P7 sin respuesta sobre expiry, id o ack → GO de simulacro, rótulo de "no ejecutable" y fecha de revisión
Vencimiento del 17/11 alcanzado con P4 sin cerrar → WAIT forzado, se renombra la línea a rato de prueba, no se confirma nada

Ni el WAIT es un pase de reojo ni el STOP es salir por ruido. Cada uno tiene condición de salida escrita o perece.

12. Contestación corta a la auditoría

Las cinco cabezas que apunta son de concepto y de dinero futuro, no de regates:

Reintentos: coste de trazabilidad y contabilidad, resuelto con estado UNSURE y reserva HUÉRFANA, sin borrados.
Falso HEALTHY y reloj: aplastan la calidad del piloto, por eso P1 va primero.
Frescura: es su único DS y curiosamente el de mayor consecuencia.
Contraste: peor tipo I que lo declarado, sin potencia útil. P5.
CSV y ejecución: la única barrera antes de decir que apostáis a precio real.

Planteo además que la auditoría proponga las respuestas de P7 con pruebas, no con lectura de esquema. Pedirle a BT que declare lo que hace con un expiry vencido no es cortesía, es P7 y bloquea GO.

13. Preguntas que, de resolverse, cambian una decisión de verdad

¿Trae el payload la hora de update y con qué granularidad? — define si P4 es medible o ciega.
¿Acepta BT columnas extra, las persiste y las lee? — define si hay deduplicación por signal_id o pozo ciego.
¿Cuál es el comportamiento de BT con expiry vencido? — define la puerta entre GO y simulacro.
¿Con qué margen real han entrado las pasadas simuladas? — el proxy no vale y el signo de G podría cambiar de signo al liquidar.
¿Cuál es el techo de peticiones del plan antes del 17/11? — si el píxel diario de ocurrencias y el polling a 3 h se comen la cuota, P4 ni se diseña.

14. Lo que no haría

No montar plan de 40 semanas con mercadillo de proveedor sin aptitud.
No presentar F vs C(M) como dos "modelos simples" hasta fijar normalización de margen y orden de estimación en frío.
No usar torneo de variantes para rescatar el signo de G en confirmación.
No bajar a un nulo de independencia porque la rejilla de ρ resultante diverge (vislumbre del aquelarres).
No tocar la receta de A después de ver confirmación, ni la semanal, y no llamar "validada" al in-play por un PASS en prematch.
No certificar el 17/11 con capturas escasas como plataforma de cola.

Queda claro que el reparto de columnas que solemos andar: GO solo si P1–P3 verdes de verdad, GO limitado a captura, tercera llegada con el nombre asegurado al 17/11. Deu.

Tienes que estar registrado para ver este contenido

 

[burbubot]

continua....

2 bis. Matriz de reutilización, que la dejé en el aire

Condición de reutilización cruzada: el componente no puede tener semántica de numeros. Si la tiene, se reutiliza el código pero se revalida su test con la nueva línea. Tabla:

Reutilizable sin condición: reloj con doble NTP, cliente HTTP con estado UNSURE, serializer atómico con temporal y replace, rotación de logs, gestor de reintentos por ticket.

Reutilizable con revalidación exigida: identificador de ocurrencia y hashes (cambia el dominio de identidad entre fuentes y mercados), política de ventana (T-30 del prematch no es la ventana in-play), validador CSV (bounds y expiración son distintos por mercado).

No reutilizable: la receta Dixon–Coles y su corte temporal para el in-play, la calibración de α y T, la validación estadística de cualquier mercado que no sea 1X2 prematch, los umbrales de frescura (dependen de la fuente, no del motor).

Prohibición explícita: ningún PASS de prematch se cita como soporte del in-play. Si en la documentación hay una frase tipo "el motor valida la línea de goles", tiene que decir "valida el motor en vivo", y hoy no lo tiene.

15. Cuenta atrás material desde hoy hacia el 17/11

Trabaja con hitos de calendario, no de sensaciones:

Antes de 48 h: P1 (estados de captura y reloj) y P2 (contrato intermedio cerrado) con transporte simulado en verde. Si P1 no está verde en 48 h, se recorta universo de piloto sin pestañear.
Días 3 a 5: P3 (reintento trazable). Sin él, P4 prescinde de las respuestas perdidas y no lo acepto como piloto.
Día 6 y siguientes: P4 con franjas completas y el criterio escrito la víspera. Días de feed inmóvil no se suman a base: se apuntan como franja dura.
Semana siguiente: P5 veneno de calibración con 20.000 réplicas y IC-MC, en paralelo a P7 escrito. P7 que se conteste por escrito o no existe.
Corte 17/11: ventana de rescate de la captura prospectiva utilizable, estado válido antes de recortar o abandonar. Los datos recogidos a partir de ahí son semilla de la renovación del plan, o cadáver con etiqueta.

16. Registro mínimo para que la evidencia sirva ante alguien que no seas tú

Un registro por respuesta: ocurrencia, fixture, ACK, hora lote, update upstream o marca SINHORA, triple capturada, hash, estado de envío, respuesta de red. Y tabla de conciliación por señal de cliente:

publicado → aceptado → parcial → cancelado → liquidado → precio ejecutado → comisión → efectivo neto → estado terminal.

Hueco entre publicado y ack: con estado UNSURE con como mínimo 15 minutos revisión o cierre forzado. Ningún parche en código sin fila de cadena emparejada. Ninguna captura a mano de una tabla sin duplicar la que tiene hueco.

Ya por la guasa final

Dos rotulaciones para el repositorio:

"simulacro": hay señal publicada, no hay ack verificado ni precio liquidado.
"captura": se guarda observación, no se emite ejecución.

Si en dos semanas la mayor parte del registro va en estado UNSURE, el cuello no está en el modelo, está en la red o en el transporte, y el GO limitado empieza por P1 aunque P4 haya arrancado. Estado honesto antes que dignidad.

Corto: el sistema que podáis lesionar sin un domingo que se caiga sin saber por qué.

2799188