Registro de cambios

Aquí se documentan todos los cambios relevantes de Kshana.

El formato se basa en Keep a Changelog, y este proyecto sigue el Semantic Versioning. Mientras el proyecto esté en una versión anterior a 1.0, el esquema público de escenarios y resultados todavía puede cambiar; los cambios incompatibles se señalan de forma explícita.

Sin publicar#

[0.40.0] - 2026-10-29#

0,40 añade el hilo de misión de clase Artemis y su segmento lunar, una etiqueta de evidencia en cada figura y tabla que escribe una ejecución, la ingesta y el ajuste de relojes medidos, una comprobación de envíos de socios de datos, una región estimada del emisor a partir de informes ADS-B o AIS, la recampaña del benchmark de 0,40, y la línea de comandos, los informes y Studio en diecisiete idiomas además del inglés (los documentos de máquina siguen en inglés). La matriz de verificación pasa de 388 a 401 filas: 176 VALIDATED (sin cambios), 221 MODELLED (antes 208) y 4 PARTNER. Ninguna fila se promovió a VALIDATED. Los tipos de escenario pasan de 87 a 92. Cada umbral que una comparación preregistrada no alcanzó se indica a continuación y sigue fijado; ninguno se relajó. La declaración de carácter consultivo no cambia: Kshana es un software de carácter consultivo, no un equipo de navegación homologado ni una certificación; el operador sigue siendo responsable.

Límites conocidos#

• Las ejecuciones en idiomas distintos del inglés tardan aproximadamente el doble, porque el escenario se ejecuta dos veces (una en inglés para los archivos de máquina y otra en el idioma elegido para la persona).
• Algunas frases de Studio se componen a partir de fragmentos y pueden carecer de artículos en los idiomas que tienen género gramatical.
• Las traducciones son traducciones automáticas que ningún hablante nativo ha revisado; el inglés es la referencia.

Añadido#

• Diecisiete idiomas además del inglés para el texto del motor dirigido a las personas y para el sitio y Studio: nl, pl, pt-BR, pt-PT, fi, sv, da, nb, cs, uk, ru, de, fr, es, et, ja, zh-Hans (--lang, KSHANA_LANG, las variables de configuración regional; lang en las llamadas de la biblioteca, de Python, de WebAssembly y de MCP). Se traducen los mensajes y errores de la línea de comandos, los resúmenes de ejecución, el texto de los gráficos, report.html, las descripciones de los tipos de escenario y las advertencias de carácter consultivo; los documentos de máquina (JSON, CSV, códigos de error, la matriz de verificación) siguen en inglés, y una ejecución en un idioma distinto del inglés ejecuta el escenario una vez en inglés para los archivos de máquina y otra vez en el idioma elegido para la persona (docs/i18n.md). Las traducciones son traducciones automáticas, no revisadas por hablantes nativos; el inglés es la referencia; el REVIEW.md de cada idioma enumera qué debería comprobar primero un revisor, y las páginas del sitio llevan un aviso que lo indica. Las palabras de veredicto, los niveles de evidencia y el alcance de carácter consultivo («no homologado», «no una certificación», «el operador sigue siendo responsable») se mantienen en todos los idiomas.
• kshana interference-map locate: una región estimada del emisor a partir de informes ADS-B o AIS. Una distribución a posteriori de dónde puede estar una fuente de informes de posición degradados (línea de visión radioeléctrica con un radio terrestre de 4/3, altura de la antena del emisor y potencia marginalizadas, las aeronaves afectadas que atraen y las no afectadas con línea de visión que empujan en sentido contrario), escrita como regiones al 50, 90 y 95 %, un centroide con su elipse de incertidumbre (nunca un punto aislado), sesiones en el tiempo (inicio, final, duración, área afectada, aeronaves distintas por encima del mínimo de publicación), un perfil de la hora del día y las horas por día, con fusión opcional de una posición TDOA de geolocation. Salidas: GeoJSON, resumen JSON, CSV de sesiones y una figura SVG, cada una con la licencia, la atribución, el identificador del método, los supuestos, los límites y su etiqueta de evidencia. Biblioteca interference_map::api::emitter_regions_from_*, Python y WebAssembly interference_emitter_regions. MODELLED (fila del registro VM-bc70cb57; la matriz tiene ahora 401 filas, 176 VALIDATED, 221 MODELLED, 4 PARTNER); calibrada solo con datos sintéticos, con la comparación frente a los emplazamientos de transmisores de Jammertest 2025 preregistrada y ejecutada una vez: ADS-B y AIS ambos NOT ASSESSABLE (demasiado pocas sesiones programadas en los datos abiertos), de modo que la fila sigue siendo MODELLED (docs/emitter-region/RESULTS.md). Redacción neutra, solo agregados; la publicación de regiones de emisores en el observatorio público sigue desactivada. Hay un ejemplo sintético en examples/emitter-region/ (docs/INTERFERENCE-MAP.md).
• Registros de reloj medidos. src/clock_log.rs lee un registro de reloj medido como una única serie de fase: ocho formatos (RINEX clock, TimeLab, TICC, linuxptp ptp4l, phc2sys y ts2phc, seguimiento y estadísticas de chrony), cada uno un subconjunto documentado; todo lo que quede fuera se rechaza con un error que indica lo que se encontró. Lo usan telecom-timing ([series.clock_log]) y el tipo de escenario de reloj ([clock_log], que añade un bloque measured con el SHA-256 del registro y las ADEV, TDEV y MTIE superpuestas), con el escenario incluido clock-measured-log (docs/CLOCK-LOG-FORMATS.md). Comparado con allantools sobre datos públicos reales frente a umbrales preregistrados: la primera ejecución no alcanzó B1 (5 de 11 casos, todas las marcas de tiempo de TICC conservadas como f64), B2, B3 (7 de 24 casos) y B4 (no se comprobaba la versión de la cabecera); tras las correcciones se alcanzan B1, B3 y B4 y se alcanza B2 salvo un par de MTIE, que queda fijado y no es un defecto del motor (allantools 2024,6 elimina la frecuencia media antes de integrar; frente a su MTIE en modo de fase el motor coincide dentro de 1e-10). La fila sigue siendo MODELLED (tests/fixtures/clock_log_real/RESULTS.md).
• Un holdover conducido por una serie medida ajustada: el [clock_fit] del tipo de escenario de reloj ajusta el ruido de una serie medida y conduce el holdover a partir de ella (src/clock_fit.rs, escenario incluido clock-fitted-log). Comparación preregistrada: F1(b), F3 y F4 alcanzados; F1(a) (recuperar el FM de paseo aleatorio registrado) NOT MET en los registros C3 (no identificable por construcción) y en dos de tres registros C4 (el FM de paseo aleatorio queda absorbido por el FM de flicker y la deriva); F2 (identificación del ruido frente a allantools) alcanzado en once de doce registros y en D3, y NOT MET en D2 tal como se registró (alcanzado en comparación equivalente). Todos los fallos quedan fijados (tests/clock_fit_known_noise.rs); el bloque fitted y el holdover conducido por él siguen siendo MODELLED (tests/fixtures/clock_fit/RESULTS.md).
• La recampaña del benchmark de 0,40, preregistrada con la aprobación del propietario antes de cualquier ejecución: A3 (EXPLORATORY, el AUC por bootstrap agrupado por carpetas de agc_k_sigma, cuantil del 2,5 % 0,8502 frente a 0,80), D3 (EXPLORATORY, tres de cinco detectores superan una brecha de optimismo de 0,05 a escala 0,25), R3 (AUC 1,0) y R4 (P_fa 0,0, P_d 1,0): todos MET, todos MODELLED. A2, D1 y R1 no se tocan y siguen NOT MET; nada de aquí los cierra (xval/bench/RESULTS-0.40.md, Bench).
• kshana partner check <submission.toml>: comprueba el formato y los metadatos de un envío de un socio de datos (kshana.partner-submission/1: dispositivo, archivo de datos y SHA-256, cómo se tomaron, las filas MODELLED frente a las que se ofrece, licencia, declaraciones) y lee los datos con los lectores propios del motor de registros de reloj o IMU. No puntúa nada y no valida nada. Hay un ejemplo sintético en examples/partner-submission/.
• docs/PARTNER-DATA.md: qué filas MODELLED del registro podrían promover los datos medidos, los formatos admitidos, cómo se comprueba un envío, se puntúa frente a un umbral preregistrado y se acredita, y qué significan PARTNER y VALIDATED; una nota de contacto en borrador para el propietario en docs/drafts/PARTNER-OUTREACH.md (no se envía nada).
• Segundas campañas para los umbrales no alcanzados de gnss-ssv y lunar-infrastructure, ejecutadas tal como se preregistraron (xval/gnss-ssv/PREREGISTRATION-v2.md, xval/lunar-infra/PREREGISTRATION-v2.md; aprobadas antes de cualquier ejecución). Cada fallo original sigue NOT MET y fijado. gnss-ssv: el control reproduce la ejecución 1 celda por celda; cinco ablaciones de una sola lectura llevan 2 de las 78 celdas no alcanzadas dentro de la tolerancia (EXPLORATORY, sin umbral); el nuevo umbral S7b (una forma de transmisión con caída y piso ajustada en paneles Classic IIR) es NOT MET en los paneles IIR-M con 3,83 a 3,95 dB frente a 3 dB; la campaña de recepción publicada reservada no se ejecutó (no había ninguna fuente fijada) (xval/gnss-ssv/RESULTS-v2.md). lunar-infrastructure: los nuevos umbrales C3a, C3b (un límite de detección de aproximadamente 3e-9 m/s2), Q3a, Q3b (una CDF normal precisa elimina la diferencia de 1.7e-6) y G3'' se alcanzan como umbrales propios, y G3' con distribuciones a priori ilustrativas se alcanza y se etiqueta EXPLORATORY (xval/lunar-infra/RESULTS-v2.md). Todo sigue siendo MODELLED. Nuevos elementos públicos: kshana::lambda::{erfc_accurate, normal_cdf_accurate, bootstrap_success_rate_accurate}.
• Una etiqueta de evidencia en cada figura y tabla que escribe una ejecución. El JSON de resultados tiene una clave evidence, el SVG del gráfico un elemento de metadatos y una línea bajo el trazado, y la tabla CSV líneas de comentario # evidence:: el nivel (VALIDATED, MODELLED o PARTNER, el más débil de las filas) y los identificadores de las filas de la matriz de verificación en que se apoya la ejecución. Las filas y los estados se leen de la matriz, no se escriben a mano; los identificadores son estables (VM- y ocho dígitos hexadecimales, una nueva columna ID en docs/VERIFICATION-MATRIX.md, una lista congelada en tests/fixtures/evidence_ids.txt). También en receiver-trust, jammertest score, iq acquire/sweep/track/monitor, el informe de exposición de la ruta y, dentro del config.json firmado, cada paquete de evidencias (config_version 1,1; kshana evidence verify informa del nivel; los paquetes creados antes de 0,40 se verifican sin cambios). tests/evidence_labels_doc_sync.rs falla si una figura no tiene etiqueta, si una etiqueta discrepa de la matriz o si un nuevo escritor de archivos ni está etiquetado ni figura en la lista con un motivo. Las salidas que no llevan ninguna figuran en docs/SURFACES.md. Los tres gráficos de demostración del README se volvieron a generar con la etiqueta (quitarla restablece los bytes anteriores; docs/revisions/STUDIO15-evidence-label-0.40.md). Ninguna afirmación cambió.
• El tipo de escenario mission-thread (scenarios/mission-thread-artemis-class.toml, docs/MISSION-THREAD.md): el presupuesto de errores de navegación y temporización de una cadena de fases desde el lanzamiento hasta la entrada, con cada número MODELLED y cada entrada indicada. Ocho tipos de fase: launch-ascent, leo-rendezvous (covarianza relativa de Clohessy-Wiltshire a lo largo de tramos de sensor, ventana de acoplamiento), tli-and-cruise (propagación de Cowell con una matriz de transición de estado por diferencias finitas, error de maniobra, actualizaciones de gnss-ssv y de seguimiento terrestre, la Luna a partir de un recorte opcional del kernel DE440), entry (sigma del ángulo de trayectoria de vuelo, probabilidad de corredor, deceleración máxima en los bordes del corredor, huella de aterrizaje) y los cuatro tipos de escenario lunares. Reglas de traspaso (carry, inflate, reacquire), conversiones de marco y de escala de tiempo como filas de presupuesto propias, una superposición opcional de la red terrestre que fija el ciclo de seguimiento de cada fase, el margen frente a los requisitos indicados y el eslabón más débil. El ejemplo sigue la secuencia de una presentación pública de concepto de operaciones de la NASA con números ILLUSTRATIVE: un ejemplo de extremo a extremo de clase Artemis en 11 fases, con segmentos terrestre y lunar. La propagación cislunar se comparó con la trayectoria pública de Artemis I a lo largo de un arco de 72 h frente a un umbral fijado en xval/mission-thread/PREREGISTRATION.md antes de la ejecución: NOT MET (45,3 km y 0,25 m/s frente a 5 km y 0,05 m/s). El diagnóstico sitúa el fallo en cinco pequeños eventos impulsivos de la referencia; entre ellos, el modelo de fuerzas reproduce los estados horarios con una mediana de 0,4 m. La fila sigue siendo MODELLED (xval/mission-thread/RESULTS.md).
• El segmento lunar del hilo de misión de clase Artemis: cuatro tipos de escenario, cada uno también un tipo de fase de la interfaz mission-thread (src/mission_thread/lunar/), todos MODELLED.
  • lunar-orbit-rendezvous: navegación relativa hasta el acoplamiento en una órbita polar circular de 100 km o en una elíptica polar de 100 km por 3000 km (scenarios/lunar-orbit-rendezvous.toml, ...-elfo.toml). Una estimación por lotes de Gauss-Newton a lo largo del arco fusiona una posición absoluta por vehículo a partir de un conjunto ilustrativo de relés de clase LCNS, un error persistente de la señal en el espacio (común a ambos vehículos e independiente) y una distancia de enlace cruzado, bajo el modelo de fuerzas lunar del crate. Informa de la posición y la velocidad relativas en los ejes locales del objetivo, la disponibilidad de posiciones, el error de estimación normalizado cuadrático medio frente a su valor esperado, el coste de ignorar los armónicos de gravedad, los modelos de sensor relativo terminal junto a la cifra solo de señales, y la covarianza de 6x6 transmitida.
  • lunar-descent: el presupuesto de dispersión de aterrizaje en un emplazamiento polar sur (scenarios/lunar-descent.toml; lunar-descent-lola.toml lee el DEM de LOLA desde una copia del repositorio): un modelo de error inercial de cinco estados por eje, una posición AFS (autónoma o diferencial, usando el residuo del enlace de corrección de lunar-differential-pnt), una posición relativa al terreno (el correlador terrain-nav sobre su relieve sintético, o la cota de Cramer-Rao de correlacionar el DEM de LOLA) y la hora lunar a través del reloj del vehículo (lunar-time-offset). Informa de la elipse de aterrizaje de 3 sigma, de cada combinación de ayudas y de una calibración Monte Carlo de la elipse.
  • lunar-surface: disponibilidad de posicionamiento y temporización por emplazamiento y estación (scenarios/lunar-surface.toml; lunar-surface-terrain.toml añade el horizonte de LOLA trazado por rayos): la cifra de posicionamiento de un solo emplazamiento es igual a la de moonlight-service-volume bit a bit; lo que varía con la estación es la visibilidad de la Tierra y del Sol según las efemérides analíticas.
  • lunar-ascent: el ascenso a la órbita de encuentro y la covarianza de posición y velocidad transportada de vuelta a la órbita (scenarios/lunar-ascent.toml), con la dispersión al corte del motor informada junto a ella.
  • docs/MISSION-THREAD-LUNAR.md; el preregistro, sus enmiendas y cada resultado, fallos incluidos, en xval/mission-thread-lunar/.

Evidencias#

• Preregistrado en xval/mission-thread-lunar/PREREGISTRATION.md antes de cualquier ejecución, con seis enmiendas fechadas (cada una hecha antes de obtener los datos, salvo la enmienda 6, que corrige un error aritmético en un recuento de estados después de la obtención y antes de cualquier resultado de A2; cada enmienda se declara en el archivo). Ningún umbral se relajó.
• A1 (el propagador frente a la trayectoria reconstruida de LRO de JPL Horizons, 24 h): MET, una diferencia 3D máxima de 33 m frente a un umbral de 500 m y una diferencia radial RMS de 2,4 m frente a 60 m.
• A2 (el mismo propagador frente a la NRHO de CAPSTONE a lo largo de una revolución de 6,5 días): NOT MET, una diferencia de posición final de 136,8 km frente a un umbral de 25 km y una diferencia del radio osculador del periapsis de 28,4 km frente a 10 km. La fila sigue siendo MODELLED, y el fallo queda fijado por tests/mission_thread_lunar_oracles.rs.
• B1 (la consistencia de la estimación de encuentro con su propio modelo) es MET con el cuarto diseño de estimador, NEES medio de 5,85 a 5,93 frente a una banda de [5,2, 6,8]; los tres diseños anteriores, un filtro de Kalman extendido en tres variantes, no la alcanzaron. Un quinto cambio, hecho tras descubrir que el escenario de 2 h incluido enviaba 4 de 50 pruebas a un mínimo local (NEES medio 1e9), ejecuta el ajuste de Gauss-Newton sobre un arco creciente con reducción de paso a la mitad; B1 no cambia por ello y los escenarios incluidos dan 6,51 y 6,33. El historial está en xval/mission-thread-lunar/RESULTS.md.
• Nada de aquí es VALIDATED: las filas de referencia independiente prueban el propagador compartido, no un filtro de navegación, una señal ni un presupuesto.

[0.39.0] - 2026-10-22#

Sin funciones nuevas: una corrección en la línea de comandos, actualizaciones de dependencias en las herramientas de validación cruzada y documentación. Los resultados del motor no cambian respecto a 0.38.0.

Corregido#

• La línea de comandos termina en silencio con el estado 141 cuando se cierra su salida estándar (kshana kinds | head), en lugar de entrar en pánico con "failed printing to stdout: Broken pipe". 141 es 128 más SIGPIPE, el estado que informa un shell para yes | head. Solo se trata una tubería cerrada: un disco lleno o cualquier otro error de escritura sigue informando de sí mismo, y un flujo en vivo que escribe en un socket cerrado sigue recibiendo su error de escritura. tests/cli_closed_pipe.rs cierra el lector antes de que se inicie el programa, de modo que la primera escritura falla en cada ejecución.

Seguridad#

Una actualización de dependencia en la biblioteca distribuida (la primera entrada), el resto en las herramientas de validación cruzada (xval/).

• p256, p384 y p521 0,13 a 0,14 (con elliptic-curve 0.14.3, ecdsa 0.17.0 y crypto-bigint 0.5.5 a 0.7.10; también la dependencia directa crypto-bigint, ahora 0,7) resuelven RUSTSEC-2026-0387, una variabilidad de tiempo de ejecución en crypto-bigint 0.5.5. Kshana usa estos crates solo para verificar firmas públicas (la clave raíz de Galileo OSNMA y los tokens de sello de tiempo RFC 3161) y solo firma en pruebas con claves desechables, así que la exposición práctica era nula; la actualización elimina el aviso sin una entrada de exclusión. Los archivos de bloqueo de la biblioteca y del MCP cambian los dos; ningún resultado de verificación cambia (las pruebas de vectores de OSNMA y de sello de tiempo pasan sin cambios).
• La versión mínima compatible de Rust es ahora 1,88 (exigida por la corrección de RUSTSEC-2026-0387).
• memmap2 0.9.10 a 0.9.11 (RUSTSEC-2026-0186) en los bloqueos de la comprobación cruzada con ANISE (xval/anise-lunar-od, xval/anise-mars-od); los bloqueos también resincronizan la dependencia de ruta kshana del propio repositorio.
• pillow 12.3.0 a 13.0.0 y certifi 2026.7.22 a 2026.10.19 en las versiones fijadas del entorno de referencias independientes (xval/oracles/requirements.lock, requirements.frozen.txt): las versiones corregidas para ocho avisos de pillow y un aviso de certifi.

Documentación#

• docs/BENCH.md, el README y este archivo listan cada umbral de kshana-bench que es NOT MET, tal como consta en xval/bench/RESULTS-v2.md: A2 (AUC de agc_k_sigma 0,766 frente a al menos 0,80 en la partición de prueba), D1 (mayor brecha 0,0301) y tarea (b) R1 (arrastrado, no se volvió a ejecutar). No se ha relajado ningún umbral.
• Revisión de integridad del README: una lista de contenidos; los tipos de escenario archivados por familias, cada uno con una página bajo docs/kinds/by-kind/ (la descripción y los campos del motor, las entradas y los resultados de una ejecución de ejemplo, las filas del registro y las referencias independientes, las limitaciones que indica el informe de la ejecución y el gráfico que escribe el motor), una hoja de contactos por familia, todo indexado por docs/KINDS.md; cada comando en docs/COMMANDS.md; cada superficie, comando de plugin, skill y página de Studio en docs/ALL-SURFACES.md; cada dominio de capacidad en docs/CAPABILITY-DOMAINS.md; diagramas Mermaid incrustados (visión general del sistema, superficies, bucle interno, confianza del receptor, ida y vuelta de laboratorio, Studio, flujo de pruebas y publicación, mapa de módulos, distribución). Escrito por tools/gen_kinds_index.py, tools/gen_readme_blocks.py y tools/gen_figures_038.py; auditado por tools/readme_audit.py; protegido por tests/readme_completeness_doc_sync.rs, que además fija la descripción y los campos de cada entrada al motor.
• tools/render-diagram-chromium.sh: renderiza un diagrama Mermaid a SVG y PNG en Linux y actualiza el registro de renderizado.
• README: las figuras de usuarios espaciales y lunares usaban rutas relativas a docs/, por lo que no se cargaban desde el README; un enlace apuntaba a ../../docs/JAMMERTEST.md.
• Se eliminaron dos archivos de gráficos obsoletos copiados a mano (docs/assets/clock-ensemble-band.svg, sweep-clock-stability.svg) que ninguna página usaba y que ya no coincidían con el motor; docs/KINDS.md contiene los gráficos actuales.

[0.38.0] - 2026-10-19#

Añadido#

• GNSS más allá de la constelación (gnss-ssv). Un nuevo tipo de escenario para naves espaciales por encima, alrededor y más allá de las órbitas GNSS (docs/SSV.md): disponibilidad de una y de cuatro señales, duraciones de interrupciones, C/N0, DOP y enlaces de lóbulo principal frente a lóbulos laterales para GPS, GLONASS, Galileo, BDS, QZSS y NavIC en una capa o a lo largo de trayectorias LEO, MEO, GEO, HEO y de transferencia lunar; patrones de transmisión del folleto, paramétricos o aportados por el usuario; un modelo de ionosfera, plasmasfera y atmósfera con rayo rasante; un diseño de receptor de señal débil; un filtro de Kalman extendido GNSS a bordo para HEO y transferencia lunar; y navegación relativa de formación. Comparado con el folleto del Space Service Volume del ICG bajo un preregistro confirmado antes de la ejecución: las constantes de potencia mínima radiada y el umbral lunar coinciden, los demás umbrales no se alcanzan según la lectura preregistrada (casi todos por el ángulo de haz inconsistente de GLONASS en el folleto), y el sustituto paramétrico de lóbulos laterales no reproduce los patrones medidos de los paneles GPS. Todo sigue siendo MODELLED (xval/gnss-ssv/RESULTS.md).
• Órbita y superficie lunares como infraestructura de navegación y geodésica (lunar-infrastructure). Un nuevo tipo de escenario con cinco estudios seleccionados por study (docs/LUNAR-INFRASTRUCTURE.md): coherencia de una determinación de órbita GNSS terrestre a bordo en una órbita de halo casi rectilínea frente a una determinación independiente de distancia y velocidad de distancia desde tierra; fase de portadora de doble diferencia conjunta de estación de superficie y orbitador con fijación de enteros mediante LAMBDA; información de Fisher del datum lunar de siete parámetros con y sin distancias entre orbitador y superficie; desfases entre técnicas GNSS, VLBI y telemetría láser frente al vínculo local; y sensibilidad a h2, k2, l2 y a la libración física. MODELLED, con entradas ILLUSTRATIVE: la numérica se comprueba con programas independientes de numpy y scipy, y nada se compara con una medición de una magnitud lunar. Los umbrales se fijaron en xval/lunar-infra/PREREGISTRATION.md y dos enmiendas declaradas. Tres son NOT MET y cada una está fijada por una prueba que afirma el fallo: C3 (un error de fuerza inyectado no se detecta a la tasa preregistrada), Q3 (la tasa de éxito con bootstrap difiere de la referencia independiente de numpy en 1.7e-6 frente a un umbral de 1e-9, por la aproximación de la CDF normal de LAMBDA) y la mitad de traza de G3 (añadir una familia de distancias no siempre reduce la traza de la pseudoinversa). Los demás se alcanzan (xval/lunar-infra/RESULTS.md).
• Un sexto artículo en la tabla de investigación. "Cislunar navigation is an observability problem: arc-length thresholds, Gramian conditioning, and the Doppler lever" (arXiv:2610,23871, eess.SP) muestra que la dilución de la precisión no está definida para el seguimiento cislunar solo por distancia y utiliza en su lugar el gramiano de observabilidad sobre cuatro órbitas retrógradas distantes planas: solo con distancia el rango es 2 de 4 en una instantánea y requiere un arco de unas 2,09 h, la velocidad de distancia (Doppler) da rango 4 al instante, y co-estimar una estación con los estados de los satélites y los relojes sigue siendo deficiente en rango por uno sin un observable interferométrico externo. Sus cifras las regenera el tipo de escenario cislunar-observability (kshana scenarios/cislunar-observability.toml); cislunar-arc-recovery prueba el umbral con un estimador independiente. La tarjeta de investigación del README, los README de crates, npm y PyPI y el generador lo incluyen.
• El árbitro neutral, hecho medible. kshana jammertest import lee el catálogo de ensayos y el plan de transmisión publicados de NPRA Jammertest como verdad programada (identificadores del catálogo conservados) y kshana jammertest score puntúa un registro de receptor frente a él por ensayo (latencia de detección, alarmas omitidas, falsas alarmas, tiempo de recuperación), opcionalmente como paquete de evidencias firmado (docs/JAMMERTEST.md). Los umbrales de puntuación se preregistraron antes de cualquier ejecución puntuada (xval/jammertest-score/). En el conjunto de datos de JammerTest 2024 (obtenido, nunca incorporado al repositorio), la regla preregistrada de datos mínimos falló tanto en la primera ejecución como en la revisión del tratamiento de datos, de modo que ningún umbral es evaluable y no se afirma nada; ambas ejecuciones están registradas y fijadas. MODELLED: el calendario son las ventanas registradas del conjunto de datos, no horas de emisión grabadas. El conjunto NMEA de SimulaMet de 2025 no se adapta (su página no indica ninguna licencia).
• Los propios indicadores del receptor, junto a los de Kshana. UBX-NAV-STATUS spoofDetState y UBX-SEC-SIG se leen en self_report en cada época, y la comparación receiver_self_report del resultado los contrasta con los monitores de Kshana (ambos, solo el receptor, solo Kshana, ninguno); no genera ninguna alarma ni cambia ninguna puntuación. Se suman un lector SBF de Septentrio (PVTGeodetic, MeasEpoch, RFStatus, solo lectura, sobre el crate sbf-tools con licencia MIT) y receiver-trust live --serial (un flujo NMEA serie o USB, solo lectura; nunca escribe en un receptor).
• Temporización y seguridad del hardware (docs/TIMING-HIL.md, docs/HARDWARE-SAFETY.md). El tipo de escenario holdover-test puntúa un ensayo de holdover de un sistema de temporización (GNSS retirado por el operador, holdover, recuperación) a partir de un registro medido del error de tiempo, medido frente a las máscaras de ITU-T de tablas públicas. clock_log lee registros de linuxptp (ptp4l, phc2sys, ts2phc) y de chrony (tracking, statistics). iq scene --format sdrx escribe metadatos ION GNSS SDR y iq monitor --follow monitoriza una grabación SigMF mientras crece (solo recepción). compliance-report incorpora el NIST IR 8323r1 Foundational PNT Profile (15 filas parafraseadas, aporta evidencias a favor de). Un paquete de evidencias puede registrar el lab-attestation del operador en su manifiesto firmado, nunca verificado; las etapas de hardware 0 a 4 y las notas legales están en HARDWARE-SAFETY.md (pendiente de revisión legal). No existe ninguna vía de transmisión de ningún tipo.
• kshana-bench v1 (kshana bench, bench/SPEC.md, docs/BENCH.md): tareas, particiones y métricas fijas para la detección de interferencias GNSS en registros de receptor (JammerTest 2024) e IQ, predicción de holdover de temporización (relojes IGS) y la brecha de optimismo fuera de distribución; manifiestos de particiones con hashes fijados y scripts de obtención (sin datos incorporados), un conjunto reservado sellado mediante compromiso y revelación, un esquema de archivo de resultados y una página estática de clasificación. Líneas base con umbrales preregistrados en xval/bench/PREREGISTRATION.md: umbrales del puntuador alcanzados, C1 a C3 alcanzados, D2 alcanzado; A2 NOT MET (AUC de agc_k_sigma 0,766 frente a al menos 0,80 en la partición de prueba), D1 NOT MET (mayor brecha 0,0301) y tarea (b) R1 NOT MET (arrastrado, no se volvió a ejecutar), cada uno fijado (xval/bench/RESULTS-v2.md). Toda puntuación es MODELLED. Python bench_score, bench_leaderboard; WebAssembly igual; MCP score_benchmark, render_leaderboard.
• Observatorio de interferencias (kshana interference-map daily, sensitivity, docs/observatory/METHOD.md): un GeoJSON diario reproducible, un PNG y un JSON de informe de incidentes con tres estados (degradado, no degradado, no observado), un retraso mínimo de 24 h, celdas de 0,5 grados o más gruesas, ninguna causa atribuida y datos de OpenSky rechazados; un estudio de sensibilidad de los parámetros preregistrados; un catálogo retrospectivo del Báltico de 30 días de adsb.lol.
• Entradas de máquina y de sensor para receiver-trust (docs/MACHINE-INPUTS.md). Nuevos valores de [log] format, todos de solo lectura, MODELLED, con fixtures escritos para la ocasión y sin datos incorporados: rtklib-pos (archivos de solución .pos de RTKLIB), novatel (BESTPOS ASCII y binarios de OEM7, C/No de RANGE y RXSTATUS; el indicador de jammer del receptor pasa a ser el self_report de la época, contrastado con las alarmas de Kshana mediante la comparación receiver-self-report), rtcm3 (C/N0 MSM4 y MSM7 para GPS, GLONASS, Galileo, SBAS, QZSS, BeiDou y NavIC; disposiciones de las tablas de pyrtcm con licencia BSD, cuyo aviso está en NOTICE, no del estándar RTCM) y gnss-sdr (mensajes de GNSS-SDR Monitor y PVT-monitor como líneas JSON, retransmitidos por integrations/gnss-sdr/relay.py).
• Registros IMU como segundo sensor. [log.imu] (csv o euroc) integra la velocidad de guiñada del giróscopo en el rumbo que lee el monitor heading-course; en línea en cada superficie y transportado a través de los paquetes de evidencias. kshana imu-fit (Python imu_fit, WebAssembly imu_fit, MCP fit_imu_log, plugin /kshana-fit-imu, una acción de JetBrains) ajusta los parámetros del acelerómetro y del giróscopo de los escenarios hybrid y fusion a partir de un registro estacionario mediante desviación de Allan e imprime una tabla [accel_classical] con el SHA-256 del registro en su procedencia.
• Integraciones: un paquete ROS 2 (integrations/ros2/kshana_trust: NavSatFix y ublox_ubx_msgs como entrada, temas de confianza como salida; su puente sin ROS se prueba contra el motor real, el propio nodo no se ha ejecutado en un grafo ROS en vivo), un puente con gnss_lib_py (integrations/gnss_lib_py, dependencia MIT, opcional) y un relé de GNSS-SDR.
• Exportador MQTT de Home Assistant para la telemetría de confianza: kshana trust-telemetry --print-mqtt y --mqtt-tcp <host:port> (mensajes de descubrimiento y un documento de estado JSON; solo publicación, sin credenciales ni TLS), y format = "mqtt" como texto en Python, WebAssembly y MCP.
• Siete filas del registro MODELLED para lo anterior. Nada de esto es VALIDATED: no se leyó ninguna captura de un receptor real, estación base, IMU, ejecución de GNSS-SDR, grafo ROS ni broker MQTT.
• Margen del enlace óptico a lo largo del tiempo. El tipo de escenario optical-atmosphere admite una tabla opcional [timeseries] (duration_h, step_s, seed) y entonces también escribe, por sitio, una realización con semilla del modelo de sitio declarado a lo largo del tiempo: episodios de nubes, una columna de agua líquida por episodio, una muestra de centelleo gamma-gamma por paso y, a partir de ellas, el margen del enlace, los desvanecimientos por nubes y por centelleo y el indicador de enlace activo, con la disponibilidad realizada, la fracción de nubes, el número de interrupciones y la interrupción más larga. MODELLED (una extracción del modelo, no el clima; sin referencia independiente externa). Sin la tabla, el resultado es el documento 0,37. Los dos escenarios ópticos incluidos llevan la tabla (336 h, 600 s, semilla 37). Umbrales preregistrados en xval/optical-atmosphere/PREREGISTRATION-timeseries.md antes de la primera ejecución.
• Especificación de condiciones de ensayo e ida y vuelta de laboratorio. kshana.test-conditions/1 se publica como docs/spec/TEST-CONDITIONS.md con un esquema JSON, e incorpora recording.kind = "receiver-log". kshana bench-export también escribe <base>.conditions.json. kshana evidence round-trip construye un paquete firmado que enlaza el hash del escenario, el hash de las condiciones declaradas, el hash del registro del receptor y la puntuación frente a los eventos declarados, y rechaza condiciones que no coincidan con los eventos de puntuación. Ejemplo desarrollado con gps-sdr-sim que solo escribe un archivo; la reproducción es responsabilidad del operador y nunca se automatiza. Python evidence_round_trip, MCP create_round_trip_pack, plugin /kshana-evidence-pack.
• Paquetes de normas (kshana standards-pack, standards/): los perfiles de ensayo del marco Resilient PNT del DHS para los niveles 1 a 4, los niveles de precisión y la evaluación de integridad de IMO MSC.1/Circ.1575 y monitorizar, evaluar y mitigar del Apéndice F de ICAO Doc 9849, cada uno un conjunto de escenarios puntuados frente a umbrales establecidos antes de la ejecución, con las filas de compliance-report a favor de las cuales aportan evidencias. Los fallos constan y están fijados: DHS L4-T1 y las cuatro pruebas de precisión de IMO. El propio Doc 9849 no se leyó (de pago); el paquete de ICAO sigue la propia presentación del Plan de mitigación de RFI de ICAO. compliance-report incorpora una sección de standards-pack. Todo MODELLED.
• LunaNet Augmented Forward Signal (docs/LUNANET-AFS.md): códigos Gold AFS-I y Weil AFS-Q para PRN 1 a 210, señales lunanet-afs-i y lunanet-afs-q en kshana iq, el código BCH SB1, CRC-24Q y entrelazador, y kshana lunanet-afs-check (spec, symbols, generate), fijados a LNIS V5 Applicable Document 1 Volume A (LSIS-AFS V1.0, 29 de enero de 2025). Códigos VALIDATED frente a las tablas impresas del documento (que lo marca como TBC); una columna terciaria impresa (PRN 147) es probablemente una errata y el fallo está fijado. La codificación LDPC de las subtramas 2 a 4 no está implementada.
• Cuadernos del curso (notebooks/course/): jamming, spoofing, holdover, integridad, OSNMA y mapa de interferencias, cada uno con ejercicios.
• Estudio de URA máxima del Hito 3 de ARAIM del WG-C UE-EE. UU. (xval/araim-m3/, src/bin/gen_araim_m3_study.rs), que sustituye al plan retirado de la "Table A-3"; MODELLED con las desviaciones declaradas.
• Borradores para aprobación del propietario en docs/drafts/: artículo de JOSS, enmienda de la carta del TSC, proceso de registro de referencias independientes y una propuesta de división de LICENSES/. Nada de ello está adoptado.
• Vistas de Studio para las funciones de 0,38 (kshana.dev/studio/). Reproducción del puente (dos ejecuciones sintéticas sobre un mismo reloj: trayectoria, puntuación de confianza, los satélites que oye el registro y el veredicto, con los propios indicadores del receptor junto a las alarmas de Kshana); PNT óptico (los dos escenarios optical-atmosphere, con una realización con semilla [timeseries] opcional, MODELLED); ensayo de holdover (el resultado de holdover-test medido frente a las máscaras de ITU-T, dibujado a partir de la propia record.series del resultado); un visor del observatorio de interferencias que abre los archivos que usted ha producido y no incluye ninguno; en la página Herramientas, un puntuador de Jammertest, un ajuste de IMU y MQTT como formato de telemetría; y en Confianza un selector de formato de registro (.pos de RTKLIB, NovAtel OEM7, RTCM 3, GNSS-SDR, Septentrio SBF) con un archivo IMU opcional. Cada vista lee archivos en el navegador y no sube nada; cada cifra conserva la etiqueta que le asigna el registro, y cada una lleva la declaración consultiva. La página del sitio /benchmark muestra el fragmento de kshana bench leaderboard.

Corregido#

• Incidencia #36: capas de fijación exactas al byte. Las capas de fijación exactas al byte solo se ejecutan en un host declarado como línea base (KSHANA_EXACT_PINS=1, establecido por scripts/gate.sh), no en todo Mac con Apple silicon, porque la biblioteca matemática de Apple difiere entre versiones de macOS; la capa portable se ejecuta en todas partes, y tests/exact_pin_gate_guard.rs impide que una capa exacta al byte vuelva a condicionarse solo a la plataforma. Las comparaciones con la referencia independiente en sí pasan en macOS. No se volvió a tomar ningún literal ni se cambió ninguna tolerancia. scripts/oracle-triage.sh y docs/LOCAL-ORACLE-TESTS.md explican cómo clasificar una diferencia; .github/workflows/oracle-macos.yml es un diagnóstico manual y semanal, no una puerta de control.
• CodeQL: un patrón sin anclar en el asistente trust-open de Studio ahora coincide con la cabecera completa (web/studio/lib/trust-open.mjs).
• CI: disco del runner. El trabajo check compila los perfiles de desarrollo y de prueba sin información de depuración, de modo que el enlazado ya no llena el disco.
• Guardas de código fuente. Todo archivo fuente que contiene fixtures de prueba con valores fijados declara su ámbito de fijación, y las pruebas que escriben archivos temporales usan una ruta única por llamada, de modo que las ejecuciones en paralelo no pueden colisionar.
• docs/SCENARIOS.md se regenera para el campo opcional timeseries de optical-atmosphere.
• Plugin de JetBrains: sin uso de API de plataforma obsoleta ni prevista para su eliminación. El IntelliJ Plugin Verifier (verifyPlugin) frente a la compilación 263 de IntelliJ IDEA (2026,3: 263.6800.24 y 263.7031.23) encontró una llamada obsoleta, FileEditorManager.openFile, en Insert Example; ahora abre el nuevo archivo con OpenFileDescriptor. El plugin es compatible con 2024,3 (la since-build, sin cambios) y con ambas compilaciones 263, sin problemas. CI ahora ejecuta verifyPlugin y falla ante problemas de compatibilidad y ante cualquier uso de API prevista para su eliminación.

[0.37.0] - 2026-10-17#

Añadido#

• PNT óptico a través de la atmósfera (tipo de escenario optical-atmosphere, docs/OPTICAL-ATMOSPHERE.md, nota de diseño docs/design/optical-atmosphere-0.37.md). Para un enlace óptico y un conjunto de sitios terrestres, informa de la pérdida en aire despejado dependiente de la longitud de onda y de la elevación, el estado de turbulencia de Hufnagel-Valley (varianza de Rytov, índice de centelleo, desvanecimientos gamma-gamma, promediado de apertura), la disponibilidad frente al margen del enlace según un clima de nubes declarado, el margen necesario para disponibilidades objetivo y el techo que ningún margen supera, la distribución de la duración de las interrupciones, el error de temporización y de distancia por interrupción mediante el modelo de holdover del reloj, la diversidad de sitios correlacionada por distancia, y ganancias hipotéticas por un cambio de longitud de onda, una apertura mayor, una reducción del centelleo con óptica adaptativa y margen adicional. optical_linkbudget incorpora un presupuesto consciente de la atmósfera; sin él, su salida es idéntica bit a bit a la de 0,36 (umbral A5). Dos escenarios incluidos llevan climas de nubes ILLUSTRATIVE. MODELLED: tres filas del registro. La numérica alcanza los umbrales A1 a A6 preregistrados en xval/optical-atmosphere/PREREGISTRATION.md frente a un programa independiente con mpmath; eso comprueba la implementación de las fórmulas declaradas, no la atmósfera, y no se ha comparado ningún registro medido de disponibilidad, por lo que ninguna fila es VALIDATED. El umbral A4 se falló al principio por 3e-9 porque la CDF normal en uso era una aproximación de 1.5e-7; se sustituyó la CDF y el umbral se dejó tal como se registró. Las compilaciones nativa y WebAssembly devuelven documentos idénticos byte a byte para ambos escenarios incluidos (A7, ejecutado sobre el commit de integración 0.37.0).

[0.36.0] - 2026-10-16#

Añadido#

• ROC de detección de los monitores IQ (PRO-32, docs/design/DETECTION-ROC.md). Una campaña con monitores conserva el máximo del estadístico de cada prueba sobre las ventanas de eventos declarados (positivas) y sobre ventanas en mosaico fuera de los eventos (negativas, roc_window_s). El informe las agrupa por tipo de alarma en una ROC con su AUC y el punto de funcionamiento en el umbral configurado, como roc.json y una sección del informe. En campañas sintéticas se alcanza la comprobación de nivel de azar. El umbral de AUC de C/N0 (0,95) no se alcanza (0,79), porque las ventanas negativas inmediatamente posteriores a un evento heredan el decaimiento del CUSUM procedente de la detección; queda registrado. MODELLED.

• Monitores IQ en la campaña de reproducción de laboratorio (PRO-31, docs/design/MONITORS-IN-CAMPAIGN.md). Una tabla opcional [monitors] en un archivo de campaña ejecuta los monitores IQ en la pasada única del ejecutor: potencia y espectral tras cada cadena de front end, y C/N0, SQM y enganche por canal seguido. Sus alarmas se puntúan frente a los eventos declarados: detectado u omitido, tiempo de detección y falsas alarmas por hora de exposición. Se declara la cifra de falsa alarma de forma cerrada de cada prueba, incluida una nueva cifra gaussiana bilateral para las pruebas SQM (2Q(k)). Sin la tabla no cambia nada. En campañas sintéticas se alcanzan los umbrales de falsa alarma de potencia y SQM y el de falsa alarma de C/N0; se detectan 18 de 18 atenuaciones, pero la cota del tiempo de detección, por construcción inferior a una muestra del detector, no se alcanza y queda registrada. MODELLED; fila del registro "Monitores IQ puntuados en campañas de reproducción de laboratorio".

• Ajuste de laboratorio a partir de campañas IQ, seguimiento (tests/iq_labfit_followup.rs, trabajo de CI labfit-iq-followup). Prueba las dos hipótesis que el §13,6 de docs/design/LABFIT-FROM-IQ.md dejó abiertas, frente a umbrales preregistrados en 1e532f84. Añade dos campañas sintéticas: S, con un J/S escalonado (semilla 2026_1014), y R, una rampa nueva (semilla 2026_1015). Los resultados están en docs/design/evidence/labfit-followup/RESULTS.md.

  • S1 alcanzado: con cada nivel de J/S mantenido, δ_eff se recupera dentro de +0,185 dB. El error de −1,1 dB de las campañas de rampa es retardo del estimador.
  • S2 no alcanzado, fijado por una prueba que afirma el fallo: (d) tal como está escrito, en la campaña escalonada, se sostiene para el modelo de lazo de seguimiento (0,45 dB) pero no para el empírico (6,42 dB).
  • R1 alcanzado: en la nueva campaña de rampa, (d) con los tiempos de permanencia de caída ajustados multiplicados por la tasa de rampa de cada evento queda dentro de 1 dB para ambos modelos.
  • Los fallos de (a′) y (d) se replican en R.
  • Una campaña ahora puede declarar su J/S como un perfil step en el arnés de pruebas.
  • Ningún veredicto del §13 cambia, y la fila del registro sigue siendo MODELLED.

• Enganche inicial del FLL limitado, opcional (DS-LOOP-05): una nueva clave de diseño de lazo [design.carrier] fll_pull_in_max_s (s), en Rust LoopConfig::fll_pull_in_max_s. Con fll_assist = "pull-in" fuerza el traspaso del FLL al PLL transcurrido ese tiempo, sea cual sea el PLI. Sin definir por defecto y entonces fuera del hash de diseño; el diseño predeterminado y su hash no cambian.

  • Comprobado frente a umbrales preregistrados en 58789af0, sobre una verdad inyectada. El control se alcanza: el valor predeterminado nunca traspasa en 9 de 10 semillas a 33 dB-Hz.
  • No alcanzado: con un límite de 1,0 s, 16 de 20 ejecuciones mantienen el enganche a 33 dB-Hz y 8 de 20 a 31 dB-Hz; las demás alternan entre traspasos forzados y el retorno del FLL. El jitter de fase es 1,8× el del PLL solo a 33 dB-Hz.
  • El piso de enganche inicial de ~35 dB-Hz sigue siendo el límite documentado del valor predeterminado.
  • MODELLED; fila del registro "Enganche inicial del FLL limitado por debajo del piso de traspaso FLL-PLL del diseño predeterminado (opcional)".

• Histéresis de adquisición y cuantificador del front end en el tipo de escenario jamming (CAP-06c): dos secciones opcionales para un escenario jamming.

  • [acquisition]: acquisition_threshold_dbhz (dB-Hz, en o por encima del umbral de seguimiento) y reacquisition_delay_s (s, por defecto 0). Un satélite se adquiere en o por encima del umbral de adquisición, una vez que ha estado sin adquirir durante el retardo. Se mantiene mientras esté en o por encima del umbral de seguimiento. Salidas: epochs[].sats[].acquired (true/false), epochs[].acquired (recuento) y fom.availability_acquired (1).
  • [front_end]: adc_bits (1 a 16) y bandwidth_mhz (MHz, por defecto el doble de la velocidad de chip). Produce un bloque front_end: agc_gain_reduction_db (dB, 10·log10(1 + J/N)), quantiser_loss_db (dB, descontada del C/N0 efectivo de cada enlace) y loss_model. La pérdida es la de entrada gaussiana, señalada como no válida para jammers CW, de banda estrecha y de barrido.
  • Sin las secciones, todas las salidas son idénticas byte a byte.
  • Comprobado frente a umbrales preregistrados en 70c72fcc. La pérdida del cuantificador está dentro de 0,0007 dB de un Monte Carlo independiente, y la lectura del AGC dentro de 0,012 dB del lazo de AGC de la capa IQ.
  • Las ejecuciones de histéresis registradas no fueron informativas (todos los enlaces perdidos), por lo que ese umbral es NOT MET. Un conjunto de ejecuciones suplementario registrado en 37793290 lo alcanza: cada indicador es igual a un recálculo independiente, y 732 de 1824 enlaces muestran la histéresis.
  • Hallazgo: con un jammer CW un ADC de 1 bit pierde unos 5 dB más que la cifra gaussiana.
  • MODELLED; fila del registro "Histéresis de adquisición y cuantificador del front end en el tipo de escenario jamming frente a recálculos independientes".

• Sombra del terreno sobre el jammer en el tipo de escenario jamming (CAP-06b): una sección opcional [terrain] en un escenario jamming con un jammer. Campos:

  • dem_hgt: una tesela SRTM .hgt, relativa al directorio de trabajo;
  • samples_per_side, ll_lat_deg y ll_lon_deg (deg): el tamaño y la esquina de la tesela;
  • geoid_undulation_m (m, por defecto 0), k_factor (por defecto 4/3) y profile_step_m (m, por defecto 30).

  El motor muestrea el perfil del terreno por círculo máximo entre el jammer y el receptor y halla el filo de cuchillo dominante. La potencia recibida del jammer, y con ella cada J/S, se reduce en la pérdida por un único filo de cuchillo de ITU-R P.526-15 §4,1.

  • El resultado incorpora un bloque jammer_terrain: nu_max (1), diffraction_loss_db (dB), obstacle_distance_m (m), obstacle_terrain_m (m), path_length_m (m) y profile_points (recuento).
  • Sin la sección, todas las salidas son idénticas byte a byte.
  • Comprobado frente a umbrales y diez ubicaciones preregistrados en 92cd2bfd, sobre la tesela SRTM real confirmada de Death Valley, frente a un recálculo independiente con numpy. Todos alcanzados: peor diferencia 1.6e-10 en ν y en la pérdida (umbral 1e-9), la pérdida monótona respecto a la altura del jammer y la pérdida que reduce exactamente el J/S.
  • MODELLED; fila del registro "Sombra del terreno sobre el jammer en el tipo de escenario jamming frente a un recálculo independiente con numpy sobre una tesela SRTM real".

• Ganancias de antena CRPA en el tipo de escenario jamming (CAP-06a): una sección opcional [crpa] en un escenario jamming. Campos: elements_enu_m (posiciones de los elementos en este-norte-arriba local, m), weighting ("null-steering" o "mvdr") y bandwidth_mhz (ancho de banda de ruido de MVDR, MHz, por defecto el doble de la velocidad de chip).

  • Cada canal forma un haz sin distorsión hacia su satélite. El ruido del enlace se escala por ‖w‖² y el jammer por |wᴴa_j|² antes de la ecuación C/N0 antiinterferencia existente.
  • Cada enlace incorpora un bloque crpa: array_noise_gain_db (dB) y jammer_gain_db (dB).
  • Sin la sección, todas las salidas son idénticas byte a byte.
  • Una sección no válida (una lista de elementos vacía, una ponderación desconocida, un ancho de banda no positivo) es un error, tanto a través de kshana y api::run_toml como de jamming::run_jamming.
  • Comprobado frente a umbrales preregistrados en 08d83b4d. Alcanzados: aditividad (tras una corrección: la primera compilación añadió las nuevas unidades a la tabla de unidades de cada ejecución de jamming); un elemento no es una agrupación; ganancia de ruido y C/N0 efectivo frente a un recálculo independiente con numpy dentro de 1e-9 dB; MVDR tiende al nulo con un JNR alto.
  • No alcanzado: la ganancia del jammer con MVDR en 194 de 456 enlaces con las matemáticas portables de 0,36 (202 con las matemáticas del host; docs/revisions/STUDIO15-batch4-rebaseline.md) (peor caso 1.7e-6 dB). Los residuos de −100 a −188 dB están por debajo de la resolución de float64 en ese umbral, y numpy discrepa de sí mismo en el mismo orden.
  • MODELLED; fila del registro "Ganancias de antena CRPA en el tipo de escenario jamming frente a un recálculo independiente con numpy".

• Motor de seguimiento IQ frente a GNSS-SDR 0.0.19 (PRO-33): kshana iq track y GNSS-SDR siguen las mismas grabaciones independientes de numpy de GPS L1 C/A a 30 hasta 45 dB-Hz.

  • Umbrales preregistrados en 48edd4a5. La calibración registrada falló por un traspaso erróneo de GNSS-SDR (F3), de modo que la Enmienda 1 (1e4288c4) añade un FLL solo de enganche inicial a ambos receptores, confirmada antes de cualquier grabación de prueba.
  • Alcanzado: el jitter de portadora y de código y el Doppler coinciden dentro del 5 % en cada C/N0.
  • No alcanzado: el C/N0 NWPR del motor lee de 2,3–7,1 dB por debajo del SNV de GNSS-SDR (F4, un límite conocido del estimador; M2M4 está a 0,06 dB de la verdad); los indicadores de enganche difieren por definición (F5); un desacuerdo de deslizamiento a 30 dB-Hz (F6).
  • MODELLED; fila del registro "Motor de seguimiento IQ frente a GNSS-SDR 0.0.19 con grabaciones independientes".

• Dos filas VALIDATED para códigos de la capa IQ (DS-GIQ-06b, PRO-39).

  • BeiDou B1I. Los 63 códigos primarios B1I coinciden chip a chip con el generador independiente de GNSS-SDR v0.0.19 (umbral preregistrado en 911106d1). Solo se confirma la salida de ese programa: los códigos PRN B1I que define el ICD público, como prefijo y hash.
  • GPS L1C. Los 126 códigos L1CP/L1CD y las 63 superposiciones L1CO coinciden con las columnas de comprobación que imprime IS-GPS-800J, y la secuencia de Legendre calculada coincide con su Tabla 6.2-1 (umbrales preregistrados en fe372e26).
  • Filas: "Códigos de distancia primarios BeiDou B1I frente a un generador independiente" y "Códigos de distancia y de superposición GPS L1C frente a las columnas de comprobación impresas de IS-GPS-800J".

• Bandas GLONASS, BeiDou y Galileo E6 en el modelo de espectro (CAP-12, señales): nuevos nombres de banda glonass-l1of y glonass-l2of (cualquier canal FDMA como glonass-l1of-k<K>, K = −7 a 6), beidou-b1i, beidou-b1c, beidou-b2a, beidou-b3i y galileo-e6. Cada una lleva su portadora, modulación y potencia mínima recibida del ICD. Son opcionales por nombre: el conjunto de bandas predeterminado y todas las salidas existentes no cambian.

  • Comprobado frente a umbrales preregistrados en 5806f28b: se alcanzan los valores del ICD, los nulos, el compuesto B1C y la ruta C/N0.
  • Dos umbrales no se alcanzaron. El umbral de área unitaria era inalcanzable tal como estaba escrito (F1). Las formas de onda B1I y B1C de la capa IQ coinciden con el modelo solo promediadas por banda, debido a los espectros de líneas irregulares de sus códigos (F2).
  • MODELLED; fila del registro "Modelo de espectro: bandas GLONASS, BeiDou y Galileo E6 (opcional)".

• Opción CFAR de promediado de celdas en la adquisición IQ (PRO-37): iq::acq::ca_cfar y ca_cfar_cells deciden sobre una cuadrícula de adquisición comparando cada celda con la media de las celdas de referencia de su fila Doppler. El umbral procede de la probabilidad de falsa alarma de forma cerrada del CA-CFAR para M bloques no coherentes (ca_cfar_pfa, ca_cfar_alpha), de modo que la decisión no depende de la normalización de la potencia de muestra. Es opcional; el detector predeterminado y todas las salidas existentes no cambian.

  • Comprobado frente a umbrales preregistrados en 3724aefa: la forma cerrada frente a Monte Carlo (18 de 18 casos), y una tasa de diseño del 1 % medida en 0,97–1,01 % con ruido gaussiano y cuantificado a 2 bits.
  • Un umbral no se alcanzó: con una señal de 2 bits sin ruido, el 1,28 % de las celdas fuera del pico superan el umbral de decisión, en los lóbulos laterales de correlación del código (hallazgo F1).
  • MODELLED; fila del registro "Opción CFAR de promediado de celdas en la adquisición IQ".

• Modelo de centelleo frente a datos medidos (PRO-34): el modelo de centelleo de Cornell del canal IQ se comparó con la intensidad y la fase medidas de GPS L1 a 50 Hz de una noche de centelleo ecuatorial (registro de Zenodo 16941224, INGV, Malindi, CC BY 4,0), con umbrales preregistrados en b6ccb499. Alcanzados: la distribución de la intensidad y el centelleo de fase ligado a S4. No alcanzado: el modelo se desvanece 2,4 veces más a menudo por debajo de −10 dB y 3,5 veces más tiempo (hallazgo F1). El procesamiento registrado lee la fase envuelta del modelo (hallazgo F2); el resultado de fase se mantiene con ella desenvuelta. scripts/fetch_scint_malindi.sh obtiene los datos. La fila sigue siendo MODELLED: "Canal de centelleo ionosférico IQ (modelo de Cornell) frente al centelleo medido de GPS L1 a 50 Hz".

• Lector de muestras de LuGRE corregido (MR-09): realdata::lugre::parse_iqs_sdrx lee un lote IQ de LuGRE con I en el nibble alto y los niveles mid-rise 2v + 1 (SdrLayout::mid_rise), que eliminan la media de −½ que llevan I y Q en los enteros en complemento a dos sin más. run_acq.py --corrected da a GNSS-SDR la misma lectura. El lector ION genérico y todas las salidas existentes no cambian: 149 resultados de escenario y un estudio son idénticos byte a byte antes y después, y los hallazgos fijados de LuGRE se leen tal como se registraron (xval/lugre-reader/RESULTS.md). No cambia ninguna fila del registro.

• Seguimiento BOC(1.1) opcional (CAP-07 (a)): LoopConfig::boc reescala los discriminadores del DLL para el pico principal del BOC(1.1) senoidal y añade un monitor de salto de pico (correladores muy adelantado y muy retrasado a ±0,5 chip, contadores ascendentes/descendentes, N = 8) que aparta el NCO de código de un pico lateral; Channel::bump_jumps lista los saltos. Desactivado por defecto, y todas las salidas existentes no cambian. Comprobado frente a umbrales preregistrados en 6b68f6cc con una señal BeiDou B1C sintética: un inicio en un pico lateral que sin la opción permanece a 0,55 chip se lleva al pico principal con un salto a los 0,08 s con ella, y no se vio ningún salto falso desde el pico principal. Un umbral no se alcanzó: la cuadrícula de pruebas unitarias del escalado llega fuera del rango lineal de los discriminadores (hallazgo F1 en docs/design/evidence/boc-bump-jump/RESULTS.md). MODELLED; fila del registro "Seguimiento de BOC(1.1): escalado del DLL y resolución de ambigüedad por salto de pico (opcional)".

• Ajuste de laboratorio a partir de campañas IQ (B7.1, docs/design/LABFIT-FROM-IQ.md). El [input] campaign = "<out-dir>" de un escenario labfit ajusta una carpeta de salida de kshana iq campaign en la CLI (kshana iq labfit), en Python (kshana.iq_labfit) y en la herramienta labfit de MCP (solo carpetas dentro de su directorio de trabajo). Ajusta una unidad por señal, diseño de lazo, cadena de front end y tipo de jammer:

  • el modelo de C/N0 frente al J/S declarado, con censura;
  • el umbral de seguimiento, directamente y en forma cerrada;
  • los modelos de lazo de seguimiento y de enganche empírico, acoplados mediante el modelo de C/N0, con sus tiempos de permanencia;
  • un bootstrap por conglomerados con semilla sobre las grabaciones, intervalos de predicción del 90 % y conjuntos reservados de dejar una grabación fuera;
  • una tabla [validation] preregistrada, con hash, con PASS/FAIL por umbral.

  El informe es kshana.labfit-iq/1 como JSON, CSV y Markdown, con un bloque de unidades. Q_eff no es identificable a partir de datos de C/N0 sin una medición independiente de la potencia. Se declara, nunca se ajusta, y el parámetro ajustado es delta_eff = delta - 10 log10 Q (enmienda de diseño 2026-10-12). Un tipo de jammer desconocido toma el Q declarado más perjudicial (cw, 1). En campañas sintéticas a partir de las propias escenas de Kshana, el umbral de cobertura del conjunto reservado (c) se supera. Los umbrales de delta_eff (a') y (b') (0 de 50 campañas cubiertas) y el umbral (d) del umbral en forma cerrada no se alcanzan: constan con sus valores. MODELLED; fila del registro "Calibración de los modelos de C/N0 y de enganche del receptor abierto con los resultados de campañas IQ, con error de predicción declarado". La vía labfit del registro del receptor y sus salidas no cambian.

• solar-system sobre un kernel de JPL (CAP-31): planetary_kernel_path toma cada cuerpo que contiene el SPK (con de440s: Mercurio, Venus, la Tierra, la Luna) del kernel, etiqueta KERNEL, y añade un bloque kernel solo cuando se establece. Fila nueva, VALIDATED frente a SPICE (preregistrada f8e946ea; peor caso 3.3e-5 m, 1.0e-11 m/s). El informe predeterminado no cambia.

• Porkchop sobre las efemérides DE440 (CAP-20b): maneuver::porkchop_kernel barre C3 y V∞ de llegada sobre estados heliocéntricos de un SPK de DE440. Fila nueva, VALIDATED frente a estados de SPICE

  • pykep 3.0.1 (preregistrada 2d857fb1; Tierra a Marte 2026-2028, 304 celdas, peor caso 2.6e-14, la misma celda de C3 mínimo).

• Macromodelo no gravitatorio de LRO: NOT MET (DS-LRO-10, preregistrado e82047e2). lunar_od::LunarMacroModel (opcional mediante LunarForceModel::macro_model): radiación solar directa sobre placa plana con la sombra de la Luna, un panel que sigue al Sol, y albedo lunar e IR térmico; LunarMacroModel::lro_generic es una aproximación genérica etiquetada de LRO a partir de hechos publicados (sin placas del bus: no se pudo obtener la tabla de placas). En el arco de LRO de 4 h deja el RMS reducido-dinámico en 6,668 m y el dinámico en 11,94 m, con un factor de radiación inverosímil (de aproximadamente +21 / −22), por lo que se fallan los tres umbrales. El hallazgo queda fijado por una prueba y ninguna salida predeterminada cambia (docs/design/evidence/ds-lro-10-macro-model/RESULTS.md). El SRP de bola de cañón lunar opcional ahora usa la sombra cónica de la Luna en lugar de la de la Tierra (forces::conical_shadow_body).

• OD lunar: marea sólida k2 y relatividad selenocéntrica opcionales (DS-LRO-11), desactivadas por defecto (LunarForceModel::lunar_tide, ::relativity); un conmutador KSHANA_LRO_DEGREE para la validación cruzada con ANISE (DS-LRO-04); un fixture de arco de LRO de 24 h y un ajuste de arco largo solo informativo (DS-LRO-09). Las ejecuciones informativas se registran en docs/design/evidence/ds-lro-09-11-longer-arc/RESULTS.md; no cambia ninguna cifra publicada.

• NRHO 9:2 del CR3BP frente a CAPSTONE (CAP-29d): nueva fila MODELLED que mide la NRHO circular restringida del motor frente a la órbita volada de CAPSTONE (JPL Horizons, marzo de 2023; preregistrada 4e868170): periodo 1,07 %, apolunio 0,05 %, perilunio 4,1 % respecto a las medias de CAPSTONE, dentro de los umbrales registrados de 3 / 5 / 20 %. Una medición, no una validación.

• Estados rotatorios del CR3BP a ICRF centrado en la Luna (RM-34, FUT-06): cr3bp::to_moon_centred_icrf / from_moon_centred_icrf / to_moon_centred_icrf_de440 proyectan un estado rotatorio adimensional Tierra-Luna sobre la línea instantánea Tierra-Luna de DE440, incluida la velocidad fuera del plano del marco. Fila nueva, VALIDATED frente a un marco de dos vectores de SPICE (preregistrada 2313eb1b, enmendada antes de cualquier ejecución d5ef79b3; 72 casos, peor caso 1.8e-7 m y 1.2e-9 m/s).

• Miembros de familias del CR3BP frente a la API de órbitas periódicas de tres cuerpos de JPL: NOT MET (RM-35, preregistrado a9074f65). cr3bp_family (corrección de halo, NRHO y DRO, índice de estabilidad de la monodromía, continuación por pseudolongitud de arco) coincide con 54 de 58 miembros de la API en todos los umbrales (estado, periodo y Jacobi dentro de 1e-10 en todos los casos). Un índice de estabilidad de un halo L1 (9.5e-2) y tres cierres de DRO pequeñas (1.5e-8 a 3.3e-8 frente a 1e-8) no se alcanzan, por lo que el módulo es #[doc(hidden)] y ninguna fila lo afirma. Resultados: docs/design/evidence/cr3bp-families/RESULTS.md.

• Orientación y entorno lunares DE440 opcionales (FUT-05, DS-LRO-08; valores predeterminados sin cambios): lunar_frame::try_icrf_to_moon_pa_de440, lunar::try_mci_to_mcmf_de440 / try_mcmf_to_mci_de440 (ancladas a la época, ejes principales de DE440) y lunar_od::De440LunarEnvironment (orientación de ejes principales de DE440 incorporada más el Sol y la Luna geocéntricos de un SPK de DE440 aportado por el usuario). Frente a ANISE (preregistrado ea537710): orientación dentro de 3.5e-7 rad y ajustes de LRO dentro de 1 mm, pero el tramo de efemérides no alcanzó su umbral (Sol 30,7 m, Luna 1,1 m, un desfase temporal de ~1 ms en el lado de ANISE), por lo que no es una fila validada. Resultados: docs/design/evidence/fut05-de440-lunar-env/RESULTS.md.

• Datum de campaña del marco lunar, umbral de NumPy escalado por condición: NOT MET (preregistrado b887eb05; sigue siendo MODELLED). El paso 0 descarta la alternativa de la pseudoinversa como causa de la brecha de 0,30 de las estaciones estimadas; NumPy coincide dentro del umbral en seis de ocho escenarios, pero stations_estimated no lo alcanza (6.8e-6 frente a 5.9e-7), y en la fecha nueva 2026-12-01 una baliza no observada del polo sur hace que la información de las balizas sea deficiente en rango, lo que la referencia independiente sin cambios no puede evaluar. Resultados: docs/design/evidence/mr05-lunar-datum-cond/RESULTS.md.

• Datum del marco lunar a partir de una campaña de observación real (Luna analítica) VALIDATED con puntos normales EDC nuevos de 2025 (preregistrado 31f5283 antes de obtener ninguno): la referencia independiente de SPICE y NumPy sin cambios coincide en la contabilidad, los rangos y el acoplamiento nulo, y dentro de 1.11e-3 en las sigmas (umbral 1e-2), 8.95e-4 en la condición y 1.79e-3 en las razones transversal/longitudinal (umbral 2e-2). Una comprobación de biblioteca solo del cálculo de la covarianza; los umbrales no discriminan entre modelos de la Luna. Resultados: docs/design/evidence/mr06-llr-analytic-fresh/RESULTS.md.

• Orientación IAU y GM de los catorce cuerpos del sistema solar añadidos, separados de la fila "Constantes físicas de cada cuerpo del sistema solar" en una fila VALIDATED (preregistrado 154bc54): Body::iau_rotation_et coincide con pxform de SPICE en pck00011 dentro de 1e-9 rad en 574 matrices en las épocas originales y en 574 en 41 épocas nuevas nunca comparadas antes (peor caso Fobos 1.38e-10 rad), y Body::mu es igual a gm_de440 para los catorce cuerpos. El resto de la fila original (J2, radio medio, el informe) sigue siendo MODELLED. Resultados: docs/design/evidence/mr08-body-orientation/RESULTS.md.

• Lambert de múltiples revoluciones (maneuver::lambert_multirev): todas las soluciones con hasta tres revoluciones, ambas ramas. Nueva fila del registro, VALIDATED frente a pykep 3.0.1 (preregistrado a75de851; 382 casos, 1058 soluciones, peor diferencia de velocidad 1.6e-13 frente a 1e-8). La guarda interna de aterrizaje de Kepler halló una limitación de maneuver::kepler_universal en un arco con e = 0,994; consta en docs/design/evidence/lambert-multirev/RESULTS.md.

• Presión de radiación solar de caja-alas y ECOM2 (DS-PA-14), opcional. srp_boxwing: un modelo de caja-alas de placas planas con las tablas FOC/IOV de Galileo de los metadatos de satélites del GSC, con guiñada nominal de dirección GNSS, con factor de radiación y derivadas parciales por panel, y el modelo empírico ECOM2 con sus derivadas parciales. Se selecciona con ForceModel::box_wing_srp / PreciseForceModel::box_wing_srp (campos srp_boxwing, por defecto None: la vía de bola de cañón y todos los valores de referencia no cambian); con un conjunto caja-alas, cr es su factor de radiación. Comparado con Orekit 12,2 bajo un preregistro (xval/srp-boxwing-orekit/): todos los umbrales alcanzados, unos 1e-15 relativos; VALIDATED como evaluación de modelo, la predicción de la SRP de Galileo sigue siendo MODELLED.

• Sombra de la SRP con Tierra achatada y oscurecimiento del limbo solar (FUT-09, RM-11). Nuevo módulo srp_shadow: oblate_conical_shadow (elipsoide ocultante WGS-84), limb_darkened_shadow (ley de Eddington) y ShadowModel, seleccionado con ForceModel::srp_shadow (por defecto: la sombra cónica esférica existente, sin cambios); forces::srp_accel_with_lit_fraction. La sombra achatada coincide con la razón de iluminación de Orekit 12,2 dentro de 7.4e-9 en 2400 geometrías (VALIDATED, xval/srp-oblate-shadow-orekit/); el oscurecimiento del limbo no tiene referencia independiente externa (MODELLED).

• Termosfera NRLMSISE-00 (FUT-08, RM-10, DS-PA-13). nrlmsise00: un port de gtd7 y gtd7d (conmutadores, modos de Ap diario y de matriz ap cada 3 horas) de la versión en C de dominio público del Fortran del NRL. Es idéntico bit a bit a ese port en C y está dentro de 1.9e-6 relativo de pymsis 0.13.0 (Fortran del NRL, precisión simple) en una cuadrícula de 720 puntos, y reproduce los 17 casos de prueba publicados (VALIDATED; xval/nrlmsise00-pymsis/). Esto valida el port, no la exactitud del modelo frente a la densidad medida.

• Nivel opcional de densidad de arrastre NRLMSISE-00. forces::DensityModel::{Exponential, Nrlmsise00 { f107a, f107, ap }}, forces::drag_accel_with_density, density_at y propagator::ForceModel::drag_density. El modelo exponencial estático sigue siendo el predeterminado, bit a bit. La meteorología espacial es constante por modelo. VALIDATED a nivel de órbita frente al propio arrastre NRLMSISE-00 de Orekit 12,2 durante 24 h (peor caso 0,03 m frente a hasta 142 km de desplazamiento por arrastre; xval/drag-tier-orekit/).

• Sol y Luna de DE440 opcionales en el propagador de Cowell (RM-33, FUT-10). propagator::ForceModel::with_ephemeris acepta cualquier EphemerisProvider (por ejemplo, un KernelEphemeris de DE440) para los términos de tercer cuerpo y de SRP; rechaza un proveedor que no pueda servir la época, cuenta los recursos a la serie analítica y está desactivado por defecto. EphemerisProvider::relative_position_jd2 conserva la precisión en dos partes. Frente a Orekit 12,2 con su propio lector de DE440, las órbitas de 24 h coinciden hasta 0,017 m; el umbral preregistrado de posición del Sol y la Luna no se alcanzó (6,4 m / 0,24 m; SPICE muestra la misma brecha), por lo que MODELLED (xval/propagator-de440-orekit/).

• Marea atmosférica S1 opcional (DS-PA-03). tides::atmospheric_tide_s1 y s1_air_tide_acceleration (Biancale & Bode 2006, GFZ STR06/01 Tabla 1 modelo N1, grados 2–6), activadas con air_tide_s1() en propagator::ForceModel y precise_od::PreciseForceModel; desactivadas por defecto. MODELLED (coeficientes recomprobados frente a la tabla publicada; sin referencia independiente externa para el efecto de la fuerza).

• Determinación de órbita por lotes con velocidad de distancia y acimut/elevación con máscara de elevación (RM-36, FUT-13). orbit_determination::determine_orbit_batch_tracking, simulate_tracking, predict_tracking, propagate_with_stm (STM variacional con derivadas parciales analíticas de dos cuerpos + J2), is_visible, measurement_with_partials; batch_ls::gauss_newton_analytic. La vía solo de distancia no cambia. Comparado con mínimos cuadrados por lotes de Orekit 12,2 en 8 escenarios preregistrados: todos los umbrales alcanzados salvo la coincidencia de estado sin ruido (≤ 1 cm), no alcanzada en 2 de 4 escenarios con 1,46 y 1,74 cm, con kshana a 1e-8 m de la verdad; registrado, MODELLED.

• Ponderación de exactitud SP3 (DS-PA-06). sp3::parse_sp3_accuracy y Sp3Accuracy::position_sigma_m asignan los códigos de exactitud de la cabecera y de cada registro a sigmas de observación; se añade una variante de ajuste de Galileo ponderada con SP3 (RMS 3-D de nivel 2 de 0,035 m frente a 0,070 m sin ponderar) junto a las ejecuciones registradas sin cambios. MODELLED.

• Trabajo de despacho de arco completo de Swarm-A (DS-PA-08) en .github/workflows/agency-od-validation.yml.

• Gravedad planetaria a partir de tablas SHADR de PDS (CAP-30, parte de CAP-31). SphericalHarmonicField::from_shadr (src/gravity_pds.rs) lee Mars GMM-3 (g/o 120) y GRAIL GL0660B (g/o 660); Body::with_gravity_field asocia cualquier campo cargado (valores predeterminados sin cambios). Se incluyen recortes de grado 20 (NASA PDS, dominio público; tests/fixtures/planetary_gravity/NOTICE.md); los archivos completos los obtiene xval/planetary-gravity-pyshtools/fetch_data.sh. VALIDATED frente a pyshtools 4.14.1 (dentro de 4e-15 de la gravedad total con g/o 120 sobre toda la esfera, 5e-14 con g/o 660 para |lat| ≤ 60°); la conexión con el marco del cuerpo sigue siendo MODELLED (el marco nativo de cada campo no es el marco IAU utilizado).

• Gravedad de alto grado hasta el grado 2190 (RM-14, FUT-07). SphericalHarmonicField::acceleration_hf / potential_hf (columna directa modificada de Holmes–Featherstone, sin desbordamiento inferior (underflow), sin singularidad polar), prepare_high_degree, un cargador ICGEM en flujo from_gfc_file / from_gfc_reader (comprobaciones de norma y de grado máximo, sistema de mareas registrado, términos variables en el tiempo rechazados) y scripts/fetch_egm2008.sh (EGM2008 completo, SHA-256 fijado, no incluido; pruebas condicionadas a KSHANA_EGM2008_GFC). propagator::FieldEvaluator lo selecciona en el Geopotential opcional. Coincide con Orekit 12,2 hasta 7.3e-17 m/s² hasta el grado 2190, y una órbita de 24 h 200×200 coincide hasta 0,13 m. MODELLED: pyshtools no alcanzó el umbral preregistrado cerca del polo (atribuido a pyshtools) y el control de sensibilidad de grado 70 de la órbita no se alcanzó (0,73 m < 1 m); ambos constan en xval/.

• Integrador DOP853 (FUT-11). integrator::integrate_dop853, integrate_dop853_checked, integrate_dop853_dense (salida densa de orden 7), dop853_step, dop853_initial_step, con una guarda de paso que falla en modo cerrado; propagator::Integrator::Dop853, propagate_dop853, propagate_dop853_checked. El controlador predeterminado no cambia. VALIDATED frente a SciPy 1.18.1 solve_ivp(method="DOP853"): pasos individuales dentro de 5.6e-15, secuencias de pasos coincidentes, estados finales dentro de 1.6e-12 (xval/dop853-scipy/).

• Resolutor robusto de Kepler (FUT-12). Nuevo módulo kepler: solve_kepler_markley (arranque de Markley 1995, residuo sin cancelación) para todo 0 ≤ e < 1, envuelto por propagator::solve_kepler_robust. VALIDATED frente a raíces de mpmath de 50 dígitos hasta 0,9 ε·|E| con e hasta 0,999999 (xval/kepler-mpmath/).

• Gravedad terrestre teseral opcional en el propagador de Cowell (RM-09). propagator::ForceModel incorpora geopotential: Option<Geopotential> (with_geopotential, with_egm2008(nmax)). Evalúa un SphericalHarmonicField (EGM2008 incluido hasta grado/orden 70, o cualquier .gfc de ICGEM) en un marco ligado a la Tierra alcanzado mediante el ángulo de rotación terrestre (EarthFixedFrame::Era) o la cadena GCRS-ITRS del CIO (EarthFixedFrame::Cio). Por defecto None: ninguna salida existente cambia. VALIDATED frente a Holmes–Featherstone de Orekit 12,2 durante 24 h (6 casos, peor caso 0,036 m), con los umbrales preregistrados en xval/cowell-tesseral-orekit/PREREGISTRATION.md.

• Fechas julianas en dos partes en la rotación terrestre de la vía de órbita: jd2::gmst82, cio::gcrs_to_itrs_matrix_jd2, frames::teme_to_itrf_jd2 / itrf_to_teme_jd2, orbit::Propagator::position_in_frame_jd2 y own_jd2_utc, conversiones From entre jd2::Jd2 y timescales::TwoPartJd, y un two_part_jd = true opcional para el escenario ephemeris (ECEF, traza sobre el suelo y vista de estación; desactivado por defecto y sin cambios, y la clave se omite del hash del escenario cuando está desactivada). Nueva fila del registro, VALIDATED frente a pyerfa gmst82/c2t06a (preregistrado b10475ee; 40 fechas: GMST idéntico bit a bit, matriz dentro de 2.7e-14, rotación en pasos de 1 µs dentro de 1.1e-14 rad, donde la vía de un solo f64 no los alcanza). La época del modelo de fuerzas de Cowell sigue siendo de un solo f64; el motivo consta en su documentación.

• Predicción de EOP más allá de la tabla (EopSeries::with_ls_ar_prediction, EopSeries::last_mjd): una extensión opcional de una serie de orientación terrestre del IERS mediante el predictor LS+AR emitido en su última fila, de modo que los argumentos de marco de una época posterior siguen la previsión en lugar de quedar fijados a la última fila. Las respuestas dentro de la tabla son idénticas bit a bit (probado); la serie sigue quedando fijada salvo que se llame a esto. La exactitud de la previsión sigue siendo el hallazgo existente de LS+AR frente al Bulletin A (MODELLED).

• Desfases del polo celeste dX, dY en la cadena del CIO (cio::gcrs_to_cirs_matrix_with_offsets), y comprobaciones vectoriales directas con ERFA de precession_matrix, teme_to_gcrs_matrix y la nueva función. Nueva fila del registro, VALIDATED frente a pyerfa (preregistrado 979c1e39; 40 épocas 1950–2100: precesión y CIO idénticas bit a bit, TEME→GCRS dentro de 1.1e-10 rad, el efecto previsto de la serie de dos términos de la ecuación de los equinoccios). Las funciones existentes no cambian.

• UTC anterior a 1972 en la vía temporal de dos partes (timescales::tai_minus_utc_on_date, y Jd2::from_utc_calendar, jd2::utc_to_tai y jd2::tai_to_utc desde 1960-01-01): la era de tasa derivante ("segundo elástico"), con la tabla de deriva de SOFA, saltos fraccionarios a final de día y el escalado de UTC a SI de la fracción del día. Nueva fila del registro, VALIDATED frente a pyerfa dtf2d/utctai/taiutc (preregistrado 23c40661; 117 instantes 1960–1971, peor caso 2.9e-11 s frente a un umbral de 1 µs). Todo resultado de 1972 en adelante es idéntico bit a bit (suma de comprobación fijada antes del cambio). Antes de 1960, TAI − UTC es 0, como en SOFA. El timescales::tai_minus_utc de un solo f64 no cambia.

• Reloj de satélite difundido de GLONASS (GlonassEphemeris::sv_clock_bias_s): −τn + γn·(t − tb) a partir del registro RINEX, a una hora leída en el reloj del satélite (dos iteraciones de punto fijo, la convención de RTKLIB). Los −τn y γn analizados no se usaban antes. Nueva fila del registro "Reloj de satélite difundido de GLONASS y propagación de la órbita difundida", VALIDATED frente a geph2clk/geph2pos de RTKLIB 2.4.2-p13 (preregistrado e099c42a; 292 casos sobre un archivo de difusión real de 2013: diferencia de reloj 0 s, peor posición 1,1 mm frente a un umbral de 1 cm). Función de biblioteca; ninguna salida de escenario cambia. No se aplica ninguna transformación PZ-90.11 → ITRF, y el módulo lo dice.

• Solución de tiempo PPP frente al reloj de estación del IGS (0,36, FUT-19): el reloj del receptor del filtro PPP flotante en WTZR coincide con el reloj combinado final del IGS para la estación hasta 0,075 ns (desviación típica) con un desfase constante de −0,66 ns durante las dos horas convergidas. Los umbrales se preregistraron en xval/ppp-time/. VALIDATED (nueva fila del registro). Nuevo fixture igs_2025055_WTZR_05m_0006.clk, los registros de reloj de estación del archivo de reloj final del IGS ya usado para los relojes de satélite.

• Paridad de PPP con gLAB (0,36, WP-07, RM-31): se ejecutó gLAB 6.0.0 con las mismas entradas de WTZR como herramienta aparte (núcleo Apache-2.0; suma de comprobación de la descarga verificada frente a la lista publicada), con la línea de comandos de una enmienda de procedimiento confirmada antes de la ejecución. En su primera ejecución registrada, el PPP flotante de Kshana y el de gLAB coinciden dentro de 0,05 m en 240 de 240 épocas y hasta 5,0 mm en la última. El umbral de SPP no se alcanzó (mediana 1,187 m frente a 0,50 m) y se registra como hallazgo: las propias soluciones SPP de gLAB y de RTKLIB difieren entre sí en 0,852 m. Por tanto, la regla registrada deja los tramos de ambas herramientas como no alcanzados en conjunto, mientras que la paridad de PPP se mantiene.

• Lectura de navegación RINEX 4 (0,36, WP-07, PRO-41): rinex::parse_nav lee archivos de navegación RINEX 4.00-4.02 (> EPH GPS LNAV, Galileo I/NAV y F/NAV, BeiDou D1/D2, QZSS LNAV; otros registros se omiten hasta la siguiente cabecera de registro), y parse_nav_with admite opciones. VALIDATED frente al archivo combinado RINEX 3 del IGS del mismo día: cada campo decodificado idéntico y 0 m en posición. La lectura de RINEX 2/3 no cambia.

• Posiciones difundidas de BeiDou GEO (opcional): NavParseOptions::include_beidou_geo y RinexEphemeris::sv_position_ecef_bds_geo (ICD de BDS, inclinación de −5 deg). parse_nav sigue omitiendo los GEO. MODELLED: la comparación preregistrada con una órbita precisa está condicionada a datos y aún no se ha ejecutado.

• Archivos de observación RINEX 4: en las pruebas se lee un archivo de observación MGEX real RINEX 4,00 (MODELLED, ajuste a la norma del formato).

• RTK con LAMBDA sobre RINEX real (0,36, WP-07 ★): rtk_real::run_rtk, dobles diferencias de línea base corta de código y fase GPS de doble frecuencia con un filtro de Kalman flotante y fijación de enteros con LAMBDA (prueba de razón). VALIDATED en las estaciones del IGS WTZR y WTZZ (a 1,4 m una de otra) frente a su línea base ITRF2020 con umbrales preregistrados: fijada en todas las épocas tras los primeros diez minutos, error de línea base con mediana de 4,5 mm y percentil 95 de 5,5 mm.

• Paridad con RTKLIB del PPP con datos reales (RM-31): xval/ppp-parity/run.sh y tests/ppp_parity_glab_rtklib.rs con umbrales preregistrados. El PPP de RTKLIB v2.4.2-p13 sobre las mismas entradas de WTZR coincide con Kshana dentro de 5 cm en cada época de las dos últimas horas (9,7 mm al final) en el tercer registro; las dos primeras ejecuciones, registradas como hallazgos, tenían la marea sólida desactivada y la antena del receptor en la ranura base de RTKLIB. El umbral de paridad de posicionamiento de punto único no se alcanzó (mediana de 1,09 m frente a 0,5 m). El tramo de gLAB no se ha ejecutado (condicionado a datos).

• Codificadores de mensajes de navegación más allá de LNAV (0,36, WP-07, PRO-40): gnss_navmsg codifica GPS CNAV (tipos de mensaje 10, 11, 30; CRC-24Q; codificación continua de tasa 1/2 con K=7), Galileo I/NAV (tipos de palabra 1-5 en páginas nominales par/impar; entrelazador de 30x8; sincronización 0101100000) y Galileo F/NAV (tipos de página 1-4; entrelazador de 61x8; sincronización 101101110000), con decodificadores de prueba. MODELLED: ida y vuelta y respuestas conocidas del ICD; una comprobación preregistrada de que las efemérides difundidas de Galileo se sitúan en la cuadrícula de LSB del codificador se sostuvo (peor caso 3.6e-3 LSB) pero no alcanzó su umbral de número de satélites (15 de 20), registrado. Los codificadores son funciones de biblioteca; la conexión con la escena no forma parte de este cambio.

• Lector de archivos IONEX (0,36, WP-07): ionex::parse_ionex_file con IonexFile, IonexHeader, IonexEpoch, IonexFileMap y IonexTimeInterp: un lector estricto de IONEX 1,0 de columnas fijas con épocas contadas desde el día del primer mapa, 9999 leído como ausente, mapas de RMS y las interpolaciones temporales del formato de mapa más cercano, consecutivo y rotado; TEC oblicuo a la altura de la capa de la cabecera. Comprobado con un mapa sintético confirmado y, condicionado a datos (obtenido en el momento de la prueba con un SHA-256 fijado, no incorporado), con un recorte de un GIM real de CODE: cada nodo exacto; la interpolación coincide con una referencia de fórmula hasta 4e-13 TECU. iontec de RTKLIB coincide hasta 3.6e-13 TECU en 6885 puntos (B6 preregistrado). VALIDATED con evidencia condicionada a datos (decisión del propietario, 2026-10-13): la prueba falla con cualquier mapa que no sea el de SHA fijado.

• Suavizado de portadora de Hatch (0,36, WP-07): hatch::HatchFilter y pvt::assemble_epoch_precise_smoothed, la forma sin divergencia (libre de ionosfera) en el ensamblado preciso de punto único. MODELLED con un hallazgo registrado: en la estación del IGS WTZR reduce el error de punto único mediano de 1,55 m a 1,12 m y el percentil 95 de 3,47 m a 3,21 m, por debajo de la reducción preregistrada del 40 % (el error restante es de tipo sesgo, no ruido).

• PPP flotante sobre RINEX real (0,36, WP-07): ppp_real::run_ppp, un filtro de posicionamiento de punto preciso flotante estático sobre código y fase GPS de doble frecuencia reales con productos finales del IGS (desfases y variaciones de antena, marea terrestre sólida, wind-up de fase, retardo de Shapiro, retardo húmedo estimado, detección de saltos de ciclo), con parse_antex_receiver. VALIDATED en la estación reservada del IGS WTZR frente a su coordenada ITRF2020 con umbrales preregistrados: tras 6 h el error es de 1,5 mm en horizontal y 2,9 cm en vertical, y cada época de las dos últimas horas está dentro de 10 cm.

• Interpolación de reloj preciso SP3 (0,36, WP-07): Sp3File::clock_s y clock_nodes interpolan linealmente los relojes de satélite tabulados de SP3 entre los dos nodos válidos que los acotan (se omite el centinela de reloj erróneo), y ClockRinex::from_sp3 los entrega a PreciseProducts, de modo que la cadena precisa funciona solo con un SP3. VALIDATED frente a los relojes finales de 30 s del IGS del 2025-02-24 con umbrales preregistrados: 32 satélites GPS, RMS en el punto medio 0,121 ns (umbral 0,15 ns), percentil 95 0,265 ns (umbral 0,30 ns).

• RAIM junto a las cifras de mérito de holdover del reloj (CAP-05b): una sección opcional [integrity] en el tipo de escenario clock informa de un bloque integrity_fom aparte (RAIM instantáneo sobre un cielo predefinido desde un sitio declarado: veredicto por época y niveles de protección, disponibilidad; no disponible mientras se deniega el GNSS, nunca extrapolado). Las cifras de holdover no cambian; sin la sección la salida es idéntica byte a byte. MODELLED.

• Umbrales de receiver-trust calibrados con JammerTest 2024 (CAP-13): una calibración preregistrada de los monitores de caída de C/N0, AGC e indicador de jamming con el conjunto de datos público JammerTest 2024 (obtenido en tiempo de ejecución, nunca incorporado; examples/jammertest_trust_calibration.rs), distribuida solo como el [monitors] profile = "jammertest-2024-calibrated" opcional (1,5 dB, 3,5 sigma, 29). Con conjunto reservado: los umbrales de AGC, indicador de jamming y unión pasan; el umbral de falsa alarma de C/N0 falla (0,023 frente a 0,02), por lo que la fila es MODELLED (xval/jammertest-trust/RESULTS.md). Los valores predeterminados y las salidas sin el perfil no cambian.

• Hipótesis de fallo ARAIM con varios satélites (CAP-05a): la regla de subconjuntos de ADD v4.2 generalizada más allá de los pares (add_v42_subset_plan, add_v42_protection_levels_to_order; el orden 2 es exactamente la vía existente comprobada con MAAST) y un RAIM avanzado opcional sobre esas hipótesis (araim_subset_raim), que informa del subconjunto de mayor separación cuando se detecta un fallo. Las probabilidades a priori que necesitan subconjuntos más profundos se rechazan, nunca se truncan. MODELLED.

• Línea del horizonte en receiver trust (FUT-01): una sesión de receiver-trust puede declarar una [skyline]; los satélites detrás de ella se pierden para el cielo (sky-blocked, behind_skyline, open_fraction) y sus pérdidas se clasifican como geometry, nunca environment; sin ella, la alternativa por huecos de acimut y todas las salidas son como antes. El generador de entrenamiento de tripulaciones incorpora un evento natural-degradation (un cielo bloqueado, no interferencia) y el escenario scenarios/training/fjord-natural-degradation.toml. El Monte Carlo de UERE x DOP incorpora las dos geometrías de línea del horizonte enmascarada de la nota de diseño, preregistradas por separado: las 26 comprobaciones pasan.

• Verificación de sellos de tiempo RFC 3161 (CAP-14): kshana::evidence::tsa::verify_token comprueba la firma de un token de sello de tiempo (RSA PKCS#1 v1.5, RSA-PSS, ECDSA P-256 y P-384), su vínculo ESS con el certificado de firma, el uso timeStamping del firmante y su cadena hasta un ancla de confianza en el genTime del token, sin conexión; kshana evidence verify --tsa-ca <anchors.pem> la aplica al timestamp.tsr de un paquete (opcional; sin ella el informe no cambia). VALIDATED, de forma acotada: los 27 casos autogenerados coinciden con OpenSSL 3.0.13 en el veredicto y en el genTime, con una comparación preregistrada antes de escribir el verificador. No se comprueba la revocación.

• Niveles de verificación por cifra para cada tipo de escenario (RM-04): el resultado de cada tipo de escenario ahora termina con un bloque figure_tiers que nombra sus cifras principales, la fila de la matriz de verificación que es propietaria de cada una y el nivel leído de esa fila (las cifras que ninguna fila posee se listan como sin nivel). El bloque se añade tras la ejecución y se retira para volver al documento anterior byte a byte (api::without_figure_tiers). lunar-station-coverage no tiene figure_tiers hasta que una nueva predicción fechada sustituya a la congelada; leo-ppp, solar-system, sweep y sweep-nd no tienen cifra principal escalar, y lunar-attack-surface escribe JSON compacto. Los miembros de campaña conservan sus documentos sin nivel.

• Preajuste cuántico quantum-cai-coast (CAP-08c): un escenario inercial incluido en el que un acelerómetro interferómetro de átomos fríos, especificado por la física de su interferómetro ([accel_quantum.cai] con un nivel de vibración de plataforma declarado), navega por inercia frente a un acelerómetro de cuarzo de grado de navegación durante una interrupción del GNSS de 110 minutos. MODELLED.

• Grados de libertad equivalentes exactos de Greenhall (CAP-03): allan::edf_greenhall, el algoritmo completo de Greenhall y Riley (2003) (órdenes de diferencia 1 a 3, exponentes de ruido de +2 a -4, con y sin solapamiento, modificado y sin modificar, con las tablas de J grande), con envoltorios de ADEV, MDEV y HDEV. VALIDATED con una comparación preregistrada con allantools 2024,6: 4.876 puntos de la cuadrícula dentro de 6.0e-13 relativo; allantools falla en 32 puntos más, que se registran sin valor de referencia independiente. Los intervalos de confianza de assurance::uncertainty no cambian bit a bit.

• Términos de error del interferómetro de átomos fríos (RM-26/27/28): ruido de fase del láser Raman (con el término de retardo de retrorreflexión), el sesgo por curvatura del frente de onda de una nube térmica (desenfoque puro, con un radio de detección) y la resolución de la ambigüedad de franjas (asistida por clásico y con dos tiempos de interrogación), como funciones de biblioteca en src/inertial/cai_error_terms.rs, cada forma cerrada comprobada frente a cuadratura o Monte Carlo. MODELLED; todavía no accesible desde un tipo de escenario (docs/QUANTUM-MODELS.md).

• Formatos de registro de reloj (RM-03): src/clock_log.rs lee archivos de reloj RINEX, registros ASCII de fase o frecuencia al estilo TimeLab y registros de contador TICC de TAPR en una única serie de fase normalizada (tau0 declarado o hallado, huecos contados, una política de huecos). Opcional: una serie de temporización de telecomunicaciones puede nombrar un registro ([series.clock_log]), y la tabla [clock_log] de un escenario de reloj añade un bloque measured (ADEV, TDEV, MTIE). Sin la tabla, ambos tipos de escenario son idénticos byte a byte (docs/CLOCK-LOG-FORMATS.md). Una comparación preregistrada con tres registros sintéticos alcanzó sus umbrales de fase y de conexión; los estimadores coinciden con allantools hasta 2.5e-14 allí donde este evalúa, y no evalúa el punto de MTIE del registro completo (registrado). MODELLED.

• Máscaras de wander de sincronización de frecuencia (RM-01): el tipo de escenario telecom-timing incorpora siete máscaras de generación de wander de MTIE y TDEV a temperatura constante, ITU-T G.811 PRC, G.812 Tipos I a III, G.8262 EEC Opciones 1 y 2 y G.8262.1 eEEC, con los tramos de ley de potencias que escriben las tablas, y el escenario de referencia scenarios/telecom-synce-eec.toml (un OCXO en funcionamiento libre frente a las máscaras EEC: falla a 1.000 s, donde debe trabajar un lazo). Cada fila se releyó frente al texto de itu.int; G.812 (06/2004) ha sido sustituida por una edición prepublicada de 08/2026 que no pudo leerse. MODELLED (una transcripción); las máscaras y salidas existentes no cambian.

• Orientación sobre el a priori del filtro para el tipo de escenario gnss-ins (0,36, WP-09, hallazgo RM-21): el a priori de filtro predeterminado del paquete es adecuado para una IMU de grado táctico. Con una IMU de grado de navegación, el valor predeterminado puede empeorar la navegación por inercia fusionada respecto a un INS libre: 52 m frente a 11 m en un perfil de aeronave de 70 m/s. Establezca [imu_*.filter_prior] para que coincida con el grado del sensor, como hacen los nuevos paquetes marítimo, ferroviario y de aviación. Ningún escenario incluido combina una IMU de grado de navegación con el a priori predeterminado: todos los que usan el valor predeterminado tienen sesgos residuales del acelerómetro de al menos 0,015 m/s². Solo documentación; ninguna salida cambia.

• Exportación para test bench comprobada con los propios lectores de un simulador (0,36, WP-09, CAP-16): los archivos de movimiento de kshana bench-export de 8 escenarios incluidos se leyeron de vuelta con los lectores de NMEA, latitud/longitud/altura y movimiento ligado a la Tierra de gps-sdr-sim (MIT, commit 28ca29a6, usado como herramienta aparte mediante xval/testbench-gpssdrsim/; no se invoca ninguna función de señal). Devuelven la trayectoria exportada con 1,2 mm, 0,15 mm y exactamente. HALLAZGO: el lector de movimiento ligado a la Tierra de ese simulador no puede aceptar el CSV de ancho completo, porque su búfer de línea de 100 caracteres divide cada fila. docs/TEST-BENCH.md ahora indica los cortes de columna que hay que usar y el límite de 300 s del simulador. VALIDATED (nueva fila del registro); los bytes de la exportación no cambian.

• GNSS/INS con el conjunto de datos KF-GINS (0,36, WP-09, FUT-17): cargadores y ejecutor de fusion::kfgins y el modelo de medida del brazo de palanca en el EKF de lazo cerrado. Con el conjunto de datos de demostración de KF-GINS (obtenido en el momento de la prueba, no incorporado), el RMS horizontal de Kshana frente a la trayectoria de referencia es de 1,09 cm frente a los 1,11 cm del propio KF-GINS, y todos los umbrales preregistrados se mantuvieron. VALIDATED con evidencia condicionada a datos (decisión del propietario, 2026-10-13): el conjunto de datos se obtiene con SHA-256 fijados y la vía de reproducción está en xval/kfgins/PREREGISTRATION.md.

• Filtro PNT acoplado en el paquete de fusión (0,36, WP-09, FUT-16): el tipo de escenario fusion admite una tabla opcional [coupled] que ejecuta un único filtro apilado sobre pseudodistancias con un estado de sesgo del acelerómetro (fusion::coupled::CoupledPntBiasFilter), y fusion::coupled::CoupledPnt3d es la versión 3-D de 8 estados. Nuevo escenario incluido fusion-pnt-coupled: con acelerómetros sesgados, el modo acoplado mantiene la posición de la suite cuántica en 18,7 m (percentil 95) con integridad completa, donde los filtros desacoplados llegan a 430 m. Sin la tabla, tanto fusion como hybrid no cambian (fijado); hybrid rechaza la tabla. MODELLED.

• Paquetes GNSS/INS marítimo, ferroviario y de aviación (0,36, WP-09, RM-21): escenarios incluidos gnss-ins-maritime, gnss-ins-rail y gnss-ins-aviation sobre la biblioteca de trayectorias, y una tabla opcional [tight] para el tipo de escenario gnss-ins que fusiona pseudodistancias de una constelación Walker SGP4 (todos los satélites en condición nominal, los pocos más altos cuando está degradado). En el paquete ferroviario, el acoplamiento estrecho mantiene la solución de grado de navegación en 5,3 m a través de una trinchera y un túnel, frente a 12,9 m con acoplamiento débil. Sin [tight] el paquete no cambia (fijado). MODELLED.

• Acoplamiento estrecho con fase de portadora (0,36, WP-09, RM-25 / FUT-17): fusion::carrier_tc, un EKF de estado de error con un reloj de receptor explícito de dos estados y ambigüedades de portadora flotantes, accionado por una constelación Walker SGP4 con correcciones de Klobuchar y Saastamoinen en el lazo de medida, detección de saltos por portadora diferenciada en el tiempo y reinicialización de ambigüedades, y una ejecución solo con código sobre las mismas medidas a modo de comparación. MODELLED: en un recorrido figure-8 la solución con portadora es de 2,5 cm frente a 47 cm solo con código, y NIS/NEES son coherentes entre semillas.

• Biblioteca de trayectorias GNSS/INS (0,36, WP-09, RM-24): el tipo de escenario gnss-ins admite una tabla opcional [trajectory] con profile = "straight" | "figure8" | "stop_go" | "aircraft" | "uas" | "csv". Los perfiles ordenan velocidades de Euler y aceleración a lo largo de la trayectoria a partir del estado verdadero y derivan la IMU verdadera a partir de la cinemática de sólido rígido (giros coordinados, ascensos, Coriolis); csv importa una trayectoria verdadera (t, lat, lon, alt, vn, ve, vd, roll, pitch, yaw) y resuelve la IMU que la reproduce. Sin la tabla, el paquete vuela su recorrido histórico, bit a bit (fijado). MODELLED.

• Teselas DEM de latitud/longitud para el horizonte lunar: [terrain] dem_tile_path lee una tesela de texto realdata::lola_dem (alturas sobre la esfera media en una cuadrícula de latitud/longitud) en lugar de la estereográfica polar dem_path, tanto para lunar-station-coverage como para moonlight-service-volume; el informe repite la tesela (terrain.dem_tile, con su SHA-256). realdata::lola_dem ahora está conectado al avance de rayos del horizonte. Una tesela remuestreada a partir del recorte incluido da a la estación el horizonte del recorte hasta 0,22 deg. MODELLED.

• Terreno en el sitio de exportación del volumen de servicio: con una sección terrain, cada fila de la exportación de geometría por satélite de moonlight-service-volume incluye clears_terrain (el satélite supera la máscara plana y el horizonte del sitio de exportación en su acimut), el informe incluye el horizonte del sitio (export_site_terrain), y el CSV de tiempo de ejecución incorpora la columna. Sin terreno, la exportación no cambia. MODELLED.

• Campos principales desde el motor (0,36, STUDIO-06): kshana::api::HEADLINE_FIELDS, field_importance_json() y el field_importance() de WebAssembly indican, para doce tipos de escenario, qué campos de un escenario responden a su pregunta, los mejores primero, como rutas con puntos (jammers[].eirp_dbw). Studio los lee antes que su propia clasificación. Solo metadatos de presentación: el motor nunca los lee, ningún archivo de escenario los necesita, ningún resultado depende de ellos. tests/field_importance.rs falla si un tipo de escenario no es despachable o si una ruta no se encuentra en ninguno de los escenarios incluidos del tipo (detectó dos rutas que los identificadores aplanados de Studio habían escrito sin los corchetes de matriz).

• Tabla de tipo de escenario a módulo desde el motor (0,36, STUDIO-05): kshana::api::KIND_MODULES, kind_modules_json() y el kind_modules() de WebAssembly dan, para cada tipo de escenario cuyas filas de la matriz de verificación nombran un módulo distinto del suyo, los nombres de módulo. El mapa de capacidades de Studio usaba su propia copia escrita a mano; tests/kind_modules.rs falla si un tipo de escenario de la tabla no es despachable o si un módulo no aparece en ninguna fila de la matriz. Ninguna salida cambió.

• Ejecución IQ corta en la compilación para navegador (0,36): iq_signals() y iq_run_short(fs_hz, duration_s, signal, ids, dopplers_hz, cn0_dbhz, seed) en el módulo WebAssembly construyen una escena sintética, adquieren cada satélite y siguen los adquiridos, todo en memoria, limitado a 0,25 s, 1.000.000 muestras y 8 satélites. El constructor de escenas y la búsqueda de señales por nombre se trasladaron fuera de iq::cli, exclusivo de la versión nativa (a iq::scene::synthetic y iq::signals::by_name), de modo que ambas compilaciones los comparten; la salida de la línea de comandos no cambia. La prueba nativa y web/smoke.mjs comparan la misma solicitud con un único valor de referencia (tests/fixtures/iq_short_golden.json), byte a byte: desde el cambio de matemáticas portables (STUDIO-15, más abajo) la compilación para navegador y la nativa dan los mismos bits.

• API tipadas de Python y TypeScript (CAP-34): kshana.pyi tipa los vocabularios cerrados (ScenarioKind, el nombre de cada tipo de escenario; ErrorKind; ProvenanceClass) y los diccionarios KindMeta y FieldUnit; scenario_kinds() y error_kind() los devuelven. El paquete WebAssembly añade run_typed (una ejecución como objeto RunOutput tipado con el documento analizado como data) y scenario_kinds (el KindMeta[] analizado), y su kshana.d.ts incluye el mismo vocabulario; error_kind se tipa como ErrorKind | "". tests/typed_api_sync.rs mantiene ambas listas iguales a las del motor.

• Unidades para cada columna de sweep-nd (FUT-28): un resultado de sweep-nd ahora incluye key_units y metric_units, la unidad de cada clave barrida y de cada métrica registrada, leídas de la propia tabla de unidades del paquete barrido. Un eje puede declarar unit para una clave que el paquete no repite; una unidad declarada que contradice la del paquete se rechaza, y una unidad que ninguno aporta es null, nunca supuesta. points[].coords[] y points[].metrics[] están descritos, de modo que cada uno de los 76 tipos de escenario queda ahora totalmente cubierto por la puerta de unidades de campo (techo de tipos de escenario sin cubrir 1 -> 0).

• Matrices NumPy desde RunOutput (FUT-26): el RunOutput de Python incorpora array(path), columns(path) y series(), que devuelven numpy.ndarray para una lista numérica, las columnas numéricas de una lista de registros o cada serie de registros del documento. Cada matriz es igual a numpy.asarray de los mismos valores de data() (dtype y bits). NumPy se importa solo cuando se llama a una de ellas y no figura en los requisitos de ejecución. Tipado en kshana.pyi y comprobado con stubtest.

• Optimizador de campañas (CAP-32): la nueva sección opcional [optimize] del tipo de escenario campaign busca una a tres claves de escenario dentro de límites declarados para el mejor valor de una métrica: minimizar, maximizar o alcanzar un objetivo. Busca de forma exhaustiva en una cuadrícula, o con un símplex de Nelder–Mead acotado determinista. Cada evaluación es una ejecución real del tipo de escenario nombrado y se lista en el trace del resultado. Ejemplo: scenarios/campaign-optimize-link-budget.toml. Los umbrales se preregistraron (docs/design/evidence/cap32-optimize/):

  • la función de Rosenbrock se alcanza (f* = 1.7e-20);
  • una resolución de objetivo 1-D de forma cerrada se alcanza (6e-15 relativo);
  • la cuadrícula es igual bit a bit a una fuerza bruta independiente;
  • el símplex lo hace al menos tan bien como una cuadrícula de 41 × 41 en 177 ejecuciones.

  El umbral 1-D de la ronda 1 se registra como NOT MET, porque el recuadro preregistrado excluía la solución. MODELLED; fila del registro "Optimización acotada de una métrica sobre parámetros de campaña". Aditivo: las campañas sin la sección no cambian.

• Conjuntos de calibración (CAP-10): tres comprobaciones de una sola semilla repetidas con 200 semillas independientes frente a umbrales preregistrados, en docs/CALIBRATION-ENSEMBLES.md (generado por gen_calibration_ensembles; valores por semilla en docs/data/calibration-ensembles.csv).

  • El intervalo del 95 % del bootstrap del Monte Carlo de campaña cubre la media verdadera en 192 de 200 conjuntos, y su comprobación de chi cuadrado pasa en 196.
  • La tolerancia de percentil de una sola semilla pasa solo en 183 de 200: NOT MET, como se había predicho. Es un umbral de unos 2 sigma, registrado y no relajado.
  • Las calibraciones de ADEV de FM blanca pasan en cada semilla, con su peor error muy por dentro de la tolerancia.

  MODELLED.

• Tipos de escenario integrados mediante el trait Scenario (FUT-27, en curso): el trait BuiltinKind (api::BuiltinKind, con un gancho de nivel por cifra y append_figure_tiers), y los primeros tipos de escenario trasladados a él (inertial, spoof, passes, link-budget, jamming). La salida no cambia: un manifiesto de todo el catálogo con el SHA-256 de cada salida es idéntico antes y después (tests/scenario_output_manifest.rs).

• Comprobación de no descarga del playground (RM-07): tests/playground_no_fetch.rs comprueba tres cosas:

  • cada escenario de la biblioteca de Studio está en el paquete del navegador;
  • el paquete es idéntico byte a byte a scenarios/;
  • cada escenario del navegador se ejecuta desde un directorio de trabajo vacío.

• Mapas de Alt-PNT: campo gravitatorio real, Monte Carlo de error de mapa, SRTM a resolución completa (0,36, WP-10). El tipo de escenario gravity-map admite un [reference] opcional: una anomalía gravitatoria sintetizada a partir de los coeficientes EGM2008 incluidos (o de un archivo .gfc de ICGEM mediante gfc_path, solo en compilaciones nativas). Esa síntesis coincide con el ICGEM Calculation Service hasta unos 1e-8 mGal en 794 nodos de dos regiones, frente a umbrales preregistrados de 0,005 mGal de RMS y 0,02 mGal de máximo (VALIDATED; fila del registro "Síntesis de anomalías gravitatorias a partir de un modelo de armónicos esféricos"). El nuevo escenario incluido gps-denied-gravity-nav-egm2008 ejecuta el benchmark de 60 minutos sobre ese campo real de grado 70. Resultado preregistrado: error de correlación 3106 m, por lo que el umbral de < 500 m es NOT MET, como se había predicho (el grado 70 es demasiado suave), y la reducción por un factor de diez de la deriva es MET (MODELLED). Una tabla opcional [map_error_mc] repite el benchmark con errores de mapa gaussianos correlacionados y con semilla, e informa de la distribución del error de correlación (escenario incluido gravity-map-error-mc). Exploratorio y no preregistrado: con un error de mapa de 2 mGal correlacionado en 0,2 deg (el tamaño que presupuesta la propia sigma del correlador), 1 de 20 realizaciones se mantiene dentro de 500 m (mediana 2,9 km, p95 14,7 km), frente a 144 m con un mapa perfecto. La solución de menos de 500 m del benchmark sintético supone que el mapa es exacto. Sin ninguna de las dos opciones, el documento es idéntico byte a byte al de versiones anteriores. combined-altpnt admite un [magnetic_grid] opcional (csv_path, column) que lee el canal magnético de un CSV en formato EMAG2v3. EMAG2 no se incorpora porque sus términos no son explícitos: tools/fetch_emag2_tile.py lo obtiene con un SHA-256 fijado y recorta un recuadro. No se afirma ningún resultado de navegación sobre la cuadrícula real de EMAG2. Estimación conjunta del mapa (SLAM de terreno, RM-18): altpnt::sequential::run_sequential_trn_on_map hace volar el navegador secuencial de terreno sobre un mapa almacenado que difiere de la verdad, ya sea confiando en él o estimando una corrección de mapa por celda con un filtro Rao-Blackwellizado al estilo FastSLAM. Preregistrado frente a SITAN con mapa conocido con un error de mapa correlacionado de 15 m en 20 semillas: una ganancia media del 1,5 %, mejor en 10 de 20, por lo que ambos umbrales de mejora son NOT MET (10 % y 12 de 20), sin perjuicio con un mapa perfecto (MET). Una sola pasada sin revisitas no permite aprender el mapa (xval/terrain-slam-rbpf/, MODELLED). Los documentos de terrain-slam son idénticos byte a byte. Las pruebas con SRTM real ahora se ejecutan en CI sobre dos recortes confirmados a resolución completa; todos los umbrales preregistrados se alcanzan, con el nodo más cercano igual a GDAL 3.8.4 en 8 de 8 puntos (xval/srtm-ungate/).

• Interoperabilidad, WP-08 (0,36; cada elemento preregistrado y confirmado por separado antes de su ejecución de referencia independiente, cada uno una nueva fila VALIDATED del registro, salvo el elemento de telemetría, que amplía una fila existente):

  • Mensajes de datos de órbita CCSDS (src/odm.rs): OPM 3.0/2.0, OMM 3.0/2.0 y OCM 3,0 (bloques TRAJ, PHYS, COV, MAN, USER) escritos y leídos en KVN y NDM/XML, y un OMM de precisión completa a partir de un conjunto de elementos SGP4 (OmmMessage::from_omm_file); la salida de OmmFile::to_omm_kvn no cambia. Frente a Orekit 13.1.8 en ambos sentidos: 27 de 30 mensajes de Kshana se analizan en Orekit y Kshana lee todos los escritos por Orekit, con valores dentro de 1e-14 relativo y épocas dentro de 1e-9 s; cuatro hallazgos fijados (Orekit exige ELEMENT_SET_NO, rechaza COMMENT en los parámetros definidos por el usuario en XML, no escribe BTERM sin BSTAR, y lee las épocas relativas de OCM en TDB en segundos SI). El META_START del escritor OMM heredado es rechazado por Orekit (registrado). Fila "Mensajes de datos de órbita CCSDS (OPM, OMM, OCM)".
  • Mensajes de datos de actitud CCSDS (src/adm.rs, src/ndm_xml.rs): AEM 2.0/1.0 y APM 2,0 en KVN y XML frente a Orekit 13.1.8, todos los umbrales alcanzados; el escritor APM de Orekit rechaza una maniobra sin MAN_DELTA_MASS (fijado). Fila "Mensajes de datos de actitud CCSDS (AEM, APM)".
  • Exportación SPICE SPK (src/spk_writer.rs): escritor y lector de SPK de tipos 9 y 13 y exportación de OEM a SPK; frente a CSPICE N0067 los kernels son idénticos byte a byte a los de SPICE y se evalúan de forma idéntica bit a bit. Fila "Exportación SPICE SPK (tipos 9 y 13)".
  • SPICE SPK de tipos 3 y 21 (src/spk_writer.rs): segmentos de tipo 3 (Chebyshev) y de tipo 21 (líneas de diferencias extendidas) escritos a partir de registros dados y evaluados como lo hace SPICE; frente a CSPICE N0067 los kernels son idénticos byte a byte a los de SPICE y cada evaluación coincide bit a bit en ambos sentidos. Fila "SPICE SPK de tipos 3 y 21 (Chebyshev, líneas de diferencias extendidas)".
  • Extensiones de Space Packet (src/space_packet.rs): cabecera secundaria con códigos de tiempo CUC/CDS, control de errores de paquete, segmentación y comprobaciones de flujo, frente a ccsdspy 2.0.1, spacepackets-rs 0.18.0, spacepackets-py 0.32.0 y crc_hqx de CPython, con cero discrepancias. Fila "Cabecera secundaria, control de errores de paquete y segmentación de CCSDS Space Packet".
  • Esquema de telemetría 1,3 mediante consumidores reales: la exposición Prometheus y el JSON OTLP/HTTP de un flujo sintético de esquema 1.3, incluida la serie de geometría y la etiqueta class, leídos exactamente por prometheus_client y el proto de OTLP, aceptados por promtool 3.5.0 check metrics sin ningún problema de lint, y pasados sin cambios por el OpenTelemetry Collector contrib 0.135.0 (condicionado a datos: herramientas obtenidas con SHA-256 fijados, salidas confirmadas).

• Determinación de órbita de Marte, ejecución 2 (0,36, WP-14, CAP-30): mars_od::fit_damped escala la matriz normal por su diagonal y amortigua el paso (Levenberg-Marquardt), después de que el ajuste de Gauss-Newton registrado fallara con una matriz cuya diagonal bruta abarca ocho órdenes de magnitud. Registrado por separado (xval/mro-od/PREREGISTRATION-RUN2.md, mismo arco, umbrales y edición). En los pasos de MRO puntuados, la órbita está a 0,36 km de RMS (0,53 km como máximo) de la reconstrucción de navegación de MRO, umbrales alcanzados. El Doppler posajuste es 48,6 mHz frente al umbral de 30 mHz, no alcanzado (hallazgo fijado). Una enmienda solo de puntuación, R2-A1, se declara en docs/revisions. La fila sigue siendo MODELLED.

• Modelo Doppler 2-way con rampa de Marte y determinación de órbita (0,36, WP-14, parte de CAP-30, etapa 2): mars_od predice el Doppler 2-way en banda X con rampa de la DSN a partir de las tablas de rampa de ODF (tiempo de luz, Shapiro, troposfera, hora de estación, estaciones de la DSN mediante la cadena del CIO y EOP del IERS) y ajusta un orbitador de Marte (GMM-3, terceros cuerpos, SRP, arrastre). naif_kernel lee SPK de tipo 1 (comprobado frente a CSPICE) y gravity_sh::from_shadr lee campos SHADR de PDS. Preregistrado frente a la reconstrucción de navegación de MRO con pasos reales de MRO (condicionado a datos, scripts/fetch_mro_od.sh, CI mensual): el Doppler predicho coincide con las observaciones hasta 12,5 mHz (umbral 30 mHz, alcanzado); el ajuste de órbita registrado falló en el arco puntuado y no produjo ninguna órbita (hallazgo fijado). La fila sigue siendo MODELLED.

• Lector de Orbit Data File de la DSN (0,36, WP-14, parte de CAP-30): odf::parse_odf lee ODF TRK-2-18. Con un ODF real de Mars Reconnaissance Orbiter (NASA PDS, incorporado), el lector coincide con el recuento de registros, las posiciones de grupo, las estaciones y las horas de la etiqueta de PDS, y todos sus tipos de datos son conocidos. La tabla de fin de archivo de la etiqueta tiene una fila menos que el archivo, una inconsistencia de la etiqueta registrada como hallazgo. MODELLED. Todavía no se ha hecho la determinación de órbita con estos datos.

• Presupuesto de TWSTFT y estabilidad de transferencia de tiempo: el tipo de escenario time-transfer-budget (0,36, WP-14, FUT-19).

  • Ecuación bidireccional: twstft_budget la resuelve para T_A − T_B con retardos de equipos de estación, la asimetría ionosférica ascendente/descendente en banda Ku, la diferencia de retardo del transpondedor y los términos de Sagnac, y recupera el modelo directo hasta 1e-15 s.
  • Presupuesto de incertidumbre: combinado en cuadratura, con el TDEV del enlace como término de tipo A.
  • Ruido del enlace: la serie bidireccional incorpora un piso de ruido de fase flicker, una no reciprocidad diurna y un residuo de reciprocidad constante. El paquete timetransfer de jitter blanco no cambia.
  • Serie real: la estabilidad de series aportadas de la Circular T del BIPM, CSV MJD,ns o de reloj de estación del IGS.

  MODELLED. Nuevo escenario incluido time-transfer-budget. La solución de tiempo PPP está VALIDATED por separado frente al reloj de estación del IGS en la rama de datos reales de GNSS.

• Calentamiento de entrada, radiometría de observación de la Tierra y pérdidas de ascenso (0,36, WP-14, CAP-28): tres nuevos tipos de escenario.

  • entry-heating: una entrada de masa puntual de 3 grados de libertad sobre una Tierra o un Marte en rotación con calentamiento en el punto de estancamiento de Sutton-Graves.
  • eo-radiometry: SNR del generador de imágenes, MTF en Nyquist, respuesta relativa de borde y NIIRS de GIQE 4.
  • ascent-losses: un ascenso con viraje por gravedad de varias etapas con pérdidas por gravedad, arrastre, dirección y contrapresión, comprobado mediante la identidad exacta de dv ideal menos pérdidas.

  La deceleración máxima de la entrada se comprobó frente al valor nominal publicado de Stardust con un umbral preregistrado: 35,44 g frente a 33,4 g (+6,1 %, umbral 10 %). Esa fila es VALIDATED. El calentamiento, la radiometría y el ascenso son MODELLED. También son nuevos: reentry::us76_pressure, los escenarios incluidos entry-heating-stardust, eo-radiometry y ascent-losses, y docs/ENTRY-EO-ASCENT.md.

• Control de actitud con ruedas de reacción: el tipo de escenario aocs (0,36, WP-14, CAP-21). Un giro de apuntamiento inercial de un cuerpo rígido con tres o más ruedas de reacción equilibradas bajo realimentación MRP, con pares de rueda de norma mínima recortados al límite de cada motor (aocs). También puede cerrar el lazo sobre un EKF multiplicativo a partir de un giróscopo y un seguidor estelar simulados (aocs_mekf). El lazo de estado verdadero se comparó con Basilisk 2.9.1 en tres casos preregistrados antes de que existiera el código (tres ruedas ortogonales, una pirámide de cuatro ruedas, un caso de saturación). Cada componente MRP, velocidad del cuerpo, velocidad de rueda y par motor coincidió en cada muestra, con un peor caso de 2.4e-14 en sigma y 2.9e-11 rad/s en velocidad de rueda. Esta fila es VALIDATED; el MEKF es MODELLED (coherencia NEES). Nuevos escenarios incluidos aocs-slew y aocs-slew-mekf, y docs/AOCS.md.

• Planificación de contactos con tierra y ACM de DVB-S2 (0,36, WP-14, CAP-22/23): dos nuevos tipos de escenario. acm-link da, para un satélite sobre una estación, el Es/N0 de cada paso y el MODCOD de DVB-S2 elegido a lo largo de él (umbrales de la Tabla 13 de ETSI EN 302 307-1 más un margen). También da el volumen de datos que mueve el ACM frente a la línea base de codificación constante. contact-schedule hace lo mismo para varios satélites sobre varias estaciones y construye un plan de contactos sin conflictos (tiempo de reorientación de la antena, una estación por satélite, entrega ponderada por prioridad limitada a cada acumulación pendiente). Informa de un plan voraz de valor marginal, una línea base por orden de llegada y el óptimo exacto en conjuntos pequeños, con la brecha de optimalidad del voraz. Las ventanas de acceso proceden del predictor de pasos aparentes VALIDATED. Nuevos escenarios incluidos acm-link y contact-schedule (entradas ilustrativas) y docs/CONTACT-SCHEDULING.md. MODELLED (dos nuevas filas del registro).

• Posicionamiento Doppler con Starlink frente a un experimento publicado (0,36, WP-14, parte de CAP-11, MODELLED). Es una comparación indirecta preregistrada del modo Doppler de leo-pvt con el preajuste starlink-sop frente a los percentiles del conjunto de datos 3 de "Unveiling Starlink for PNT" (NAVIGATION 72(1), 2025, doi:10.33012/navi.685). El modelo usó 3 satélites (una máscara de 47 deg elegida con una regla fija), sin ayuda de altura y con una sigma Doppler de 30 Hz, con 200 semillas. Su error 3-D del percentil 90 es 92,2 m a 20 s y 870 m a 8 s, frente a los 2 m y 10 m publicados, por lo que ambos umbrales de factor dos son NOT MET. El modelo es pesimista, no optimista como se había predicho: tres satélites fijos dan mucha menos diversidad geométrica que los 63 satélites del experimento durante 10 minutos con cambio de canal cada 15 s. Ambos fallos se afirman (tests/starlink_doppler_published_proxy.rs).

• Optimizador de transferencias impulsivas sobre DE440 (0,36, WP-14, CAP-20c/d): maneuver::optimise_transfer_kernel halla las fechas de salida y llegada de una transferencia balística de dos impulsos de una sola revolución que minimizan el C3 de salida o el V-infinito de llegada dentro del Tipo I o el Tipo II. Busca en una cuadrícula de 2 días y luego refina con Nelder-Mead 2-D, sobre estados heliocéntricos del kernel DE440; se apoya en porkchop_kernel. La comparación se preregistró (bf0439e8) frente a un optimizador independiente con SPICE + pykep 3.0.1 + SciPy 1.18.1 sobre la oportunidad Tierra-Marte de 2026: las cuatro optimizaciones coinciden hasta 8.7e-13 relativo, con fechas dentro de 1e-5 días (VALIDATED, nueva fila del registro). Como referencia publicada secundaria, NASA/TM-2010-216764 (el manual Tierra-Marte 2026-2045) coincide en el C3 mínimo del Tipo II (9,182 frente a 9,144) y en el V-infinito de llegada mínimo del Tipo II (2,564 frente a 2,565). Su C3 mínimo del Tipo I no coincide: 10,535 frente a 11,11 (-5.18 %), donde la referencia independiente de la biblioteca coincide con Kshana. Ese fallo se registra y se afirma.

• Estudio de la estación de referencia lunar (0,36, motivado por material publicado sobre una estación de referencia prevista en el polo sur lunar; fuentes en docs/LUNAR-REFERENCE-STATION.md): el tipo de escenario lunar-station-coverage, un barrido de Monte Carlo del modelo de PNT diferencial lunar sobre una cuadrícula de usuarios polar sur y un día de épocas, que da por punto y sobre la región el error corregido y sin corregir por percentiles, la disponibilidad con sus motivos, la cobertura frente a un umbral declarado, los niveles de protección, el radio de cobertura por acimut y el presupuesto del enlace de correcciones. Se reduce exactamente a lunar-differential-pnt en un punto, una época y un ensayo; su aritmética se recalculó con numpy con un umbral preregistrado (posiciones y percentiles alcanzados; las correcciones de la estación no alcanzaron el suyo por redondeo de doble precisión, registrado). MODELLED; fila del registro "Mapa de cobertura y exactitud de la estación de referencia lunar". Sin afiliación ni respaldo de ninguna agencia; ninguna afirmación sobre el rendimiento de ningún sistema real.

• Predicción preregistrada: cobertura de la estación de referencia lunar (no es una validación; MODELLED). docs/predictions/lunar-reference-station.md congela, en el commit c05dac1d, los resultados de lunar-station-coverage bajo los supuestos declarados públicamente, con hashes SHA-256 de las entradas y los resultados y un protocolo de puntuación fijado ahora (factor 2 para exactitudes y niveles de protección, 10 puntos porcentuales para disponibilidad y cobertura; un supuesto modificado recibe una nueva predicción fechada, nunca una edición; un fallo se publica con tanta visibilidad como un acierto). Cada cifra está dominada por el conjunto de elementos no publicado de la constelación de cuatro satélites, que es ILLUSTRATIVE, y así se indica. tests/prediction_frozen.rs la protege; docs/VALIDATION.md incorpora una sección "Predicciones preregistradas". Ninguna fila del registro.

• Extensiones de la estación de referencia lunar (0,36; las limitaciones 2 y 3 del estudio de la estación y el estilo de solución de las fuentes), cada una opcional en lunar-station-coverage y ausente por defecto, de modo que todos los documentos existentes, incluida la predicción congelada, no cambian: [receiver] (multitrayecto a + b exp(-el / el0) en el usuario y en la estación, el de la estación opcionalmente de Gauss-Markov a lo largo de las épocas, ruido de código del DLL a partir del C/N0, sesgos entre canales; valores ILLUSTRATIVE en la Luna); orbit_err_growth_m_per_s (crecimiento lineal del error de la órbita difundida durante la latencia de la corrección, ILLUSTRATIVE); [solution] (restricción de altura, un mínimo de tres satélites con ella, una ventana de usuario estático a lo largo de las épocas). Dos anexos a la comparación con las afirmaciones publicadas, cada uno preregistrado por separado antes de su ejecución, se sitúan junto a la ejecución registrada sin editar: K5 con crecimiento falla a todas las tasas; con el estilo de solución de las fuentes, K1 a K5 fallan y K6 pasa (1 de 6), con el error 3-D corregido del percentil 95 de R300 bajando de 280,6 m a 2,11 m. MODELLED; tres filas del registro.

• Máscaras de horizonte del terreno lunar (0,36; la primera limitación del estudio de la estación de referencia lunar): una sección opcional [terrain] en lunar-station-coverage (la estación y cada punto de usuario) y moonlight-service-volume (cada punto de la cuadrícula) da a cada sitio un horizonte dependiente del acimut en el formato de tabla de línea del horizonte de 0,36, a partir de un perfil declarado etiquetado con su fuente (station_horizon, user_horizon) o un avance de rayos sobre un DEM polar (dem_path) a lo largo de círculos máximos de la esfera lunar con curvatura exacta, o ambos. Incorpora un recorte de 0,98 MB del DEM polar sur LRO LOLA LDEM_75S_240M de dominio público, remuestreado por media de bloques de 5 x 5 a 1200 m (data/lunar-dem/, con su NOTICE, SHA-256 y scripts/make_lola_south_polar_crop.py), y el escenario solo de repositorio scenarios/lunar-station-coverage-terrain.toml. Comprobado frente a horizontes de forma cerrada (esfera desnuda, cráter en una meseta, cono rasterizado); MODELLED, fila del registro "Máscaras de horizonte del terreno lunar a partir de un perfil declarado o un DEM polar". Sin la sección, todos los documentos, incluido el bloque de unidades, son idénticos byte a byte.

• Confianza consciente de la geometría (nota de diseño de geometría de 0,36, sección 4). Cada época de receiver-trust, estática o de buque, por lotes o en vivo, lleva su geometría de satélites: good, degraded (motivos few-satellites, high-pdop, high-hdop, e informativo sky-blocked) o unknown cuando el registro no da geometría de satélites, con HDOP, PDOP, VDOP y los satélites utilizados. Se deriva de las elevaciones y los acimuts que informa el receptor (NMEA GSV, UBX NAV-SAT) mediante el kernel orbit::dop existente, o se toma de NMEA GSA. Cada época también lleva una etiqueta, good, fair o poor, siempre informada y nunca puntuada, y una nota con el HDOP, el PDOP, el VDOP, el número de satélites y la pérdida de señal en palabras. La puntuación de un buque incorpora un monitor geometry que no descuenta nada salvo que la geometría sea mala (HDOP por encima de 4, PDOP por encima de 6 o menos de 5 satélites utilizados), y entonces aumenta gradualmente hasta un tope de 15 puntos; la geometría por sí sola alcanza como máximo la banda degradada, nunca la no fiable (sin alarma). Cada descuento recibe una clase, geometry, environment o inconsistency, de modo que un cielo malo no se lea como un ataque. loss-of-lock es geometry cuando los satélites perdidos estaban todos por debajo de 15 grados en su último informe; un descuento por mala geometría es inconsistency cuando el HDOP que declara el receptor discrepa de su cielo declarado en más de max(1,0, 25 % del HDOP derivado), de modo que un cielo malo falsificado no puede comprar la etiqueta. Una nueva tabla [geometry] declara cada umbral con su procedencia (HDOP 4, PDOP 6, al menos 5 utilizados, sigma_UERE 1,5 m, una tolerancia de HDOP de max(1,0, 25 % del HDOP derivado) con el 25 % como elección representativa para receptores con relojes por constelación o soluciones por subconjuntos, 15 grados; las cifras de IEC 61108-1 y de GPS SPS tal como se citan, por comprobar frente al texto de las normas). La pérdida total de señal no se etiqueta como cielo: cuando los satélites a la vista no se siguen y el DOP de los satélites a la vista es bueno (y los no seguidos no se concentran en una mitad del horizonte), la época lleva signal_loss y el descuento por geometría es environment. Un HDOP o PDOP declarado de 99 o más, una calidad GGA de 0 y un modo GSA de 1 se leen como ausencia de solución, no como DOP. El tope (cap_points 15), el final de la rampa (full_ratio 1,5) y el piso (floor, por defecto el degraded_min de la puntuación) están en [geometry], igual que los niveles buenos de la etiqueta (HDOP 2, PDOP 3, 6 satélites, representativos); el tope en vigor es min(cap_points, 100 - floor), de modo que una tabla [score] que eleve degraded_min (incluida una de 0,35) reduce el tope en lugar de ser rechazada, y un piso por debajo de degraded_min se rechaza. MODELLED; Software de carácter consultivo, no un equipo de navegación homologado (IEC 61108, IEC 61162): el operador sigue siendo responsable de la navegación del buque.

• La geometría llega a todas las superficies: el JSON de resultados (epochs[].geometry, class en cada descuento, geometry_model, geometry_summary), las líneas JSON en vivo (esquema 1,3), los receiver_trust de Python y WebAssembly, assess_vessel_log y receiver_trust_replay, las herramientas assess_* de MCP, los paquetes de evidencias (epochs.json, config.json, un carril de geometría en la página de resumen) y trust-telemetry (Prometheus kshana_trust_geometry* y una etiqueta class en kshana_trust_reason_active, OTLP kshana.geometry.*, campos personalizados de CEF cs6 (estado y clases de geometría), cfp3 (HDOP) y cfp4 (PDOP), comprobados con ambos analizadores de referencia independiente de CEF, y LEEF geoStatus, geoHdop, geoClass). La etiqueta de geometría también se exporta, añadida después de cada serie y campo anteriores y solo para las entradas que la llevan: Prometheus kshana_trust_geometry_label{label} y kshana_trust_geometry_vdop, OTLP kshana.geometry.label y kshana.geometry.vdop, LEEF geoLabel, geoPdop, geoVdop, geoUsed, y en CEF un tercer campo cs6 (la etiqueta) y cn1 (satélites utilizados); el VDOP no está en CEF (los campos personalizados de coma flotante están ocupados). Ambos analizadores de referencia independiente de CEF leen de vuelta los casos de etiqueta tal como se escribieron (enmienda 5: 176 líneas, 172 analizadas por pycef, 176 por Logstash). Un HDOP declarado que el cielo declarado no explica se señala en cada época y se cuenta (geometry_summary.hdop_mismatch, una línea en la página de resumen de evidencias), y se puntúa solo cuando la geometría es mala. La pérdida de señal se exporta por separado, ya que el estado de la geometría sigue siendo degraded mientras dura: Prometheus kshana_trust_geometry_signal_loss, OTLP kshana.geometry.signal_loss, LEEF geoSignalLoss=1; en CEF aparece como la clase environment en cs6.

• orbit::dop_cofactor: el factor de covarianza (HᵀH)⁻¹ que hay detrás de orbit::dop, extraído de él con la misma aritmética.

• Fila del registro "Error de posición por geometría: error RMS = sigma_UERE x DOP" (MODELLED, coherencia interna): un Monte Carlo con semilla de la solución de mínimos cuadrados del motor sobre las 8 geometrías DOP emparejadas con gnss_lib_py frente al factor de covarianza del kernel DOP validado, con tolerancias preregistradas antes de la primera ejecución y dos controles negativos que fallan como se requiere; junto a ella, una comprobación anterior sobre cuatro cielos elegidos a mano con intervalos de confianza de chi cuadrado, informada como ejecutada antes del preregistro.

• Máscaras de línea del horizonte dependientes del acimut (src/skyline.rs, docs/SKYLINE.md, elemento 1 de la nota de diseño): un corte de elevación que depende del acimut, el máximo puntual de tablas (cada una interpolada por separado, envuelta en 360°), un cañón urbano en forma cerrada (con extremos abiertos opcionales), sectores de borde afilado y un perfil de terreno con la curvatura de la Tierra; el corte efectivo es max(mask_deg, skyline). Cuatro preajustes REPRESENTATIVE con procedencia declarada (city-street, harbour-approach, fjord, container-terminal), sobrescribibles campo a campo. Una sección opcional [skyline] en los archivos de entrenamiento gnss-sim, jamming, leo-pvt (todos los modos, incluido el barrido polar), leo-pass y nmea-scenario, y en orbit e integrity mediante un nuevo usuario de sitio en tierra, user_site = { lat_deg, lon_deg, height_m } (ángulos de observación geodésicos sobre la Tierra en rotación, con la vertical geodésica para la separación horizontal y vertical de ARAIM; cada muestra es un instante absoluto, epoch + t, al que se avanzan los conjuntos de elementos, las efemérides difundidas y los archivos SP3 desde sus propias épocas, fechadas desde la época de satélite más reciente cuando no se declara epoch; un user en órbita rechaza una línea del horizonte). Los resultados incorporan skyline { source, open_fraction, provenance } y masked_by_skyline por muestra. Sin la sección, todos los escenarios son idénticos byte a byte a 0.35.0, comprobado frente a los resúmenes del commit de la versión. Seis ejemplos incluidos: orbit-urban-canyon-skyline, integrity-harbour-approach, gnss-sim-container-terminal-skyline, jamming-harbour-approach-skyline, leo-pvt-fjord-skyline y la campaña leo-vertical-autonomous-vehicle-skyline (el cañón del vehículo autónomo como corte plano y como calle; la campaña existente no cambia). MODELLED.

• Funciones de geometría del cielo (src/geometry.rs, elemento 2 de la nota de diseño): sky_geometry (satélites visibles y enmascarados desde un sitio, una hora y preajustes de constelación, conjuntos de elementos de dos líneas (tle, como máximo 4 MiB, propagados por el SGP4 del motor a una epoch UTC) o satélites dados; sky_source y sky_statement indican si el cielo es representativo o el cielo que dan los conjuntos de elementos en esa época, no una medición; tle_skipped lista cada línea sin usar con su motivo; límites de entrada de 2000 satélites sobre el horizonte, comprobados antes de construir una tabla de sistema, y 16 relojes de receptor; los cinco DOP; el cofactor y la covarianza ENU con un reloj por sistema o uno en común; la elipse de error horizontal a una sigma y con una confianza declarada), sky_monte_carlo (errores de mínimos cuadrados con semilla, como máximo 5000), skyline_presets, skyline_profile y skyplot_svg. orbit::dop_cov expone la covarianza que hay detrás de orbit::dop, que ahora es su reducción (los escalares validados no cambian). Superficies: kshana sky y kshana skyline, funciones de Python y WASM con los mismos nombres, y la herramienta MCP sky_geometry (40 herramientas), y el cuaderno notebooks/geometry.ipynb (con su réplica .md; ejecutado por tests/python/test_notebooks.py). Cada resultado lleva la etiqueta MODELLED, la declaración del modelo de error y la declaración consultiva.

• Registro: cinco filas de línea del horizonte y geometría del cielo. VALIDATED, cada una en una comparación preregistrada antes de ejecutar su referencia independiente: Máscara de línea del horizonte dependiente del acimut: conjunto visible, acimut y elevación, y DOP bajo la máscara frente a Orekit 12,2 (TopocentricFrame, ElevationMask) y gnss_lib_py 1.0.4 (get_dop), peores diferencias de ángulo de observación y de máscara 1.1e-12° frente a 1e-9°, conjuntos visibles idénticos, DOP 3.3e-13 relativo (xval/orekit-skyline/); Elipse de error horizontal y cofactor por sistema a partir de la covarianza de la geometría frente a linalg.inv y linalg.eigh de numpy (estándar P2), 270 casos, ejes 5.1e-13 relativo (xval/numpy-ellipse/). MODELLED: las reducciones de cañón, sector y terreno; los preajustes; la composición de la geometría del cielo (cielo predefinido, nube de Monte Carlo).

• Con las filas de confianza por geometría, línea del horizonte y estación de referencia lunar, el registro tiene 274 filas: 134 validadas, 136 modeladas, 4 de socio.

• Estación de referencia lunar: laboratorio de tiempo de la estación (MODELLED). Un bloque opcional [time_lab] en lunar-time-budget (src/lunar_time_lab.rs). Modela un reloj de estación (por defecto la clase miniRAFS, cualquier clase con nombre, o una ficha de dispositivo ajustada a puntos de estabilidad declarados) guiado a LTC y luego en funcionamiento libre o reguiado cada N segundos. Emite la curva de error de tiempo x(t), el tiempo hasta 1, 10 y 100 ns (bisección junto a la forma cerrada) y el término dominante por horizonte, todo con unidades. El residuo de guiado es ILLUSTRATIVE. La tasa de LTC no se rederiva y conserva su propia fila VALIDATED. El objetivo de nivel de nanosegundos del material público de PNT lunar del ICG WG-B (junio de 2024) se cita como declaración de la fuente, no como afirmación. El orden de relojes óptico < PHM < RAFS < miniRAFS se mantiene de 1 s a 7e5 s, y la prueba fija el cruce de las curvas de PHM y RAFS cerca de 7.5e5 s. Ese cruce es una propiedad de los modelos de reloj de un solo tipo de ruido (FM flicker pura frente a FM blanca pura), no un resultado físico. Sin el bloque, el informe, su tabla y su resumen no cambian. Ejemplo: scenarios/lunar-station-time-lab.toml. Añade una fila del registro, etiquetada MODELLED.

• Estación de referencia lunar: geodesia de la estación (MODELLED). Las entradas opcionales extra_reflectors y extra_beacons en lunar-llr-datum añaden un bloque station_geodesy. La información de datum de cinco matrices del segmento archivado de telemetría láser se combina con lo que aportarían un retrorreflector añadido y una baliza VLBI añadida en sitios declarados. El reflector se mide a las épocas archivadas en que puede ver, con sus pesos archivados. La baliza usa la red y el calendario de lunar-frame-campaign, con las estaciones fijas. El bloque da cada 1-sigma de Helmert antes y después, y su razón. Son cotas de Cramér-Rao para un conjunto reducido de parámetros, sobre un calendario y un sitio ILLUSTRATIVE. Las entradas ausentes o vacías dejan el informe idéntico byte a byte. Ejemplos: scenarios/lunar-station-geodesy-baseline.toml y -with-station.toml. Añade una fila del registro, etiquetada MODELLED.

• Estación de referencia lunar: comparación con afirmaciones publicadas (MODELLED). Cada afirmación numérica de cinco fuentes públicas se lista con su redacción exacta, página y supuestos declarados, y se clasifica como comparable, parcialmente comparable o no comparable (tests/fixtures/lunar_station_published/CLAIMS.md; fuentes con URL, fecha de obtención, SHA-256 y licencia en tests/fixtures/lunar_station/SOURCES.md). Las afirmaciones parcialmente comparables se puntuaron con seis umbrales unilaterales preregistrados antes de la ejecución (PREREGISTRATION.md, revisión 2, 05bf9a19): 1 de 6 afirmaciones dentro del umbral preregistrado (preregistrado 05bf9a19). La cobertura es 0,00 frente a >= 0,95 en ambos círculos polares sur, y el p95 corregido es 280,6 m frente a <= 1,5 m. La causa son los elementos orbitales de los satélites, que ninguna fuente publica: con los elementos ILLUSTRATIVE del propio repositorio, cuatro satélites están a la vista en común en el 8 % de las épocas, con una geometría casi singular. La ejecución no reproduce las afirmaciones con esos elementos y no es evidencia de que las afirmaciones sean erróneas. Fijado en tests/lunar_station_published_oracle.rs. Una fila del registro, etiquetada MODELLED con el hallazgo.

• Estación de referencia lunar: preparación de datos de archivos de reloj. realdata::clk::rinex_clock_series ahora declara el sistema de tiempo de sus épocas. Es el valor de TIME SYSTEM ID o, cuando este no está declarado, el valor predeterminado del sistema de satélites de la cabecera. El resultado también indica si el sistema se declaró. La función rechaza un sistema de tiempo desconocido (una escala de tiempo lunar, por ejemplo), un archivo de sistemas mixtos sin declarar y archivos que discrepan, en lugar de leerlos como hora GPS. Incluye un fixture sintético de reloj de estación. No se define ningún formato de archivo de correcciones, porque no existe ninguno público.

Cambiado#

• La documentación de módulo de fusion::ukf, fusion::tightly_coupled y fusion::gnss_ins_ekf ya no califica de trabajo futuro el navegador UKF de 17 estados, el acoplamiento estrecho con INS completo y el estado de reloj explícito; remite a hybrid_ukf, tightly_coupled17 y carrier_tc.

• RINEX 4 ya no se rechaza (0,36, WP-07): un archivo de navegación RINEX 4 se rechazaba a propósito; ahora se lee (véase Añadido). Para los archivos de observación de la versión 4 y posteriores, las etiquetas de cabecera se buscan solo en las columnas 61-80, de modo que los nuevos registros de texto libre no puedan pasar por etiquetas.

• ionex::parse_ionex lee archivos IONEX reales (0,36, WP-07): un registro completo de 16 valores llena las columnas 61-80, que el lector tomaba por una etiqueta, de modo que devolvía None con cada archivo IONEX real. Ahora lee como valores un registro cuyo campo de etiqueta es numérico. Ninguna salida distribuida lo usaba.

• Potencias recibidas de Galileo E1 y E5a según OS SIS ICD Issue 2,1 (revisión, 2026-10-14). Las bandas de espectro galileo-e1 y galileo-e5a, y las víctimas GNSS de señales LEO que toman su potencia de ellas, ahora usan las potencias mínimas recibidas de la Tabla 12 del Galileo OS SIS ICD Issue 2,1: −157,25 dBW (antes −157,0) y −155,25 dBW (antes −155,0).

  • Cambian nueve resultados de escenario: los ejemplos de espectro, la campaña de espectro, tres verticales de resiliencia LEO y tres diseños de señal LEO. El C/N0 efectivo cambia −0,25 dB y el J/S +0,25 dB en estas bandas.
  • Cada valor modificado (1766, antiguo → nuevo) figura en docs/revisions/CAP12-galileo-icd21-power-changes.md y su CSV, con las tablas de documentación que cambiaron. Ninguna fila del registro cambia de estado.
  • Segunda parte, el mismo día: las víctimas de señales LEO galileo-e5b (−155,0 → −155,25 dBW, Tabla 12 E5b) y galileo-e5-altboc (−152,0 → −152,24 dBW). El ICD no tiene una fila de E5 de banda completa, de modo que el valor de AltBOC es la suma de potencias de los totales de E5a y E5b de la Tabla 12, construida como lo era el valor antiguo. Cambian tres resultados de diseño de señal LEO (64 valores: estas potencias recibidas y la degradación del C/N0 de LEO a GNSS en las dos víctimas), listados en la misma revisión (§5) y el CSV. Nada más cambia.

• Corrección de la marea atmosférica S2 (tides::atmospheric_tide). Los armónicos de presión del aire S2 de Ray (2001) son coeficientes de P_nm sin normalizar con retardos de fase de coseno; se usaban como totalmente normalizados con el retardo como adelanto de seno del IERS. Ahora entran divididos por N_nm con ε = 90° − ψ; el nuevo tides::s2_air_waves reproduce el modelo A2 de la Tabla 5 de GFZ STR06/01 para las 21 ondas (peor caso 0,0005 cm, 0,05°; VALIDATED). Solo cambian las salidas con mareas activadas: el ajuste CI de Galileo 0,132 → 0,133 m, los componentes de Swarm-A en 1–2 mm (preregistrado en xval/s2-air-tide-fix/).

• Solo documentación: propagator::solve_kepler_checked, orbit::solve_kepler y ephem::solve_kepler se documentan como resolutores heredados, numéricamente sin cambios, que remiten a kepler::solve_kepler_markley.

• Estado de la ronda 3 de D9 (utck_bound). La Circular T 465 del BIPM salió el 2026-10-12. La puntuación prospectiva preregistrada sigue sin ejecutarse: el número 465 contiene unos 285 valores de prueba, y la regla de parada necesita 1000, es decir, aproximadamente los números 465–468. La ejecución también necesita los archivos por laboratorio archivados del 2026-09-30, porque el BIPM ha reescrito desde entonces 87 de los 113. La fila del registro y la cabecera de la prueba lo indican; la prueba, sus umbrales y su partición no cambian.

• Revisión de veracidad de la documentación (0,36). La hoja de ruta, las filas de capacidades, las líneas de estado de los documentos de diseño y los comentarios de módulo se han puesto en línea con el código; ninguna salida cambia. Los elementos ya construidos pero todavía listados como abiertos se marcan ahora como hechos: las comprobaciones de máscara de ITU-T, el escenario de holdover de 24 h y la ingesta de registros de reloj (temporización de telecomunicaciones), las guías de inicio del primer minuto, Lense–Thirring y la comprobación cruzada del propagador de Orekit, la cadena GCRS precisa en ITRF, los hashes de referencia y multiplataforma, la procedencia, el ARAIM de fallos múltiples (ADD v4.2), el FDE de un solo satélite, la biblioteca CRPA, el límite de ambigüedad de franjas de CAI, el dimensionamiento de calles de cobertura y la vista de órbita 3-D, la dinámica de actitud de sólido rígido, el escritor OMM y el lector de kernels NAIF, la libración lunar de DE440, la frase de significado de la ejecución en el playground, PositioningFom, el navegador de acoplamiento estrecho de 17 estados y el tipo de escenario gravity-map. Las filas también indican con precisión qué sigue abierto (por ejemplo, el JD en dos partes en orbit::Propagator, el lector de src/ionex.rs frente a un producto real y la exclusión de varios satélites en raim). El docs/design/evidence/cn0-m2m4/RESULTS.md que faltaba se escribe a partir de una ejecución nueva de sus pruebas (M1–M4 pasan), y el borrador de validación IQ orientado a socios tiene los recuentos actuales del registro.

• Los códigos de memoria de Galileo E1 ya no se incluyen en el paquete. data/galileo-os-sis-icd/C7_E1B.txt y C8_E1C.txt (anexo C.7/C.8 del ICD) se han retirado del repositorio y de los paquetes. Los términos del ICD (citados en LICENSING.md) permiten a un usuario almacenar los códigos citando la fuente y utilizarlos en un producto, pero solo permiten su redistribución con fines no comerciales, y Kshana también se ofrece con una licencia comercial. galileo::e1b_table / e1c_table ahora devuelven un Result y leen la copia propia del usuario desde KSHANA_GALILEO_E1B / KSHANA_GALILEO_E1C o, en una copia del código fuente, desde data/galileo-os-sis-icd/, donde el nuevo scripts/fetch_galileo_e1_codes.sh las extrae del PDF del ICD (con comprobación de hash). galileo::E1B_TABLE_TEXT / E1C_TABLE_TEXT se han retirado. Sin las tablas, las señales Galileo E1 (galileo-e1b, galileo-e1c) devuelven un error que indica cómo proporcionarlas, y las pruebas de E1 se omiten con un mensaje. Con las tablas disponibles, todas las salidas de E1 permanecen sin cambios. Ningún escenario, golden ni salida de espectro utiliza las tablas de códigos. Los archivos de prueba del anexo C.3/C.4 de E5a (la referencia independiente LFSR en tests/iq_signals.rs) se tratan igual: los descarga el mismo script, se excluyen de git y la prueba se omite si faltan.

• Matemáticas portables en todas partes (0,36, STUDIO-15): todas las funciones trascendentes de f64 de la biblioteca, y los muestreadores normal, gamma y exponencial de rand_distr, ahora se calculan mediante la biblioteca libm escrita en Rust puro (portable_math::PortableFloat, portable_distr), de modo que una compilación nativa y la compilación WebAssembly devuelven JSON de resultados idénticos byte a byte para los 141 escenarios incluidos y para la ejecución IQ corta. El coste es que se desplazaron los últimos bits de los resultados calculados con la biblioteca matemática del host: cambiaron 98 de los 141 escenarios incluidos y 43 no cambiaron; 5 cambiaron en más de 1e-3 en su campo mayor, y el resto en menos. Cada valor desplazado figura como antiguo -> nuevo en docs/revisions/STUDIO15-portable-math-rebaseline.md (con un CSV de los 136.127 números desplazados); no cambió ningún umbral, tolerancia ni límite. Cifras publicadas que cambiaron: disponibilidad de europa-surface-pnt con el alcance a la Tierra 0,719 -> 0,713 y error RMS 86,147 -> 86,499 m (una época en el límite de disponibilidad ahora se resuelve igual en todas partes; en macOS arm64 imprimía 0,725 / 85,800 m); error de estación de lunar-joint-od-clock 3,541350 -> 3,536885 m con VLBI y 2183,558 -> 2184,021 m sin VLBI; paper/crossover/inertial.json, ocho valores de vibration_psd en 3 unidades en el último lugar (fe de erratas del informe técnico); el documento cislunar-observability publicado en magnitudes situadas en el suelo del error de redondeo (ocho valores más allá de la sexta cifra significativa, hasta 6.8e-5 en términos relativos; no se movió ningún rango ni umbral). Los hashes fijados de las protecciones de identidad byte a byte (skyline_scenarios, geometry_corpus_identity, geometry_trust_no_change) se rebasan a una línea base denominada "0,36 portable", y los valores de 0.35.0 se conservan como registro histórico; la predicción congelada de la estación de referencia lunar no se toca y su nueva ejecución portable se guarda junto a ella (docs/predictions/*.portable-0.36.json). tests/lunar_joint_od_numpy_oracle.rs (la fila validada de OD conjunta lunar): se reexportaron los archivos de prueba y se repitió la comparación con numpy 2.4.6, la versión registrada, con el script y el umbral sin cambios; las seis redes pasan (docs/revisions/STUDIO15-lunar-joint-od-oracle-rerecord.md). El trabajo de los lotes 2-3 incorporado después de STUDIO-15 también usa matemáticas portables (457 puntos de llamada en 62 archivos); lo que eso desplazó figura en docs/revisions/STUDIO15-batch4-rebaseline.md: 12 escenarios incluidos (mayor cambio relativo 5.2e-8, ninguna cifra impresa se mueve), 28 filas de protección de skyline reaprobadas, el digest M2M4 de iq_campaign, los hashes de verdad de referencia heredados de gnss-ins, la sigma de datum de balizas no observadas (632,3769 -> 632,3772 m) y dos hallazgos registrados (cierres de DRO en CR3BP; CRPA A3, 194 de 456 enlaces). El edf exacto de Greenhall mantiene su umbral validado con un logaritmo de doble-doble en su núcleo (docs/revisions/STUDIO15-greenhall-edf-portable.md), y la referencia independiente del test bench de gps-sdr-sim se volvió a ejecutar sobre las exportaciones NMEA desplazadas, y todos los umbrales se mantienen (docs/revisions/STUDIO15-testbench-gpssdrsim-rerun.md).

• README: la fila de la suite lunar indica el nivel de evidencia de cada pieza (decía que todas eran MODELLED).

• realdata::clk::rinex_clock_series devuelve RinexClockSeries (serie, registro de interpolación en malla, sistema de tiempo, si se declaró y tipo de registro) en lugar de una tupla (PhaseSeries, GriddingLog). Ahora recurre a los registros de receptor/estación (AR) con el nombre solicitado cuando no hay registros de satélite (AS).

• Ninguna puntuación cambia a menos que la geometría sea mala; la etiqueta se informa siempre. Con geometría buena o aceptable (incluido un cielo abierto solo con GPS de 8 satélites) o con geometría desconocida (el monitor no se ejecuta), toda puntuación es la de 0,35: tests/geometry_trust_no_change.rs mantiene las salidas de ambas sesiones de ejemplo y tests/geometry_corpus_identity.rs cada corpus NMEA de buque confirmado (también como cielo abierto solo con GPS) y los escenarios de formación de tripulaciones con los bytes de 0.35.0, una vez eliminadas las claves añadidas; en los dos escenarios de formación en los que el jamming hace que la geometría sea mala, las épocas malas difieren únicamente por la deducción por geometría. Un registro con geometría mala pierde hasta 15 puntos que no perdía en 0,35. Por lo demás, los cambios previstos son todos adiciones: las claves anteriores en el JSON de resultados y en los paquetes de evidencias (score_model.weights no cambia); el esquema JSON-lines en vivo pasa de 1,2 a 1,3 (geometry añadido, class en cada deducción); el resumen del extracto incorpora geometry; la telemetría incorpora series, campos y la etiqueta class de geometría solo para las entradas que los incluyen, de modo que un flujo o resultado de 0,35 se representa byte a byte como antes. geometry es el 17.º nombre de monitor; figura en último lugar en monitors_run cuando decidió (un buque cuyo registro proporciona la geometría; una lista de 0,35 conserva su orden y el recuento de monitores del resumen aumenta en uno) y no tiene entrada en [score.weights] (establecerla se rechaza: su deducción se fija en [geometry]).

• tests/fixtures/dop/NOTICE indicaba que la licencia de gnss_lib_py era Apache-2.0; la versión 1.0.4 es MIT.

• El lector NMEA ahora lee GSA (una GSA corta se ignora, no se cuenta como omitida) y conserva las elevaciones y los acimuts de GSV, también para satélites listados sin señal; el lector UBX conserva la elevación y el acimut de NAV-SAT. C/N0 se lee exactamente igual que antes.

• Cambio de resultados: los inhibidores de banda ancha y de barrido ahora usan Q = 2. La ecuación antiinterferencia usa para estos inhibidores el ajuste Q de espectro ensanchado de los manuales, donde antes usaba 1. Q = 2 corresponde a ruido blanco sobre el lóbulo principal con la potencia de señal en banda normalizada; en las pruebas está fijado a la forma cerrada de navsignal.

  • Sin cambios: los inhibidores CW y de banda estrecha (Q = 1), un tipo de inhibidor no reconocido (Q = 1, el valor más perjudicial) y q_override.
  • Efecto: allí donde actúa un inhibidor de banda ancha o de barrido, el C/N0 efectivo aumenta hasta 3,0103 dB, los umbrales J/S derivados aumentan 3,0103 dB y los radios de denegación en espacio libre se reducen en un factor de 0,7071.
  • Escenarios incluidos que cambian: cambian 12 de 144, todos según lo preregistrado (xval/jammer-q/PREREGISTRATION.md, resultados en xval/jammer-q/RESULTS.md):
    • jamming-demo: C/N0 +3,01 dB;
    • jamming-harbour-approach-skyline: min_tracking 6 → 7;
    • lunar-jamming: satélites perdidos 26 → 0, distancia de seguridad mediana de pérdida de enganche 27,4 → 19,4 km;
    • tracking-loop: radio de denegación por dinámica del lazo 75,2 → 53,2 km;
    • y las campañas y verificaciones cruzadas de espectro que los contienen.
  • Consumidores afectados: los tipos de escenario jamming, lunar-jamming, tracking-loop y impairment-eval, la jamming_kind_cross_check de los tipos de escenario de espectro, la curva de referencia MODELLED de la campaña IQ y la Q por defecto de labfit, y la exportación de escenas de interoperabilidad.

• Complemento de JetBrains: ninguna API de la plataforma obsoleta o programada para su eliminación. Los cinco diálogos de selección usan un pequeño DialogWrapper con una lista desplegable en lugar del obsoleto Messages.showChooseDialog; los selectores de un solo archivo usan el constructor de FileChooserDescriptor en lugar del obsoleto FileChooserDescriptorFactory.createSingleFileDescriptor(); la animación se abre con BrowserUtil.browse(Path) en lugar de browse(File), que la plataforma 2026,3 programa para su eliminación. Since-build sigue siendo 243. El IntelliJ Plugin Verifier informa Compatible sin ningún uso obsoleto o programado para su eliminación frente a 2024,3 (IC-243.21565.193), 2025,2 (IC-252.23892.409), 2026.2.3 (IU-262.10968.63) y 2026,3 EAP (IU-263.6259.32); verifyPlugin comprueba 2024,3 por defecto y cualquier lista indicada en KSHANA_VERIFY_IDES.

• gnss_sim::run_gnss_sim y jamming::run_jamming devuelven Result: una sección [skyline] no válida es un error cuando se llama directamente, como ya lo era a través de api::run_toml, en lugar de una vuelta silenciosa a la máscara plana. Cambio incompatible para quienes llamen a estas dos funciones desde Rust.

Corregido#

• Evaluador de campañas: nunca se contaba un falso enganche real del seguidor (iq::campaign). La comprobación de falso enganche del seguidor pasa un canal de LOCKED a LOST al dispararse. El evaluador marcaba en cambio la siguiente actualización del canal, que ya estaba desenganchado y por tanto nunca se contaba. Un evento false-lock notificado desde LOCKED es ahora un episodio en su instante, en la ejecución y en cada evento indicado que lo contiene. Uno encontrado durante la captura inicial, o repetido por un canal que ya está LOST, no es un episodio nuevo. Una prueba nueva provoca un falso enganche real: una portadora legítima de GPS L1 C/A que da un salto de 1/(2T) mientras está enganchada (tests/iq_campaign_false_lock.rs).

  • En la campaña de referencia de tests/iq_campaign.rs, solo cambia el PRN 11 de ramp/agc-3bit (episodios de falso enganche 0 → 1, 426 y 437 por hora de enganche).
  • Sus DIGEST de celda se vuelven a fijar.
  • El fijado preregistrado de los resultados evaluados sigue vigente y se sigue reproduciendo exactamente: en su hash solo esos seis campos, cambiados por esta corrección hecha tras el registro, se vuelven a asignar a sus valores anteriores a la corrección. Los valores corregidos se fijan por separado.
  • No se modificó ningún umbral, y no se movió ninguna fila, cifra ni número web VALIDATED.

• lunar-frame-campaign: ahora se informa de una baliza sin observación (hallado por MR-05). El informe incorpora unobserved_beacons y warning solo cuando alguna baliza no tiene observación y, entonces, las sigmas de las balizas observadas proceden de su propia información en lugar de ser todas nulas. El datum no cambia y no se mueve ninguna salida por defecto, incluida ni publicada (docs/revisions/BEACON-unobserved-cell-changes.md).

• Marco lunar de ejes principales (lunar_frame::icrf_to_moon_pa, usado por lunar_od y el ajuste de LRO): el desfase de DE421 entre el marco de Tierra media y el de ejes principales de moon_080317.tf se aplicaba en sentido contrario y con un orden de Euler erróneo, de modo que el marco analítico PA quedaba a unos 208″ de PA en lugar de coincidir con él. Ahora se transcribe tal como lo define el Frames Required Reading de SPICE y coincide con SPICE pxform('MOON_ME','MOON_PA') hasta 2.6e-16 rad; el marco analítico PA queda a entre 6″ y 8″ del PA de DE440 (preregistrado e1ead19b, reregistrado be33382e después de que el primer cambio propuesto no alcanzara el umbral de 1e-12; docs/design/evidence/fut05b-me-pa-offset-sign/). Cifras publicadas que se mueven: el ajuste de LRO (tests/agency_lro.rs), solapamiento en bruto 53,8 → 39,9 m, dinámico 12,6 → 12,05 m, dinámico reducido 6,65 → 6,67 m (umbrales sin cambios). La pila analítica ahora coincide con la validación cruzada de grado DE de ANISE (12,0 / 6,67 m) en ambos niveles; la discrepancia anterior en el nivel dinámico se debía a este error.

• El servidor MCP rechaza [terrain] dem_hgt (seguimiento de CAP-06b). La ruta del mosaico de terreno del tipo de escenario jamming figura ahora en inline_only::FILE_SOURCE_KEYS. Una superficie en línea rechaza un escenario que nombre una, con un mensaje que no incluye ni la ruta ni un error del sistema operativo. La prueba de la protección de fuentes de archivo ahora también señala los campos que terminan en _hgt.

• Jd2::from_parts con una parte fraccionaria del día descartaba la fracción en las conversiones UTC, TAI, UT1 y de rotación terrestre (una hora de parte del día hacía que la Tierra quedara 15° mal); ahora la parte del día se normaliza a un entero. No se vio afectada ninguna llamada del motor: todas pasan un día entero, y toda salida distribuida es idéntica bit a bit.

Previsto#

• La geometría a partir de un skyline indicado (elemento 1 de 0,36, ahora en el motor como src/skyline.rs): sky-blocked y open_fraction a partir del skyline cuando la entrada proporciona uno (el hueco de acimut como alternativa), un evento de degradación natural (fiordo o terminal) en nmea-scenario y las dos geometrías enmascaradas de la nota de diseño en la fila sigma_UERE x DOP, preregistradas como adenda.
• Geometría para registros RINEX con navegación (a partir de la solución del propio motor) y registros de Android (a partir de las filas Status); ambos indican hoy unknown. Geometría en $PKSHT (versión 1 sin cambios en 0,36) y las integraciones con Signal K y OpenCPN.
• Una carencia previa, no introducida en 0,36: cuando el campo SNR de todos los satélites está vacío, no se activa ninguna deducción de loss-of-lock ni de C/N0; la pérdida total de señal solo es visible a través de signal_loss del monitor de geometría (clasificada como environment). Está prevista una deducción para ese caso.
• Un flujo de esquema 1,3 en las referencias independientes de telemetría externas (el analizador de formato de texto de Prometheus y el recolector OTLP), que hoy solo cubren flujos 1,2.
• Una obstrucción por ambos lados (un cañón o un fiordo estrecho) se interpreta como pérdida de señal y no como cielo bloqueado hasta que se integre el skyline.

[0.35.0] - 2026-10-12#

Un pasaje que nombra a clientes de IA de terceros se omite aquí; está en CHANGELOG.md en GitHub.

Verificador de Galileo OSNMA#

• Nuevo módulo kshana::osnma y kshana osnma verify <input>: un verificador abierto en Rust puro, del lado del receptor, para Galileo OSNMA. Lee páginas I/NAV e informa, por satélite y época, de si los datos de navegación están autenticados, con un motivo para cada fallo o retraso: análisis de HKROOT y MACK, reensamblado de DSM-KROOT y DSM-PKR, verificación Merkle de la clave pública, verificación de la cadena de claves TESLA, verificación de MACSEQ y de etiquetas para ADKD 0, 4 y 12 con autenticación cruzada, y un resultado con la forma de $PKSOS para el monitor de confianza del receptor. La salida incluye un aviso orientativo de que el estado no es un servicio de integridad de la navegación. docs/OSNMA.md indica lo que se verifica y lo que no, el requisito de tiempo, y que Kshana no concede derechos sobre los IPR del ICD de OSNMA de la UE (los usuarios se basan en la autorización del anexo E del ICD). Implementado conforme al SIS ICD Issue 1,1 y a las Receiver Guidelines Issue 1,3. Las páginas se comprueban con CRC y se puede leer directamente un flujo de bytes UBX-RXM-SFRBX de u-blox (--format ubx). Las pruebas por defecto usan datos sintéticos y pruebas de respuesta conocida de las primitivas publicadas; una prueba opcional lee una copia descargada localmente de los vectores oficiales. Tras una revisión independiente, el verificador toma su tiempo solo de claves TESLA verificadas (un subframe falsificado situado en un futuro lejano ya no puede borrar un fallo), hace que una autenticación caduque y siga el IODnav en uso, respeta los mensajes de alerta verificados (cuya hoja Merkle ahora incluye el campo NPK aleatorio) y el estado NMA "don't use", mantiene las etiquetas ficticias fuera del estado del satélite, conserva las cadenas por CID con revocación y renovación, comprueba el hash de relleno de KROOT y limita las longitudes de trama UBX y el trabajo de verificación TESLA. Un satélite figura como autenticado solo mientras los datos más recientes de efemérides y reloj que envía son, bit a bit, los datos que se autenticaron (no meramente bajo el mismo IODnav); un estado o una revocación procedente de la cabecera NMA no autenticada cuenta solo cuando dos satélites coinciden o lo transporta un KROOT verificado, un KROOT anterior reproducido no puede sustituir a una cadena, y se informa de un flujo de claves detenido.

Añadido (canales del servidor MCP)#

Un pasaje que nombra a clientes de IA de terceros se omite aquí; está en CHANGELOG.md en GitHub.

• kshana-mcp --http <addr>, HTTP en streaming, autoalojado. Solo loopback por defecto; una dirección que no sea loopback requiere --allow-remote y un token de portador en KSHANA_MCP_HTTP_TOKEN; ninguna herramienta lee ni escribe una ruta (las herramientas de archivos IQ están desactivadas); límites de tamaño de solicitud, de tiempo y de concurrencia; sin cabecera CORS; comprobaciones de Host y Origin. Kshana no aloja ningún punto de conexión (docs/deploy/mcp-http.md, con plantillas para Docker, Fly.io y Cloud Run).

Añadido (superficies)#

• osnma_verify en Python y WebAssembly. El verificador que hay detrás de kshana osnma verify sobre bytes en memoria, que devuelve el JSON que imprime --json (aviso orientativo en su campo advisory; solo estado de autenticación, no un servicio de integridad de la navegación). Las mismas negativas que en la línea de comandos. No está en MCP: la entrada es un flujo bruto largo de receptor que la CLI y Python atienden mejor. docs/SURFACES.md y docs/OSNMA.md lo indican.

• trust_telemetry en WebAssembly, Python y MCP, con un comando de complemento y una acción de JetBrains. Representa un flujo de confianza o un resultado de receiver-trust como texto de Prometheus, líneas de syslog CEF o LEEF o una carga útil JSON de OTLP, con los codificadores que usa kshana trust-telemetry (kshana::surface::trust_telemetry); sin socket ni reloj. Complemento: /kshana-trust-telemetry y la skill trust-telemetry. JetBrains: Render Trust Telemetry. Las funciones wasm y python y el servidor MCP ahora también activan otlp, que no añade ningún crate.

• Barrido de paridad. Acciones de JetBrains Validate Scenario, List Scenario Kinds y Assess Receiver Stream; kshana --help ahora lista receiver-trust evidence, evidence, trust-telemetry y nmea-scenario; el cuaderno compliance-and-test-bench (correspondencia de compliance y exportación a test bench); y cada celda restante de JetBrains "CLI only" en docs/SURFACES.md es ahora un N/A explícito con su motivo.

Un pasaje que nombra a clientes de IA de terceros se omite aquí; está en CHANGELOG.md en GitHub.

Añadido (paquetes de evidencias)#

• kshana receiver-trust evidence y kshana evidence verify: paquetes de evidencias firmados y verificables para un evento de confianza de GNSS. Un paquete reúne el fragmento del registro en bruto y el SHA-256 del registro completo, la configuración con todos los umbrales, los resultados y motivos de cada época, la versión del motor, un manifiesto encadenado por hash y un resumen HTML autónomo, firmado con Ed25519 (una clave de kshana evidence keygen o su propio archivo; las claves nunca se almacenan en un paquete y *.evidence-key está excluido de git). verify comprueba cada hash, la cadena y la firma e indica exactamente qué falla; con --pubkey fija el firmante. Se puede adjuntar un token RFC 3161, que se lee y se vincula al manifiesto (esta compilación no comprueba la firma propia de la autoridad; openssl ts -verify la cubre). El fragmento del registro son los bytes exactos de la ventana cuando el lector informa de rangos de origen (NMEA, UBX, RINEX 3, Android) y, si no, el registro completo, y el manifiesto indica cuál. La creación y la verificación son funciones públicas puras (kshana::evidence) que se compilan para wasm32. Los paquetes declaran que son un registro técnico, no un dictamen jurídico. Las dependencias nuevas son el árbol de ed25519-dalek (BSD-3-Clause y Apache-2.0/MIT, funciones mínimas) y zeroize directo (ya presente en ese árbol) para borrar el material de claves. Véase docs/EVIDENCE-PACKS.md.

Añadido (telemetría de confianza)#

• kshana trust-telemetry: la confianza en GNSS como fuente de telemetría de seguridad. Lee el flujo de confianza por época (líneas JSON: puntuación 0-100, banda, motivos) o un resultado por lotes de receiver-trust y alimenta un punto de conexión /metrics de Prometheus (localhost por defecto), eventos syslog en CEF o LEEF dentro de un envoltorio RFC 5424 (UDP o TCP) y, tras la función otlp, desactivada por defecto, exportación JSON OTLP/HTTP. El envío se ejecuta en hilos de trabajo con límites de tiempo de conexión y de escritura, retroceso de reconexión acotado y un contador kshana_trust_syslog_send_failures_total, de modo que un recolector caído o bloqueado no pueda detener la evaluación en vivo ni congelar /metrics; las etiquetas de motivo se limitan a 64 series. Sin dependencias nuevas. Hay un panel de Grafana de ejemplo en deploy/grafana/. Los nombres de las métricas, las etiquetas y la correspondencia de campos CEF/LEEF están en docs/TRUST-TELEMETRY.md. El formato del flujo está aislado en src/telemetry/sample.rs.

Añadido#

• Confianza marítima: una puntuación de confianza en vivo de 0 a 100 para la posición de un buque en movimiento, a partir del NMEA 0183 que el receptor ya emite, con una compuerta opcional. kshana receiver-trust admite una tabla [platform] (kind = "static" o "vessel", la velocidad, la aceleración y la velocidad de giro máximas del buque, la altura de la antena sobre la línea de flotación y un sensor de rumbo opcional; cada valor por defecto está documentado con su motivo). Para un buque, el monitor estático de saltos de posición, que mide la distancia a la media de calibración y es erróneo en un barco en marcha, se sustituye por monitores causales de plataforma móvil: coherencia cinemática de la posición con la velocidad y el rumbo notificados y con los límites del buque, rumbo del girocompás frente al rumbo sobre el fondo, corredera frente a velocidad sobre el fondo, altitud de la antena frente a la altura declarada sobre la línea de flotación, colapso de la dispersión de C/N0 y su aumento conjunto frente a la línea base de calibración, y coherencia temporal (también con el reloj de este ordenador, en modo en vivo). También lee un estado de autenticación notificado, global o por satélite (solo un estado notificado: sin criptografía OSNMA). Cada umbral se declara en una tabla [maritime] antes de la ejecución. Después cada época recibe una puntuación de 0 a 100 mediante una asignación determinista y preregistrada (sin aprendizaje, nada ajustado a los eventos; los pesos, los límites de banda y la evidencia constan en una tabla [score]), asignada a los estados de confianza existentes, con los monitores que dedujeron y sus puntos. Los escenarios estáticos no cambian y su hash es el de antes. kshana receiver-trust live <session.toml> lee stdin, un archivo al que se añaden datos, TCP o UDP y escribe una línea JSON por época y una sentencia propia $PKSHT; con --gate pasa el flujo sin cambios mientras la posición es fiable y marca la posición como no válida (calidad GGA 0, estado RMC y GLL V, modo GNS y VTG N) mientras no lo es. La compuerta está desactivada salvo que se pida; --listen tcp:<port> sirve el flujo con compuerta a cualquier número de clientes TCP (loopback por defecto; un cliente lento se descarta en lugar de bloquear a los demás). Este es un software de carácter consultivo, no un equipo de navegación homologado (IEC 61108, IEC 61162); el operador sigue siendo responsable. examples/maritime-trust/ es un registro sintético de Tallin a Helsinki, escrito solo como texto, con un arrastre de la posición a mitad del recorrido durante el cual el receptor sigue notificando una posición válida; su salida esperada está fijada por una prueba. Guía: docs/MARITIME-TRUST.md. Las comprobaciones no pueden detectar a un falsificador cuya posición sea coherente con todo lo que hay en el bus; la guía lo indica.

Mapa de interferencias#

• kshana interference-map y kshana route-exposure: una imagen pública de dónde aeronaves y buques notificaron datos de navegación degradados y de cuánto de una ruta alcanza. Las entradas son archivos CSV locales elaborados a partir de datos ADS-B (adsb.lol, ODbL 1,0) y AIS (NOAA MarineCadastre, Kystverket bajo NLOD 2,0) con licencia abierta; cada archivo de salida corresponde a una fuente y a un día UTC de GeoJSON que contiene el método, sus umbrales, la licencia de los datos, la atribución y el sesgo de cobertura de la fuente. El método ADS-B agrega NIC y NACp en una cuadrícula fija y califica una celda como degradada según la proporción de aeronaves distintas, con protecciones para equipos que nunca notifican precisión, para baja altitud y para causas de área amplia. El método AIS ejecuta cinco detectores: posiciones en tierra (frente a una línea de costa proporcionada por el usuario), trayectorias circulares, saltos inverosímiles, velocidades inverosímiles y muchos buques en una misma posición. Los umbrales son constantes preregistradas de una versión de método con nombre. Solo agregados: los identificadores se calculan con hash en memoria y nunca se escriben, y no se publican las celdas con menos de 5 aeronaves o buques distintos. Una celda degradada no es una constatación de interferencia. Los comandos por defecto no usan la red; un asistente fetch-land --allow-network opcional descarga los polígonos de tierra de Natural Earth desde una dirección fijada a un commit y conserva el archivo solo si su SHA-256 coincide. La entrada ADS-B es un CSV o directamente los archivos de historial readsb de adsb.lol (nueva dependencia: flate2 con su backend en Rust puro, para gzip). Ambos métodos están en la versión 2: una calificación de degradada o anómala requiere al menos 5 aeronaves o buques (el mínimo de publicación), todo recuento por celda inferior a 5 se retiene como null, y un día cuyo fondo no pueda estimarse retiene sus calificaciones. Los archivos de salida se llaman <source>-<dataset>-<date>.geojson y nunca se sobrescriben; la entrada se procesa en flujo línea a línea; la exposición de ruta maneja el antimeridiano. Las pruebas usan solo datos sintéticos. Véanse docs/INTERFERENCE-MAP.md y la revisión de licencias en docs/data/INTERFERENCE-DATA-SOURCES.md.

Añadido (flujos de formación)#

• kshana nmea-scenario: NMEA 0183 sintético de puente para la formación de tripulaciones en el reconocimiento de jamming y spoofing de GNSS. A partir de un TOML de escenario escribe un archivo, o emite por TCP o UDP (unicast o broadcast; en tiempo real, acelerado o lo más rápido posible), el conjunto completo de sentencias de puente GGA, RMC, VTG, GSV, GSA, GNS, ZDA, HDT y VBW para la derrota de un buque con límites de velocidad de giro, aceleración y corriente, con la geometría de satélites de las constelaciones nominales propias del motor. Eventos con guion en una línea temporal: jamming, arrastre de posición (una posición válida que se va alejando), spoofing de hora y un retardo de repetición, cada uno con rampas de inicio y de recuperación. Un registro del instructor (JSON y texto) anota qué se inyectó y cuándo, con la derrota real frente a la notificada. Una biblioteca en scenarios/training/ (jamming en mar abierto, arrastre costero, spoofing de hora en la aproximación a puerto, combinado) incluye notas para el instructor. La salida tiene sumas de comprobación válidas y es determinista por semilla; las pruebas fijan un extracto golden por escenario y leen cada sentencia con el lector NMEA de receiver-trust. Solo texto: sin salida de RF, IQ ni forma de onda; los flujos son para formación y pruebas y nunca deben alimentar los sistemas de navegación en vivo de un buque. Véase docs/NMEA-TRAINING.md.

Integraciones marítimas (0.35.0, línea de trabajo B)#

• Complemento de Signal K (integrations/signalk/, no publicado en npm): ejecuta kshana receiver-trust live o se conecta a él (la propia entrada NMEA del servidor, argumentos de entrada personalizados, una fuente TCP JSON-lines o las sentencias $PKSHT de un flujo con compuerta), publica la puntuación de confianza, la banda, los motivos, las alarmas y el estado de la compuerta bajo navigation.gnss.kshana.* (incluida la posición notificada por el receptor como contexto, nunca navigation.position), y emite una notificación de Signal K (warn en degradado, alarm en no fiable, con umbrales de mantenimiento, de borrado y de obsolescencia, todos en el esquema de configuración). Sin dependencias de npm. Probado con salida sintética grabada.
• OpenCPN: el NMEA en modo compuerta lo sirve directamente kshana receiver-trust live --gate --listen tcp:10110 (recomendado); un relé TCP sin dependencias (integrations/opencpn/nmea-tcp-relay.mjs) es la alternativa opcional. En cualquier caso OpenCPN ve una posición no válida cuando la confianza se desploma y $PKSHT en su ventana de depuración NMEA; las pruebas reproducen el flujo sintético con compuerta a través de un socket TCP real y comprueban lo que recibe un consumidor. Un complemento nativo de panel de puntuación (integrations/opencpn/plugin/, API de complementos 1,18, CMake) lee $PKSHT del propio flujo NMEA de OpenCPN y alerta en la banda no fiable; se compila, su lógica tiene pruebas unitarias y se ejecutó dentro de OpenCPN 5.8.4 bajo una pantalla virtual (evidencias y un script de reproducción en integrations/opencpn/evidence/); no está empaquetado para el gestor de complementos.
• Construcción de referencia (deploy/reference-build/): lista genérica de piezas, configuración del sistema operativo, unidades systemd para el monitor consultivo y la compuerta opcional (comprobadas con systemd-analyze verify mediante check-units.sh), una opción de contenedor, conexión con Signal K.
• El complemento de Signal K acepta el esquema JSON en vivo 1,2 (se añade una clave position y luego una advisory; las claves añadidas desconocidas se ignoran), comprobado con salida real de 1,2 y con un signalk-server real.
• Correcciones de la revisión: las unidades systemd se reinician siempre y se ejecutan aisladas (sin shell, sin red donde no hace falta), un fragmento de logrotate, check-units.sh falla ante cualquier hallazgo; el contenedor ejecuta la compuerta desde variables de entorno con una comprobación de estado y con imágenes base fijadas por digest; metadatos de puntuación en Signal K, la notificación obsoleta se sustituye cuando se reanudan los datos, se conservan los errores de procesos hijos y las terminaciones escalan, se rechazan los inputArgs no seguros y la notificación está en notifications.navigation.gnss.kshana.trust; el relé limita una línea parcial retenida; los analizadores de $PKSHT rechazan puntuaciones fuera de 0 a 100; una comprobación de enlaces de la documentación; un flujo de trabajo de CI (marine-integrations.yml) que ejecuta todo ello, incluido el binario real de extremo a extremo.
• docs/MARINE-INTEGRATIONS.md. Software de carácter consultivo, no un equipo homologado; el operador sigue siendo responsable. Solo software: no transmite nada y no se afirma ninguna cifra de detección ni de falsas alarmas.

Añadido: correspondencia de compliance y exportación a test bench#

• docs/compliance/ y kshana compliance-report. Una correspondencia entre las salidas de Kshana y cinco marcos y normas de resiliencia (el Resilient PNT Conformance Framework v2.0 del DHS de EE. UU., la guía de la OMI para buques, la guía de la EASA para la aviación, el artículo 21 de NIS2 y EN 16803, una norma de pago citada por parte y por los pocos números de cláusula visibles en el texto del catálogo), con una tabla por marco: la referencia, lo que exige según nuestra paráfrasis, las salidas que aportan evidencias a favor de ella y la carencia. Se registran las versiones de las fuentes, las URL y lo que se leyó y lo que no. kshana compliance-report <result.json>... rellena la correspondencia a partir de las ejecuciones indicadas y marca cada fila como evidenced, partly-evidenced, not-evidenced o out-of-scope, en Markdown y JSON, con la carencia conservada en cada fila. La fórmula es "aporta evidencias a favor de"; nada se califica ni se aprueba. Las pruebas usan ejecuciones sintéticas y fallan cuando una tabla confirmada se desvía del código.
• kshana bench-export <scenario.toml>. Escribe el movimiento del vehículo y los eventos de un escenario gnss-ins, jamming o gnss-sim para un simulador GNSS de laboratorio: un CSV de movimiento de usuario con marcos documentados y un archivo auxiliar de metadatos, NMEA 0183 GGA/RMC, texto de puntos de ruta, y los eventos como CSV y como bloques receiver-trust [[events]] (src/interop/testbench.rs). Solo movimiento y eventos: no se escribe ninguna señal. Cada archivo se vuelve a leer en tests/interop_testbench.rs y se compara dentro de su tolerancia declarada. docs/TEST-BENCH.md indica el método para reproducir la exportación mediante un simulador y puntuar el registro del receptor con kshana receiver-trust.
• Qué cuenta como evidencia. Un resultado cuenta para una capacidad solo cuando incluye los campos que escribe su tipo de escenario; una etiqueta de tipo de escenario por sí sola no cuenta para nada. Los tipos de escenario desconocidos, un resultado que discrepa de su escenario hermano, los hashes no hexadecimales y los recuentos de receiver-trust mal formados se listan como no usados, con el motivo. El informe escapa las celdas de Markdown y no puede entrar en pánico ante un hash no ASCII. compliance::run_from_text y assess_texts reciben textos, no rutas.
• Exportación a test bench. --epoch se comprueba en rango (UtcEpoch::parse_iso); el archivo de puntos de ruta comprueba cada intervalo y el comando indica el motivo cuando se omite; la documentación señala que el rumbo de gnss-ins es la guiñada del cuerpo y no el rumbo efectivo, los campos de relleno de GGA y el cambio de altura propio del escenario. bench-export y compliance-report están en el texto de uso.
• fusion::pack::truth_trajectory expone el historial de estados verdaderos del perfil de conducción de gnss-ins (el mismo avance que usa la verdad de referencia del propio tipo de escenario), y UtcEpoch incorpora campos de fecha y hora NMEA.

Validación del mapa de interferencias#

• La semántica de decodificación y la geometría del mapa de interferencias se comprueban frente a implementaciones independientes sobre entradas sintéticas. Los significados de los códigos NIC y NACp frente a la decodificación de pyModeS de tramas ADS-B sintéticas, los valores de no disponible de AIS frente a la decodificación de pyais de sentencias AIVDM sintéticas, la asignación de celdas de la cuadrícula frente a shapely, la longitud de ruta por estado de celda frente a shapely y GeographicLib, y el enmascarado de zonas interiores frente a shapely y pyproj, cada uno con una tolerancia fijada antes de la primera comparación (tests/fixtures/interference_map_ref/PREREGISTRATION.md). Esto valida cómo se leen los códigos y los valores de los campos, y la geometría, no que una celda señalada sea interferencia. El lector de polígonos de tierra ahora cierra un anillo que no repite su primer vértice, y antes lo leía sin su última arista. La documentación indica los umbrales de baja precisión de NACp y NIC como la cota que representa cada código (NACp 6 es una cota de EPU de 556 m, NIC 5 una cota de contención de 1 NM).

Añadido (validación de los formatos de telemetría y de los paquetes de evidencias)#

• Comprobaciones externas de la criptografía de los paquetes de evidencias, del verificador de paquetes y de los formatos de transmisión de telemetría. Los vectores de prueba Ed25519 de la sección 7,1 de RFC 8032 (1, 2, 3 y 1024) y los ejemplos SHA-256 de FIPS 180-4 se ejecutan a través de las propias funciones de firma, verificación y hash del paquete, hasta la igualdad exacta. Un verificador escrito en Python solo a partir de la sección normativa de docs/EVIDENCE-PACKS.md (hashlib y cryptography) coincide con el verificador de Rust en 71 paquetes íntegros y manipulados: veredicto, conjunto de fallos, veredicto de la firma y ambas cabezas de cadena. Nuestra exposición de Prometheus se lee con el analizador del cliente oficial de Python y nuestro JSON de OTLP con el mensaje oficial opentelemetry-proto, de forma estricta, y ambos coinciden con el estado a partir del cual se generaron. CEF y LEEF no tienen un validador abierto independiente y siguen siendo de nivel modelado. docs/EVIDENCE-PACKS.md incorporó el formato normativo del paquete y el procedimiento de verificación a partir de los cuales se escribió el verificador de sala limpia; VerifyReport incorporó signature_valid. Referencias independientes y archivos de prueba: scripts/gen_ed25519_rfc8032_ref.py, scripts/gen_evidence_pack_ref.py con scripts/evidence_verify_cleanroom.py, scripts/gen_telemetry_formats_ref.py; pruebas evidence_crypto_reference, evidence_pack_reference y telemetry_formats_reference. La CI no necesita Python.

Añadido (validación de los eventos CEF)#

• Los eventos CEF de telemetría los leen correctamente dos analizadores independientes de código abierto. pycef 1,11 y el códec CEF de Logstash (logstash-codec-cef 6.2.7 en Logstash 8.15.3) analizan 157 líneas CEF (cada cambio de banda y cada época del flujo de telemetría confirmado, más texto adversarial que contiene =, barras invertidas, barras verticales, saltos de línea, tabuladores y texto multibyte) y recuperan cada campo de cabecera, la severidad, el conjunto exacto de claves de extensión y cada valor exactamente. El códec de Logstash también lee cuatro líneas cuyo texto de cabecera necesita escapado, algo que pycef no puede. El umbral se registró antes de ejecutar ninguno de los dos analizadores (tests/cef_reference.rs); archivos de prueba en tests/fixtures/cef/, scripts de referencia independiente scripts/gen_cef_ref.py y scripts/gen_cef_logstash_ref.py; la CI no necesita ni Python ni Logstash. LEEF no tiene un analizador abierto mantenido y sigue siendo de nivel modelado. Los eventos CEF ahora llevan la puntuación de confianza y el desfase de época en los campos personalizados de coma flotante del diccionario CEF (cfp1, cfp2) en lugar de los campos enteros cn1 y cn2, que no convenían a ninguno de los dos valores; CEF es nuevo en esta versión, de modo que no cambia nada de lo ya distribuido.

Cambiado#

• MCP: assess_receiver_log acepta el registro como text o base64; la entrada de la herramienta está limitada a 4 MiB.
• El gráfico de jamming también toma sus colores de la paleta. src/jamming.rs era el único módulo que la revisión de la paleta del Observatory dejó con sus propios colores mientras llegaba el trabajo sobre la Q de los inhibidores; su *.chart.svg (los escenarios jamming, maritime-strait-jamming y otros del tipo de escenario jamming) ahora lee src/palette.rs, y la lista de permitidos de tests/palette_sync.rs está vacía. Solo colores y tipografía: los gráficos de jamming-demo y maritime-strait-jamming son iguales a sus representaciones registradas anteriormente una vez normalizados el color, font-family y el pie con la versión. No se movió ningún valor representado. Las copias grabadas de Studio en web/studio/recorded/ se volvieron a grabar en los nuevos portes de 0.33.0 y 0.34.0 (solo el sello de versión): todavía llevan los colores antiguos del gráfico de jamming y tomarán los de la paleta en el próximo nuevo porte.

Corregido#

• La cota de 3 sigma del conjunto de relojes ahora cubre el suelo de flicker, y la comprobación de salud del filtro lo detecta. Con un flicker_floor, el reloj verdadero llevaba FM de flicker pero el filtro de dos estados que proporciona la cota de integridad no, de modo que la cobertura de 3 sigma del escenario clock-ensemble distribuido era 0,41 (clásico) y 0,33 (cuántico), y la comprobación NIS/NEES, que extraía su verdad de referencia del modelo del propio filtro, informaba valores idénticos con y sin el suelo. Ahora la cota es la varianza de dos estados más la varianza exacta de la fase de flicker acumulada desde la última sincronización, calculada con el mismo banco que usa el reloj verdadero; la comprobación NIS/NEES extrae su verdad de referencia del modelo ampliado con ese banco y ejecuta el filtro ampliado correspondiente (y el filtro de dos estados frente a una verdad de referencia con flicker informa consistent = false). Cambio de salida, solo para relojes con flicker_floor distinto de cero: integrity en clock-ensemble pasa de 0,40866 / 0,33026 a 0,99970 / 1,0 (clásico / cuántico) y los NIS/NEES de filter_health ahora incluyen el flicker; el error de temporización, holdover_s y timing_p95_ns no cambian, y los escenarios sin suelo son idénticos byte a byte. scenarios/orbit-gnss-challenged.toml (tipo de escenario orbit, semilla 7, suelos 1e-16 / 2e-11) también se mueve: fom.integrity clásico de 0,7734 a 1,0 y cuántico de 0,9796 a 1,0, y cambian los NIS/NEES de filter_health y sus bandas. Su filter_health.consistent cuántico pasa de true a false: un evento de muestreo del conjunto de flicker de 16 semillas por 60 pasos (NIS 0,8815 frente a una banda de [0,9125, 1,0914]), no un defecto. La banda es una banda del 95 %, de modo que aproximadamente el 5 % de las semillas señalan un filtro correspondiente por construcción (40 semillas nuevas de este escenario: cuántico 1 y clásico 2 señalados); con 64 por 200 la misma semilla queda dentro de la banda para ambos relojes (NIS 0,990 y 1,001). Seguimiento conocido: el tipo de escenario fusion tiene la misma carencia (integridad clásica 0,80 con un suelo); el tipo de escenario hybrid se mantiene por encima de 0,99.

[0.34.1] - 2026-10-10#

Seguridad#

• Reforzamiento de la entrada del servidor MCP. Las herramientas de escenario del servidor MCP ahora aceptan solo contenido en línea y rechazan los campos de fuente de archivo; el tamaño de la entrada está limitado. Aviso: GHSA-8wpf-hqg5-6xjr.

[0.34.0] - 2026-10-09#

Reproducción de laboratorio: un motor de seguimiento, monitores de detección y un ejecutor de campañas para grabaciones IQ de GNSS, con los diseños de lazo, los estimadores de C/N0 y las puntuaciones que los acompañan. Clase de evidencia: todo lo que sigue es MODELLED o está comprobado en su coherencia interna frente a formas cerradas y simulación con semilla; nada de ello añade una fila VALIDATED, y el registro de verificación no cambia (251 filas: 124 validadas, 123 modeladas, 4 del socio). Es una capa de análisis de software: nada de esto sintetiza una forma de onda de inhibidor o de spoofer, y nada transmite.

Añadido#

• Reproducción de laboratorio: condiciones de prueba, ejecutor de campañas y puntuación (0.34.0). kshana iq campaign <campaign.toml> reproduce grabaciones × cadenas de front-end × diseños de lazo (kshana.loop-design/1) y puntúa cada celda frente a un archivo de condiciones de prueba por grabación (kshana.test-conditions/1, TOML o JSON). Ese archivo indica lo que un laboratorio sabe de la grabación: los satélites esperados y, para cada evento, su etiqueta de tipo, el inicio y el final, los satélites afectados y el perfil indicado de J/S o de potencia del inhibidor. Son solo metadatos. Las puntuaciones por satélite, para toda la ejecución y por evento, son:

  • disponibilidad, tiempo hasta la pérdida de enganche y J/S indicada en el momento de la pérdida;
  • tiempo de readquisición, desde el final del evento y desde la pérdida;
  • degradación medida de C/N0 por intervalo de J/S indicada;
  • episodios de falso enganche por hora enganchada (el indicador del seguidor, o Doppler frente a un archivo auxiliar de verdad de referencia);
  • fluctuación de los discriminadores PLL y DLL.

  Junto a cada curva de degradación medida se dibuja una referencia analítica de separación espectral (jamming::effective_cn0_dbhz con la Q del tipo) y se etiqueta MODELLED dondequiera que aparece.

  Las celdas se ejecutan en paralelo a través de la máquina de estados de enganche de la sesión de seguimiento, y cada una se escribe de forma atómica bajo una clave de hash de contenido. La clave abarca el SHA-256 de la grabación, los hashes de condición, front-end, diseño, ejecución y puntuación, el data_class obligatorio (synthetic | client-confidential) y la versión del motor. Con run.epochs establecido, también se conservan el flujo kshana.track-epoch/1 y los eventos de enganche de cada celda, nombrados por clave de celda y con su hash incorporado a la celda. cell_key y report::digest son públicos, de modo que un consumidor puede volver a derivar cada clave y el digest. Por tanto, una nueva ejecución omite las celdas terminadas, y las salidas nunca dependen del número de procesos de trabajo. La ejecución escribe scorecard.csv/.json, un report.html autónomo y un DIGEST. Los umbrales de superado/no superado ([scoring.bars], sustituibles por grabación) se aplican al construir el informe.

  • [scoring] cn0_estimator = "m2m4" | "nwpr" (por defecto "m2m4", parte del hash de puntuación) elige el C/N0 en el que se basan el C/N0 notificado y la curva de degradación. Ambas estimaciones se puntúan y se notifican siempre (medianas de toda la ejecución y de la línea base, y por intervalo de J/S), y la celda y el cuadro de puntuación registran el estimador. NWPR lee unos 8 dB × Bn·T por debajo bajo la propia fluctuación del lazo; M2M4 no.

  También es nuevo:

  • kshana iq campaign report <dir> reconstruye los cuadros de puntuación, el informe y el digest a partir de las celdas;
  • kshana iq conditions <file> comprueba un archivo de condiciones de prueba frente a su esquema;
  • events_from_sigmf = true importa como eventos las anotaciones kshana:test_event de una grabación SigMF;
  • Python incorpora iq_test_conditions, iq_campaign y iq_campaign_report;
  • kshana-mcp incorpora iq_campaign, que es incremental y reanudable bajo el presupuesto de muestras por llamada, con todos los archivos confinados al directorio de trabajo, y iq_campaign_status.

  Pruebas: tests/iq_campaign.rs ejecuta una campaña sintética de 3 grabaciones × 2 front-ends × 2 diseños. Sus escenas llevan perfiles de C/N0 indicados y cubre:

  • cada métrica comprobada frente a la verdad de referencia inyectada;
  • reanudación tras una ejecución parcial con un solo proceso y una celda corrupta, idéntica byte a byte a una ejecución ininterrumpida con cuatro procesos;
  • archivos de épocas por celda;
  • una regresión de readquisición de tres satélites de 20 s: con reacquire activado, todos los canales vuelven en 2 s tras un hueco de 2 s; el resultado con reacquire desactivado queda fijado;
  • umbrales reevaluados sin volver a ejecutar;
  • la CLI;
  • comprobaciones ignoradas en modo release de rendimiento y memoria, incluida una grabación de 4 GB (5,45× el tiempo real, memoria máxima 2 MB por encima del RSS inicial; mediciones en una máquina, no umbrales).

  Solo software: nada transmite y no se sintetiza ninguna forma de onda de interferencia ni de spoofing. Notas de diseño y de lo construido: docs/design/LAB-CAMPAIGN.md.

• Motor de seguimiento para reproducción de laboratorio (0.34.0: B3.1, B3.2, B3.3, B6.1).

  • Archivos de diseño de lazo: TOML kshana.loop-design/1 (docs/design/LOOP-DESIGN-TOML.md; analizador iq::track::design). Uno o más diseños con nombre fijan cada campo del lazo:

    • tipo de portadora (PLL, FLL o PLL asistido por FLL), órdenes y anchos de banda;
    • discriminadores PLL/FLL/DLL y ayuda a la portadora;
    • espaciado e integración;
    • umbrales de enganche y ventanas de C/N0, y sincronización de bits;
    • la máquina de estados de enganche;
    • la adquisición de relevo ("auto" o explícita).

    Los diseños pueden extends unos a otros. Se rechazan las claves desconocidas. Cada diseño resuelto tiene un hash SHA-256 sobre una forma JSON canónica (claves ordenadas en cada nivel, formato numérico fijo), de modo que el hash no depende del orden de los campos; todas las salidas lo registran. Superficies:

    • kshana iq track --design <file> [--design-name], donde las opciones explícitas prevalecen sobre el diseño y quedan registradas;
    • kshana iq sweep --design <file>, que ejecuta todos los diseños del archivo;
    • Python iq_track(design=, design_name=, reacquire=), iq_loop_designs;
    • MCP iq_track design/design_name.

  • C/N0 M2M4 (EpochOutput.cn0_m2m4_dbhz, la columna cn0_m2m4_dbhz de track-epoch tras cn0_beaulieu_dbhz; diccionarios de épocas de Python). La estimación por momentos de segundo y cuarto orden sobre las mismas ventanas que NWPR, solo a partir de la potencia del prompt: NWPR lee por debajo bajo la propia fluctuación de portadora del lazo (unos 8 dB × Bn_PLL·T) y M2M4 no. En GPS L2C CM (20 ms, nominal 40 dB-Hz, PLL de 1 a 10 Hz) lee 39,93 dB-Hz en cada ancho de banda mientras que NWPR cae de 39,55 a 38,22; en L1 C/A a 45 dB-Hz lee 45,34. NWPR y todas las demás salidas no cambian (fijado bit a bit). El registro binario sigue siendo de 184 bytes (el valor ocupa el flotante reservado y el bit de indicador 6).

  • Tomas de correlador adicionales (multicorrelador / SQM). [design.integration] extra_taps_chips = [..] (desfases en chips respecto al prompt, positivos hacia adelantado; como máximo 16, cada uno dentro de ±2) correlaciona réplicas adicionales junto a E/P/L y las devuelve como EpochOutput.extra ((offset, value) en el orden del diseño). Los lazos nunca las usan. La clave se omite del JSON canónico cuando está vacía, de modo que el hash del diseño por defecto y toda salida sin tomas no cambian (kshana.track-epoch/1 se mantiene; el CSV/JSONL/binario sin tomas son idénticos bit a bit). Con tomas: columnas CSV/JSONL y un registro binario de 184 + 16 × taps bytes cuya cabecera lleva extra_taps_chips, de modo que un lector antiguo rechaza el archivo en lugar de interpretarlo mal. --extra-taps (CLI), extra_taps (Python) y extra_taps_chips (MCP iq_track). Los diseños de una misma ejecución deben coincidir en las tomas.

  • Canales en paralelo (iq track / iq sweep --threads <N|auto>; Rust TrackSession::with_threads). Los canales de cada fragmento se ejecutan en hasta N hilos (std::thread::scope; wasm32 sigue siendo serie). La correlación y la máquina de estados de enganche de un canal solo afectan a ese canal; sus épocas y eventos se almacenan en búfer y se escriben en los destinos en orden de canal, de modo que la salida (CSV, JSONL, binario, eventos, resumen) es idéntica byte a byte a la ejecución en serie para cualquier N. Por defecto sigue siendo 1 hilo. Medido en una grabación de 12 canales, 4 s, 4,092 MHz en 4 núcleos: 19,5 s en serie, 11,5 s con 2 hilos, 6,3 s con 4 (3,1×; la adquisición inicial es en serie).

  • Exportación de la superficie de adquisición (kshana.acq-surface/1; iq::acq_surface, docs/design/ACQ-SURFACE.md). iq acquire --surface <path> (un PRN; CSV, JSON o binario), iq_acq_surface de Python y iq_acquire surface_out de MCP escriben toda la superficie de potencia de correlación Doppler × fase de código que calcula la búsqueda (sus celdas son las de acquire, bit a bit) con el pico y dos refinamientos de Doppler fino: una estimación parabólica y una búsqueda fina de 1/16 de intervalo (≈5 Hz con 4 ms coherentes, frente a intervalos de 167 Hz). acquire en sí y todos los valores por defecto no cambian.

  • Salida de épocas en flujo (kshana.track-epoch/1; iq::track::sink). Cada actualización del lazo incluye:

    • los correladores adelantado/prompt/retrasado;
    • las tres salidas del discriminador;
    • los estados de los NCO de PLL/FLL/DLL y la fase de portadora;
    • los indicadores PLI y de enganche;
    • ambas estimaciones de C/N0 y los bits;
    • el estado de enganche.

    Se escribe a medida que ocurre, como CSV, JSON Lines o una forma binaria versionada con lectores en Rust (BinaryEpochReader) y Python (iq_read_epochs).

    • iq track incorpora --epochs, --events y --summary (kshana.track-summary/1), y iq sweep incorpora --epochs y --events. iq_track de MCP incorpora epochs_out/events_out y construye su respuesta a partir del resumen de memoria acotada.
    • El montón de una ejecución ya no crece con la duración de la grabación: tests/iq_track_memory.rs lo mide con un asignador contador (6× la duración, mismo pico dentro de 64 KiB), con un control que muestra que la vía en memoria sí crece.
    • La salida en flujo es idéntica bit a bit a la reproducción en memoria.

  • Máquina de estados de enganche (iq::track::lock, TrackSession): captura inicial → enganchado → perdido → readquisición → captura inicial, o retirado cuando una pérdida supera reacq_window_s (por defecto 30 s). Las búsquedas fallidas se reintentan cada reacq_interval_s (0,1 s), con espaciado uniforme, de modo que el calendario de reintentos añade como máximo 0,1 s al tiempo de readquisición medido. Un retroceso opcional (reacq_max_interval_s por encima de reacq_interval_s) está desactivado por defecto, y max_reacq_attempts es un tope opcional (0, ninguno, por defecto). Una interrupción de 2 s en tres PRN a 4,092 MS/s ahora termina con todos los canales readquiridos y enganchados. Con un presupuesto de 3 intentos, todos los canales se retiraban en 0,2 s desde la pérdida.

    • Los umbrales (loss_dwell_s, pull_in_max_s, la ventana Doppler de readquisición) proceden del diseño. Cada transición es un evento con su motivo.
    • La comprobación de falso enganche busca el Doppler seguido frente a su alias FLL/PLL de ±1/(2T). Detecta el falso enganche que midió PR #38 (−2400 Hz seguido con 500 Hz de desviación). Con la readquisición activada, el canal termina enganchado en el Doppler inyectado.
    • Un hueco de señal de 0,8 s se declara como pérdida y se readquiere en 0,3 s desde el regreso de la señal.
    • --summary final_state (y la columna de la tabla) es el estado tras la última transición, de modo que un canal retirado después de su última actualización del lazo figura como RETIRED.
    • Asistencia del FLL solo durante la captura inicial ([design.carrier] fll_assist = "pull-in", el valor por defecto; "always" mantiene el comportamiento anterior bit a bit). El FLL cede el control al PLL cuando el PLI suavizado se mantiene en fll_off_pli (0,8) o por encima durante fll_gate_dwell_s (0,1 s), y vuelve cuando cae por debajo de fll_on_pli (0,6). Con la asistencia siempre activa, la vía FLL de 10 Hz rompía el enganche de fase por debajo de unos 38 dB-Hz en señales limpias: a 35 dB-Hz la fracción de enganche de fase era del 10–16 %, con un error de fase verdadero de 38–41°. Con la compuerta, el valor por defecto mantiene el 100 % a 35 dB-Hz con 4,5°, igual que un PLL solo. La captura inicial desde un error de relevo de 100 Hz no cambia. Evidencias con umbrales preregistrados: docs/design/evidence/carrier-lock/. Por tanto, los lazos por defecto no coinciden bit a bit con las ejecuciones anteriores del diseño por defecto. Use fll_assist = "always" para reproducirlas. Límite conocido: a 35 dB-Hz el traspaso llega a los 1,9–2,6 s del seguimiento, y a 33 dB-Hz el FLL de 10 Hz mantiene el PLI por debajo del umbral de traspaso, de modo que la captura inicial nunca se completa.
    • Claves de diseño de lazo y API nuevas, en lista:
      • [design.carrier]: fll_assist, fll_off_pli, fll_on_pli, fll_gate_dwell_s;
      • [design.lock]: reacq_window_s, reacq_interval_s, reacq_max_interval_s, con max_reacq_attempts cambiado de un valor por defecto de 3 a un tope opcional (por defecto 0);
      • Rust: LoopConfig.fll_assist (FllAssist, FllGate), LoopCore::set_fll_enabled, EpochOutput.fll_active, ChannelSummary.final_state.
    • El hash del diseño se calcula sobre una forma JSON canónica, y el hash del valor por defecto incorporado es 33261cd171a53803a6c262686e878e01f37d902a93d5918c20a44297b8ef8e80 (fijado por una prueba).
    • Notas de compatibilidad de la salida:
      • la tabla de iq track tiene una columna final final_state;
      • el CSV de iq sweep tiene una columna final design_hash, y su JSON tiene design_hash y warnings;
      • el mean_cn0_dbhz del barrido es ahora la media de todas las actualizaciones que tienen una estimación NWPR (resumen de memoria acotada), y ya no la de la segunda mitad de la ejecución.
    • La readquisición está desactivada en el valor por defecto incorporado, donde la máquina de estados solo observa y los lazos funcionan bit a bit igual que sin ella. (Los propios lazos por defecto sí cambiaron: véase la asistencia del FLL más arriba.) Actívela por diseño ([design.lock] reacquire = true), con --reacquire o con reacquire=True.
    • Una advertencia de commensurate_sampling: cuando fs está a menos de 1e-6 de un múltiplo de la mitad de la tasa de chips (iq::track::commensurate_samples_per_chip), iq track/iq sweep (salida, --summary, JSON del barrido), la respuesta de iq_track de MCP y el resultado de iq_track de Python advierten de que la fluctuación y el sesgo del lazo de código no son representativos. La causa raíz está documentada con umbrales preregistrados en docs/design/evidence/dll-jitter/. Con exactamente 2 muestras por chip y espaciado de 0,5 chips, la curva S del DLL es un único escalón y el lazo oscila: ≈ 0,09 chips de error de código RMS (≈ 26 m) a 45 dB-Hz, frente a ≈ 0,004 chips con una tasa inconmensurable. El C/N0 NWPR unos 2 dB bajo a esa tasa tiene la misma causa. Con exactamente 0 Hz de Doppler de código y 4 muestras por chip, el código nunca cruza la zona muerta de ±0,21 chips, de modo que puede persistir un sesgo de fase de código de hasta aproximadamente 0,2 chips sin aparecer en la fluctuación (medido: un espaciado de 0,5 chips da 2,0× el error de código del control con una media de +0,011 chips; un espaciado de 0,25 chips da +0,125 chips); la advertencia cubre la tasa.
    • Límite conocido: el diseño por defecto no hace el traspaso FLL→PLL por debajo de unos 35 dB-Hz (un suelo de captura inicial de ~35 dB-Hz; véase la asistencia del FLL más arriba y docs/design/evidence/carrier-lock/).
    • Una búsqueda de falso enganche o de readquisición que no puede ejecutarse (una tasa sin un número entero de muestras por periodo de código) ya no detiene el seguimiento.
    • Pruebas: tests/iq_track_engine.rs, tests/iq_cli.rs, iq::track::design::tests, tests/python y el viaje de ida y vuelta de IQ por MCP.

• Perfiles de C/N0 en escenas sintéticas (0.34.0). iq::channel::cn0_profile programa un C/N0 variable en el tiempo por satélite en las propias escenas de Kshana, como desfases en dB relativos al C/N0 de la escena. Formas: escalón, rampa, lineal por tramos y desvanecimientos de Rice con semilla de tipo centelleo, con un S4 y un tiempo de decorrelación indicados. Se aplican mediante el gancho de canal de escena existente (Cn0ProfileChannel, que se compone con los efectos de ionosfera, troposfera, centelleo y multitrayecto), sin cambios en el núcleo de la escena. El cn0_dbhz del archivo auxiliar de verdad de referencia sigue el perfil.

  • Superficies: kshana iq scene … --cn0-profile <toml> y kshana.iq_scene(…, cn0_profile="<toml>").
  • Para qué sirve: los lazos, los monitores y la puntuación de campañas pueden someterse a pruebas de esfuerzo frente a una verdad de referencia conocida. Solo cambia la intensidad de las señales legítimas.
  • Comprobaciones (tests/iq_cn0_profile.rs). Umbrales: intensidad media del desvanecimiento dentro del 5 % de 1, S4 dentro del 8 % del objetivo (con S4 = 0,3, 0,7 y 1), correlación de intensidad superior a 0,9 con 0,05 τ e inferior a 0,05 con 5 τ; verdad de referencia exactamente el C/N0 indicado más el perfil; una caída del C/N0 NWPR seguido dentro de 0,7 dB de un escalón de 6 dB. Medido: S4 dentro del 1,3 % del objetivo y una caída seguida de 6,26 dB.

• Monitores de detección en la vía IQ (0.34.0 "Reproducción de laboratorio"). Nuevo módulo iq::monitor, comando kshana iq monitor y enlace kshana.iq_monitor(path, ...). Observan una grabación e informan de series temporales y de eventos marcados (instantes de inicio, de alarma y de fin, pico, umbral). Solo detectan y miden; nada de esto genera una señal.

  • Potencia total / AGC: potencia por bloque y la ganancia que aplicaría un AGC ideal; marca subidas y bajadas.
  • Espectro precorrelación: PSD de Welch por bloque frente a una línea base aprendida. El umbral de exceso procede de un objetivo de falsas alarmas. También curtosis compleja y un detector de pulsos. El detector de pulsos cuenta las muestras que superan un umbral en cada bloque y genera un evento cuando la cola superior binomial exacta de ese recuento queda por debajo de pulse_pfa (por defecto 1e-4 por bloque), no cuando una puntuación z supera un límite: con los recuentos esperados pequeños de bloques cortos, una sola muestra ya supone varias sigmas.
  • C/N0 por canal: dos detectores de cambio CUSUM unilaterales (descenso y ascenso), alimentados con estimaciones independientes (el paso se fija a partir de la ventana de C/N0 del lazo).
  • SQM a partir de los correladores: delta (I_E − I_L)/I_P y cociente (I_E + I_L)/(2 I_P), además de pruebas de asimetría con correladores adicionales cuando un canal los proporciona.
  • Serie de indicadores de enganche: PLI y un indicador de enganche de frecuencia a partir de prompts sucesivos, como señales en bruto. Las decisiones de enganche y de pérdida de enganche siguen en la máquina de estados de enganche del motor de seguimiento.

  Una sola pasada en flujo (iq::monitor::run::run_monitors) ejecuta todo, con un archivo de ajustes TOML/JSON (MonitorConfig); el ejecutor de campañas usa el mismo punto de entrada. Todo MODELLED. Cada estadístico se comprueba frente a su forma cerrada mediante simulación con semilla (tests/iq_monitor.rs):

  • superaciones de la potencia por bloque frente a la cola Gamma;
  • media de curtosis 2 y dispersión 2/√N;
  • fracción de pulsos e^{−t};
  • longitudes de racha de CUSUM frente a la aproximación de Siegmund (medidas 330 y 8,46 muestras frente a 338 y 8,34);
  • el indicador de enganche de fase frente a la media de fase de Rice;
  • en una señal C/A seguida, las dispersiones del delta y del cociente SQM se desvían alrededor de un 6 % de las formas cerradas de primer orden (medido 5,97 %; umbral de la prueba 12 %).

  La fórmula de falsas alarmas del exceso espectral es una aproximación; la tasa medida fue 1,3× la fórmula. De extremo a extremo, los monitores marcan:

  • un escalón de C/N0 de 6 dB (instante del cambio dentro de una estimación);
  • un trayecto reflejado que aparece a mitad de la grabación (prueba de cociente);
  • una interrupción de la señal (el PLI cae de 0,999 a −0,3 y el FLI de 0,93 a 0,03 durante ella);
  • un tono de banda estrecha y muestras dispersas de gran amplitud (pruebas espectrales, de pulsos y de curtosis). Son entradas genéricas de prueba de DSP, no modelos de interferencia.

Cambiado#

• iq track/iq sweep transmiten en flujo a través de la nueva sesión (véase Añadido).
  • --csv conserva sus columnas de 0,32 pero ahora se emite en flujo, de modo que las filas de varios canales se intercalan en orden temporal en lugar de agruparse por canal. --json conserva su forma de 0,32 y sigue guardando todas las épocas en memoria: use --epochs para grabaciones largas.
  • iq sweep mide la fluctuación sobre las actualizaciones de la segunda mitad de la duración de la ejecución (antes la segunda mitad del número de actualizaciones), y su CSV/JSON incorporan una columna design_hash.
  • La tabla de seguimiento incorpora una columna final_state.
  • El texto de uso ya no afirma que iq track acepte las opciones del front-end; solo iq acquire las aplica.
  • acq_noncoherent y doppler_max de iq_track de Python ahora tienen None por defecto (los valores del diseño, 1 y 5000 Hz en el diseño incorporado). Sus épocas incorporan los correladores adelantado/retrasado, carrier_phase_cycles, bit_edge, bit y state, y el resultado incorpora design y events.

Corregido#

• El paso de adquisición por defecto ya no entrega al seguimiento de Galileo E1 un residuo que el FLL no puede captar. El paso 2 / (3 · N · T_code) deja hasta 1 / (3 · N · T_code) de error Doppler en el traspaso, pero el FLL de dos cuadrantes por defecto solo capta 1 / (4 T_track). Para todo código de 4 ms o más (N = 1), incluidos Galileo E1-B y E1-C, el residuo (83,3 Hz con 4 ms) quedaba fuera de la captura de 62,5 Hz y el seguimiento hacía falso enganche a +125 Hz, con un indicador de enganche de fase de 0,97 que lo ocultaba. El paso por defecto ahora también está limitado a 0.2 / T_track (kshana::iq::acq::default_step_hz), 0,8 de la captura, de modo que el traspaso queda dentro de ella incluso cuando gana el intervalo contiguo. (0,4 se probó primero: hizo falso enganche en 1 ejecución de 42 con E1-B, y una búsqueda GPS L1 C/A de 1 ms coherente eligió un intervalo a 350 Hz y se enganchó a +500 Hz; 0,25 y 0,2 no tuvieron ninguno en las mismas ejecuciones.) Coste: Galileo E1-B/E1-C pasan de intervalos de 166,7 Hz a 50 Hz, 201 intervalos sobre ±5 kHz en lugar de 61; los códigos de 1 ms (166,7 Hz, N = 4) no cambian. "auto" en un diseño de lazo significa esto; un doppler_step_hz o --doppler-step explícito se usa tal como está escrito, y iq acquire (sin traspaso al seguimiento) conserva el paso de los manuales. La cabecera de época y --summary ahora registran el paso resuelto y los anchos de banda de lazo de cada canal (resolved). El hash del diseño por defecto no cambia. Cambio de salida: las detecciones en códigos de 4 ms o más pueden caer en intervalos Doppler distintos.

• GPS L2C CM (actualización de lazo de 20 ms) mantiene el enganche con el diseño por defecto. El PLL de 15 Hz y el FLL de 10 Hz por defecto tienen Bn · T de 0,3 y 0,2 con T = 20 ms, y el lazo perdía el enganche incluso desde un inicio perfecto (PLI −0,08, M2M4 15,8 dB-Hz). Una nueva clave de diseño, carrier.bn_t_max (por defecto 0,1), limita los anchos de banda de ruido del PLL y del FLL a bn_t_max / T cuando el tiempo de actualización del lazo es superior a 4 ms (Design::loop_config_for): 5 Hz y 5 Hz con 20 ms, 10 Hz y 10 Hz con los 10 ms de BeiDou B1C; los códigos de 1 ms y 4 ms conservan 15 y 10 Hz. Se aplica también a los anchos de banda explícitos; bn_t_max = 0 lo desactiva. La clave se omite de la forma canónica en su valor por defecto, de modo que el hash por defecto no cambia; un diseño que fija cualquier otro valor tiene un hash distinto. A 45 dB-Hz, L2C CM da ahora PLI 0,996, error Doppler 0,00 Hz y M2M4 42,71 dB-Hz. Asunto abierto conocido: el C/N0 NWPR lee 1,76 dB por debajo allí (y 2,45 dB por debajo en B1C con 10 ms), por lo que el T5 de la matriz para L2C sigue siendo un hallazgo ignorado.

• docs/assets/clock-ensemble-band.svg regenerado: la figura confirmada estaba desactualizada respecto a su propio escenario (un cambio de datos, no un redibujado). El gráfico se dibujó el 2026-06-02 a partir de scenarios/clock-ensemble.toml; dos días después, 67fed19e fijó los suelos de FM de flicker en ese escenario (cuántico flicker_floor = 1e-16, CSAC flicker_floor = 2e-11) y la figura nunca se volvió a dibujar. Mostraba la ejecución anterior a los suelos: eje y de 0 a 47 ns, p95 de interrupción por ejecución del CSAC de 10,5 a 47,6 ns (media 25,2 ns), holdover clásico de 4050 s de media. El escenario tal como se distribuye (y como ya indican el tutorial y el resumen de la CLI) da un eje y de 0 a 407 ns, p95 por ejecución del CSAC de 40,8 a 374,0 ns (media 167,0 ns), holdover clásico de 844 s [220 a 2130 s]; la línea de especificación de 20 ns queda en los mismos 20 ns sobre un eje aproximadamente nueve veces más alto. El motor no ha cambiado: el motor actual sobre el archivo de escenario de junio reproduce exactamente el eje de la figura antigua. La figura no se referencia desde el README ni desde la documentación.

Limitaciones conocidas#

• El C/N0 NWPR lee por debajo con un C/N0·T por prompt alto, y BOC(1.1) a 5 MS/s pierde aproximadamente 1 dB. NWPR no tiene sesgo con prompts ideales, pero la propia fluctuación del PLL del lazo cuesta unos 8 dB × Bn·T ajustados (una escena, cuatro puntos: −0.24/−0.44/−0.77/−1,58 dB a 1/2.5/5/10 Hz y 20 ms; unos −1 dB con el bn_t_max = 0.1 por defecto); M2M4 es insensible. Los datos de BeiDou B1C a 5 MS/s también pierden unos 1 dB de potencia de prompt por la limitación de banda (use 10 MS/s o más). Ninguno de los dos es un defecto del estimador; las filas T5 de la matriz de señales para GPS L2C y BeiDou B1C siguen siendo hallazgos ignorados con estas causas.

[0.33.1] - 2026-10-08#

Seguridad#

• Texto de los gráficos y adopción de gráficos en Studio reforzados. El texto que un escenario lleva a un gráfico generado ahora se escapa de forma coherente mediante una rutina compartida, y Studio adopta solo el marcado de dibujo de un gráfico. Los parámetros de dirección de Studio, las búsquedas por tipo de escenario y las descargas de escenarios se restringen a valores conocidos. Los gráficos incluidos, los resultados registrados y las cifras publicadas no cambian. Se recomienda actualizar a quien abra en Studio archivos de escenario de fuentes no fiables o incruste gráficos generados en páginas web. Aviso: GHSA-h25h-cg9f-v2cg.

[0.33.0] - 2026-10-08#

Documentación#

• El alcance de la capa IQ en interferencia y spoofing, indicado con exactitud. Las entradas de 0.31.0 y 0.32.0 más abajo dicen que la capa IQ añade "ninguna síntesis de formas de onda de interferencia ni de spoofing". Eso es cierto de la propia capa IQ (iq::scene genera solo señales GNSS legítimas), pero se leía como una afirmación sobre todo el motor, y no lo es: desde 0.29.0, la sección [iq] del tipo de escenario spectrum escribe una instantánea SigMF de su modelo analítico con los inhibidores configurados (inhibidores de tipo ruido intervalo a intervalo, tonos y chirps como formas de onda), y spoof_capture suma en memoria una señal auténtica y una réplica de spoofer para probar la captura del lazo (el compuesto nunca se escribe). El motor también incorpora un receptor GNSS por software desde 0.20.0 (sdr: adquisición y seguimiento; desde 0.31.0 también iq::acq y iq::track). Nada en Kshana transmite ni controla hardware de radio. La línea de estado del README, docs/POSITIONING.md, docs/SPECTRUM.md y las notas de diseño de IQ ahora lo dicen; las entradas publicadas se dejan como se publicaron. No cambia ningún comportamiento.
• Limitación conocida: muestreo conmensurable. Con una tasa de muestreo que es un múltiplo entero o semientero de la tasa de chips, las muestras caen en las mismas fases de chip en cada chip y el discriminador de código se convierte en una escalera. En una señal sintética GPS L1 C/A a 45 dB-Hz con espaciado de 0,5 chips, 2,046 MHz (2 muestras/chip) da un error de código RMS de ≈ 0,09 chips (≈ 26 m) y un sesgo de −0,09 chips, frente a ≈ 0,003 chips con una tasa inconmensurable. El C/N0 NWPR lee ≈ 2,4 dB por debajo allí. A 4,092 MHz depende del espaciado y del Doppler de código. Con 0,5 chips es inocuo con 1500 Hz de Doppler, pero 2× con un sesgo de 0,011 chips con 0 Hz, y con 0,25 o 0,1 chips el error de código es de 8–10×. El seguimiento de portadora no se ve afectado. docs/design/iq-notes/receiver.md contiene las mediciones.

Añadido#

• Capa IQ de GNSS en el servidor MCP (Fase B.1). kshana-mcp incorpora seis herramientas que manejan la capa kshana iq desde un agente: iq_signals (los nombres de señal aceptados y la configuración IQ), iq_info (describir una grabación), iq_scene (generar una escena de perfil indicado o de efemérides de difusión, con el canal opcional a nivel de señal), iq_acquire (adquisición por FFT, opcionalmente tras etapas de front-end), iq_track (adquirir y luego el banco DLL/PLL/FLL) y iq_frontend (paso de banda, filtro de muesca, supresión, excisión, AGC, cuantificador). Las muestras IQ nunca cruzan el protocolo: cada herramienta recibe rutas de archivo dentro de un único directorio de trabajo fijado por KSHANA_MCP_IQ_DIR (si no está definido, las herramientas de archivos IQ quedan desactivadas y las demás no se ven afectadas), rechaza las rutas que resuelven fuera de él y las salidas que ya existen salvo que se fije overwrite, aplica un presupuesto de muestras por llamada (KSHANA_MCP_IQ_MAX_SAMPLES, por defecto 50.000.000) antes de cualquier trabajo, rechaza los argumentos desconocidos y responde con un resumen JSON compacto (detecciones, C/N0, estado de enganche y cada archivo escrito con su recuento de bytes). La salida por época va solo a los archivos que nombre quien llama. Las herramientas ejecutan la misma vía de código que la CLI a través de una nueva junta pública, kshana::iq::cli::execute, que devuelve el mensaje de la CLI en lugar de imprimirlo (stdout es el canal JSON-RPC de MCP); iq::cli::build_code y iq::cli::signal_names también son ahora públicas. Solo software y aditivo: la capa IQ no añade síntesis de interferencia ni de spoofer, nunca se transmite nada y no hay dependencias nuevas. server.json declara las dos variables de entorno. Las pruebas de ida y vuelta de mcp/kshana-mcp/tests/iq_round_trip.rs generan una escena corta de dos satélites y comprueban la adquisición frente al propio archivo auxiliar de verdad de referencia de la escena, el enganche y el C/N0 del seguimiento, el front-end, la salida SigMF, el presupuesto, el confinamiento de rutas y el estado desactivado.

• La capa IQ de GNSS en el registro de validación. Una verificación cruzada preregistrada frente a gps-sdr-sim (un generador independiente de banda base GPS L1 C/A, MIT, commit 28ca29a6) forma ahora parte de la suite de pruebas siempre activa (tests/iq_gpssdrsim_cross_generator.rs). Su salida de referencia confirmada (tests/fixtures/iq_gpssdrsim_cross_generator/: 20 ms de I/Q de 8 bits propios de gps-sdr-sim, su listado de canales y el estado de canal subyacente obtenido con un arnés enlazado contra la misma compilación) se regenera con scripts/gen_iq_gpssdrsim_ref.sh. Nada en el momento de la prueba necesita red ni la herramienta externa. Se añaden dos filas al registro (251 filas: 124 validadas, 123 modeladas, 4 del socio):

  • Geometría de señal de la escena IQ de GNSS frente a un generador independiente de banda base: Validado. La verdad de referencia de la escena (conjunto visible, pseudodistancia, fase de código, Doppler, ángulos de observación) para una escena de efemérides de difusión coincide con el estado de canal de gps-sdr-sim en los 11 canales: en el peor caso 1,6 mm, 5.5e-6 chips, 7.4e-5 Hz, 4e-9 grados, frente a umbrales de 0,05 m, 2e-4 chips, 0,02 Hz y 1e-4 grados fijados antes de la ejecución.
  • Adquisición IQ de GNSS sobre muestras I/Q generadas de forma independiente: Modelado, con un hallazgo. iq::acq encuentra todos los satélites simulados en las muestras de gps-sdr-sim dentro de los umbrales registrados (fase de código dentro de 0,195 chips, Doppler dentro de 72 Hz). Sin embargo, el umbral registrado "ningún otro PRN detectado" falla: en la salida sin ruido de gps-sdr-sim, el umbral de ruido gaussiano es superado por la correlación cruzada de los otros satélites en los 21 PRN ausentes. La prueba estricta se conserva, ignorada junto con el hallazgo, y una prueba fijada lo registra. No cambia ningún código del motor ni API pública. Las muestras I/Q no se comparan muestra a muestra: la tabla de senos entera de gps-sdr-sim, las ganancias, la fase inicial de portadora nula y los campos LNAV truncados no son magnitudes en las que un receptor necesite coincidir. La comparación se hace en los observables que mide un receptor.

Cambiado#

• iq track hace el traspaso desde una adquisición de ≈4 ms por defecto (cambio de comportamiento). La adquisición que inicializa cada canal de seguimiento ahora integra ceil(4 ms / T_code) periodos de código de forma coherente en lugar de uno, donde T_code es el periodo completo del código (primario por longitud secundaria en un código por niveles, la unidad sobre la que integra la adquisición). Los códigos de 1 ms sin niveles (GPS L1 C/A, BeiDou B1I, GLONASS L1OF) ahora buscan 4 periodos (4 ms), de modo que el paso Doppler por defecto 2 / (3 · N · T_code) es de ~167 Hz en lugar de ~667 Hz. Todo código cuyo periodo completo ya es de 4 ms o más conserva 1 periodo: Galileo E1-B (4 ms), BeiDou B1C (10 ms), y los GPS L5-I/L5-Q, Galileo E5a-I/E5a-Q y E1-C por niveles (10 a 100 ms con sus códigos de recubrimiento), y GPS L2C. Por tanto, todas las señales integran al menos ~4 ms. Una búsqueda de un solo periodo podía hacer el traspaso a un canal con una desviación de hasta ~333 Hz, fuera de la captura del FLL, y este hacía seguimiento de un falso enganche a ~500 Hz mientras notificaba un seguimiento limpio. En un barrido con semilla de 180 canales GPS L1 C/A (Doppler en ±5 kHz, de 38 a 47 dB-Hz, la mitad con datos de navegación; docs/design/evidence/iq-track-acq-default/, repetible), los falsos enganches bajan de 27 de 180 a 1 de 180 y las adquisiciones fallidas de 102 a 11, a cambio de ~40 ms más de búsqueda por PRN en GPS L1 (11 → 52 ms). El único falso enganche residual está a 38 dB-Hz, a 36 Hz de desviación. Todas las superficies coinciden: kshana iq track y kshana iq sweep (--acq-coherent), kshana.iq_track de Python (acq_coherent=None es ahora automático; stub actualizado) y la herramienta iq_track de MCP. Quien dependiera del valor por defecto anterior puede pasar acq_coherent=1 (--acq-coherent 1). El valor por defecto propio de --coherent en kshana iq acquire sigue siendo 1. Nuevos iq::acq::auto_coherent_periods y iq::acq::AUTO_COHERENT_S públicos; prueba de regresión tests/iq_cli.rs::track_default_handoff_does_not_false_lock_where_one_period_did.
• Todo gráfico generado sigue ahora el tema Observatory del sitio: cambian los bytes de todos los gráficos. Es una revisión deliberada de las figuras publicadas, solo de colores y tipografías; no se movió ningún valor representado, coordenada ni etiqueta. El *.chart.svg de cada escenario (y por tanto las exportaciones de gráficos de Studio y los gráficos de demostración del README), el HTML del informe de ejecución (*.report.html), la animación de la línea temporal (--animate), las páginas HTML de resultados de escenarios y de estudios, el resumen de validación y las figuras y diagramas de la documentación usaban la paleta oscura cálida de julio (fondo #0c0b08, oro #e0bd84) y un tema de informe en papel cálido. Ahora toman cada color y tipografía de un único módulo, src/palette.rs, que refleja web/theme.css: los gráficos se dibujan en oscuro de instrumento sobre el fondo Observatory (#060A14) con la pila tipográfica Geist; el informe, el reproductor de animación y las páginas de resultados siguen la preferencia clara/oscura de quien los ve con los tokens claros y oscuros de Observatory. Los seis dominios de fallo conservan un color cada uno (interferencia coral, spoofing magenta, temporización azul, órbitas cian, integridad lima, navegación ámbar), y los niveles de evidencia se leen validado lima, modelado ámbar, socio magenta. Las rampas de la cascada conservan su orden perceptual (inferno), reanclado en el nuevo fondo.
  • tests/palette_sync.rs ajusta el módulo a web/theme.css en ambos temas, comprueba que docs/assets/palette.json y docs/diagrams/mermaid-config.json (ambos generados a partir del módulo, para las herramientas de figuras de Python y mermaid-cli) estén al día, y falla si aparece un literal de color hexadecimal en src/ fuera de la paleta.
  • tests/published_figures_still_reproduce.rs incorpora un tercer diagnóstico, "solo se movieron colores y tipografías", de modo que una revisión de la paleta se distingue de un valor representado que se haya movido. Se comprobó que cada gráfico del README regenerado es igual a su predecesor bajo ese normalizador.
  • tools/gen_validation_figures.py lee la paleta y ahora también genera las tres figuras de resultados del README que no tenían generador confirmado (domain-coverage-map, scenario-fom, sgp4-regime-bars), con elementos de texto reales, a partir de web/capabilities.json, el resultado de clock-holdover y tests/fixtures/sgp4_comparison.md. tools/gen_readme_assets.py lee la misma paleta, lo que corrige su deriva del tema claro respecto al sitio. Los valores de sgp4-regime-bars son la columna del peor caso kshana↔ref de ese archivo de prueba (7.31e-9, 8.05e-9, 8.18e-9 y 4.12e-6 km), sin cambios respecto a la figura de Matplotlib, y tests/figures_doc_sync.rs ahora falla si la figura confirmada y el archivo de prueba discrepan.
• docs/assets/figures/domain-coverage-map actualizado a los datos vigentes (un cambio de datos, no un redibujado). La figura indicaba 28 capacidades en 8 dominios (11 validadas, 17 modeladas), desactualizada respecto a su propia fuente declarada; dibujada ahora por su nuevo generador a partir de web/capabilities.json, indica 46 capacidades en 8 dominios (17 validadas, 29 modeladas).

Corregido#

• La Q de los inhibidores CW/de banda estrecha es ahora 1,0, no 1,5. El valor de los manuales para un tono sobre la portadora es 1 (un tono conserva el pico espectral de la señal, κ = T_c, Q = 1/(R_c κ)); el antiguo 1,5 hacía que un tono fuera menos dañino que el ruido de banda ancha con la misma J/S. Cambio de salida: unos −1,8 dB de C/N0 efectivo bajo inhibidores CW/de banda estrecha con J/S alta en los tipos de escenario jamming, lunar-jamming e interop (el tono del ejemplo spectrum incluido: 17,98 dB-Hz según la tabla, era 19,74). La Q de banda ancha sigue siendo 1,0 (conservadora, unos 3 dB por debajo de los ~2 de los manuales) a la espera de la revisión de 0,34. Fije q_override para conservar el antiguo 1,5.

• La salida entera de kshana iq scene usa el rango entero. Con ruido de potencia unitaria y una escala de escritura de 1, las escenas ci8/ci16 salían como aproximadamente {-1, 0, 1} y las escenas de 2 bits tenían sus umbrales a 2,8 sigmas. Los formatos enteros ahora se escalan de modo que el RMS esperado por componente sea una cuarta parte de la escala completa (31,75 LSB en ci8, 8191,75 en ci16) o 2 LSB en 2 bits. La escala y el recuento de elementos recortados se imprimen y se escriben en el archivo auxiliar. La salida en coma flotante no cambia.

• Ocho fijaciones de archivos de prueba en siete archivos de test ya no fallan en macOS por diferencias en el último bit (parte de la incidencia #36). Las fijaciones que comprueban que el motor sigue construyendo las entradas confirmadas de una referencia independiente (jacobianos, una tabla de estados, acimuts de lanzamiento) se comparaban bit a bit y fallaban en macOS arm64 por entre 2 y unos pocos miles de unidades en el último lugar. Ahora comparan dentro de 1e-12 de una escala tomada del archivo de prueba; los enteros, las claves y las longitudes se siguen comparando exactamente, y una prueba de mutación muestra que un cambio relativo de 1e-6 sigue fallando. La fijación del acimut de lanzamiento compara sin az y la rama ascendente/descendente en lugar del propio acimut, porque asin amplifica un ulp de su argumento hasta unos 3e-9 rad cuando una inclinación es igual a la colatitud de un emplazamiento. No cambió ninguna tolerancia de referencia independiente ni umbral preregistrado. Dos pruebas (OD conjunta lunar, observabilidad lunar) no están cubiertas: en macOS se mueven las propias comparaciones preregistradas, y eso se deja para un seguimiento posterior.

• kshana iq track y kshana iq sweep aplican las opciones del front-end. El texto de uso anunciaba --bandpass/--notch/--blank/--excise/--agc/--bits en track, pero track y sweep nunca construían la cadena: las opciones se ignoraban en silencio, y una sin valor, como --notch, se tragaba la opción siguiente. Ahora ambos comandos las analizan como lo hace iq acquire y colocan una cadena de front-end nueva delante de la pasada de adquisición y de la de seguimiento. La salida es igual a ejecutar el comando sobre el archivo que escribe iq frontend con las mismas opciones.

• Los datos de la escena IQ se colocan por señal. kshana iq scene --data (y NavData::Seeded) ponían bits de 50 bit/s en cada señal, pilotos incluidos, y a la tasa LNAV de GPS en Galileo y BeiDou. Ahora los datos siguen la temporización de símbolo propia de cada señal, indicada por el nuevo SpreadingCode::data_modulation() (DataModulation, fijado por cada constructor de iq::signals). Eso son 10 ms en L5-I5, 4 ms en E1-B, 2 ms en BeiDou B1I GEO (D2), y bits de 20 ms con un meandro de 10 ms en GLONASS L1OF. Se rechazan los datos en pilotos, en GPS L2C como un único flujo CM/CL, y NavData::Lnav en cualquier señal que no sea L1 C/A. Los códigos personalizados conservan por defecto la temporización anterior de 20 ms. Una Scene programática que pedía NavData::Lnav en un código distinto de L1 C/A, o NavData::Seeded en un piloto, generaba en silencio y ahora devuelve un error en la primera lectura.

• Los canales GLONASS L1OF se adquieren y se siguen en su propia portadora FDMA. iq::acq::acquire y los canales de seguimiento llevaban todos los códigos a banda base usando solo if_hz. En una grabación GLONASS de varios canales, una búsqueda del canal +3 encontraba por tanto la señal del canal 0 (todos los canales comparten un código de medición de distancia) y nunca buscaba 1,6875 MHz más arriba. Ahora ambos usan SampleSpec::baseband_hz(carrier) = if_hz + (carrier − center_hz). El término de portadora es cero para cualquier grabación centrada en la propia portadora de la señal y se omite cuando se desconoce el centro, de modo que el procesamiento CDMA no cambia. Si evitaba el comportamiento anterior incorporando carrier − center al if_hz del archivo auxiliar, elimine ese término: el desfase ahora se aplica a partir de la portadora y el centro, de modo que dejarlo lo aplica dos veces. Limitación conocida, sin cambios aquí: una escena GLONASS identifica cada satélite por su canal de frecuencia k, y el identificador de satélite u32 envuelve un canal negativo. El archivo auxiliar de verdad de referencia escribe k = -7 como sat_id 4294967289 (k + 2^32). Léalo de nuevo como k con una conversión a i32.

[0.32.0] - 2026-10-05#

Añadido#

• Capa IQ de GNSS en la CLI y en Python (0.32.0 Fase A). El módulo iq existente ya es utilizable sin escribir Rust. Cinco comandos kshana iq nuevos se unen al grupo de manejo de datos: scene genera a un archivo una escena IQ larga de varios satélites con un archivo auxiliar de verdad de referencia; acquire ejecuta la adquisición por FFT de uno o más PRN sobre una grabación e informa de cada detección (PRN, Doppler, fase de código, estadístico, umbral); track adquiere y luego ejecuta el banco DLL/PLL/FLL sobre una grabación y emite una salida de seguimiento por época (CSV/JSON) con anchos de banda de lazo, tiempo de integración y espaciado de correladores configurables; sweep reproduce una grabación a través de varios diseños de lazo e informa de la fluctuación y de las métricas de enganche resultantes por diseño; y labfit ajusta el modelo de pérdida de enganche del lazo de seguimiento a una línea temporal de confianza del receptor. El mismo núcleo se expone a Python (kshana.iq_scene, iq_acquire, iq_track, iq_labfit, iq_signals), que devuelve listas y diccionarios aptos para NumPy. Solo software y aditivo: sin dependencias nuevas, sin transmisión, sin síntesis de formas de onda de interferencia ni de spoofing; el motor, la adquisición, el seguimiento y los diseños de lazo son los propios del crate, de modo que quien llama desde la CLI o Python obtiene los mismos bits que las pruebas de Rust. Nuevo módulo iq::cli; el propio archivo auxiliar de verdad de referencia de la escena es la referencia independiente en tests/iq_cli.rs (la adquisición recupera cada fase de código y Doppler inyectados, el seguimiento converge al Doppler inyectado). No cambia ningún recuento publicado de tipos de escenario ni ninguna fila de la matriz de verificación.
• Capacidades restantes de la biblioteca IQ de GNSS en la CLI iq y en Python (0.32.0 Fase A.2). Se apoya en la Fase A y expone el resto de la capa iq sin escribir Rust:
  • Canal de propagación en iq scene (y en iq_scene de Python): una ionosfera de primer orden (--iono-stec/--iono-vtec o --iono-klobuchar), la troposfera de Saastamoinen/Niell (--tropo), el modelo de centelleo de Cornell (--s4, --scint-tau0, --sigma-phi), multitrayecto especular con el suelo (--multipath-height/--multipath-ground), el canal móvil terrestre de tres estados (--land-mobile) y un bloqueo sin visibilidad directa (--nlos) se aplican a cada satélite mediante un nuevo puente interno del crate (iq::channel::SceneChannelAdapter) que convierte las trayectorias absolutas de los modelos de canal a la forma de exceso sobre la geometría de la escena.
  • Salida SigMF en iq scene (--format sigmf): escribe las muestras como un par .sigmf-data/.sigmf-meta con una captura y anotaciones por satélite; acquire/track ya leen SigMF, de modo que una escena hace el viaje de ida y vuelta.
  • DSP de front-end: un nuevo comando iq frontend <in> <out> y las mismas opciones en acquire/track (--bandpass, --notch, --blank, --excise, --agc, --bits 1/2/3/8/14) ejecutan las etapas de iq::frontend (FIR paso de banda, filtro de muesca adaptativo, supresión de pulsos, excisión en el dominio de la frecuencia, AGC, cuantificador); reflejado en Python como iq_frontend.
  • Escenas de efemérides de difusión: iq scene --nav <rinex_nav> --rx-pos lat,lon,alt (con --start/--window/--prn) coloca cada satélite GPS sano en su geometría de difusión real usando el lector RINEX del motor, de modo que el archivo auxiliar de verdad de referencia lleva la distancia, el Doppler y la fase de código reales por satélite; reflejado en Python como iq_scene_broadcast. Solo software y aditivo: sin dependencias nuevas, sin transmisión, sin síntesis de formas de onda de interferencia ni de spoofing (los efectos de propagación del canal actúan solo sobre la señal legítima). Cada afirmación numérica se prueba frente a una referencia independiente (forma cerrada o verdad de referencia inyectada) en las pruebas unitarias de canal y de front-end y en tests/iq_cli.rs.

[0.31.0] - 2026-10-04#

Añadido#

• Capa IQ de GNSS: simulación a nivel de señal y procesamiento de receptor por software. Un nuevo módulo iq lleva a Kshana desde un front-end L1 C/A de un solo satélite y de bloques cortos a una capa completa a nivel de señal, accesible desde el grupo de comandos kshana iq. Genera escenas IQ en bruto largas y de varios satélites con un archivo auxiliar de verdad de referencia por época (iq::scene); aplica la propagación a nivel de señal: ionosfera con divergencia código-portadora, troposfera, centelleo de amplitud y de fase (modelo de Cornell), multitrayecto de Fresnel y un canal móvil terrestre de tres estados, con visibilidad directa bloqueada (iq::channel); adquiere y sigue con adquisición por FFT y un banco DLL/PLL/FLL de varios canales, reproduciendo una grabación a través de muchos diseños de lazo (iq::acq, iq::track); modela el front-end: filtrado FIR/IIR, cuantificación de 1 a 14 bits, AGC, filtro de muesca, supresión de pulsos y excisión en el dominio de la frecuencia (iq::frontend); procesa en flujo grandes conjuntos de datos grabados con memoria acotada: formatos int8/int16/float32/2 bits empaquetados e IF real, SigMF de varios archivos, remuestreo, un inventario de conjuntos de datos con SHA-256 por archivo y un ejecutor por lotes (iq::io); añade códigos de ensanchamiento para GPS L5/L2C, Galileo E1 (CBOC, códigos de memoria reales del ICD) y E5a, BeiDou B1C/B1I y GLONASS L1OF, cada uno comprobado frente a su documento de control de interfaz (iq::signals); y ajusta el modelo de pérdida de enganche del lazo de seguimiento al comportamiento observado de un receptor real en ejecuciones de laboratorio, con error de conjunto reservado dejando una ejecución fuera y extrapolación etiquetada como predicción (iq::labfit). Cada afirmación numérica se prueba frente a una referencia independiente (una tabla del ICD, una forma cerrada o un receptor independiente que recupera la verdad de referencia inyectada); los modelos físicos de canal y de lazo siguen siendo MODELLED. Es solo una capa de software: escribe archivos IQ para receptores por software y no sintetiza formas de onda de interferencia ni de spoofing ni controla hardware de radio. No cambia ningún recuento publicado de tipos de escenario ni ninguna fila de la matriz de verificación. Diseño: docs/design/GNSS-IQ-PLAN.md.
• Confianza del receptor: evaluar un registro real de un receptor GNSS. kshana receiver-trust <scenario.toml> lee un registro u-blox UBX, RINEX 3 (con un archivo de navegación de difusión opcional), Android GnssLogger o NMEA 0183 en una única línea temporal con marcas de tiempo y ejecuta sobre ella monitores de confianza: caída de la densidad de portadora a ruido (C/N0), pérdida de enganche, control automático de ganancia (AGC), el indicador de jamming de u-blox, salto de posición y, con RINEX y navegación, la propia solución de punto único del motor con monitorización autónoma de la integridad del receptor (RAIM) por paridad y el monitor asistido por reloj. Cada época es nominal, degradada o no fiable, y el resultado indica cuándo y por qué. Los eventos y las caídas de C/N0 previstas indicadas en el escenario se puntúan frente a tolerancias indicadas en el mismo archivo: detectado, tardío o no detectado, y coincide o discrepa. Las salidas son el JSON de resultados, un CSV por época y un gráfico; el resultado lleva el SHA-256 del registro y cada umbral. También es accesible desde Python (kshana.receiver_trust), el paquete WebAssembly (receiver_trust, registros en línea) y la nueva herramienta assess_receiver_log del servidor del Model Context Protocol (MCP). Guía: docs/RECEIVER-TRUST.md; ejemplo: examples/receiver-trust/. En los registros de spoofing de JammerTest 2024, la vía del motor reproduce la primera alarma de la canalización preregistrada de referencia independiente en cada inicio publicado (tests/receiver_trust_jammertest.rs). Los monitores siguen siendo MODELLED; no cambia ninguna fila de la matriz de verificación.

0.30.0 - 2026-10-03#

Una versión menor. Las rondas de validación 2 y los paquetes de wave-1 llevan la matriz de verificación de 223 filas (93 VALIDATED) en 0.29.3 a 249 filas (123 VALIDATED, 122 MODELLED, 4 PARTNER); cada promoción se comprobó frente a una referencia independiente con una tolerancia fijada antes de la ejecución, y cada discrepancia se publica como un hallazgo. Novedades: un lector nativo de kernels NAIF y una vía DE440, una propagación y vía de tiempo validadas de SGP4 a ITRS, una biblioteca de relojes medidos, un generador de referencia LunaNet AFS, solucionadores de precisión extendida y de información en raíz cuadrada, y procesamiento IQ lunar real sobre datos de LuGRE. Las cifras publicadas que se movieron figuran a continuación como revisiones.

Veintisiete filas de la matriz de verificación pasan a VALIDATED después de que una referencia independiente coincidiera dentro de una tolerancia fijada antes de la primera comparación (la regla de promoción de docs/VALIDATION.md): diez en una primera ronda de validación y diecisiete en una segunda. Cincuenta y una filas MODELLED se sometieron a una referencia independiente externa en la primera ronda y las demás filas encaminables en la segunda; cada discrepancia se registra a continuación como hallazgo en lugar de ajustarse para que desaparezca. Tres filas se dividieron para que una parte validada no cargue con un resto sin validar, lo que lleva la matriz de 223 a 226 filas; los paquetes de validación incorporados desde entonces la llevan a 249. Los recuentos se leen del docs/VERIFICATION-MATRIX.md generado.

Abreviaturas usadas en esta entrada

Abreviatura	Significado
ADD, ARAIM, MAAST	Airborne Design Document (de ARAIM); monitorización autónoma avanzada de la integridad del receptor; la herramienta de simulación de disponibilidad de algoritmos en Matlab de la Universidad de Stanford
ADEV, VRW, ARW	desviación de Allan; paseo aleatorio de velocidad; paseo aleatorio de ángulo
ANISE, SPICE, NAIF, PCK	un kit de herramientas de astrodinámica de código abierto (Nyx Space); el kit de herramientas Spacecraft, Planet, Instrument, C-matrix, Events de la NASA, de su Navigation and Ancillary Information Facility; kernel de constantes planetarias
BCRS, TDB, TT	Sistema de Referencia Celeste Baricéntrico; Tiempo Dinámico Baricéntrico; Tiempo Terrestre
BIPM, UTC(k)	Oficina Internacional de Pesas y Medidas; la realización por un laboratorio del Tiempo Universal Coordinado
CCSDS, OEM, LTC, TCL	Consultative Committee for Space Data Systems; Orbit Ephemeris Message; sistemas de tiempo lunar escritos en el campo TIME_SYSTEM del mensaje
CRLB	cota inferior de Cramér–Rao
CW	movimiento relativo de Clohessy–Wiltshire
DE440	Development Ephemeris 440 del Jet Propulsion Laboratory
DOP, PDOP	dilución de la precisión; dilución de la precisión de posición
EKF, UKF, INS, GNSS, IMU	filtro de Kalman extendido; filtro de Kalman unscented (UKF); sistema de navegación inercial; sistema global de navegación por satélite; unidad de medida inercial
EMT, VPL, HPL	umbral efectivo del monitor; nivel de protección vertical y horizontal
EOP, IERS, PCC, MAE	parámetros de orientación de la Tierra; Servicio Internacional de Rotación de la Tierra y Sistemas de Referencia; Prediction Comparison Campaign; error absoluto medio
ERFA, SOFA	Essential Routines for Fundamental Astronomy; Standards of Fundamental Astronomy
GMAT	General Mission Analysis Tool de la NASA
NTN, SSB	red no terrestre (3GPP); bloque de señal de sincronización
IGS, ILRS, ITRF2020	Servicio Internacional de GNSS; Servicio Internacional de Telemetría Láser; Marco de Referencia Terrestre Internacional 2020
ILS, LAMBDA	mínimos cuadrados enteros; Least-squares AMBiguity Decorrelation Adjustment
ISB	sesgo entre sistemas
LEO	órbita terrestre baja
MHSS, PL, TPL	separación de soluciones con hipótesis múltiples; nivel de protección; nivel de protección de temporización
PSD, IQ, SigMF	densidad espectral de potencia; muestras en fase y en cuadratura; Signal Metadata Format
QPN	ruido de proyección cuántica
RAIM	monitorización autónoma de la integridad del receptor
SBAS, WAAS, DFMC, GEO	sistema de aumentación basado en satélites; el Wide Area Augmentation System de EE. UU.; doble frecuencia y multiconstelación; un satélite SBAS geoestacionario
RMS, SISRE	raíz del valor cuadrático medio; error de distancia de la señal en el espacio
RTKLIB	una biblioteca de posicionamiento GNSS de código abierto
TCXO	oscilador de cristal con compensación de temperatura
VLBI	interferometría de línea de base muy larga

Validado#

Cada fila siguiente indica su tipo de referencia independiente (Library: una biblioteca independiente de terceros que calcula una magnitud definida de forma unívoca; Measured: datos reales medidos; P2: una biblioteca numérica independiente que recalcula una magnitud de álgebra lineal sobre entradas confirmadas), la referencia independiente, la tolerancia fijada antes de la ejecución y el resultado. Cada promoción fue repetida por un segundo revisor, que regeneró el archivo de prueba byte a byte y mostró que una mutación deliberada del motor pone la prueba en rojo.

• Fusión de sensores GNSS/INS (Library), limitada al EKF de estado de error de 15 estados débilmente acoplado: NaveGo v1.4 (LGPL-3.0, ejecutado con GNU Octave) sobre su propio recorrido real con IMU/GNSS Ekinox. El RMS horizontal, vertical y de innovación de posición de Kshana es 0,912, 0,940 y 0,861 del de NaveGo (umbral 1,2) y su innovación media normalizada es 0,395 (umbral 1,5). GNSS está presente durante todo el recorrido, de modo que no se prueba ninguna interrupción. El UKF fuertemente acoplado y el filtro de reloj acoplado quedan fuera de la afirmación.
• Actitud en 3 grados de libertad y presupuesto de error de apuntamiento (Library), limitado al pico del par de gradiente de gravedad: Basilisk 2.9.1 GravityGradientEffector, 40 casos, dentro de 1e-12 en términos relativos (peor caso 2.1e-15). El presupuesto de apuntamiento RSS es una suma de números aportados por quien llama y queda fuera.
• Geometría conjunta lunar de comunicaciones y navegación (Library), limitada a la colocación del emplazamiento, el acimut, la elevación y la distancia: ANISE 0.10.2, 768 muestras, dentro de 1e-6 grados y 1 mm (peor caso 2.2e-12 grados y 5.6e-9 m). El parámetro de precisión de medición de distancia es una entrada de diseño fuera de la afirmación.
• Dinámica de actitud de un cuerpo rígido sin par (Library): el cuerpo central de nave de Basilisk 2.9.1, 1e4 s sobre dos inercias generales, cuaternión y velocidades dentro de 1e-9 (peor caso 3.3e-11 y 3.4e-12 rad/s).
• Resolución de ambigüedad entera de fase de portadora GNSS (LAMBDA) (Library), limitada a la solución ILS y sus dos mejores normas: RTKLIB v2.4.2-p13 lambda(), 300 covarianzas, 0 discrepancias enteras, normas dentro de 1e-9 en términos relativos (peor caso 5.6e-13). La tasa de éxito con bootstrap sigue comprobándose solo internamente.
• PL de temporización compuesto, MHSS escalar (P2): numpy 2.3.5 y scipy 1.18.1 sobre 300 entradas confirmadas, PL dentro de 1e-9 en términos relativos (peor caso 1.2e-10), subconjunto determinante idéntico.
• Blanqueo GLS de modo común e identidad de Mahalanobis (P2): LAPACK de numpy 2.3.5 sobre 201 covarianzas confirmadas, dentro de 1e-12 en términos relativos (peor caso 7.9e-16); números de condición de hasta 19,3.
• Proveedor de orientación de ejes principales lunares de DE440 (Library): SPICE pxform sobre el PCK binario en 2.000 épocas fuera de nodo, dentro de 1.7e-5 rad (peor caso 1.7e-6 rad, unos 3 m en la superficie), tras la corrección indicada en "Corregido".
• Entrada y salida de grabaciones SigMF, y espectros de Welch (Library), limitado a la lectura y escritura de SigMF y a welch_psd: signal.welch de scipy 1.18.1 dentro de 1e-12 en términos relativos por intervalo (peor caso 6.0e-14); grabaciones de sigmf-python 1.13.0 decodificadas de forma idéntica bit a bit; los metadatos del crate válidos frente al esquema SigMF v1.2.6. La síntesis IQ y sus comparaciones de modelos quedan fuera.
• Ajustador de efemérides de difusión LEO y SISRE frente al intervalo de ajuste (Measured), limitado al ajuste kepleriano de 16 parámetros y a su SISRE solo orbital: órbitas precisas ITSG de TU Graz de cuatro satélites frente a las estadísticas de Liu et al. 2025, componentes dentro de 1,5x (0,804 a 1,087) y SISRE dentro de 1,5x (0,716 a 0,809).

Hallazgos#

La referencia independiente discrepó con estas filas, por lo que siguen siendo MODELLED. Cada hallazgo también se escribe en el texto de referencia independiente de la fila (y por tanto en docs/MODELLED-RATIONALE.md), con una prueba que lo fija.

• Estimación del estado del reloj de a bordo: con relojes IGS reservados de 11 satélites GPS Block IIF, el filtro de tres estados es coherente a un paso pero demasiado confiado a una hora en 9 de 11 (los términos periódicos y de flicker no están en el modelo).
• Detección de spoofing: en JammerTest 2024 ningún monitor a nivel de observables dio la alarma en 10 s desde ninguno de los 8 inicios publicados, y tres ventanas previas al inicio presentaron falsas alarmas.
• Nivel de protección de temporización bajo spoofing: el error de tiempo no detectado medido supera el TPL en 3 de 8 inicios detectados (de 1,9x a 5,3x); una calibración de reloj de 60 s no cubre la deriva del TCXO del receptor.
• Geometría de la ventana de lanzamiento y del ascenso: frente a Orekit 12,2 la geometría coincide hasta el redondeo, pero la velocidad del emplazamiento por rotación terrestre no alcanza 1e-6 en términos relativos a 62,9 grados de latitud (1.12e-6, el movimiento polar que omite el modelo esférico). Ronda 2: la velocidad con polo verdadero y época coincide, la velocidad por defecto sin época sigue sin alcanzarlo (véase más abajo).
• Corredor de reentrada balística (Allen–Eggers): la deceleración máxima prevista para la reentrada de Stardust es de 61,8 g frente a los 32,89 g reconstruidos (+88 %, tolerancia 15 %).
• Error conjunto de UT1 y movimiento polar: frente a la fórmula de precisión impresa en 178 números del Boletín A del IERS, el polo coincide dentro de 1,5x pero UT1 no (0,48 a 10 días, 1,59 a 40 días). Reemplazado en la ronda 2: la fila es ahora VALIDATED (véase más abajo).
• Entrada de orientación terrestre por defecto sin conexión: astropy confirma el censo de filas, pero las 12 filas que el crate llama predicciones del Boletín A están marcadas como medidas (I), no como predichas (P). Por tanto, las cifras de concordancia de la fila del predictor operativo se compararon con filas medidas. Reemplazado en la ronda 2: el motor clasifica las filas por indicador y la fila es VALIDATED.
• Error de predicción de orientación terrestre de estilo operativo: el error de UT1 del predictor es de 2,4x a 12,6x el del Boletín A a 1 a 10 días y de 5,32 ms a 10 días, fuera del intervalo de 0,36 a 3,13 ms de la 2.ª EOP PCC.
• VLBI geodésico lunar: frente a los tiempos de luz de ANISE a través de DE440, ningún retardo queda dentro de 1 ps; la mayor diferencia es de 24 µs, sobre todo por el centro lunar analítico (a unos 200 km de DE440). Ronda 2: la vía de kernel es VALIDATED en una fila propia; esta vía analítica sigue siendo MODELLED.
• Exportación de interoperabilidad lunar: Orekit 12,2 rechaza los sistemas de tiempo LTC y TCL, por lo que no está establecido el intercambio de los archivos OEM lunares con un segundo lector.
• Movimiento relativo de Clohessy–Wiltshire: frente al movimiento no lineal de Orekit a 100 m, la diferencia es de 1,2 a 6,3 mm, por encima de 1 mm; escala como el término de segundo orden omitido, de modo que la tolerancia preregistrada quedaba por debajo del error de linealización. Reemplazado en la ronda 2: la corrección de segundo orden es VALIDATED frente al mismo umbral.
• Crecimiento del error de deriva de INS/TRN: frente a un Monte Carlo de inercial libre de NaveGo, las leyes de crecimiento se cumplen dentro del 5 % hasta 600 s y sobrestiman más allá (de 2,2x a 8x a una hora), porque omiten la realimentación de Schuler. Reemplazado en la ronda 2: el modelo de error de Schuler es VALIDATED.
• Volumen de servicio lunar a partir de la geometría real de la constelación: 4 de 12 estadísticas de disponibilidad publicadas difieren en más de 2 puntos porcentuales (hasta 22,5).
• Sobrecota del sesgo de trazabilidad heterogéneo de UTC(k): en 105.024 filas del BIPM, la sobrecota se supera en el 50,8 % de las filas; la incertidumbre publicada acota la medición del desfase por el BIPM, no el desfase.
• Clasificación del espacio nulo del datum lunar: en la geometría publicada de cinco reflectores, la correlación es -0.78 frente a -0.97, y la CRLB del origen es un 96 a 98 % inferior a la del artículo.
• Sustrato de geometría del datum LLR lunar: frente a 192 puntos normales lunares del ILRS de 2024, el RMS del residuo unidireccional fue de 96 m con la interpolación de orientación anterior y es de 22,7 m tras la corrección siguiente, todavía por encima del umbral de 10 m (coordenadas de estación redondeadas, sin movimiento polar). La serie de orientación se satura en silencio fuera de 2024-2025. Ronda 2: el modelo de distancia medida es VALIDATED en una fila propia (2,81 m); la serie ahora cubre 2014-2030 y da error fuera de ese intervalo.
• Acoplamiento relativista de la tasa de reloj al marco: el término de autopotencial supera en 3.18e-4 el valor publicado (tolerancia 1e-4); el artículo evalúa un potencial distinto, por lo que no existe ningún valor publicado de esta forma cerrada. Reemplazado en la ronda 2: el potencial ecuatorial de grado 2 es VALIDATED frente al mismo artículo.
• Constantes físicas de todos los cuerpos del sistema solar: 12 de 84 constantes de los cuerpos añadidos difieren de NAIF pck00011 y gm_de440 (elementos más antiguos de los satélites de Marte; otras soluciones de GM para Urano, Neptuno y Plutón). Ronda 2: las constantes ahora siguen a NAIF (una transcripción, no se cuenta) y la orientación calculada coincide con SPICE; la fila sigue siendo MODELLED.
• Modelos de efemérides LEO seleccionables: el ajuste de 22 parámetros deja 1,71x y 1,86x el error a lo largo de la traza publicado en arcos de 20 min, por encima de 1,5x. Reemplazado en la ronda 2: el modelo de 22 parámetros y su ajuste son VALIDATED en una fila propia.
• Posicionamiento conjunto GNSS y LEO: el sesgo entre sistemas coincide con RTKLIB, pero el 93,2 % de las épocas queda dentro de 3 m de ITRF2020 frente al 95 %; el propio RTKLIB alcanza el 88,2 % con los datos (93,6 % tras la corrección del retardo de grupo de la ronda 2).
• Ceguera de integridad de modo común y mapas de cobertura y DOP: ambas comparaciones se superaron pero se rechazaron en la revisión porque un motor deliberadamente erróneo también las supera (la primera solo comprueba una identidad interna; los suelos publicados de la segunda no pueden detectar un PDOP duplicado). Ronda 2: la ceguera de integridad de modo común es VALIDATED con entradas que llevan paridad; los mapas de cobertura siguen siendo un hallazgo (véase más abajo).

Ronda de validación 2#

La segunda ronda tomó todas las filas que la primera dejó encaminables, con preregistros nuevos confirmados antes de obtener ningún archivo de prueba o ejecutar ninguna referencia independiente, un segundo revisor adversarial que repitió cada comparación y una mutación deliberada del motor que debe poner cada prueba en rojo. El propietario aceptó la redacción corregida de la fila de la cota fuera de Omega el 2026-10-02 antes de su promoción (su texto anterior contradecía el código).

Promovidas a VALIDATED (17). Tipo de referencia independiente entre corchetes; tolerancia fijada antes de la ejecución.

• Acoplamiento relativista de la tasa de reloj al marco (Reference): L_m de Ashby y Patla 2024 dentro de 2.8e-6 (umbral 1e-4) a partir del potencial ecuatorial de grado 2 de los dos campos que cita el artículo; gravedad de grado 350 de pyshtools para la entrada radial (8.3e-5); velocidad lunar de DE441 (2.5e-3).
• Entrada de orientación terrestre por defecto sin conexión (Library): astropy 8.0.1 y el Boletín A del IERS n.º 039 confirman las 30 filas finales, 54 rápidas y 90 predichas del extracto reelaborado.
• Error conjunto de UT1 y movimiento polar (Library): las rotaciones completas de astropy y pyerfa reproducen la tabla conjunta (UT1 y polo dentro de 6e-16, la combinación dentro de 1.9e-7); los errores realizados del IERS Annual Report 2019 dan cocientes de 1,001 a 1,100.
• Huella y cobertura de cargas útiles de observación de la Tierra (Library): Orekit 12,2 y GeographicLib 2,1 en cada umbral preregistrado, con la regresión nodal de J2 ya incluida en el espaciado de nodos.
• Movimiento relativo de Clohessy–Wiltshire (Library): con una corrección de segundo orden en forma cerrada, dentro de 1.2e-7 m del movimiento no lineal de Orekit frente a 1e-3 m; la matriz lineal por sí sola sigue caracterizada (1,2 a 6,3 mm).
• Apuntamiento en el plano B y asistencia gravitatoria de cónicas empalmadas (Library): plano B, asíntotas, C3 y elementos heliocéntricos de GMAT R2026a; sbpy 0.6.0 y Kasuga y Jewitt 2019 para el parámetro de Tisserand.
• Crecimiento del error de deriva de INS/TRN (Library): un modelo de error de Schuler de nueve estados dentro del 5 % de las ejecuciones de deriva de NaveGo corregidas en los 48 puntos (peor caso 3,70 %).
• Ceguera de integridad de modo común (P2): lstsq de numpy sobre 1464 entradas con paridad dentro de 1e-12 (peor caso 1.06e-14).
• OD y reloj multitécnica conjunta lunar (P2): numpy recalcula cada paso de Gauss-Newton, sigma y error de estación en seis redes (dentro de 2.4e-11) tras una corrección de la solución QR.
• Covarianza de coordenadas de estación del VLBI lunar (Library): un jacobiano construido con SPICE reproduce el calendario, el espectro, las sigmas y el espacio nulo dentro del 1 % y 0,1 grados; numpy hasta 2e-13.
• Cota de modo común indetectable con residuo fuera de Omega (P2, redacción corregida por decisión del propietario): LAPACK de numpy en 256 casos dentro de 1e-12, seis infinitos exactos.
• Clasificación del espacio nulo invariante respecto a la base (P2): intersección de subespacios con SciPy y NumPy en 72 matrices construidas, enteros exactos, norma del proyector dentro de 6.0e-15.
• Servicios ionosféricos de frecuencia única y UTC de un mensaje de navegación LEO (Library): GNSSTk 15.3.1 para Klobuchar, Az y la deriva de UTC; ERFA para los tres casos de segundo intercalar.
• Cota de posicionamiento de redes no terrestres 5G (P1): cotas de SSB único de Bachl, Lei y Nabeel 2026 dentro de medio dígito impreso; numpy para las covarianzas de la solución.
• Modelo de distancia medida de LLR (Measured, nueva fila separada del sustrato del datum LLR): 192 puntos normales lunares del ILRS con 2,81 m de RMS frente a un umbral de 10 m, con el tiempo de luz baricéntrico de IERS 2010; los componentes por debajo del umbral no se resuelven uno a uno, y la fila lo indica.
• VLBI geodésico lunar, vía de kernel (Library, nueva fila separada de la fila de VLBI lunar): tiempos de luz convergidos de SPICE dentro de 1 ps y parciales dentro de 1e-6 en épocas cercanas a J2000; la vía analítica por defecto sigue siendo MODELLED.
• Modelo de efemérides LEO de 22 parámetros de Liu et al. 2025 y su ajuste (Measured, nueva fila separada de la fila de modelos seleccionables): órbitas precisas reales dentro de 1,5x de las estadísticas publicadas en los días del artículo y en días reservados (0,683 a 1,186); la convención de escala de n_dot está transcrita y esta comparación no la valida, y la regla de parada es la regla de convergencia de parámetros de Kshana, no la regla de cambio de RMS del artículo. El polinomio ATOMIC y la tabla de cinco altitudes siguen siendo MODELLED.

Filas VALIDATED existentes con nuevo respaldo (sin cambio de recuento).

• Posiciones planetarias a partir de los elementos de Standish del JPL y tiempo de luz entre cuerpos del sistema solar: los umbrales posteriores de dos veces el valor nominal se sustituyen por comparaciones preregistradas con JPL Horizons DE441 (RMS como máximo la cifra de la Tabla 8.10.1 del Explanatory Supplement, peor caso 0,778, con la división de la Tierra y la rotación ICRF incluidas; tiempos de luz dentro de 1e-6 s de Horizons con posiciones DE441, peor caso 6.7e-9 s). Se retiran sus indicadores "límite fijado después de la comparación".
• Integridad (RAIM/ARAIM/SBAS): la fila ya no se apoya en comprobaciones de verosimilitud. Ahora dice: la separación de soluciones con hipótesis múltiples de ARAIM del ADD v4.2 coincide con Stanford MAAST para ARAIM 2 en 270 casos reales (peor diferencia de VPL 2.2e-3 m frente a 0,05 m); la detección y exclusión RAIM instantánea coinciden con raim_fde de RTKLIB en 2016 de 2016 decisiones, con el nivel de protección por pendiente dentro de 2.7e-12 m; los niveles de protección L1 de SBAS DO-229E coinciden con Stanford MAAST en emisiones WAAS reales (2868 pares dentro de 1.6e-5 m). Indica con claridad que las funciones de sigma uniforme raim::araim_raim y raim::araim_dual_raim NO están ajustadas a la norma ADD (diferencias con entradas coincidentes de 0.75/4.04 m y 0.39/1.93 m de VPL/HPL, un hallazgo), que la comparación de SBAS DFMC L5 es un hallazgo (308 pares sin ningún GEO a la vista están protegidos por Kshana y no por MAAST) y que raim::solution_separation_raim no tiene comparación externa. Se retira su indicador propio.
• Ajustador de efemérides de difusión LEO: la órbita verdadera integrada se añade a la parte validada (Orekit 12,2 dentro de 4,55 mm en 6 h, umbral 2 cm); los polinomios de corrección, el ajuste del reloj y el compromiso del periodo de actualización siguen siendo de nivel modelado.

Hallazgos y filas bloqueadas (siguen siendo MODELLED). El texto de referencia independiente de cada fila incluye el hallazgo y su prueba fijada.

• Modulación de señales de navegación (Betz 2001, Hein 2006): los espectros y las correlaciones coinciden; los lóbulos laterales de 24 MHz y todos los sesgos de multitrayecto (11 a 15 % por debajo) no, causa sin resolver.
• Geolocalización TDOA/FDOA: las cotas coinciden con Ho y Chan y Ho y Xu, y con el código de los autores hasta 3e-12; los factores de Ottawa impresos a partir de un Monte Carlo difieren en el 1,3 % y el 4,4 %.
• GNSS terrestre a distancia lunar: las medias en cenit de GENESIS coinciden con Montenbruck et al. 2023 en 5 de 6; las medias en nadir quedan de 1,0 a 2,4 satélites por encima.
• Mapas de cobertura y DOP: los diseños terrestres coinciden con Orekit, gnss_lib_py y numpy en cada umbral; los diseños de la Luna y de Marte superan 1e-9 solo en celdas casi singulares.
• Posicionamiento GNSS conjunto: doble frecuencia 79,9 % y productos precisos 94,2 % dentro de 3 m frente al 95 % (RTKLIB 67,9 % y 94,1 %); la diferencia de ISB con productos precisos se debe a que RTKLIB ignora los desfases de antena.
• Lazos de seguimiento (GNSS-SDR 0.0.19): coinciden entre 35 y 45 dB-Hz; a 30 dB-Hz PLL +21 %, DLL -32 %, umbrales +1,5 dB; tiempos de deslizamiento de 0,5 a 2 décadas más cortos.
• Volumen de servicio lunar (Orekit e Hipparchus): 155 de 160 valores coinciden; el requisito de la peor muestra falla en la geometría casi singular de LNCSS B.
• Sensor inercial cuántico: el suelo solo de QPN es un 21 a 31 % inferior al ruido medido de Gauguet 2009 (umbral 30 %, no alcanzado por 0,5 puntos).
• Preajustes de osciladores: las unidades medidas superan los preajustes de holdover de rubidio, de corto plazo de cesio y de peor unidad de CSAC; el preajuste de OCXO no tiene registro medido.
• Densidad de meteorología espacial: Jacchia 1971 queda dentro de un factor 2 de las densidades de acelerómetro en el máximo solar, pero es aproximadamente 1,7x demasiado densa en el mínimo de 2008.
• TEC oblicuo libre de geometría: 33 de 36 arcos dentro de 3 TECU del mapa CODE (peor caso 6,84).
• Detección de spoofing y TPL frente al registro oficial de JammerTest 2024: 4 de 10 inicios detectados a tiempo; el TPL se supera en 4 de 10.
• Filtro de reloj con relojes IGS nuevos: dos de 11 satélites no superan el criterio de la suma de innovaciones.
• Predictor de EOP de mínimos cuadrados más autorregresivo: UT1 1,73 a 2,11x el del Boletín A a 2 a 10 días.
• Sobrecota del desfase realizado de UTC(k): superación agrupada 0,0333 frente a 1e-2.
• Datum de marco lunar a partir de una campaña: la rama SPICE coincide; la rama P2 con estaciones estimadas no alcanza 1e-9 en un problema de condición 2,1e8.
• Datum de marco lunar a partir de LLR real: 15 de 16 cifras coinciden con SPICE; la sigma de la traslación z es un 1,03 % alta frente a un 1 %.
• Reentrada (Allen-Eggers): la solución de masa puntual coincide con las reconstrucciones de las agencias (solo una verificación cruzada); la comparación con el acelerómetro está bloqueada a la espera de una fuente legible de Hayabusa2.
• Máscaras de la ITU-T: los valores resueltos impresos coinciden; los límites de clase de G.8273.2 no tienen ninguno (bloqueado).
• Geometría de la ventana de lanzamiento: la velocidad del emplazamiento con polo verdadero y época coincide con Orekit (4.9e-8); la velocidad por defecto sin época sigue sin alcanzarlo (1.12e-6). No promovida; seguimiento pendiente.
• Constantes físicas de todos los cuerpos: ahora 0 de 84 difieren de NAIF (una transcripción), y la orientación calculada coincide con SPICE hasta 1.4e-10 rad. No promovida; seguimiento pendiente.
• Bloqueadas por una decisión de alcance del propietario, cada una con su comparación coincidente confirmada: observabilidad absoluta de estaciones lunares, DOP de balizas de superficie, la exportación fuera del eje, la potencia de detección entre modalidades, el estadístico de coherencia de modo común y la cobertura LEO polar.
• Bloqueadas por datos: presupuesto de errores de transferencia de tiempo (requiere una reducción de datos reales), C/N0 de JammerTest (la posición de la antena y el reparto de potencia no están documentados).

Revisiones (cifras publicadas que se movieron, antiguo -> nuevo).

• Los niveles de protección de snapshot_raim ahora están en el nivel local geodésico en lugar del radial: hasta 0,31 m de HPL y 0,14 m de VPL en ABMF (16 grados N); no se movió ningún golden, pero el resumen registrado del tutorial de gnss-sim pasa de HPL medio 22,1 m / VPL 40,0 m a 22,2 m / 39,9 m (docs/tutorials/scenarios/gnss-sim.toml).
• Valores por defecto del acoplamiento lunar de marco de tasa: d_alpha/d_scale 3.139807e-11 -> 3.138801e-11; d_alpha/d_radial 1.807187e-17 -> 1.806185e-17 por metro.
• Ejecución de EOP por defecto sin conexión (realtime-frame-eop, celdas listadas en docs/revisions/M035-default-eop-recut-cell-changes.md): predicted_rows 12 -> 90; suelo del polo 0,06776 -> 0,05550 mas; eop_term_m 14,01601 -> 14,01583; total_m 20,09759 -> 20,09746; total_time_ns 67,03834 -> 67,03790; las filas de la Tabla 2 de tests/golden/realtime-frame-eop.csv; concordancia del predictor operativo 0.256/0.695/1.252/3.885 ms -> 0.133/0.421/0.839/2.786 ms.
• docs/LEO-NAVMSG.md SISRE de liu22 órbita/con reloj: 60 s 0.011/0.046 -> 0.014/0.046 cm; 300 s 0.068/0.139 -> 0.074/0.142 cm; 600 s 0.269/0.299 -> 0.258/0.290 cm.
• Tabla de altitudes de Liu, Kshana (cociente): GRACE-A 5,40 (0,61) -> 4,25 (0,48); GRACE-C 4,12 (0,66) -> 2,87 (0,46); Sentinel-2A 2,95 (1,03) -> 2,20 (0,77); HY-2A 2,38 (1,13) -> 1,25 (0,59); Sentinel-6A 0,70 (0,94) -> 0,51 (0,67).
• Escala de nDot del mensaje de navegación LEO 2^-60 -> 2^-58 (no preregistrada, comunicada; fuera de la comparación del ajuste); el CRC de la trama de muestra de liu22 0x62373A -> 0xDED99C.
• Tabla de verificación de docs/LEO-NAVMSG.md: la fila de Liu y ATOMIC se divide en una fila VALIDATED de 22 parámetros y una fila MODELLED de ATOMIC y cinco altitudes.
• Texto de la fila de orientación de ejes principales lunares de DE440: intervalo 2024-2025 / 731 filas -> 2014-2030 / 6.209 filas; "se satura en silencio" -> da error fuera de su intervalo.
• Escenario eo-coverage: equatorial_ground_track_spacing_km 2756,37 -> 2752,17 km; nuevos campos inclination_deg (98,19) y nodal_period_min (98,893).
• constellation-multi-gnss-coverage (el reloj de referencia de TDOP/GDOP es ahora la constelación de menor número a la vista): GDOP global máx. 2,2236 -> 2,1205, media 1,122 -> 1,131, mediana 1,115 -> 1,125, p90 1,255 -> 1,265, p95 1,305 -> 1,315, p99 1,41 -> 1,42, y el mapa de GDOP por celda; mean_visible_by_constellation sumado como enteros (alrededor de 1e-12 en términos relativos, invisible con 4 decimales).
• Solución GNSS conjunta de frecuencia única tras la corrección del retardo de grupo de difusión: 93,2 % -> 93,6 % dentro de 3 m; mediana de ISB -0.351 -> -0.114 ns.
• tracking-loop jitter_table log10_mean_time_to_cycle_slip_s (SNR rho/4 del lazo de Costas): en el umbral de 25,47 dB-Hz 11,58 -> 2,10; a 25 dB-Hz 9,55 -> 1,60; a 22 dB-Hz 2,24 -> -0.14.
• ins-trn-coast: todas las salidas se mueven con el modelo de error de Schuler; el pico de TRN del escenario distribuido 52,932679 -> 44,711834 m (tests/conflict_resilience_architecture_guard.rs).
• Informe de lunar-vlbi: nueva clave geometry_path ("analytic" en la ejecución por defecto, ningún valor numérico cambió); nuevos campos opcionales planetary_kernel_path, earth_orientation_kernel_path y moon_orientation_kernel_path, con epoch_partials en la vía de kernel; se reescribe la descripción del tipo de escenario. La referencia independiente de la vía de kernel de la fila de verificación es SPICE (0,06 ps); ANISE (0,12 ps) pasa a ser una verificación cruzada de evaluación de kernel.
• Constantes de cuerpos: GM de Fobos 7.087e5 -> 7.087546066894452e5; Deimos 9.62e4 -> 9.615569648120313e4; Urano 5.7939506103e15 -> 5.793951256527211e15; Neptuno 6.83509997e15 -> 6.835103145462294e15; Plutón 8.69326e11 -> 8.696138177608748e11 (m^3/s^2); radio ecuatorial de Fobos 13,1 -> 13,0 km; polo y meridiano origen de Fobos y Deimos de pck00011; el prime_meridian_deg del sistema solar ahora incluye los términos cuadráticos y periódicos.
• europa-surface-pnt (body-pnt en Europa), a partir de la orientación completa de Europa de pck00011 (7cfd66b4; la orientación coincide con pxform de SPICE hasta 1.4e-10 rad), que mueve el módulo de aterrizaje en el espacio inercial: disponibilidad solo con relés / con el alcance a la Tierra 0,485 / 0,725 -> 0,480 / 0,719 (83 -> 82 de 171 épocas solo con relés), PDOP mediano 5,266 -> 5,360, error de posición RMS 129,516 / 100,983 m -> 112,742 / 86,147 m, sigma formal mediana 5,266 / 4,272 m -> 5,360 / 4,239 m. La tabla de docs/SOLAR-SYSTEM.md y la fijación de mcp/kshana-mcp/tests/round_trip.rs las siguen; mars-orbit-pnt no cambia.
• space-weather (f107 180, f107a 165, kp 4), con el factor calibrado sustituido por Jacchia 1971: activity_density_kg_m3 a 300/400/500/600/800 km 2.602e-11 -> 3.608e-11, 4.176e-12 -> 6.929e-12, 8.136e-13 -> 1.618e-12, 1.769e-13 -> 4.189e-13, 1.544e-14 -> 3.781e-14; activity_factor 1.076/1.121/1.168/1.216/1.320 -> 1.492/1.860/2.322/2.881/3.232; reference_exospheric_temperature_k retirado, mean_exospheric_temperature_k añadido (1186,7 K); tests/space_weather_reference.rs: la oscilación del ciclo solar a 800 km es ahora 10,4x (NRLMSISE-00 13,6x) y la aserción de altitud sigue el aumento de NRLMSISE hasta 500 km y su descenso a 800 km.
• ntn-5g-positioning toa_median_sigma_3d_m: NR 5 MHz 2,0903959 -> 2,0903962 m; NB 200 kHz 25,938613 -> 25,938839 m (el texto del resumen no cambia, en 2,09 / 25,94 m).
• lunar-joint-od-clock (solución QR): with_vlbi.station_pos_err_m 3,541344 -> 3,541350 m; without_vlbi.station_pos_err_m 2183,119 -> 2183,558 m.
• docs/field-units-schema.json se vuelve a emitir para los campos nuevos y eliminados indicados arriba.

Paquetes de validación#

D12, precisión extendida y un solucionador de raíz cuadrada (dos filas VALIDATED nuevas: 226 -> 228 filas, 110 -> 112 validadas).

Parte 1, referencia independiente de precisión extendida:

• Datum de marco lunar con las estaciones estimadas: una referencia independiente de precisión extendida de 50 dígitos con mpmath (preregistrada 804662d5, umbrales escalados por condición a partir de una fórmula de error hacia atrás a priori) coincide en una nueva fecha de campaña (2026-03-18) y en el escenario original de 2024-01-01; nueva fila VALIDATED bajo P2. Resuelve la disputa anterior de doble precisión: las sigmas del datum del motor se desvían hasta 9.7e-6, las rutas de inversa y de autovalores de NumPy hasta 6.2e-6, y sus rutas de Cholesky y QR en torno a 1e-8. El motor está dentro de su cota de error pero es unas mil veces menos preciso que una ruta de factorización.
• Entorno de la referencia independiente: se añade mpmath 1.3.0.
• Revisiones: ninguna. No cambia ningún archivo golden ni cifra publicada; la fila "Datum de marco lunar a partir de una campaña de observación" sigue siendo MODELLED (decisión del fundador 2026-10-02, opción A: no toma prestado el estado de la fila independiente); el texto de sus pruebas cita la nueva prueba y su hallazgo.

Parte 2, solucionador de datum de información en raíz cuadrada:

• Nuevo solucionador de información en raíz cuadrada opcional (linalg_sr; solver = "srif" en el escenario lunar-frame-campaign): QR de Householder, marginalización a través del factor triangular, una SVD de Jacobi para el espectro y productos compensados solo a partir de operaciones correctamente redondeadas. Frente a la referencia independiente de 50 dígitos (preregistrada b41908c9), sus sigmas de datum coinciden hasta 3e-13 en una fecha nueva (2026-06-09); en las entradas de 2026-03-18 y de 2024-01-01, el solucionador por defecto se desvía hasta 1e-5. Nueva fila VALIDATED bajo P2. El solucionador por defecto y su salida no cambian. Los umbrales preregistrados solo acreditan errores superiores a unos 2e-7 en términos relativos: rechazan el solucionador por defecto pero no un signo de Householder invertido, un producto escalar sin compensar ni una inversa final espectral, y la fila lo indica.
• Vías opcionales de raíz cuadrada junto a los valores por defecto sin cambios: fim::crlb_srif, batch_ls::gauss_newton_srif, orbit_determination::determine_orbit_batch_srif, lunar_combination::formal_covariance_srif, precise_od::fit_srif y cislunar_srif::srif_cross_validation_sqrt, sobre los nuevos linalg_sr::weighted_lstsq y covariance_from_sqrt_information. Cada una coincide con su valor por defecto allí donde ambos son precisos (una comprobación interna, sin fila; no se afirma validación alguna para ellas). precise_od::fit ahora delega en una rutina compartida; su salida y la salida por defecto de todos los escenarios no cambian.
• Decisiones de rango de la campaña de marco lunar: una comprobación preregistrada de precisión extendida sobre 40 días confirma cada decisión decidible de bloque de estaciones y de Helmert de rango completo. La cota a priori no puede acreditar los 20 días de Helmert con rango deficiente; en aritmética exacta su defecto es geométrico, con el umbral de 1e-9 dentro del intervalo natural de cocientes de autovalores de la campaña. Sin fila.
• La afirmación de la fila de la campaña de precisión extendida se limita a "dentro de la cota del peor caso", y su comprobación de la dirección más débil con estaciones fijas ahora mide un ángulo real (6.6e-16 rad; el comparador cambió de acos a una cuerda, el umbral no).
• Revisiones: ninguna. No cambia ningún archivo golden ni cifra publicada; la fila "Datum de marco lunar a partir de una campaña de observación" no cambia y sigue siendo MODELLED (decisión del fundador 2026-10-02, opción A).

D4, columna vertebral de efemérides de kernel del JPL, fase 1 (cuatro filas VALIDATED nuevas: 228 -> 232 filas, 112 -> 116 validadas).

• El lector de kernels NAIF tiene su propia fila. naif_kernel (contenedor DAF, SPK tipo 2, PCK binario tipo 2) coincide con el SPICE Toolkit (CSPICE N0067 a través de spiceypy 8.2.0) y con ANISE 0.10.6 en los 600 estados de DE440 y las 200 rotaciones de orientación lunar de una malla aleatoria obtenida del propio hash del commit de preregistro (abcd9133), dentro de umbrales derivados de antemano de la evaluación de Chebyshev en doble precisión (peor caso 0,6 % del umbral, 1.95e-3 m). La fila afirma que el motor lee correctamente los kernels del JPL, no que DE440 o la serie analítica sean exactas (tests/naif_reader_spice_oracle.rs).
• ephem_provider::KernelEphemeris: posiciones de DE440 (o de cualquier SPK de tipo 2) a través del propio lector del motor, con épocas TDB en dos partes y el SHA-256 del kernel conservado para los informes; nunca sustituye un baricentro de sistema por un planeta. LunisolarSource permite que una vía de geometría elija la serie analítica (por defecto) o un kernel.
• Luna de kernel opcional para lunar-llr-datum y lunar-vlbi-fim: una clave planetary_kernel_path lee del kernel el centro geocéntrico de la Luna; no cambia nada más, y el informe incorpora un bloque moon_ephemeris que nombra el kernel y su SHA-256. Sin la clave, ambos informes son idénticos byte a byte a los anteriores.
• Covarianza de un punto de la superficie lunar en la vía de kernel (nueva fila VALIDATED): con todas las estaciones fijas y la baliza en la Luna de DE440, la covarianza de la baliza coincide con un jacobiano de tiempo de luz de SPICE (peor caso 1.7e-3 frente a un umbral del 1 %) y con una inversa de NumPy (4e-14 frente a 1e-9), preregistrada 4a51256 (tests/lunar_vlbi_surface_point_spice_oracle.rs). La fila de la vía analítica sigue siendo MODELLED: con la Luna analítica su menor sigma de baliza es un 3,9 % inferior a la de la referencia independiente.
• Datum de marco lunar a partir de una campaña real, centro lunar de kernel (nueva fila VALIDATED): con 447 puntos normales de 2019-T2 no vistos, preregistrada 830d945a antes de obtener ninguno, la covarianza del datum en la vía de kernel coincide con la referencia independiente SPICE y NumPy sin cambios dentro de 7.6e-5 frente a umbrales del 1 % y del 2 % (tests/validate_llr_datum_kernel_moon_fresh.rs). El fundador decidió que esta fila solo se promueve con puntos nuevos; el diagnóstico con datos ya vistos (c51f8b2) es un hallazgo, no una evidencia. El umbral no discrimina entre modelos de la Luna: la Luna analítica también lo supera en el mismo tramo (peor caso 3.8e-3), la mutación prevista (la Luna de kernel con una hora de retraso) no se detectó, y en el pliegue un centro lunar erróneo en unos 4.650 km (la Luna tomada respecto al baricentro Tierra-Luna) también lo superó. La fila afirma la covarianza en esa vía, no el centro lunar, y así lo indica.
• Posiciones del Sol, la Luna, Mercurio y Venus a partir de DE440 en épocas UTC (nueva fila VALIDATED): KernelEphemeris::relative_position_utc coincide con Skyfield 1,54 en 600 posiciones entre 1973 y 2026, peor caso 2,96 m, dentro de un umbral preregistrado (0bfafe6d) fijado por la serie de dos términos TDB − TT (tests/kernel_ephemeris_skyfield_oracle.rs). Las posiciones planetarias obtienen ahora esta nueva fila de kernel; la fila de Standish y la de las lunas planetarias no cambian, y las lunas esperan a un escenario que las necesite (decisión del fundador).
• Hallazgos: el único fallo de la comparación del datum LLR (sigma de la traslación z 1,025 % frente a 1 %) baja a 0,049 % cuando solo se lee de DE440 el centro lunar, con datos ya vistos (tests/validate_llr_datum_kernel_moon.rs); en el tramo nuevo de 2019 la Luna analítica también lo supera, de modo que el fallo de 2015 era marginal respecto a la geometría de ese trimestre. Las filas analíticas "Datum de marco lunar a partir de una campaña de observación REAL" y "Covarianza de coordenadas de un punto de la superficie lunar … distinta de la de una estación terrestre" siguen siendo MODELLED; sus textos de referencia independiente ahora remiten a las filas de la vía de kernel.
• lunar_ephemeris ya no dice que el motor carece de lector de kernels binarios; remite a la fila del lector y explica por qué los kernels de naves (tipos 13 y 21) siguen obteniéndose de Horizons.
• Revisiones: ninguna. No cambia ningún archivo golden, cifra publicada ni valor de prueba existente; los informes analíticos de lunar-llr-datum, lunar-vlbi-fim y lunar-vlbi-fim con todas las estaciones fijas son idénticos byte a byte a los anteriores (prefijos SHA-256 del resultado 9927aac2, cf1d2671, 25c357e4).

D9, biblioteca de relojes medidos "Clock Atlas" (tres filas nuevas, una VALIDATED: 232 -> 235 filas, 116 -> 117 validadas).

• Biblioteca de relojes medidos (clock_library). Fichas de dispositivo (ruido blanco de fase, modulación de frecuencia blanca, flicker y de paseo aleatorio, una deriva lineal de frecuencia y, opcionalmente, términos de fase de una a cuatro veces por revolución) ajustadas a un registro de reloj medido con nombre y puntuadas sobre datos reservados; varianzas de Allan y de Hadamard conscientes de los huecos; un detector de acondicionamiento que registra cada hueco, valor atípico de fase, salto de fase, ráfaga y salto de frecuencia y que no sabe nada de los límites de archivo o de día; conversión de una ficha al modelo de ruido de temporización de ranura, al modelo de reloj de Kalman extendido y a los niveles de ruido del monitor de spoofing. Lectores de archivos de reloj RINEX e IGS, de archivos por laboratorio del BIPM y de la Sección 1 de la Circular T (realdata::clk); una cota de envejecimiento jerárquica y agrupada para UTC(k) (utck_bound, todavía sin puntuar).
• Identificación de ruido por autocorrelación de retardo 1 (allan::lag1_noise_id, Riley y Greenhall 2004), nueva fila VALIDATED (Library): coincide con autocorr_noise_id de allantools 2024,6 en 140 casos, enteros idénticos, peor diferencia 9.6e-13 frente a un umbral de 1e-9 (preregistrada 2ec76864; tests/clock_library_lag1_noise_id_allantools.rs).
• Fichas de dispositivo medidas con predicción sobre datos reservados, nueva fila MODELLED (un hallazgo): ajuste con un tercio, predicción de la desviación de Allan de los otros dos tercios dentro de un factor de 1,5 (preregistrada 2ec76864). GPS Block IIF en una ventana IGS nueva (de 2026-03-01 a 14): 10 de 11; G27 es optimista a la escala de dos horas (peor factor 1,510). Se informa del cesio (dentro, 1,070), del OCXO (fuera, 2,348) y del estroncio (dentro), no a ciegas. La ficha del receptor de JammerTest y las fichas del máser de Galileo y del Deep Space Atomic Clock están bloqueadas. Una clase de modelo de TCXO de receptor ZED-F9P en 12 estaciones estáticas de Wroclaw (Zenodo 6488497) falla: 1 de 11 estaciones a ciegas en una nueva ejecución corregida comunicada (tests/clock_library_device_cards_oracle.rs, tests/clock_library_f9p_cards_oracle.rs).
• Fichas de GPS Block IIF con términos por revolución, nueva fila MODELLED (un hallazgo): en una segunda ventana nueva (de 2026-04-01 a 14) 9 de 11 quedan dentro del umbral; G03 (1,947) y G25 (1,581) son optimistas porque sus registros reservados son más ruidosos que sus tercios de ajuste; al eliminar los términos periódicos fallan los 11 (preregistrada fb475550; tests/clock_library_periodic_cards_oracle.rs).
• M002, estimación del estado del reloj de a bordo, ronda 3 (un hallazgo, sigue siendo MODELLED): tras el detector de acondicionamiento congelado, el filtro ampliado de la ronda 2, con ajuste y criterios sin cambios, satisface (a) y (c) en los 11 satélites por primera vez; (b) falla en G09 (0,894) y G26 (0,876) (preregistrada fb475550; tests/clock_state_ext_igs_conditioned_oracle.rs).
• M010, detección de spoofing, rondas 3 a 4b (sigue siendo MODELLED): la ronda 3 quedó bloqueada (167 épocas de entrenamiento de las otras sesiones de la unidad de JammerTest frente a 3600); con una ficha de clase de modelo ZED-F9P (rondas 4 y 4b) el monitor de reloj produce cero falsas alarmas previas al inicio en los 10 inicios registrados (ronda 2: 86) y 6 de 10 inicios se detectan en 10 s (ronda 2: 4); los mismos cuatro siguen siendo tardíos (tests/clock_library_tcxo_card_jammertest_oracle.rs).
• M083, sobrecota de UTC(k), ronda 3: preregistrada de forma prospectiva (fb475550) sobre números de la Circular T a partir de 465, todavía no ejecutada (tests/utck_bound_prospective_oracle.rs).
• Entorno de la referencia independiente: el registro ZED-F9P de Wroclaw está sujeto a datos bajo $KSHANA_ORACLES/data/wroclaw_f9p (CC BY 4,0, unos 1,5 GB); los archivos de prueba de relojes IGS están incorporados (productos IGS, con atribución).
• Revisiones: ninguna. No cambia ningún archivo golden, cifra publicada ni valor de prueba existente; no se actúa sobre M001 (reanclaje de holdover) porque no se promovió ninguna clase de reloj.

D8, una vía validada de propagación, marco y tiempo (tres filas VALIDATED nuevas y M131 promovida: 235 -> 238 filas, validadas 117 -> 121).

Los tipos de escenario de órbita terrestre que llevaban sus propios modelos de dos cuerpos, de J2 secular o solo de tiempo sidéreo ahora comparten una única vía: conjuntos de elementos SGP4/SDP4 con fechas julianas en dos partes, llevados al GCRS y al ITRS (International Terrestrial Reference System) mediante la cadena IAU (International Astronomical Union) 2006/2000A, con parámetros de orientación de la Tierra opcionales.

• Nuevos sgp4::MeanElementSet, sgp4::SgpOrbit, sgp4::Eop, sgp4::teme_to_itrs_matrix[_eop] y sgp4::gcrs_to_itrs_matrix[_eop]; Sgp4::new_at y Sgp4::propagate_at reciben épocas en dos partes. Nuevos jd2::Jd2::from_utc_calendar (convención dtf2d de SOFA para los días con segundo intercalar), jd2::utc_to_tai, tai_to_utc, utc_to_ut1 (a través de TAI, como utcut1 de SOFA), tai_to_tt y un jd2::earth_rotation_angle en dos partes.
• El modo polar de leo-pvt propaga con SGP4 en 2026-01-01T00:00:00 UTC sobre la cadena IAU (leo_fusion::polar::latitude_sweep_at acepta cualquier época); el generador Walker SGP4 gira al marco fijo a la Tierra a través de la cadena IAU.
• El tipo de escenario passes ejecuta un nuevo predictor de pasos aparentes (passes::predict_passes_apparent, apparent_look_angles): SGP4 sobre la cadena IAU, refracción ITU-R P.834-9 y el tiempo de luz del enlace descendente (nuevos interruptores refraction y light_time, activados por defecto), parámetros de orientación de la Tierra (ut1_minus_utc_s, xp_arcsec, yp_arcsec, por defecto 0), cruces resueltos hasta 1e-7 s y la culminación mediante búsqueda de sección áurea. El passes::predict_passes geométrico no cambia.
• tests/no_private_models.rs impide que los núcleos de geometría, tiempo y propagación del paquete lleven una propagación kepleriana propia, tasas de J2 seculares o una rotación solo de tiempo sidéreo; los niveles rápidos con nombre y la física que es el objeto de una fila son excepciones razonadas.
• Nueva fila VALIDATED "Fechas julianas en dos partes y segundos intercalares en la vía de tiempo de órbita terrestre": pyerfa 2.0.1.5 dtf2d/utctai/taiutc en 224 instantes alrededor de los 27 segundos intercalares dentro de 1e-6 s (preregistrada e947e69d); peor caso 1.9e-11 s.
• Nueva fila VALIDATED "Una única vía de órbita terrestre": posiciones TEME de 232 conjuntos de elementos frente a python-sgp4 2,24 (el SGP4 de referencia de Vallado) dentro de 6.1e-8 m (umbral 1 cm), y las rotaciones GCRS -> ITRS y TEME -> ITRS frente a c2t06a, pnm06a y ee06a de ERFA dentro de 2.9e-6 mas y 0,41 mas (umbrales 0,1 y 2 mas), con parámetros de orientación de la Tierra (preregistrada 72ea9eb0). Comunicado: la primera ejecución falló en 2016-12-31T23:59:59,5 por un segundo de rotación; UT1 se tomó de la fecha juliana cuasi UTC en un día con segundo intercalar, el motor ahora pasa por TAI, y la segunda ejecución coincide con los umbrales sin cambios.
• M131 "Cobertura LEO y dilución de la precisión para usuarios polares y árticos frente a GNSS MEO" pasa a VALIDATED: Orekit 13.1.8 toma los estados GCRS del motor, los rota y calcula la visibilidad y el DOP (NumPy para grupos de varios relojes); posiciones dentro de 6.8e-5 m (umbral 0,2 m), recuentos de satélites a la vista idénticos en 4040/4040 muestras, DOP mediano dentro de 2.3e-11 en términos relativos.
• Nueva fila VALIDATED "Predicción de pasos aparentes por una estación terrestre con refracción y tiempo de luz": Orekit 13.1.8 propagando los mismos conjuntos de elementos en un TEME que construye según la definición indicada, con refracción ITU-R P.834 y su modelo de medición de tiempo de luz, sobre 60 casos en estaciones a nivel del mar: 1210 pasos, cruces dentro de 3.4e-6 s (umbral 5 ms), elevación máxima dentro de 5.5e-7 grados, dirección aparente dentro de 8.8e-7 grados (umbral 1e-4 grados).
• Hallazgos, mantenidos fijados: las primeras comparaciones de la afirmación completa frente a Orekit de extremo a extremo no alcanzaron sus umbrales de posición y de dirección, no por el motor sino porque el SDP4 de Orekit 13.1.8 se aparta del SGP4 de referencia para órbitas de espacio profundo circulares (e = 0) (hasta 67 m) y su TEME por defecto se construye sobre la nutación IERS 1996 (IAU 1980), a unos 72 milisegundos de arco de la cadena IAU 2006/2000A (2,7 m en LEO). El coeficiente de refracción ITU-R P.834 de Orekit para h*theta0^2 es 0,011380 donde la Recomendación imprime 0,01380; la comparación se hace a nivel del mar, donde el término se anula, y la diferencia por encima queda fijada.
• "Predicción de pasos por una estación terrestre (segmento terreno)" sigue siendo VALIDATED con su afirmación limitada al passes::predict_passes geométrico; el tipo de escenario passes pertenece a la nueva fila.
• Entorno de la referencia independiente: Orekit 13.1.8 con Hipparchus 4.0.3, pyerfa 2.0.1.5, python-sgp4 2,24 (xval/d8-orekit13/setup.sh).
• Revisiones: el scenarios/passes.toml incluido pasa de un acceso total de 1675 s a 1659 s (cinco pasos como antes; mejor elevación máxima 73,25 grados -> 70,08 grados), y todas las salidas de passes se mueven con la nueva vía (la línea impresa en docs/examples/multi-tool-pipeline.md y la entrada passes de docs/CAPABILITY.md ahora lo indican); el VDOP GNSS de polar-arctic-leo-coverage incluido en el ecuador 1,19669 -> 1,19710, a 89,9 grados 1,50645 -> 1,50590, VDOP fusionado a 89,9 grados 1,14388 -> 1,14250 (las cifras publicadas con dos decimales 1,20, 1,51 y 1,14 no cambian). No cambia ningún archivo golden.
• Todavía sin encaminar: leo_pass, los modos doppler, joint y timing de leo-pvt y la órbita de verdad de referencia de leo_navmsg (sus modelos viven en leo_link::geometry y leo_fusion::geom), y los diseños terrestres de constellation-design (un nivel rápido de dos cuerpos con nombre).

D6, generador de referencia LunaNet AFS, LSIS V1.0 (cuatro filas nuevas, dos VALIDATED: 238 -> 242 filas, validadas 121 -> 123).

• Generador de referencia de LunaNet Augmented Forward Signal (AFS) (lunar_afs), fijado al LunaNet Signal-In-Space Recommended Standard (LSIS) V1.0 del 29 de enero de 2025 y que nombra esa versión en cada salida: la portadora de 2492,028 MHz; el canal de datos AFS-I BPSK(1) a 500 símbolos por segundo con su código Gold de 2046 chips; el piloto AFS-Q BPSK(5) con sus códigos primario de Weil de 10230 chips, secundario de 4 chips y terciario de 1500 chips; la trama con identificador de trama 0 (patrón de sincronización, subtrama 1 BCH (51, 8), CRC-24, subtramas LDPC de tasa un medio 2 a 4, entrelazador de bloques de 60 por 98) con un decodificador exhaustivo de la subtrama 1 y un decodificador LDPC min-sum escrito solo a partir de la matriz de comprobación de paridad; y síntesis de IQ en banda base con etiquetas de verdad de referencia escrita como una grabación SigMF. Los códigos se generan a partir de los registros de desplazamiento y de las construcciones de Legendre/Weil del estándar. No se redistribuye nada copiado del estándar (que no contiene términos de reutilización): los índices primarios de AFS-Q proceden de IS-GPS-800J, y lo que solo definen los anexos del estándar (retardos G2 de AFS-I, códigos terciarios, submatrices LDPC) se lee en tiempo de ejecución de una caché local que xval/lunar-afs/fetch_lsis.sh rellena desde el PDF alojado por la NASA, con cada archivo comprobado frente a un SHA-256 fijado (lunar_afs::lsis). El modelo es una referencia de ajuste a la norma, no un modelo de canal, de propagación ni de balance de enlace.
• sigmf::meta_to_json_with_extensions y sigmf::annotation_extension_fields: una grabación puede llevar campos de extensión con espacio de nombres declarados en core:extensions.
• Nueva fila VALIDATED "Representación en banda base de LunaNet AFS frente a un generador independiente, dado su estado de canal": frente a LANS-AFS-SIM (BSD-2-Clause, commit 480c6bf3, compilación de banda S), cero discrepancias de chips en los códigos de los PRN 1 a 210, cero discrepancias de símbolos en las tres tramas de la ejecución, y una correlación compleja normalizada de 0,999990 sobre 23,9 s de sus propias muestras (peor bloque de 2 ms 0,999948), dentro de umbrales fijados antes de la comparación (preregistrada 986ac280). Maneja el renderizador con el propio estado de canal del simulador y no cubre el reparto de potencia a partir de la densidad de portadora a ruido ni la escritura en SigMF y en 8 bits.
• Nueva fila VALIDATED "Codificación de canal de tramas de LunaNet AFS, FID 0": las tramas de 6000 símbolos son iguales a las de LANS-AFS-SIM símbolo a símbolo (preregistrada 986ac280); el código de la subtrama 1 reproduce el ejemplo resuelto de la Figura 8 del LSIS y el CRC-24 el valor de comprobación del catálogo CRC-24/LTE-A.
• Ambas filas promovidas están sujetas a datos en la caché de LSIS: su prueba de referencia independiente se omite con un aviso hasta que se haya ejecutado xval/lunar-afs/fetch_lsis.sh.
• Hallazgo (nueva fila MODELLED), "Generación de códigos de ensanchamiento de LunaNet AFS": de 2.937.232 chips y bits generados y comparados con las tablas del estándar y los archivos del Anexo 3, uno difiere: los "últimos 24 chips" que imprime la Tabla E-5 para el PRN terciario 147, que duplica la celda del PRN 151 mientras que el propio archivo del Anexo 3 del estándar coincide con el generador. No se alcanza el criterio de cero discrepancias.
• Hallazgo (nueva fila MODELLED), "Decodificabilidad en lazo cerrado de LunaNet AFS": tres ejecuciones preregistradas frente a PocketSDR-AFS; la tercera alcanzó íntegramente sus umbrales de seguimiento y decodificación pero no su protección de que una compilación del receptor que solo imprime reproduzca el registro de la compilación fijada, porque dos ejecuciones del receptor sin modificar ya difieren en sus registros de adquisición.
• Corregido: la portadora por defecto de lunar_service (export_antenna.carrier_hz), lunar_jamming y attack_surface era un valor redondeado de 2,4 GHz; ahora es la portadora AFS de LSIS-020, 2492,028 MHz. Con el valor por defecto anterior, la pérdida en espacio libre estaba subestimada en 0,327 dB.
• Revisiones: ninguna. Cada escenario incluido nombra su portadora, y los resultados de los 138 archivos de escenario son idénticos byte a byte a los del main anterior.

D7, IQ lunar real y LNAV de GPS (siete filas nuevas, ninguna VALIDATED: 242 -> 249 filas, validadas 123 sin cambios).

• portable_math::FftPlan: una transformada rápida de Fourier (FFT) de base mixta cuya salida son los mismos bits en todas las plataformas; una fijación SHA-256 de las transformadas de 8000 y 24000 puntos pasa en x86_64 y en wasm32-wasip1 (ejecutor en xval/portable-fft-wasm/).

• acquisition: búsqueda paralela de fase de código sobre IQ muestreado (pcps_acquire, pcps_grid) con plegado coherente, acumulación no coherente, un umbral chi-cuadrado para una probabilidad de falsa alarma de toda la búsqueda y un estadístico de promediado por celdas para ruido de banda limitada; refine, prompt_series con Doppler de código, y los estimadores de densidad de portadora a ruido (C/N0) M2M4 y de pico de malla.

• gps_lnav: un codificador del mensaje de navegación heredado (LNAV) de IS-GPS-200 para las subtramas 1 a 3, con la paridad de la Tabla 20-XIV y un decodificador de campos.

• realdata::ion_sdr: un lector del ION GNSS SDR Metadata Standard (.sdrx) y de sus archivos de muestras, con to_mid_rise para niveles en complemento a dos.

• realdata::lugre: la cabecera de lote IQS de LuGRE (Lunar GNSS Receiver Experiment), la telemetría RAW, ACQ y NAV y los archivos CLK, y una comprobación que lista dónde los metadatos de .sdrx contradicen la cabecera binaria.

• antenna::GainPattern2D y, en earth_gnss_lunar, el marco del cuerpo con guiñada dirigida, los ángulos de acimut de transmisión y fuera del nadir, y transmit_side_db para el C/N0 relativo con diagramas medidos.

• Codificación del mensaje de navegación LNAV de GPS (nueva fila, sigue siendo MODELLED tras la verificación posterior del integrador): en el archivo de difusión de IGS del 2 de marzo de 2025, analizado y decodificado por RTKLIB v2.4.2-p13, las 960 palabras pasan la paridad, las 96 subtramas se decodifican y los 608 enteros de difusión son iguales a los de Kshana (tests/gps_lnav_rtklib_integer_oracle.rs), pero el preregistro (d4d9eb9d) llegó a la rama pública dos segundos después del commit que contenía el resultado, de modo que no puede demostrarse el orden "registrado antes de obtener el archivo" y la fila no se promueve.

• realdata::ion_sdr rellena las palabras desde el bit más significativo (I en el nibble alto de un byte de LuGRE; la lectura anterior producía la señal conjugada), conserva la lectura antigua como SdrLayout::fill_lsb_first y lee muestras más anchas que una palabra.

• acquisition::refine_doppler_coherent: refinamiento Doppler coherente en fase (0,2 Hz RMS a 30 dB-Hz sobre 200 ms en simulación).

• GPS L1 C/A frente a gps-sdr-sim: chips y bit de paridad exactos bit a bit; 230 de 1152 campos LNAV difieren en una unidad porque gps-sdr-sim trunca donde el entero de difusión necesita redondeo.

• LNAV decodificado por RTKLIB: toda la paridad y todas las subtramas pasan y cada parámetro queda dentro de medio cuanto; 41 valores escalados difieren en unas pocas unidades del último lugar por la constante decimal 2^-43 de RTKLIB, por encima del umbral registrado.

• Adquisición de LuGRE frente a GNSS-SDR 0.0.19: 266 de 266 decisiones coinciden, 250 localizadas en la misma celda; la mayoría de los positivos son artefactos de una media de −0,5 en los niveles de 4 bits en bruto; la rama de C/N0 no tuvo datos de vuelo contemporáneos. Dos lotes (OP5, OP12) se excluyeron por error: sus metadatos coinciden con sus cabeceras, pero el lector no podía entonces leer una muestra más ancha que una palabra.

• Adquisición de LuGRE frente al Doppler predicho por la órbita: con la decisión por potencia de muestra, toda búsqueda cruza sobre ruido de banda limitada; con la decisión por promediado por celdas, los pares más fuertes coinciden en magnitud con el signo invertido, lo que muestra que el orden I/Q registrado es el conjugado de los datos.

• Adquisición a ciegas en los lotes de la superficie lunar: cuatro lotes adquieren cada uno un satélite (predicho visible, sin falsa alarma a 1e-7), ninguno dos, de modo que el umbral de diferencia de Doppler no tiene ningún par que puntuar.

• C/N0 relativo a distancia lunar (M039 reformulada): 15 registros Block IIR/IIR-M y un par, demasiado pocos para el umbral registrado.

• Revisiones: ninguna; no cambia ninguna cifra publicada, archivo golden ni figura de la documentación.

• La fila M039 "GNSS terrestre a distancia lunar" reformula su afirmación a distancia lunar como el C/N0 relativo entre satélites en una misma época más la visibilidad (no se afirma el C/N0 absoluto); sigue siendo MODELLED. El NOTICE de nivel superior incluye la atribución CC BY 4,0 de LuGRE.

Corregido#

• La orientación de ejes principales lunares de DE440 ahora se interpola a lo largo de la geodésica entre nodos diarios. La interpolación anterior, elemento a elemento, tenía un error de hasta 2.0e-4 rad (340 m en la superficie lunar) cerca de los puntos de cuarto de cada día, no los "unos 14 m" que indicaba la fila. Sus usuarios (geometría de telemetría láser lunar, datum lunar, observabilidad de fallos lunares) obtienen la orientación corregida.
• Correcciones del motor de la ronda 2, cada una repetida frente a su tolerancia preregistrada sin cambios: la versión de IERS de una fila de EOP se lee de sus indicadores I/P y no de un bloque en blanco del Boletín B; snapshot_raim usa el nivel local geodésico; el acoplamiento lunar del marco de tasa usa el radio ecuatorial, J2 y la rotación; el ajuste liu22 parte de correcciones nulas sin a priori y usa la tasa de movimiento medio del artículo; el espaciado de nodos de EO incluye la regresión nodal de J2; el tiempo de deslizamiento de ciclo de Costas usa rho/4; la solución conjunta aplica el retardo de grupo de difusión del par; la solución conjunta lunar usa un paso QR; la cota de NTN se evalúa en la posición verdadera; la referencia de reloj del diseño de constelaciones es la constelación de menor número a la vista; la serie de orientación de DE440 abarca 2014-2030 y da error fuera de ese intervalo en lugar de saturarse.

Añadido#

• leo_navmsg::truth::TruthOrbit::from_ecef_states, una órbita de verdad de referencia construida a partir de estados tabulados fijos a la Tierra, usada por la comparación del ajustador de órbitas reales.
• Los archivos de prueba y los archivos auxiliares de las comparaciones anteriores, cada uno con su generador y un NOTICE.md que indica la fuente, la licencia, la fecha de obtención y el SHA-256.
• Ronda 2: araim_reference::add_v42_protection_levels y _ecef (detección de fallos ADD v4.2, siguiendo a Stanford MAAST para ARAIM 2, aviso BSD-3 en el código fuente); raim::snapshot_raim_fde; cw_dynamics::second_order_correction y propagate_second_order; el modelo de error de INS de nueve estados inertial::coast::ErrorDynamics; los parciales de lunar_vlbi::KernelGeometry y las entradas de lunar-vlbi en la vía de kernel; naif_kernel, un lector de kernels SPK tipo 2 y PCK binarios; lunar_llr_geometry::llr_bcrs_one_way_m con estaciones ITRF2020; densidad de Jacchia 1971; solar_system::link_on sobre cualquier proveedor de efemérides; launch::site_rotation_speed_at; eo_payload::j2_nodal_period y ground_track_spacing_equator_j2; batch_ls::gauss_newton_qr; precise_products (lectores de reloj RINEX, ANTEX y DCB).

[0.29.3] - 2026-10-01#

Una versión de parche sobre 0.29.2. Kshana Studio se reconstruye en torno a dos vistas: una vista Simple que responde primero y explica en palabras llanas, y una vista Avanzada con el panel completo. Con ella llegan dos pequeñas correcciones en kshana.dev. El motor no cambia: todo escenario incluido da un resultado idéntico byte a byte al de 0.29.2, salvo por el sello de versión.

Cambiado#

• Kshana Studio tiene una vista Simple. Es la vista con la que se abre el Studio.
  • La respuesta va primero: un escenario se abre con su resultado, expresado en una frase llana. Todo escenario incluido tiene su propia frase, escrita para lo que ese escenario mide.
  • Se muestran como máximo cinco ajustes, los que más cambian la respuesta. El resto está en "Ajustes avanzados", plegado hasta que se abre.
  • "Cómo se calcula" explica el método en unas pocas líneas, y "Para investigadores" ofrece las cifras propias del motor, el archivo del escenario y las evidencias que respaldan el resultado.
• El panel completo es la vista Avanzada. Aquí están todos los paneles, gráficos, exportaciones e informes del Studio anterior.
• Un interruptor permite pasar de una vista a otra y conserva su posición. Se mantienen el escenario, la vista en la que estaba y los ajustes que haya editado. El Studio recuerda qué vista usó por última vez. Los enlaces del sitio y de la documentación abren la vista Simple; un enlace con view=advanced abre la vista Avanzada, y todo enlace anterior al Studio sigue abriendo el mismo escenario y la misma vista.
• Una primera vista más rápida con conexiones lentas. La respuesta registrada de un escenario se dibuja antes de que cargue el resto del Studio, de modo que con una conexión móvil lenta la respuesta aparece en unos dos segundos en lugar de unos nueve.
• Mejor búsqueda. Ahora una búsqueda muestra primero los escenarios cuya área o título coincide con las palabras, antes que los escenarios que solo las mencionan en el nombre del archivo o en el texto.

Corregido#

• El globo de la página de inicio ya no se queda en blanco con el movimiento reducido activado. Con el ajuste del sistema de movimiento reducido activado, al redimensionar la ventana el globo principal podía quedar vacío hasta que la página se desplazaba. Ahora el globo se vuelve a dibujar en el mismo fotograma que el cambio de tamaño.
• La consola de banda L de la página de inicio explica su banda vacía. En "Watch a jammer take the band" el panel GPS L5 / Galileo E5a permanecía oscuro durante todo el minuto, lo que parecía una avería. En este escenario ningún jammer transmite en esa banda y las señales de los satélites están por debajo del suelo de ruido, de modo que nada por encima de él destaca. Ahora una etiqueta discreta lo indica en cualquier tramo de un panel sin nada por encima del suelo (el panel L5 / E5a, y el panel L2C antes de que arranque su jammer de ruido), con el C/N0 y el estado de enganche de cada banda de la misma ejecución. Solo se coloca donde nada está por encima del suelo, por lo que nunca tapa la energía del jammer.

0.29.2 - 2026-10-01#

Una versión de parche sobre 0.29.1. Elimina código duplicado en los módulos de mensaje de navegación, fusión y espectro de LEO, añade un tema claro a kshana.dev, traslada Kshana Studio a su propia dirección, hace el sitio legible para buscadores y asistentes de IA, corrige varios detalles pequeños del Studio y permite que las versiones de npm se publiquen sin un token almacenado. No cambia ninguna salida del motor: todo escenario incluido da un resultado idéntico byte a byte al de 0.29.1, salvo por el sello de versión.

Añadido#

• Un tema claro para kshana.dev. Todas las páginas pueden leerse en modo claro u oscuro. El sitio sigue el ajuste del sistema del lector y tiene un interruptor para cambiarlo.
• Los buscadores y los asistentes de IA pueden leer el sitio. Ahora cada página tiene su propio título, descripción, dirección canónica, etiquetas de tarjeta social y datos estructurados de schema.org, además de texto plano para las secciones que dibuja un script. El sitio publica robots.txt, un sitemap.xml con la fecha del último cambio de cada página, llms.txt y llms-full.txt (una guía de texto plano breve y otra completa para asistentes de IA), y una clave IndexNow para que un despliegue pueda indicar a los buscadores qué ha cambiado.
• Las versiones de npm pueden publicarse sin un token almacenado. El trabajo de npm ahora ejecuta Node 24 y npm 11.5.1 o posterior, que admiten la publicación de confianza de npm: npm intercambia la identidad de GitHub del trabajo de publicación por una credencial de corta duración. El secreto NPM_TOKEN sigue funcionando y se usa mientras esté definido, de modo que nada cambia hasta que se active la publicación de confianza para el paquete en npmjs.com. docs/RELEASING.md enumera los pasos.

Cambiado#

• El titular de la página de inicio se lee bien sobre el globo. Ahora hay una sombra suave detrás del titular y de su texto, que atenúa las líneas de órbita y los puntos de satélite del globo animado allí donde lo cruzan.

• Kshana Studio tiene su propia dirección: https://kshana.dev/studio/. Todos los enlaces del sitio y de la documentación apuntan allí. La dirección antigua, /playground/, sigue funcionando y redirige a la nueva conservando el escenario, la vista y los demás ajustes del enlace.

• Correcciones del Studio. El archivo del motor se descarga una vez en lugar de dos. Mientras se descarga, el Studio muestra de inmediato el resultado registrado del escenario, etiquetado como registrado, en lugar de una pantalla vacía. En un teléfono la cabecera es una sola fila compacta. Las cifras clave se distribuyen de dos en dos por fila, de modo que ninguna queda oculta fuera de la pantalla. Las etiquetas de los campos usan las palabras propias del escenario, con el nombre del campo a su lado, y la búsqueda encuentra los campos por cualquiera de los dos.

• Menos código duplicado. La tabla de unidades del mensaje de navegación de LEO escribía las mismas diez filas de estadísticas SISRE para cuatro resúmenes de ajuste. Ahora una macro las escribe una sola vez. Los dos gráficos de cascada de espectro comparten un eje de tiempo, una barra de color y un panel de barra de C/N0. El submuestreo de la rejilla principal reutiliza downsample_grid, y la integral de Simpson reutiliza navsignal::simpson. Los dos puntos de entrada del tipo de escenario de paso de LEO comparten un paso de preparación. leo_link::geometry importa los ayudantes de vectores de leo_fusion::geom en lugar de copiarlos. El informe avanzado importa el escape de HTML del informe de la API en lugar de copiarlo. Cada uno de los 139 archivos de escenario de scenarios/ se ejecutó en 0.29.1 y con este código, y todos los archivos de salida son idénticos byte a byte.

• Las tablas de unidades de leo-navmsg y leo-pvt tienen sus propios archivos. Se han sacado de módulos que también contienen lógica y se han pasado a src/leo_navmsg/units.rs y src/leo_fusion/pvt_units.rs. PVT_UNITS conserva su ruta pública. Solo estos dos archivos de tabla se suman a las exenciones de detección de copia y pega para catálogos declarativos en sonar-project.properties, que tests/sonar_cpd_exclusions_are_justified.rs comprueba.

Corregido#

• La insignia de CI del README muestra el resultado de los envíos a main. La insignia contaba las ejecuciones de todos los eventos en main, por lo que podía indicar "failing" mientras todas las ejecuciones de envío estaban en verde; ahora solicita únicamente las ejecuciones de envío (event=push).

0.29.1 - 2026-10-01#

Una versión de parche sobre 0.29.0: la cifra de cobertura medida, la línea con el nombre del proyecto en kshana.dev, un trabajo de cobertura más rápido y un README renovado. No cambia ninguna salida del motor: todo escenario da el mismo resultado que en 0.29.0.

Revisiones de cifras publicadas#

• Cobertura de líneas: ~96 % → ~95 %. El trabajo de cobertura volvió a medir el código publicado de 0.29.0 (commit db796dd, ejecución de CI 36809850252, 2026-10-01): 95.35 %, 55.970 de 58.697 líneas de src/. La cifra publicada era 95,63 % (37.697 de 39.419 líneas), medida sobre b1d350d antes de 0.28.0; se redondeaba a ~96 %. La nueva cifra se redondea a ~95 %, de modo que todas las superficies que fija tests/coverage_figure_doc_sync.rs cambian a la vez: docs/COVERAGE.md, la insignia del README, la línea de Evidencias y la tabla de CI, las insignias de crates.io, PyPI y npm, el informe técnico y la página de cobertura de kshana.dev. El mínimo del 85 % no cambia.

Añadido#

• La línea con el nombre en kshana.dev. "Kshana · क्षण · the precise instant" ahora abre la portada de Inicio y aparece bajo la marca en el pie de todas las páginas. kshana.dev sigue sin hacer ninguna petición a otro host: el devanagari es un subconjunto autoalojado de Noto Sans Devanagari con las tres letras de क्षण (1.692 bytes, web/fonts/, con el texto de su SIL Open Font License y su SHA-256 en web/fonts/FONTS.json). web/tools/fetch_third_party.py aprendió a guardar un subconjunto text= de Google Fonts con un nombre de archivo direccionado por contenido.

Cambiado#

• Los enlaces del sitio llegan adonde apuntan, con direcciones limpias. Un enlace a una sección ahora coloca esa sección justo debajo de la cabecera, tanto en un teléfono como en un ordenador: un enlace a un sector de Missions abre ese sector con su panel arriba; los enlaces de Capabilities y Editions mantienen su posición mientras se dibujan los gráficos que tienen encima; Editions ya no añade un segundo desfase de cabecera; y un enlace a una parte plegada de una página de documentación la abre. Cada página se enlaza con su dirección limpia (/evidence#research, /docs/changelog, / para Inicio), y los enlaces canónicos, el mapa del sitio y las redirecciones de las direcciones antiguas nombran las mismas; las direcciones .html siguen funcionando. Research tiene su propio enlace en la cabecera, entre Evidence y Developers, y en el pie. La documentación ya no muestra la hoja de ruta (ROADMAP.md permanece en el repositorio): el grupo Project es Changelog, Licensing, Security, Contributing, Governance y Code of conduct, y el Glossary pasó a Get started.
• El trabajo de cobertura es más rápido. En 0.29.0 tardó 143 minutos frente a unos 91 normales a
  94. El fuzzer de tests/property.rs, la causa la última vez, se llevó 4 de ellos. El corpus incluido pasó de 74 a 139 escenarios, y tres binarios de prueba lo recorrían entero archivo por archivo (determinism dos veces, advanced_report y animation una vez): 37 minutos en total con instrumentación de cobertura, frente a 3 en 0.27.2. Ahora comparten tests/support/corpus.rs, que ejecuta el trabajo de cada escenario en todos los núcleos y devuelve los resultados ordenados; se conservan todos los escenarios y todas las aserciones. En un portátil arm64, con compilación de depuración: determinism tarda 143 s en 14 núcleos frente a 612 s con KSHANA_CORPUS_THREADS=1 (el antiguo recorrido en serie).
• El README, renovado. Se abre con la misma línea de nombre que el sitio; las capturas del Studio se han vuelto a tomar con el Studio 0.29.1, con una nueva del Studio en un teléfono y su barra de pasos inferior; una nueva tira "The site" muestra tres páginas de kshana.dev de la compilación 0.29.1 (tools/capture_site_shots.mjs, compuesta por tools/readme_shots.py y registrada en docs/assets/readme/site/SHOTS.json); la cifra de cobertura es ~95 %; y el texto alternativo de la figura de investigación, que repetía el de la figura de arquitectura, ahora describe los artículos. Las insignias de la cabecera son más pequeñas y más cortas (18 px de alto; "~95%", "83/223", "quality", "AGPL-3.0", "zenodo.20528627"), de modo que las once caben en dos líneas; todos los enlaces y textos alternativos conservan su significado completo.
• El trabajo de la imagen de contenedor dispone de 90 minutos. En v0.29.0 la compilación emulada linux/arm64 de la imagen kshana-mcp alcanzó el antiguo límite de 45 minutos mientras compilaba su último crate, por lo que la imagen, la entrada del registro MCP y la comprobación del canal no se publicaron. El límite es ahora de 90 minutos; la imagen no cambia.
• Ocho literales de coma flotante reagrupados en src/ephem.rs y src/sgp4.rs (0.323_273_64 → 0.323_273_640): SonarQube Cloud interpretaba un último grupo de _64 o _32 como un sufijo f64 o f32 ausente (regla S7454). Los valores son los mismos números, así que ningún resultado cambia.

0.29.0 - 2026-10-01#

Doce nuevos tipos de escenario y tres nuevas formas de leer una ejecución. El motor ahora abarca el espectro radioeléctrico, todo el sistema solar, constelaciones alrededor de cualquier cuerpo, campañas que encadenan escenarios en una sola misión, y posicionamiento, navegación y temporización (PNT) desde la órbita terrestre baja (LEO), de la señal a la solución de posición. Además, toda ejecución puede escribirse como una animación, un informe completo y un conjunto de archivos de interoperabilidad para otras herramientas.

Alrededor del motor: un kshana.dev rediseñado (un sitio de varias páginas y un nuevo panel Kshana Studio que ejecuta todas las capacidades en el navegador), un README reescrito, catorce herramientas en el servidor del Model Context Protocol (MCP), una compilación para navegador que da los mismos números que la nativa, y una página pública para Kshana Pro.

De dónde procede el crecimiento:

La capacidad de LEO es independiente del sistema: se ejecuta con parámetros genéricos declarados y no necesita ningún sistema con nombre. Los sistemas con nombre son preajustes opcionales, cada uno en su propio archivo con su fuente pública. Un preajuste, Celeste IOD (demostración en órbita), usa cifras presentadas en el taller LEO-PNT de ESA NAVISP, 2026 (ESA es la Agencia Espacial Europea; NAVISP es su Programa de Apoyo e Innovación en Navegación); reside en un solo archivo, src/celeste_iod.rs, con sus cinco escenarios solo de repositorio, de modo que puede retirarse sin editar el código fuente, y ninguna de las cifras de su taller se repite en este registro de cambios.

Lea "Revisiones de cifras publicadas" antes de actualizar. Cambia una salida del motor (las columnas de marco inercial del tipo de escenario ephemeris, tras una corrección de signo en la matriz de nutación), y la auditoría de la documentación corrigió cifras que documentos anteriores habían impreso.

Abreviaturas usadas en esta entrada

Estados: VALIDATED significa comprobado frente a una referencia independiente externa (una tabla publicada, el software de otro grupo o datos medidos); MODELLED significa un modelo declarado comprobado solo en cuanto a coherencia interna; PARTNER significa que la comprobación requiere hardware o datos de un socio.

Abreviatura	Significado
3GPP, 5G, NTN	3rd Generation Partnership Project (Proyecto de Asociación de Tercera Generación); red móvil de quinta generación; red no terrestre
AD, BC	eras del calendario (anno Domini, antes de Cristo)
AIAA	American Institute of Aeronautics and Astronautics (Instituto Americano de Aeronáutica y Astronáutica)
AltBOC, BOC, BPSK, MBOC	portadora de desplazamiento binario alternativa; portadora de desplazamiento binario; modulación por desplazamiento de fase binaria; portadora de desplazamiento binario multiplexada (modulaciones de señal)
ATOMIC	Autonomous Time and Orbit Determination for Microsatellite Constellations (un modelo publicado de efemérides de LEO)
C/A, L1, L2, L2C, L5	código de adquisición gruesa y los nombres de portadoras y señales civiles del Sistema de Posicionamiento Global
C/N0	relación entre portadora y densidad de ruido
CIO	Origen Intermedio Celeste
CLI	interfaz de línea de comandos
CRC-24Q	comprobación de redundancia cíclica de 24 bits (polinomio de Qualcomm)
CSAC	reloj atómico a escala de chip
CSS, HTML, SVG, XML	hojas de estilo en cascada; lenguaje de marcado de hipertexto; gráficos vectoriales escalables; lenguaje de marcado extensible
CSV, JSON, PDF, TOML, URL	valores separados por comas; notación de objetos de JavaScript; formato de documento portátil; Tom's Obvious Minimal Language; localizador uniforme de recursos
CW	onda continua
CZML, KML, GeoJSON	Cesium Language; Keyhole Markup Language; JSON geográfico (formatos de mapa y globo)
DE441	Development Ephemeris 441 del Jet Propulsion Laboratory
DOI	identificador de objeto digital
DOP, GDOP, PDOP, HDOP, VDOP	dilución de la precisión: geométrica, de posición, horizontal, vertical
E1, E5, E5a, E5b	nombres de las señales de Galileo
E3F	el nombre de una ranura en la tabla de la constelación del Sistema de Posicionamiento Global
ECEF	centrado en la Tierra y fijo a la Tierra
EE	ecuación de los equinoccios
EGM2008	Earth Gravitational Model 2008
EIRP	potencia isotrópica radiada equivalente
ERFA, SOFA	Essential Routines for Fundamental Astronomy; Standards of Fundamental Astronomy (bibliotecas de astronomía de referencia)
ESA, NAVISP	Agencia Espacial Europea; su Programa de Apoyo e Innovación en Navegación
FDMA	acceso múltiple por división de frecuencia
GCRF, GCRS	Marco de Referencia Celeste Geocéntrico; Sistema de Referencia Celeste Geocéntrico
GLONASS	el Sistema Global de Navegación por Satélite de Rusia
GNSS, GPS	sistema global de navegación por satélite; Sistema de Posicionamiento Global
IAU	Unión Astronómica Internacional
ICD, OS SIS ICD, OS SDD	documento de control de interfaz; Documento de Control de Interfaz de la Señal en el Espacio del Servicio Abierto de Galileo; Documento de Definición del Servicio Abierto de Galileo
ICRF	Marco de Referencia Celeste Internacional
IMO	Organización Marítima Internacional
INS, MEMS	sistema de navegación inercial; sistema microelectromecánico
IOD	demostración en órbita
IQ	en fase y en cuadratura
IS-GPS-200	la especificación de interfaz del Sistema de Posicionamiento Global
ISS	Estación Espacial Internacional
ITRF, ITRS, PEF, TEME	Marco de Referencia Terrestre Internacional; Sistema de Referencia Terrestre Internacional; pseudo fijo a la Tierra; ecuador verdadero, equinoccio medio (marcos de referencia)
ITU, ITU-R	ITU, ITU-R
J/S	Unión Internacional de Telecomunicaciones; su Sector de Radiocomunicaciones
J2 a J6, J2000	armónicos zonales del campo gravitatorio; la época 2000-01-01 12:00
JPL	Jet Propulsion Laboratory
LEO, MEO	órbita terrestre baja; órbita terrestre media
MBSE	ingeniería de sistemas basada en modelos
NEES	error de estimación normalizado al cuadrado
NeQuick-G	el modelo ionosférico de Galileo
OEM, SP3, TLE	Orbit Ephemeris Message; Standard Product 3 (órbitas precisas); conjunto de elementos de dos líneas
PNT, PPP	posicionamiento, navegación y temporización; posicionamiento preciso de punto
PSD, SSC	densidad espectral de potencia; coeficiente de separación espectral
RAIM, SQM	monitorización autónoma de la integridad por el receptor; monitorización de la calidad de la señal
RINEX, RTCM	Formato de Intercambio Independiente del Receptor; Radio Technical Commission for Maritime Services
RMS	raíz cuadrática media
RTKLIB	una biblioteca de posicionamiento GNSS de código abierto, usada aquí como referencia independiente
SGP4	Simplified General Perturbations 4 (el modelo orbital de los conjuntos de elementos de dos líneas)
SHA-256	Secure Hash Algorithm, 256 bits
SigMF	Signal Metadata Format
SISRE	error de distancia de la señal en el espacio
SPS PS	Standard Positioning Service Performance Standard
SRTM	Shuttle Radar Topography Mission
STK	Systems Tool Kit (su formato de archivo de efemérides .e)
STL	Satellite Time and Location
SVID	identificador de vehículo espacial
T/P/F	el total de satélites, planos y fasado de una constelación Walker
TEC	contenido total de electrones
UHF	frecuencia ultraalta
UTC	Tiempo Universal Coordinado
WGS 84	World Geodetic System 1984
X1, X5	nombres de señal del sistema Xona Pulsar

Revisiones de cifras publicadas#

Una cifra publicada que cambia es una revisión y se registra, nunca se corrige en silencio. Esta versión incluye una revisión de la salida del motor y varias de cifras impresas en la documentación.

Salida del motor

• La reducción TEME→GCRS giraba 2·Δψ de más: la matriz de nutación tenía el signo de Δψ invertido. nutation::numat construía Rx(−(ε̄+Δε))·Rz(Δψ)·Rx(ε̄) donde la iauNumat de SOFA construye Rx(−(ε̄+Δε))·Rz(−Δψ)·Rx(ε̄), de modo que nutation_matrix, nutation_matrix_2000a, teme_to_gcrs y gcrs_to_teme giraban el doble de la nutación en longitud, unos 25 segundos de arco. Todas las comprobaciones de la cadena eran pruebas de propiedades (rotación propia, ida y vuelta, una contribución de nutación distinta de cero) que un error de signo supera; la prueba integral de Vallado cubría TEME→PEF, TEME→ITRF y GCRS→ITRS, pero no TEME→GCRS. En el ejemplo de Vallado (AIAA 2006-6753, 2004-04-06) la cadena se desviaba del GCRF publicado en 1.145 m; ahora queda a 0,11 m de él, y la matriz coincide con la numat de ERFA hasta 1e-14. tests/frame_reference_vectors.rs::teme_to_gcrs_matches_vallado_gcrf y nutation::tests::nutation_matrix_matches_erfa_numat fallan ambas con el signo antiguo. La prueba de coherencia del CIO (Origen Intermedio Celeste) en src/cio.rs había atribuido el desacuerdo resultante de ~130 m a "≈ 2·EE"; el residuo es ahora de 5 cm y su cota se reduce de 250 m a 1 m. Esto cambia cifras publicadas, que se registran aquí como una revisión: las columnas gcrs_r_m y gcrs_v_m_s del tipo de escenario ephemeris (unos 0,8–1,0 km para el escenario incluido de la ISS (Estación Espacial Internacional); sus columnas TEME, fijas a la Tierra, de traza en el suelo, de ángulos de observación y de Doppler no cambian), y Propagator::position_in_frame / state_gcrs para los marcos GCRS e ITRS. Ninguna línea de resumen, gráfico ni hash de referencia de ningún escenario incluido lee estas columnas. Las nuevas exportaciones de interoperabilidad usan la cadena corregida: la posición CZML del primer satélite orbit-sgp4-gps coincide con una reducción de ERFA del mismo TLE (propagado por el paquete de Python sgp4) hasta 2,3 cm.
• El tipo de escenario leo-navmsg, de forma nativa y en la compilación para navegador. Ahora el tipo de escenario calcula todas las funciones trascendentes mediante una única biblioteca matemática portátil, de modo que su trama son los mismos bytes en todas las plataformas y en todas las compilaciones (bajo Fixed). Todas las cifras de leo-navmsg cambian con ello, y también la etapa navmsg de leo-pnt-chain. El tipo de escenario es nuevo en esta versión, así que no cambia nada de versiones anteriores, pero sí las cifras impresas antes de la corrección: el valor de comprobación de docs/LEO-NAVMSG.md para el escenario de codificación y decodificación era 0x110315 y ahora es 0x19105F, y su SISRE del mensaje decodificado es 0,129 cm. En kshana.dev, la tarjeta de Missions de leo-navmsg-fit-interval-trade mostraba un peor error de distancia de 1,6 mm con un ajuste de 60 s y 40,3 mm con un ajuste de 900 s; ahora el sitio se compila con el motor de esta versión y muestra 1,8 mm y 46,6 mm.
• El mapa de la huella de jamming en kshana.dev (Missions). Cada una de sus 875 celdas es una ejecución de maritime-strait-jamming en la que solo cambia la posición del receptor. Ahora las celdas se calculan con las mismas coordenadas de tres decimales que el enlace "open this run" de la celda entrega a Kshana Studio, de modo que una celda muestra exactamente lo que reproduce su enlace. La relación media entre jammer y señal (J/S) de 30 celdas cambia en 0,1 dB, al alza o a la baja; la disponibilidad de seguimiento de ninguna celda cambia. El motor da resultados idénticos para todas las celdas en 0.28.0 y 0.29.0.
• Remuestreo con semilla en el paquete WebAssembly (WASM). La compilación para navegador generaba, a partir de la misma semilla, índices de bootstrap y de barajado distintos de los de la compilación nativa (bajo Fixed). El intervalo de quantum-anomaly-detect del área bajo la curva en el navegador era [0.9901265, 0.9938305] y ahora es el nativo [0.99035875, 0.993861]. Ninguna cifra nativa cambia.

Cifras impresas en la documentación

La documentación se auditó palabra por palabra frente a ejecuciones del motor de esta versión. Cuando una cifra impresa no coincidía con la ejecución, se corrigió el documento, y cada corrección se enumera aquí, antiguo → nuevo. En todos los casos siguientes la salida del motor no cambió; el documento la había leído mal, redondeado mal o la había dejado desfasada.

• Auditoría de la documentación de las páginas de espectro, constelaciones, campañas, animación, informes e interoperabilidad, y un nuevo docs/SOLAR-SYSTEM.md. Todas las cifras se volvieron a ejecutar con este motor. Cambian dos cifras publicadas: docs/CONSTELLATION-DESIGN.md daba la prueba de cobertura de 5 000 satélites como "unos 0,13 s en una compilación de depuración"; eso no se reprodujo (1,24 s en un portátil cargado), por lo que la página ahora da la proporción del prefiltro que imprime la prueba (9,9 % de 19.440.000 pruebas de pares) y los 0,14 s del binario de producción para el leo-pnt-mega-shell incluido. La misma página daba el cruce de E3F como "desviado 0,050 deg"; ninguna prueba imprime esa cifra, así que la página ahora indica solo el umbral de 0,06 deg que la prueba exige y la derivación de 7,30 frente a 7,36 deg que lo respalda. Ninguna salida del motor cambia.
• Documentos de LEO-PNT: cifras publicadas revisadas (vueltas a ejecutar con el motor de esta versión). Comparación de bandas de docs/LEO-SIGNAL.md: el retardo ionosférico de primer orden de generic-s es de 3,24 m (se imprimía 3,25 m) y el de generic-c-wide de 0,77 m (era 0,78 m). Codificación y decodificación de docs/LEO-NAVMSG.md: el SISRE del mensaje decodificado se imprimía como 0,119 cm cuando la ejecución daba 0,122 cm; la página ahora imprime 0,129 cm, la cifra posterior a la corrección de independencia de plataforma incluida más abajo en Fixed. Paso de LEO frente a GNSS de docs/LEO-PASS.md: 32 dB menos de pérdida en espacio libre en el máximo del paso (era "de 26 a 32 dB"). En las cifras de señal y de paso la salida del motor no cambió; los documentos la habían leído mal o redondeado mal.
• Tutoriales, el ejemplo de canalización trabajado y el comando /kshana-run, auditados frente al motor de esta versión. Revisiones de cifras publicadas, antiguo → nuevo: los tipos de escenario que escriben <scenario>.table.csv son seis, no cuatro (faltaban leo-navmsg y telecom-timing; docs/tutorials/README.md, commands/kshana-run.md); el cruce de ½bT² de átomos fríos en el Tutorial 3 es de 18.443 s, no de 18.440 s; el error de ida y vuelta de oem-interop en docs/examples/multi-tool-pipeline.md es el medido de 4.88e-7 km, no "~1e-7 km"; la banda de holdover del CSAC del Tutorial 2 es de 2000–3200 s, la que afirma la prueba, no "~2600–4400 s"; el Tutorial 1 cita las filas SP3 y el bloque de geometría con la precisión con que el motor las escribe. Ninguna salida del motor cambió.
• Páginas de validación, cuántica, SGP4, animación, afirmaciones e integridad. docs/VALIDATION.md: el umbral aplicado a la desviación de Allan simulada a un segundo de un reloj con ruido blanco de frecuencia es del 20 % (se imprimía 25 %; el umbral del 25 % es el de la curva a 1, 10 y 100 s); la fila del paseo aleatorio de velocidad ahora indica su umbral aplicado del 20 % junto al 12 % aproximado observado; y la disponibilidad del reloj atómico a escala de chip en orbit-gnss-challenged es de aproximadamente 0,73 (se imprimía aproximadamente 0,83). docs/QUANTUM.md: el ruido por disparo limitado por vibración en el ejemplo trabajado de átomos fríos de la página es unas 46 veces su suelo de ruido de disparo (era "~45×"; recalculado 46,49), y el intervalo "1–50 µg/√Hz" para dispositivos en campo, que contradecía un dispositivo que la propia página cita, se sustituye por las cifras publicadas de los dos dispositivos citados. docs/SGP4-VALIDATION.md: la peor diferencia de posición es de 4,12 mm (era "≈ 4 mm"), con el satélite indicado. docs/ANIMATION.md: el ejemplo del codificador de vídeo leía los fotogramas de 24 fotogramas por segundo a 12; ahora usa 24, la tasa que indica el manifiesto de fotogramas. docs/CLAIMS-VS-REALITY.md: el modelo de jamming tiene 10 pruebas (eran 8), y el "2,97 m frente a 48,8 m" del filtro acoplado se sustituye por lo que afirma su prueba (el error de posición acoplado inferior a 0,6 veces el desacoplado, ganando al menos 90 de 100 ensayos). docs/INTEGRITY.md: el sello "Hoy" decía v0.22.0; ahora nombra esta versión, y dos capacidades construidas desde entonces (el modo de fallo de toda la constelación y el mensaje de apoyo a la integridad) salen de su lista de carencias.

Añadido#

Espectro

• Tipo de escenario spectrum: un modelo de espectro de banda L y cascada (src/spectrum.rs, src/sigmf.rs, docs/SPECTRUM.md). Toda la banda L de GNSS como una única densidad espectral de potencia (PSD): GPS L1 de adquisición gruesa (C/A) y L2 civil (L2C) (BPSK(1)), Galileo E1 (portadora de desplazamiento binario multiplexada, MBOC(6,1,1/11), o BOC(1.1)), GPS L5 y Galileo E5a (BPSK(10)), un suelo de ruido kT con una cifra de ruido del receptor, y jammers de onda continua (CW), de banda estrecha, de chirp y de ruido adaptado en una cronología programada. Cada jammer se puntúa por banda mediante su coeficiente de separación espectral (SSC), lo que da la relación entre jammer y señal (J/S) y la relación efectiva entre portadora y densidad de ruido (C/N0) por banda y por fila. El gráfico es una cascada SVG con barras de C/N0; result.json lleva la rejilla promediada por bloques en potencia. El opcional [iq] dibuja el modelo como muestras IQ, escribe y lee una grabación Signal Metadata Format (SigMF) (cf32_le, ci16_le) y compara una estimación de Welch con el modelo; el opcional [recording] estima un archivo SigMF real. Ejemplo incluido scenarios/l-band-waterfall-jamming.toml: un chirp se lleva L1 C/A y E1 a los 10 s, un tono CW en la portadora L1 mantiene C/A en 17,98 dB-Hz después de que el chirp se detiene, mientras que E1, cuyo espectro tiene un nulo ahí, se recupera; L5 y E5a no se ven afectados.
  • Nueva fila VALIDATED: las PSD y los SSC de las señales, frente al lóbulo principal de BPSK(n) de 2n x 1,023 MHz, los lóbulos de BOC(1.1) centrados en +/-1.023 MHz, las formas cerradas de Parseval que respaldan los SSC publicados de -61.8 / -64.8 / -67.8 dB/Hz, y los valores de manual Q = 1 (CW) y 1,5 (adaptado). El máximo de la PSD de BOC(1.1) está en +/-0.759 MHz, no en el centro del lóbulo; la prueba fija ambos.
  • Dos nuevas filas MODELLED: la cascada y la cronología de C/N0, que se reducen exactamente a la cadena del tipo de escenario jamming (comprobado de forma cruzada en cada informe), y el códec SigMF y el estimador de Welch. No hay ninguna grabación de terceros en el repositorio.
  • navsignal: una variante de MBOC y spectral_separation_coeff_offset.
  • El informe imprime el C/N0 que daría la tabla Q representativa del tipo de escenario jamming junto al derivado del espectro; para un tono CW en la portadora C/A difieren en 1,8 dB. Tres nuevas filas de la matriz: una validada (espectros de señal y coeficientes de separación espectral) y dos modeladas.

Sistema solar

• Efemérides del sistema solar y posicionamiento alrededor de cualquier cuerpo. Dos nuevos tipos de escenario.
  • solar-system: el Sol, los ocho planetas, Plutón, la Luna, Fobos, Deimos, Ío, Europa, Ganímedes, Calisto y Titán en una época: posición y velocidad heliocéntricas en el Marco de Referencia Celeste Internacional (ICRF), parámetro gravitacional, radios, J2 (el segundo armónico zonal) cuando está publicado, rotación sidérea, el polo y el meridiano origen de la Unión Astronómica Internacional (IAU), una traza orbital a lo largo de una revolución, y el tiempo de luz, la distancia de ida y de ida y vuelta, el retardo Shapiro solar y la separación del Sol desde un cuerpo observador y para cualquier enlace adicional. Los planetas proceden de los elementos keplerianos del Jet Propulsion Laboratory (JPL) de Standish y Williams (Tabla 1, 1800 d. C. a 2050 d. C.; Tablas 2a/2b, 3000 a. C. a 3000 d. C.); las lunas, de los elementos medios del JPL con la velocidad de rotación síncrona de la IAU, y Titán, del modelo de rotación de la IAU. Ejemplo: scenarios/solar-system-tour.toml.
  • body-pnt: un orbitador o un módulo de aterrizaje en superficie alrededor de cualquiera de esos cuerpos, que navega con pseudodistancias de una constelación Walker alrededor del cuerpo y una distancia de ida y vuelta sin reloj desde la Tierra; dilución de la precisión, incertidumbre formal y soluciones de mínimos cuadrados con semilla con y sin el enlace con la Tierra. Ejemplos: scenarios/mars-orbit-pnt.toml, scenarios/europa-surface-pnt.toml.
  • Body incorpora Mercurio, Venus, Júpiter, Saturno, Urano, Neptuno, Plutón y las siete lunas, una búsqueda por nombre y un registro físico; AnalyticSolarSystem da cualquier cuerpo respecto de cualquier otro a través de la interfaz EphemerisProvider existente.
  • VALIDATED frente a JPL Horizons (Development Ephemeris DE441; datos de prueba y consultas en tests/fixtures/solar_system/): de Mercurio a Saturno y la Tierra según la Tabla 1 dentro del doble del error nominal indicado (el peor, 1,87 veces), los ocho planetas según las Tablas 2a/2b (el peor, 1,71 veces), y el tiempo de luz de la Tierra a Marte y a Júpiter. MODELLED: Urano y Neptuno según la Tabla 1, que superan el error indicado frente a DE441 (2,0 y 5,2 veces), Plutón, las lunas, las constantes de los cuerpos y los resultados de body-pnt.
  • Hallazgo: la serie lunar de Montenbruck & Gill de src/ephem.rs ya está referida al equinoccio J2000 por su propio término de precesión (0,05 grados respecto de Horizons), por lo que se usa sin una rotación de precesión adicional. Seis nuevas filas de la matriz: dos validadas (posiciones de planetas, tiempo de luz) y cuatro modeladas.

Constelaciones alrededor de cualquier cuerpo

• Diseño de constelaciones a gran escala (tipo de escenario constellation-design, src/constellation.rs). Patrones Walker delta y Walker star (T/P/F), listas explícitas de elementos y diseños de varias capas, varias constelaciones por ejecución, alrededor de la Tierra, la Luna, Marte o cualquier otro planeta, Plutón o una luna importante, a partir de las constantes de cuerpo que añadió el tipo de escenario solar-system. Preajustes a partir de elementos nominales publicados: la línea base del Sistema de Posicionamiento Global (GPS) y la constelación ampliable de 24 ranuras (Standard Positioning Service Performance Standard, SPS PS, 2020), Galileo Walker 24/3/1 (Open Service Service Definition Document, edición 1,1), BeiDou en órbita terrestre media Walker 24/3/1 más satélites geoestacionarios y geosíncronos inclinados (Open Service Performance Standard 3,0) y GLONASS 24/3/1 (Interface Control Document 5,1). Cobertura y dilución de la precisión (DOP) sobre una rejilla de latitud/longitud: satélites a la vista, GDOP, PDOP, HDOP y VDOP (geométrica, de posición, horizontal, vertical) y disponibilidad por celda, globalmente y en el peor emplazamiento, con un reloj de receptor por constelación. Un prefiltro de visibilidad (semiángulo de cobertura más una banda de latitud del subsatélite, exacto en un cuerpo esférico) procesa 5.000 satélites en una rejilla de 10 deg en unos 0,13 s en una compilación de depuración.
  • VALIDATED: el generador Walker reproduce la Tabla 23 del OS SDD de Galileo y la fórmula de ranuras del ICD de GLONASS; el preajuste de GPS reproduce la columna de cruces del ecuador del SPS PS (35 de 36 ubicaciones a menos de 0,0108 deg; E3F a menos de 0,06 deg, siendo incoherente la propia fila de la tabla); la distribución global de HDOP de la línea base de GPS coincide con el Apéndice B del SPS PS (mediana 0,940 frente a 0,94, percentil 95 % 1,255 frente a 1,25, media 0,965 frente a 0,96; umbral 0,03).
  • MODELLED: diseños arbitrarios, otros cuerpos, la fase de BeiDou y los nodos geosíncronos inclinados, órbitas de dos cuerpos con J2 opcional, solo geometría.
  • Escenarios: constellation-multi-gnss-coverage (102 satélites, disponibilidad del 100 %, PDOP mediano 0,95, 31,0 a la vista por encima de 10 deg), leo-pnt-mega-shell (5.000 satélites, disponibilidad del 99,22 % con PDOP de 3 o menos por encima de 20 deg, 0 % en los casquetes polares, el prefiltro conserva el 11,5 % de las pruebas de pares), lunar-relay-constellation (14 satélites alrededor de la Luna, disponibilidad del 21,33 % en conjunto y máxima sobre la región polar sur). Los tres se incluyen para kshana example. Notas: docs/CONSTELLATION-DESIGN.md. Tres nuevas filas de la matriz: dos validadas (generador Walker y preajustes de GNSS, DOP global de GPS) y una modelada.
• Una campaña impulsada por el modelo de espectro y constelaciones alrededor de cualquier cuerpo. scenarios/campaign-spectrum-holdover-integrity.toml encadena el tipo de escenario spectrum con un holdover de reloj y un monitor de integridad (un chirp se lleva L1 C/A y E1; luego un tono CW mantiene C/A caído mientras E1 se recupera y el receptor recurre a un cielo solo de Galileo), fijado frente al ejemplo independiente de cascada de tests/campaign_composition_reference.rs. Ahora constellation-design resuelve su cuerpo central mediante Body::by_name, de modo que se puede disponer una constelación alrededor de cualquier planeta, Plutón o una luna importante con las constantes que usa el tipo de escenario solar-system.

Campañas

• Campañas: muchos escenarios compuestos en una sola ejecución. Un nuevo tipo de escenario campaign (src/campaign.rs, documentado en docs/CAMPAIGNS.md) ejecuta miembros de tipos de escenario existentes por el mismo despacho que la línea de comandos y lee números de sus resultados. Cuatro secciones, en cualquier combinación:
  • [[phases]]: una misión encadenada en una sola cronología. Los preajustes por tipo de escenario leen el error de tiempo del reloj frente a su límite de guarda, la relación efectiva media entre portadora y densidad de ruido (C/N0) frente al suelo de seguimiento, el nivel de protección vertical frente al límite de alerta, el error de posición, los satélites en seguimiento y los indicadores de alarma, mantenidos en una rejilla común con límites de fase y eventos. El estado se transfiere mediante carry, handoff y end_at.
  • [sweep]: de una a tres claves con puntos de cualquier tipo de escenario, opcionalmente con un conjunto con semilla en cada nodo.
  • [monte_carlo]: la realización k con la semilla base + k, con media, dispersión, percentiles y un intervalo de confianza bootstrap del 95% con semilla fija.
  • [compose]: valores compartidos vinculados a varios miembros, con un resumen combinado del mejor y del peor caso. Cada resultado lleva un hash de campaña y un resumen criptográfico sobre el resultado de cada miembro. Cuatro escenarios incluidos: campaign-jam-spoof-holdover-integrity (nominal, jamming, spoofing terminado en la detección del monitor de reloj a los 370 s, holdover con el desfase suplantado de 37,0 ns con una unidad inercial a la deriva, una alarma de integridad, recuperación), campaign-sweep-jammer-power, campaign-shared-jammer-sea-road y campaign-monte-carlo-clock-holdover. tests/campaign_composition_reference.rs fija las identidades de composición: una campaña de una fase reproduce la ejecución independiente bit a bit en tres tipos de escenario, un conjunto con semilla fija es estable byte a byte, y en un reloj con ruido blanco de frecuencia la media del conjunto queda dentro del intervalo indicado y la dispersión dentro del intervalo chi cuadrado de sqrt(q_wf * tau) = 16,459 ns. Tres nuevas filas modeladas de la matriz.

Animación

• Exportación de animación (--animate svg|html|frames|all, src/animation.rs, docs/ANIMATION.md). Toda ejecución cuyo resultado lleve una serie temporal puede escribirse ahora como un archivo de gráficos vectoriales escalables (SVG) animado (fotogramas clave de hojas de estilo en cascada, sin script: las trazas se dibujan tras un cursor de tiempo en movimiento), un único reproductor autónomo de lenguaje de marcado de hipertexto (HTML) (reproducir y pausar, desplazarse, velocidad, todos los paneles sobre un cursor sincronizado, marcadores de eventos que saltan al hacer clic; sin ningún recurso externo), o una secuencia numerada de fotogramas SVG con un manifest.json que indica fotogramas por segundo, duración y tiempos de los fotogramas para un codificador de vídeo. Una campaña se reproduce como sus fases con sus alarmas marcadas; una ejecución de espectro anima su cascada fila a fila. El reproductor sigue prefers-color-scheme, y con prefers-reduced-motion tanto el SVG como el reproductor muestran la imagen terminada en lugar de moverse. --animate-fps y --animate-duration fijan la reproducción; kshana::api::animate_toml y kshana::animation::animate_result son los puntos de entrada de la biblioteca, y result.json gana un bloque animation solo cuando se ejecuta --animate. La salida es una función pura del resultado y de las opciones, idéntica byte a byte en una nueva ejecución, sin marca de tiempo. Un tipo de escenario sin eje temporal muestreado se rechaza con "no time series to animate" y no se escribe nada. El exportador dibuja las propias muestras de la ejecución y no añade ningún número, por lo que es MODELLED (coherencia interna) y no lleva ninguna fila de la matriz de verificación; ninguna cifra publicada cambia. Pruebas: tests/animation.rs (determinismo, número de fotogramas, ninguna dirección externa, XML bien formado, la vía de movimiento reducido, y todos los escenarios incluidos con serie temporal animándose).

Informes

• Informes avanzados de ejecución (src/advanced_report.rs, docs/REPORTS.md). Toda ejecución por interfaz de línea de comandos (CLI) escribe ahora <scenario>.report.html, un informe imprimible en lenguaje de marcado de hipertexto (HTML), y <scenario>.report.json, el mismo contenido como documento legible por máquina en notación de objetos de JavaScript (JSON). Secciones: un resumen ejecutivo; cada entrada del escenario con su unidad, leída del esquema de unidades de campo (el bloque units del resultado), o bien del sufijo del nombre del campo, o bien indicada como no indicada; los resultados con el gráfico de la ejecución, cada escalar y un resumen de cada columna numérica; para una campaña, la tabla de nodos del barrido, la media de Monte Carlo, la desviación típica, los percentiles 5.º / 50.º / 95.º y el intervalo de confianza bootstrap con un histograma por métrica, la tabla de fases de la cadena, o los miembros de la composición y su resumen combinado (y la rejilla de una ejecución sweep o sweep-nd); una cronología de eventos; la etiqueta VALIDATED / MODELLED / PARTNER, la referencia independiente y la evidencia de pruebas de cada fila de la matriz de verificación que ejercitan los tipos de escenario de la ejecución, leída de la matriz mediante una tabla de correspondencia entre tipo de escenario y fila (una fila que califica una sola vía de entrada, como la vía Simplified General Perturbations 4 (SGP4) de orbit o la vía de registro medido de slot-timing, se enumera solo cuando la ejecución tomó esa vía, y la fila del lector de la Shuttle Radar Topography Mission (SRTM) no se enumera para ningún tipo de escenario, ya que ningún campo de escenario lee un mosaico SRTM); las declaraciones de lo no modelado y los supuestos, cada uno citado con su fuente; y un registro de reproducibilidad (versión del motor, el commit de origen cuando la compilación define KSHANA_GIT_COMMIT, resúmenes criptográficos Secure Hash Algorithm de 256 bits (SHA-256) del archivo de escenario y del documento de resultado, semilla, plataforma y el comando exacto). El informe no lee ningún reloj: el mismo escenario, la misma semilla y la misma compilación del motor dan un informe idéntico byte a byte, y la única marca de tiempo que puede mostrar es la que --study-name ya escribe. Una hoja de estilo de impresión se ajusta a A4 y US Letter, repite las cabeceras de tabla y mantiene enteras las filas y las figuras entre páginas; un archivo de formato de documento portátil (PDF) se obtiene con "Guardar como PDF" del navegador. No hay opción --report pdf, porque representar los gráficos en un PDF exigiría una dependencia nueva y pesada. Pruebas: tests/advanced_report.rs informa de todos los escenarios incluidos (ninguna sección vacía, ningún texto de relleno, etiquetas iguales a la matriz, el resumen criptográfico del escenario igual al del archivo, idéntico byte a byte en una nueva ejecución) y tests/advanced_report_cli.rs vuelve a ejecutar el comando registrado en un directorio nuevo y exige un result.json idéntico byte a byte. Ninguna cifra publicada cambia, y los recuentos de tipos de escenario, archivos de escenario y filas de la matriz no cambian.
• El informe, la animación y las exportaciones funcionan conjuntamente. El informe avanzado incorpora una sección "Animación y exportaciones": el dibujo animado de la ejecución incrustado como imagen inerte (o el motivo de que no haya), enlaces a la animación y a los archivos de exportación escritos junto a él, y cada formato de interoperabilidad con si se aplica, por qué no, y su especificación; report.json lleva el mismo bloque companions. El reproductor de animación HTML enumera los archivos de exportación escritos junto a él. Ahora la interfaz de línea de comandos (CLI) genera las exportaciones antes de escribir el informe, de modo que ambos puedan nombrar los archivos.

Exportaciones de interoperabilidad

• Exportaciones e importaciones de interoperabilidad (--export, src/interop/, docs/INTEROP.md). kshana <scenario.toml> --export <format> escribe la geometría del escenario como CZML (el Cesium Language), KML (Keyhole Markup Language 2,2, un estándar del Open Geospatial Consortium, con trazas con marca de tiempo gx:Track), GeoJSON (Internet Engineering Task Force Request for Comments 7946) y efemérides .e de Ansys STK (Systems Tool Kit) (EphemerisTimePosVel, metros, un archivo por objeto en movimiento), y la instantánea IQ (en fase y en cuadratura) sintetizada del tipo de escenario spectrum como un par SigMF (Signal Metadata Format) mediante el src/sigmf.rs existente. --export all escribe todos los formatos aplicables e imprime por qué los demás no lo son; --export list informa sin ejecutar. Los objetos en movimiento se escriben en el Sistema de Referencia Celeste Geocéntrico (CZML INERTIAL, STK ICRF) y en longitud, latitud y altura WGS 84 (World Geodetic System 1984) fijas a la Tierra (KML, GeoJSON); los emplazamientos fijos en CZML son FIXED. El tipo de escenario jamming añade dos huellas de jammer a partir de sus propias ecuaciones de enlace. --import-route <file.geojson> escribe un LineString de GeoJSON en las entradas de traza de terrain-nav, terrain-slam, gravity-map y combined-altpnt. Las exportaciones son deterministas byte a byte y no llevan marca de tiempo. tests/interop_formats.rs valida cada exportación frente a su especificación publicada, compara los estados de los satélites exportados con los del propio motor hasta 1 mm, y pasa cada escenario incluido por cada formato, de modo que cada uno o bien se exporta o bien indica por qué no (la tabla de docs/INTEROP.md). Ninguna cifra publicada cambia: la síntesis IQ del tipo de escenario spectrum pasó a una única función compartida y su documento de resultado es idéntico byte a byte, y PassesScenario incorpora propagator() y epoch_calendar(), que usa su propia ejecución. Los recuentos de tipos de escenario, archivos de escenario y matriz de verificación no cambian. Un escenario de órbita o de integridad sin epoch se fecha con los propios datos de sus satélites: t = 0 es la época más temprana de TLE (conjunto de elementos de dos líneas), de efemérides de difusión o de SP3 (Standard Product 3), y cada uno de esos satélites se rota a los marcos GCRS y fijo a la Tierra en su propio instante; 2000-01-01T00:00:00Z se usa solo cuando ningún satélite lleva época. Las exportaciones SP3 y OEM (Orbit Ephemeris Message) conservan su etiqueta 2000-01-01. Para apoyarlo se añaden Sgp4::epoch_jd_utc, Sp3Interpolator::jd_ut1 y Propagator::own_jd_utc; nada de lo que ya existía las lee.

Navegación en órbita terrestre baja: señal

• Diseños de señal LEO-PNT y un espectro multibanda. Un nuevo tipo de escenario leo-signal y un tipo de escenario spectrum que va más allá de la banda L: un tipo de escenario, cuatro archivos de escenario (tres incluidos; el archivo de Celeste IOD es solo de repositorio) y cuatro filas de la matriz (dos VALIDATED, dos MODELLED).
  • leo-signal: diseños de señal parametrizados de posicionamiento, navegación y temporización (PNT) de órbita terrestre baja (LEO) para cualquier sistema (banda, ancho de banda de transmisión, asignación de la UIT; componentes de adquisición, de datos y piloto con espectros BPSK(n), BOC(m,n), MBOC o planos, reparto de potencia, subportadoras FDMA, longitudes de código y tasas de datos), a partir de archivos de preajuste públicos compilados en data/leo-signals/ (Xona Pulsar X1/X5, Iridium STL, una señal de oportunidad de Starlink, CentiSpace, un diseño representativo de banda C y diseños representativos UHF/L/S/C/C ancha, cada uno con la URL de su fuente) o escritos en línea. Por señal: la PSD limitada en banda y las fracciones de potencia en banda, el ancho de banda de Gabor, la fluctuación de seguimiento de código early-late limitada en banda frente al C/N0 y la separación (Betz & Kolodziejski 2009) y la precisión de medición de distancia, el espacio de búsqueda de adquisición, la probabilidad de detección y el tiempo medio de adquisición serie y paralela de código, el SSC hacia y desde GPS L1 C/A, Galileo E1, GPS L5, Galileo E5a, E5b y AltBOC con la pérdida de C/N0, la tolerancia de J/S frente a CW, banda ancha y ruido adaptado a partir del código de SSC del tipo de escenario de espectro, una comparación de bandas (retardo ionosférico, pérdida en espacio libre, medición de distancia con igual C/N0 e igual EIRP, tolerancia al jammer), y comprobaciones opcionales de forma frente a una medición descrita. Ejemplos: scenarios/leo-band-trade.toml, scenarios/xona-pulsar-signals.toml, scenarios/celeste-iod-classical-pilot-signals.toml (las bandas y la configuración de señal de Celeste IOD presentadas en el taller LEO-PNT de ESA NAVISP, 2026; retirado junto con el preajuste de Celeste IOD, véase "LEO-PNT de extremo a extremo" más abajo). Notas en docs/LEO-SIGNAL.md.
  • spectrum: las bandas ahora pueden ser un diseño de señal predefinido (cada componente dibujado, limitado en banda, con C/N0 y J/S referidos al componente seguido) o una portadora y una modulación personalizadas; [[panels]] añaden cascadas sobre otros intervalos de frecuencia en una sola cronología; un jammer wideband (de barrera) se suma a las cuatro formas de onda. El informe añade bands[].tracked_power_dbw, bands[].design y panels, y una entrada not_modelled. Las bandas simples dan los mismos números que antes. Ejemplo: scenarios/multi-band-jamming-waterfall.toml.
  • navsignal incorpora la integral seno, las formas cerradas de la potencia en banda de BPSK y del ancho de banda de Gabor limitado en banda, la fluctuación early-late limitada en banda para cualquier espectro y su cota de Gabor, la forma cerrada del SSC de BPSK desplazado, el espectro AltBOC(15.10) de Galileo E5 y un analizador de etiquetas de modulación; Modulation::label imprime BPSK(1/3) como fracción.
  • Cuatro filas de la matriz: formas cerradas limitadas en banda VALIDATED (el 90,3 % de la potencia de BPSK en el lóbulo principal, la fluctuación que se reduce a la forma coherente de Kaplan & Hegarty, 0,0039564 chips a 45 dB-Hz, B_L 1 Hz, d 1 chip, T 20 ms, y a su cota de Gabor, y el autoSSC de BPSK 2/(3 R_c); la forma cerrada de Gabor y el SSC desplazado frente a su forma de Parseval se indican como comprobaciones cruzadas internas); Doppler máximo de LEO VALIDATED (Xona X1 33,2 kHz dentro de los 32 a 34 kHz publicados, Iridium a menos de 0,5 kHz de 36 kHz); MODELLED leo-signal; espectro multibanda MODELLED.

Navegación en órbita terrestre baja: enlace

• Paso LEO-PNT y presupuesto de enlace por banda: el tipo de escenario leo-pass. LEO-PNT es posicionamiento, navegación y temporización desde satélites en órbita terrestre baja (LEO). Un usuario (terrestre, marítimo, aéreo o en interior, estático o en movimiento) y uno o más satélites LEO a partir de un paso diseñado, elementos explícitos, un conjunto de elementos de dos líneas (TLE) mediante SGP4, o una constelación Walker del código de constellation-design. Por satélite, banda y época: ángulos de observación, distancia, tasa de variación y aceleración de la distancia en forma cerrada (comprobadas en cada ejecución con diferencias centrales), Doppler y tasa de Doppler, pérdida en espacio libre, EIRP (potencia isotrópica radiada equivalente) con un diagrama de satélite isoflujo, de haz gaussiano o plano, una antena de usuario de parche, atenuación gaseosa de ITU-R P.676, atenuación por lluvia de ITU-R P.838/P.618, centelleo troposférico de P.618, pérdida de penetración en edificios de ITU-R P.2109 para un usuario en interior, desadaptación de polarización, temperatura de ruido del sistema y C/N0 (relación entre portadora y densidad de ruido); el retardo ionosférico de primer orden por banda a partir de un TEC oblicuo (contenido total de electrones) de Klobuchar o de TEC vertical por debajo del satélite, y pares de bandas libres de ionosfera con su amplificación de ruido. Los satélites de Galileo o GPS se evalúan con el mismo receptor a partir de las potencias recibidas de sus documentos de interfaz, de modo que el paso LEO en forma de campana y las portadoras planas de MEO (órbita terrestre media) comparten un mismo gráfico. Una sección [iot] da el tiempo hasta la primera solución, la energía por solución y la vida de la batería según el ciclo de trabajo (MODELLED).
  • Independiente del sistema: el motor no necesita ningún preajuste. Preajustes opcionales, cada uno en su propio archivo y marcados PUBLIC (con URL), REPRESENTATIVE o WORKSHOP: multibanda genérico (UHF, L, S, C), banda C genérica, Xona Pulsar X1/X5 (arXiv 2509,19551), Iridium STL, Starlink como señal de oportunidad solo Doppler, CentiSpace, y Celeste IOD (demostración en órbita), cuyos parámetros de señal se presentaron en el taller LEO-PNT de ESA NAVISP, 2026, y residen en src/celeste_iod.rs para poder retirarse (véase "LEO-PNT de extremo a extremo" más abajo).
  • Bloques de construcción públicos en src/leo_link/ (geometría, antena, itu, iono, energía, preajustes) para que los llamen otros módulos.
  • Escenarios: leo-pass-vs-gnss-cn0, leo-indoor-uhf, leo-iot-energy, leo-pass-xona-pulsar, leo-pass-iridium, leo-pass-celeste-iod-multiband.
  • Nueve filas de la matriz. VALIDATED (6): coeficientes de ITU-R P.838-3 frente a su Tabla 5; atenuación por lluvia y centelleo de P.618-14 frente a los ejemplos de validación del Grupo de Estudio 3 de la UIT-R; pérdida de penetración en edificios de P.2109 frente al libro de cálculo del Grupo de Estudio 3; escalado ionosférico de primer orden frente a la razón de retardo de grupo de IS-GPS-200, con la pérdida en espacio libre; el Doppler máximo de un usuario estático en una órbita circular frente a la Tabla 1 de arXiv 2509,19551. MODELLED (3): el paso y el presupuesto de enlace, los preajustes y el presupuesto de solución de bajo consumo. Un tipo de escenario y seis archivos de escenario. Notas en docs/LEO-PASS.md.

Navegación en órbita terrestre baja: mensaje de navegación

• Mensaje de navegación LEO (tipo de escenario leo-navmsg, src/leo_navmsg/). El mensaje de efemérides y reloj difundido por un satélite de posicionamiento, navegación y temporización (PNT) de órbita terrestre baja (LEO), para cualquier órbita, portadora y modelo; los preajustes con nombre son datos opcionales y todas las capacidades funcionan sin ellos. Un tipo de escenario, cinco archivos de escenario y nueve filas de la matriz (tres VALIDATED, seis MODELLED). Véase docs/LEO-NAVMSG.md.
  • Contenido del mensaje: SVID, edición de datos, banda y estado de salud de la señal; semana, tiempo de la semana y un polinomio de reloj de segundo orden; las efemérides en uno de cuatro modelos (el conjunto kepleriano de 16 parámetros del OS SIS ICD de Galileo, ese conjunto más polinomios de corrección a lo largo de la traza, transversal y radial, el modelo de 22 parámetros de Liu et al. 2025 (doi 10.3390/rs17162894), o el polinomio ECEF de reloj cero de ATOMIC), y un conjunto de Klobuchar, coeficientes NeQuick-G con el nivel de ionización efectivo, y parámetros de tiempo del sistema a UTC con los casos de segundo intercalar del ICD.
  • Ajustador: una órbita de referencia integrada con gravedad zonal J2–J6 o EGM2008 y arrastre, un reloj libre o corregido con semilla, un ajuste de Levenberg–Marquardt sobre elementos no singulares, y luego polinomios de corrección por mínimos cuadrados lineales y un reloj ajustado descontando el término relativista del usuario.
  • Cuatro análisis y escenarios: leo-navmsg-fit-interval-trade (error de distancia de la señal en el espacio (SISRE) frente al intervalo de ajuste y al periodo de actualización), leo-navmsg-model-comparison (cuatro modelos, bits y el ajuste de 22 parámetros de Kshana a las altitudes de Liu et al. junto a las cifras publicadas, MODELLED), leo-navmsg-midpass-update (continuidad en cada cambio de mensaje durante un paso) y leo-navmsg-encode-decode (la propia trama binaria documentada de Kshana con CRC-24Q y un presupuesto de cuantización, un bloque al estilo RINEX-4 etiquetado como extensión de Kshana, y una tabla CSV).
  • VALIDATED: los pesos de SISRE promediados globalmente frente a la tabla publicada de órbita media y geoestacionaria de Montenbruck et al. 2018; el algoritmo de usuario de Galileo frente a RTKLIB en cuatro efemérides de difusión reales de Galileo (tests/leo_navmsg_reference.rs); CRC-24Q frente al valor de comprobación del catálogo y la trama de ejemplo RTCM 10403 1005.
  • Preajustes, un archivo cada uno con sus fuentes: Xona Pulsar y Pulsar-0, Iridium, Starlink, CentiSpace, un sistema representativo de banda C, ATOMIC y Celeste IOD (el único preajuste que usa material presentado en el taller LEO-PNT de ESA NAVISP, 2026, conservado en src/celeste_iod.rs con sus escenarios para poder retirarlo).

Navegación en órbita terrestre baja: fusión

• Posicionamiento, navegación y temporización fusionados MEO + LEO: leo-pvt, leo-ppp y ntn-positioning. Tres nuevos tipos de escenario en src/leo_fusion/, independientes del sistema: toda constelación son capas Walker, conjuntos de elementos o un preajuste de GNSS, toda señal una portadora, una tasa de chip y una envolvente de relación entre portadora y densidad de ruido (C/N0), todo presupuesto de error una sigma explícita, y los sistemas con nombre de órbita terrestre baja (LEO) son preajustes opcionales, un archivo cada uno con sus fuentes marcadas como públicas, de taller o derivadas (Xona Pulsar X1/X5, Iridium Satellite Time and Location (STL), señales de oportunidad de Starlink, CentiSpace, un sistema representativo de banda C, el modelo de efemérides de reloj cero ATOMIC, y un preajuste de la demostración en órbita Celeste de ESA cuyos parámetros derivados del taller residen en src/celeste_iod.rs para poder retirarlos).
  • leo-pvt tiene cuatro modos: posicionamiento Doppler (mínimos cuadrados por lotes sobre la tasa de variación de la distancia con estados de deriva de reloj y de velocidad, un modo de señales de oportunidad solo Doppler, la precisión de un solo paso a lo largo de la traza y transversal, y la envolvente de Doppler, tasa de Doppler y sacudida); mínimos cuadrados ponderados conjuntos GNSS + LEO con un reloj por sistema (el sesgo entre sistemas) o un desfase conocido, sigmas por medición como entradas, y el DOP frente al número de satélites LEO; cobertura polar y ártica frente a la latitud; y transferencia de tiempo LEO al Tiempo Universal Coordinado (UTC) frente al C/N0 y al oscilador del receptor con la expresión de tiempo del sistema a UTC de IS-GPS-200.
  • leo-ppp: un filtro de Kalman extendido de posicionamiento preciso de punto (PPP) flotante sobre código y fase libres de ionosfera, solo con GNSS y con aumentación LEO, con su tiempo de convergencia y una prueba de coherencia NEES (error de estimación normalizado al cuadrado) de Monte Carlo. El escenario incluido da 7,4 min con cuatro sistemas MEO y 4,8, 3,2, 2,7 y 2,3 min con 60, 96, 192 y 288 satélites LEO, junto a los 9,6, 7,0, 3,2, 2,1 y 1,3 min de Li et al. (J. Geod. 93:749, 2019) como comparación MODELLED de la tendencia.
  • ntn-positioning: posicionamiento de red no terrestre (NTN) 5G en la banda S de satélite móvil n256 de 3GPP a partir de la cota de Cramér-Rao sobre el tiempo de llegada y el Doppler.
  • Escenarios: leo-doppler-positioning, starlink-sop-doppler-positioning, meo-leo-fused-pvt, leo-ppp-convergence, ntn-5g-positioning, polar-arctic-leo-coverage, leo-timing-utc (incluidos) y celeste-iod-fused-pvt (solo de repositorio, retirado junto con el preajuste de Celeste IOD).
  • Ocho filas de la matriz: la envolvente Doppler de LEO VALIDATED frente a las cifras publicadas de Iridium (±36 kHz: 35,9 kHz, dentro del 5%) y de Xona Pulsar X1 (32 a 34 kHz: 33,6 kHz desde la capa de 97 deg, sin ensanchamiento) (tests/leo_doppler_reference.rs); posicionamiento Doppler, posicionamiento conjunto por pseudodistancias, convergencia de PPP, cotas de NTN, temporización LEO, cobertura polar y los preajustes MODELLED. Tres tipos de escenario y ocho archivos de escenario. Documentación: docs/LEO-PNT-FUSION.md.
• LEO-PNT de extremo a extremo: el tipo de escenario leo-pnt-chain y las etapas LEO conectadas entre sí. Un sistema de posicionamiento, navegación y temporización (PNT) de órbita terrestre baja (LEO) seguido desde el diseño de su señal hasta la posición del usuario, siendo cada etapa un tipo de escenario propio del motor sobre su propia tabla de escenario, con valores transferidos en el código (docs/LEO-PNT.md):
  • Las bandas de leo-pass pueden nombrar un diseño de leo-signal (signal = "xona-x5"): la banda toma el centro, el ancho de banda de transmisión y la tasa de chip del componente seguido del diseño, reparte su EIRP (potencia isotrópica radiada equivalente) entre los componentes del diseño, e informa en cada época del C/N0 (relación entre portadora y densidad de ruido) del componente seguido y de la fluctuación de seguimiento de código limitada en banda (el error de medición de distancia; el ruido del par iono_free también la usa). Una banda sin diseño da la misma salida que antes.
  • leo-pnt-chain ejecuta señal -> paso -> mensaje de navegación -> solución conjunta fusionada de leo-pvt -> leo-ppp opcional. Todo sistema LEO de la etapa de posicionamiento que los deja sin definir toma una línea de C/N0 en sin(elevación) ajustada al paso, el error de distancia de la señal en el espacio (SISRE) del mensaje: su error de representación en la órbita del satélite del paso, con un término de determinación de órbita od_sisre_m indicado, en suma cuadrática, y la portadora y la tasa de chip del diseño; los casos de posicionamiento preciso de punto (PPP) toman el SISRE. Cada traspaso se enumera con su valor y su unidad, y tests/leo_pnt_chain.rs comprueba que cada uno es igual a la salida de la etapa anterior y que los cambios en las etapas anteriores mueven las cifras posteriores. LeoNavmsgScenario::broadcast_sisre es el nuevo punto de entrada del mensaje.
  • Escenarios: leo-pnt-end-to-end (una constelación genérica a 1080 km y la señal representativa generic-l), xona-pulsar-end-to-end (la señal pública X5), ambos incluidos, y el opcional celeste-iod-end-to-end, solo de repositorio.
  • Los preajustes de Celeste IOD (demostración en órbita) de las áreas de paso, mensaje y posicionamiento fusionado residen ahora en un único archivo, src/celeste_iod.rs, que build.rs compila solo cuando existe (la bandera de configuración kshana_celeste). Sus cinco escenarios (scenarios/*celeste-iod*.toml) son solo de repositorio, de modo que eliminar ese archivo y esos escenarios retira todas las cifras presentadas en el taller LEO-PNT de ESA NAVISP, 2026, sin editar el código fuente; tests/workshop_preset_isolation.rs comprueba qué archivos pueden nombrar el preajuste o llevar los números de su plan de bandas.
  • Todo tipo de escenario LEO en la tabla de correspondencia del informe avanzado, con sus filas específicas de cada vía enumeradas solo cuando la ejecución tomó esa vía (una tasa de lluvia, un edificio, un análisis o un modo que se ejecutó). Las ventanas Doppler de leo-pvt incorporan t_s y los casos de leo-ppp incorporan t_min, de modo que ambos se animan; leo-pass y leo-pnt-chain exportan efemérides CZML, KML, GeoJSON y STK, y los demás tipos de escenario LEO indican por qué un formato no se aplica.

Navegación en órbita terrestre baja: resiliencia, áreas de interés y escenarios de usuario final

• Resiliencia de LEO-PNT, un escenario por cada área de interés del experimento y uno por cada vertical de usuario final, y docs/LEO-PNT.md como panorama de todos los tipos de escenario y escenarios LEO. Todos los escenarios se ejecutan sin ningún dato de Celeste y están incluidos.
  • leo-pass incorpora una sección [spoofer]: un spoofer falsifica, de forma autoconsistente en distancia y en tasa de variación de la distancia, las señales de una posición declarada que salta y/o se desplaza respecto de la verdadera tras un instante de inicio (por banda LEO, y la señal GNSS de MEO), con o sin ionosfera. Se ejecutan dos monitores con una probabilidad de falsa alarma indicada: coherencia de Doppler y de geometría del paso (tasas de variación de la distancia medidas frente a las previstas a partir de las órbitas y de una posición y velocidad previas independientes; un chi cuadrado de mínimos cuadrados generalizados sobre una ventana, en los canales GNSS, LEO y en todos, con ruido del lazo de enganche de frecuencia a partir del C/N0) y coherencia entre bandas (el escalón de la combinación libre de geometría corregida por el modelo de cada par de bandas LEO). El resultado da los estadísticos por época (de modo que se anima), cada par, y cuándo detecta cada monitor. Bloques de construcción en leo_link::spoof. Sección ausente, salida sin cambios.
  • Cada par de bandas de leo-pass informa también del contenido total de electrones (TEC) oblicuo que recupera su combinación libre de geometría en el máximo del paso y de la sigma de ruido de código de esa estimación (sondeo de la ionosfera). Esto añade dos campos a todo resultado multibanda de leo-pass; ninguna cifra existente cambia.
  • El modo de temporización de leo-pvt admite trace = true: entonces cada fila informa de su error de tiempo y de su sigma prevista en cada época, con las mismas extracciones, de modo que las estadísticas de las filas no cambian y la ejecución se anima y se encadena en una campaña.
  • Ahora una campaña exporta cada escenario miembro que tiene geometría (ejecuciones de fase, los escenarios base de barrido y de Monte Carlo, miembros compuestos con sus valores compartidos vinculados) como su propio conjunto de archivos, con la etiqueta del miembro en el nombre de archivo; antes, una campaña no exportaba nada. La tabla de interoperabilidad de docs/INTEROP.md cambia en consecuencia.
  • Una clave de barrido de campaña puede indexar una matriz de tablas por posición (system.2.sisre_m).
  • Escenarios de resiliencia: leo-resilience-multiband-diversity (una barrera de banda L5 de 50 MHz barrida en potencia: todas las señales de banda L caen, las señales LEO de banda UHF, S y C mantienen su C/N0), leo-resilience-js-margin (margen de J/S a partir de la potencia recibida: GPS L5, Galileo E5a y Xona X5 perdidas a -105, -100 y -95 dBW, una señal LEO genérica de -135 dBW que sigue en seguimiento a -90 dBW), leo-resilience-spoof-doppler (un salto de 30 m que la prueba Doppler solo GNSS no detecta y que la prueba sobre todos los canales detecta 105 s después del inicio), leo-resilience-spoof-monitors (cuatro spoofers frente a ambos monitores) y leo-resilience-gnss-jammed-leo-carries (GNSS bloqueado, la capa LEO de banda S y C en seguimiento, y la monitorización autónoma de la integridad por el receptor sobre la capa LEO sola da alarma en 2 de 30 épocas).
  • Escenarios de áreas de interés: leo-focus-ppp-altitude, leo-focus-ntn-bandwidth, leo-focus-iot-eirp, leo-focus-science-iono-sounding, leo-focus-data-services, leo-focus-indoor-uhf, leo-focus-fused-pnt-sisre (la resiliencia en L, S y C es leo-resilience-multiband-diversity).
  • Campañas verticales, cada una animada y exportando sus pasos LEO: leo-vertical-autonomous-vehicle, leo-vertical-rail-maritime (los escenarios marítimos y ferroviarios incluidos más LEO), leo-vertical-critical-infrastructure-timing, leo-vertical-polar-arctic, leo-vertical-5g-network-timing, leo-vertical-asset-tracking-iot. Resultados en una línea en docs/LEO-PNT.md.
  • Tres filas MODELLED de la matriz: el monitor de spoofing por Doppler y geometría del paso, el monitor de spoofing entre bandas y el sondeo de la ionosfera. tests/leo_resilience_verticals.rs comprueba los monitores (silenciosos antes del inicio, el estadístico Doppler cuadrático en un salto, el escalón ionosférico de un spoofer terrestre y ninguno en uno consciente de la ionosfera), la identidad del sondeo, la traza de temporización frente a las estadísticas de las filas, y que la exportación de una campaña es igual a la de cada miembro.
  • La página de leo-pass pasa a docs/LEO-PASS.md; docs/LEO-PNT.md es el panorama general.

Escenarios marítimos, por carretera y ferroviarios

• Escenarios marítimos, por carretera y ferroviarios. Cinco ejemplos incluidos sobre tipos de escenario existentes, de modo que los barcos, los vehículos de carretera y los trenes tengan cada uno un caso trabajado. Todas las cifras son MODELLED; ninguna está validada frente a datos medidos.
  • scenarios/maritime-strait-jamming.toml (jamming): un jammer de banda ancha de 50 W en un mástil de 30 m, a 30 km sobre aguas abiertas de un barco. Relación media entre jammer y señal (J/S) de unos 48 dB, y la disponibilidad cae de 1,00 a 0,00.
  • scenarios/maritime-port-approach-coast.toml (ins-trn-coast): un sistema de navegación inercial (INS) de grado de navegación a 12 nudos con el GNSS perdido y sin ayuda externa. Cruza 10 m tras 281 s y 100 m tras 833 s, las cifras de aproximación a puerto y de aguas oceánicas de la Resolución A.1046(27) de la Organización Marítima Internacional (IMO), usadas aquí como presupuestos.
  • scenarios/maritime-spoof-position-push.toml (spoof-detect): un spoofer de +2 dB, no alineado con la portadora, que empuja cuatro satélites para arrastrar un barco 500 m. El monitor fusionado lo detecta (puntuación 0,70 frente a un umbral de 0,50) mediante la monitorización autónoma de la integridad por el receptor (RAIM) y la monitorización de la calidad de la señal (SQM); la monitorización de potencia por sí sola no lo detecta.
  • scenarios/automotive-urban-canyon.toml (gnss-ins): un coche que atraviesa un paso inferior de 15 s y una interrupción de 60 s por un jammer junto a la carretera, frente a un presupuesto de 1,5 m de medio carril. El error cuadrático medio (RMS) fusionado durante la interrupción es de 1,9 m para una unidad microelectromecánica (MEMS) de clase automotriz y de 0,7 m para un comparador de grado táctico; en marcha libre, la unidad MEMS deriva hasta 850,8 m.
  • scenarios/rail-tunnel-coast.toml (ins-trn-coast): un INS de grado táctico en un tren a 160 km/h en un túnel. Cruza 2 m (discriminación de vía) tras 35,8 s, a unos 1,6 km de entrada, y 20 m tras 107,3 s. Esto es solo INS: el motor no tiene un modelo de odómetro, de modo que es la cota pesimista. El recuento de archivos de escenario del README pasa de 77 a 82. Los cinco están incluidos para kshana example y figuran en el playground del navegador.

Servidor del Model Context Protocol

• El servidor del Model Context Protocol (MCP) llega a todos los tipos de escenario y a todas las vistas de una ejecución: siete herramientas nuevas, catorce en total. run_scenario ya despachaba todos los tipos de escenario; lo que le faltaba a un agente era una vía hacia un escenario válido de cada tipo de escenario, y las tres salidas que la línea de comandos escribe junto a un resultado. Herramientas nuevas:

  • list_example_scenarios y get_example_scenario sirven los escenarios de referencia incluidos (la tabla de kshana example), cada uno con su tipo de escenario y la primera frase de su propia cabecera, byte a byte el archivo de scenarios/. Un escenario que está en el repositorio pero no incluido se rechaza indicando el motivo. Todo tipo de escenario salvo lunar-llr-datum (cuyo fragmento de datos solo se entrega con el repositorio) tiene al menos un ejemplo.
  • report_scenario devuelve el informe de la ejecución como JSON (notación de objetos de JavaScript) o como página HTML (lenguaje de marcado de hipertexto) imprimible (docs/REPORTS.md).
  • animate_scenario devuelve la serie temporal de la ejecución como un dibujo SVG (gráficos vectoriales escalables) animado, un reproductor HTML o fotogramas numerados, tras un resumen JSON de lo que se dibujó (docs/ANIMATION.md). Una respuesta lleva como máximo 120 fotogramas; la línea de comandos escribe cualquier longitud.
  • list_export_formats, export_interop y import_route sirven las exportaciones de interoperabilidad y la importación de rutas GeoJSON (docs/INTEROP.md): CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON, las efemérides STK (Systems Tool Kit) .e y SigMF (Signal Metadata Format), con un índice JSON de los archivos (sufijo, tamaño y SHA-256, el resumen criptográfico del Secure Hash Algorithm de 256 bits) y el archivo binario de muestras SigMF en base64.

  La biblioteca incorpora una función bundled-scenarios, desactivada por defecto, que expone la tabla de escenarios de referencia como kshana::bundled_scenarios; solo el servidor MCP la activa, de modo que la rueda de Python y el módulo WebAssembly siguen sin llevar el texto de los escenarios. Las suites de estudio (--study) siguen siendo solo de línea de comandos, porque una suite nombra archivos en disco y el servidor no lee ninguno. Las pruebas de ida y vuelta ejecutan cada herramienta nueva sobre escenarios incluidos y comprueban las cifras del motor: espectro, el sistema solar, constelaciones alrededor de la Luna y Europa, un barrido de campaña, y los tipos de escenario de señal, paso, mensaje de navegación, posicionamiento fusionado, posicionamiento preciso de punto, red no terrestre y de extremo a extremo de órbita terrestre baja (LEO). Todas las superficies que indican el número de herramientas MCP o las enumeran dicen ahora catorce, salvo la página del playground bajo web/, que se sustituye por el sitio.

kshana.dev, Kshana Studio y el README

• Un kshana.dev rediseñado. La página única del playground se sustituye por un sitio de varias páginas: Home, Missions, Capabilities, Evidence, Developers, Editions y Docs, con Kshana Studio a un clic. Todo gráfico, mapa y número del sitio es una ejecución registrada del motor de esta versión, con el escenario y un enlace que reabre la misma ejecución en el Studio; la compilación del sitio rechaza una grabación hecha por otro commit del motor. Las páginas de documentación se generan a partir de docs/ del repositorio, y las opciones de instalación a partir de sus canales. Las fuentes y las bibliotecas de scripts se sirven desde el propio kshana.dev, de modo que ninguna página solicita nada a un host de terceros. Las direcciones antiguas (/#playground, los enlaces para compartir /#ledger y /#s=<scenario>, los enlaces para incrustar /?embed=1&… y el resto) redirigen a su nuevo lugar, y una dirección desconocida recibe una página 404.
• Kshana Studio, un panel para cada capacidad. El Studio se abre en una pantalla de inicio con mosaicos de dominio y buenas primeras ejecuciones, y luego lleva una ejecución a través de cinco pasos numerados: Elegir un escenario, Fijar sus parámetros, Ejecutar el motor localmente en el navegador, Leer los resultados (primero las cifras clave, cada una con una etiqueta PASS o FAIL cuando la ejecución indica un umbral, y luego los paneles) y Compartir o exportar. Un único cuadro de búsqueda encuentra escenarios, dominios y los campos que contienen y salta al control; las ejecuciones pueden fijarse y compararse; una ruta de navegación indica dónde se encuentra; en un teléfono los pasos pasan a ser una barra de pasos. Todo tipo de escenario tiene su vista, incluida la cascada de espectro, el sistema solar, la cobertura de constelaciones, las campañas, la animación, el informe de la ejecución, las exportaciones de interoperabilidad y la cadena de órbita terrestre baja. Un enlace profundo (?scenario=…&tab=…) abre la misma ejecución en el panel indicado.
• Investigación y citación. La página Evidence enumera los cinco artículos de Kshana en arXiv (2606,22054, 2606,24210, 2607,02566, 2607,05415 y 2607,06212), cada uno con un resumen, una figura calculada por este motor, el comando que la reproduce, un enlace al Studio y BibTeX, junto con cómo citar el software. El README incorpora la misma sección de Research.
• Una página pública para Kshana Pro. docs/PRO.md y la página Editions del sitio dicen qué añade la capa propietaria Pro sobre el mismo motor (optimizador de diseño, incertidumbre y sensibilidad, dossier de misión, vigilancia de campañas, coexistencia de espectro, servicio de trabajos en las instalaciones del cliente, trazabilidad de requisitos), qué produce cada una y qué no hace. Toda cifra de Pro que muestra el sitio está indicada en esa página pública. Pro no añade ningún modelo físico, y el motor abierto sigue siendo completo y gratuito.
• Un README reescrito. Secciones breves, una imagen por sección, la marca de Kshana, dos filas de insignias, imágenes generadas de arquitectura, flujo de escenarios, cadena de órbita terrestre baja y verificación (tools/gen_readme_assets.py, que falla ante una imagen obsoleta), y capturas del Studio tomadas del Studio en ejecución por tools/capture_studio_shots.mjs. Los README de crates.io, PyPI, npm y del servidor MCP siguen el mismo diseño. El material de referencia largo se pliega o se traslada a docs/.

Cambiado#

• <scenario>.report.html es ahora el informe avanzado de la ejecución descrito en Añadido, y la línea wrote … de la CLI nombra también <scenario>.report.json. El cuadro de mando de una página al que sustituye no cambia y sigue siendo RunOutput::html_report(), que los enlaces de Python y WebAssembly siguen devolviendo. OracleKind::modelled_reason() expone la frase que docs/MODELLED-RATIONALE.md imprime para cada fila MODELLED; ese documento no cambia.
• El README dice sobre qué se apoya Kshana Pro. La sección Ediciones y la línea de Kshana Pro bajo «Soporte y servicios profesionales» indican ahora qué hacen las herramientas de ingeniería de sistemas basada en modelos (MBSE) y de programa de Pro y cuáles de las salidas publicadas del motor abierto lee (los result.json y report.json de cada ejecución, el archivo de escenario, el esquema de unidades de campo y las etiquetas de la matriz de verificación), y en qué se apoyan en el motor abierto los gemelos digitales de reloj, los estudios comparativos y los paquetes de evidencias. Solo cambia la redacción: no cambia ninguna salida del motor ni ningún número publicado.
• Compatibilidad. El enum público navsignal::Modulation incorpora una variante Mboc, lo que supone un cambio incompatible para quien lo compare de forma exhaustiva. Cambian las columnas gcrs_r_m y gcrs_v_m_s del tipo ephemeris (véase «Revisiones de números publicados»). Una ejecución se sigue reproduciendo con la versión del motor que la produjo.

Corregido#

• export_table_csv en el servidor MCP nombraba cuatro tipos como los únicos con una tabla CSV (valores separados por comas); seis la publican. La herramienta siempre devolvía la tabla de telecom-timing y de leo-navmsg (su análisis encode-decode sobre un modelo de mensaje kepler16 o kepler-rac), pero su descripción, su mensaje de rechazo y los documentos que enumeran los tipos omitían ambos, de modo que a un agente se le decía que no la pidiera. Ahora se nombran, y una prueba de ida y vuelta obtiene ambas tablas.

• La trama del mensaje de navegación en órbita terrestre baja (LEO) no tenía los mismos bytes en todas las plataformas, ni en todas las compilaciones de una misma plataforma. scenarios/leo-navmsg-encode-decode.toml codificó una trama con comprobación de redundancia cíclica 0x110315 en la compilación de lanzamiento en aarch64 macOS, 0x898BD8 en una compilación de depuración del mismo código fuente en la misma máquina, y 0x6A82D9 en la compilación de WebAssembly (WASM); leo-navmsg-celeste-iod.toml dio 0x6EDB2D de forma nativa frente a 0xC6E4F0 en el navegador. Tres causas, cada una rastreada hasta el primer valor divergente:

  • Entre plataformas. La órbita de referencia fue idéntica bit a bit en ambas; el punto de partida del ajuste no. truth::state_to_elements toma la inclinación osculatriz de un acos y el argumento del perigeo de un atan2, y las dos bibliotecas matemáticas los redondean de forma distinta en el último lugar (sobre 20.000 argumentos discrepan en 781 senos, 858 cosenos, 1.931 exponenciales y 1.899 arcotangentes de dos argumentos).
  • Entre perfiles de compilación. Una compilación optimizada en macOS fusiona un seno y un coseno de un mismo argumento en una única llamada a la rutina combinada del sistema, y su seno no es el del sin aislado en 379 de 200.000 argumentos; una compilación sin optimizar hace las dos llamadas. El tipo toma un seno y un coseno juntos en trece lugares.
  • En el reloj. El muestreador normal de rand_distr llama a exp y ln del anfitrión en sus dos ramas poco frecuentes: de cuatro millones de extracciones con semilla, tres diferían en el último bit entre la compilación nativa y la de WASM.

  El ajuste de Levenberg–Marquardt, que en este arco se detiene en su límite de 80 iteraciones y no en un mínimo, arrastra una unidad en el último lugar a campos cuantizados distintos. El tipo calcula ahora toda función trascendente mediante el nuevo src/portable_math.rs, que llama a la biblioteca libm en Rust puro (ya presente en el árbol de dependencias, ahora nombrada en Cargo.toml), compilada desde un único código fuente para todos los destinos y no una llamada a biblioteca que el optimizador reescriba: leo_navmsg::{truth, fit, elements, codec, sisre, services} y el código del escenario. Las potencias enteras de esa ruta se escriben explícitamente como elevación al cuadrado y multiplicación, porque f64::powi tiene una precisión no especificada, y el reloj de referencia extrae sus desviaciones normales de portable_math::standard_normal (método polar de Marsaglia sobre la salida bruta del generador). Las rutinas compartidas por las que se integra la órbita de referencia se escriben una sola vez, genéricas sobre la biblioteca matemática, con un punto de entrada _portable interno al crate junto al existente: la aceleración por armónicos esféricos, las aceleraciones zonal y de arrastre, las tasas seculares de J2 y el retardo de Klobuchar. Los puntos de entrada existentes no cambian ni en el último bit, de modo que no se mueve el número de ningún otro tipo. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform fija la trama completa de 171 bytes y un valor de comprobación por modelo de efemérides, en el perfil de pruebas ordinario (sin optimizar), en todas las plataformas y sin puerta de equipo de referencia; the_kind_never_calls_the_host_mathematics_library lee del disco el código fuente del tipo y falla ante una llamada trascendente inherente, ante un muestreador rand_distr o ante una llamada a un módulo que no se ha revisado. Tras el cambio, una compilación de depuración, una de lanzamiento y la de WASM producen documentos de resultados idénticos byte a byte para los cinco escenarios de leo-navmsg. Esto mueve números, y se registra aquí como una revisión. El tipo leo-navmsg es nuevo en esta versión, así que no se mueve nada publicado en una versión anterior, pero sí se mueve toda cifra de leo-navmsg, de forma nativa y en la compilación de WASM, y con ella la etapa navmsg de leo-pnt-chain: las cifras de órbita porque el ajuste parte ahora de los elementos portables, las cifras de reloj porque el reloj de referencia es otra realización del mismo proceso. docs/LEO-NAVMSG.md se regenera a partir de los nuevos resultados; su valor de comprobación publicado para el escenario de codificación y decodificación era 0x110315 y es 0x19105F (posición a 1,126 mm del mensaje exacto donde antes estaba a 0,665 mm, reloj a 0,185 mm donde antes estaba a 0,451 mm). La magnitud de los cambios en las cifras submilimétricas es la sensibilidad del ajuste, no un error de ninguno de los dos conjuntos: el ajuste no cambia y sigue deteniéndose en su límite de iteraciones.

• El remuestreo con semilla extraía índices distintos en un destino de 32 bits. Rng::gen_range sobre usize toma 64 bits del generador en un anfitrión de 64 bits y 32 bits en uno de 32, de modo que la misma semilla daba otros índices, y dejaba el flujo en otro punto, en la compilación de WASM. Tres lugares extraían así: los bootstraps por percentiles de eval_stats (bootstrap_ci, bootstrap_auc_ci), el barajado previo a cada pasada de entrenamiento en impairment_ml y la prueba de permutación en impairment_study. Ahora extraen mediante portable_math::uniform_index, que siempre muestrea como u64: exactamente lo que hacía un anfitrión de 64 bits, así que no se mueve ningún número nativo. Esto mueve números publicados del paquete WASM, y se registra aquí como una revisión: el intervalo bootstrap de quantum-anomaly-detect para el área bajo la curva (quantum_auc_ci, trade.foms[0].ci95) era [0.9901265, 0.9938305] en el navegador y ahora es el nativo [0.99035875, 0.993861].

• Nombres de archivo de efemérides STK a partir de identificadores de móvil. Un identificador de móvil que contenía un / o un espacio (una capa de constelación y un satélite, Pulsar inclined/S1-0163) hacía que la CLI entrara en pánico con --export stk; ahora cada identificador pasa por una parte de archivo segura (letras, dígitos, -, _).

• El signo de la nutación TEME→GCRS, descrito arriba en «Revisiones de números publicados» porque mueve una salida publicada.

0.28.0 - 2026-09-26#

Añadido#

• Tipo de escenario slot-timing (src/slot_timing.rs): segundos hasta que un reloj en funcionamiento libre sale de la guarda de una ranura de encaminamiento o de tareas indexada en el tiempo, todos los términos que contribuyen en ese momento con el dominante nombrado, el tiempo restante desde la última corrección y el mayor intervalo entre correcciones que mantiene el reloj dentro, descontada la latencia de la corrección. El reloj procede de un valor por defecto de su clase, de un preajuste de hoja de datos de telecom-timing, de una hoja de datos en línea (máximos de desviación de Allan, envejecimiento, coeficiente de temperatura) o de un registro de fase medido. Una superación más allá del mayor tiempo de promediado que admite la fuente se marca como extrapolada. Ejemplo incluido: slot-timing-ocxo-leo. Véase docs/SLOT-TIMING.md.
• Suelo de ruido rojo medido. La desviación de Allan solapada de un registro de fase se ajusta por mínimos cuadrados ponderados en la base de modulación de fase blanca y de frecuencia de IEEE Std 1139 (slot_timing::fit_weighted), con cada punto ponderado por sus grados de libertad equivalentes, de modo que una respuesta de holdover pueda apoyarse en el suelo propio del reloj en lugar de en la suposición de su clase. Un ajuste sin ponderar puso un suelo de ruido flicker espurio en un registro de prueba de ruido blanco y acortó en un 30 % una superación de 2.000 s.
• Validación con datos reservados de la inversión de holdover en un reloj real (tests/slot_timing_cs5071a_holdout.rs): ajustadas con el primer tercio del registro de cesio 5071A frente a máser de hidrógeno, las superaciones predichas de un sigma en seis umbrales de 0,5 a 2,5 ns quedan entre 0,84 y 1,03 de las superaciones medidas en los otros dos tercios, frente a un umbral de 1,5 fijado antes de la primera ejecución de la prueba. Un control (la desviación de Allan a un segundo leída como ruido blanco) falla por un factor de aproximadamente 1.000 y no alcanza el umbral. Nueva fila VALIDATED del registro; el flujo de trabajo realdata-clock la ejecuta ahora.
• La misma predicción en un oscilador de cuarzo real (tests/slot_timing_ocxo_holdout.rs, scripts/fetch_ocxo.sh): en un oscilador de cuarzo termostatizado medido, la predicción con datos reservados es conservadora, entre 0,59 y 0,70 de la superación medida y nunca más tarde, y en su mayor parte queda fuera del umbral de 1,5, porque el suelo de ruido de ese oscilador se redujo a la mitad durante el registro de 5,5 horas; ajustada con la propia muestra queda entre 0,98 y 1,17. El caso del cuarzo no está validado y sigue siendo MODELLED. La ejecución también puso de manifiesto un término ausente: la frecuencia de un cuarzo deriva, así que el modelo incorpora ahora la incertidumbre de la frecuencia conocida en la corrección (fix_frequency_sigma); sin él, la predicción era optimista hasta en 2,5×.
• La misma predicción en relojes atómicos en órbita (tests/slot_timing_igs_holdout.rs, scripts/fetch_igs_clocks.sh): 14 días de relojes finales del International GNSS Service para los satélites GPS Block IIF, con el protocolo escrito antes de descargar los datos. Ocho de diez satélites quedan dentro del umbral de 1,5; G25 y G30 predicen superaciones hasta unas dos veces más tardías de lo medido. El protocolo exige que todos los satélites lo superen, así que el caso orbital no está validado y sigue siendo MODELLED; el resultado queda fijado.
• Clases de reloj de cuarzo compensado en temperatura (TCXO), cuarzo termostatizado (OCXO) y patrón atómico de frecuencia de rubidio (RAFS) (ClockClass::Tcxo, Ocxo, Rafs), los componentes que vuelan en un bus comercial de satélite pequeño o en una pasarela terrestre, cada uno con cita de una hoja de datos pública (ClockClass::source). Se añaden ClockClass::ALL, id y from_id. El baseline_clock_class de quantum-trade acepta los tres identificadores nuevos. Añadir variantes a un enum público es un cambio incompatible para quien lo compare de forma exhaustiva.
• Nivel de protección de temporización para un receptor en órbita (src/orbital_timing.rs, la sección opcional spoofing del tipo slot-timing): durante cuánto tiempo puede un suplantador desde tierra alcanzar a un satélite de órbita terrestre baja en cada pasada, el arrastre que acumula un suplantador con una tasa máxima de rampa indicada antes de que el satélite salga de su alcance o se ejecute una comprobación independiente, y si cada comprobación de contacto con tierra o de enlace cruzado es independiente de ese suplantador. Se reduce exactamente a tpl::timing_protection_level_ns para un reloj sin ruido flicker, de fase blanca ni de recorrido aleatorio. MODELLED.
• Tres notas: docs/SLOT-TIMING.md (incluida la métrica de deriva con la que debería aceptarse una ranura: error de tiempo máximo absoluto, no error máximo de intervalo de tiempo ni desviación de tiempo, y por qué), docs/DECEIVED-TIME.md (una orden firmada aplicada en un tiempo engañado sigue encaminándose mal) y docs/DEPLOYMENT-TARGETS.md (dónde se ejecuta Kshana; no se ofrece un núcleo de vuelo no_std).

0.27.4 - 2026-09-26#

La versión v0.27.3 llegó a crates.io (kshana y kshana-mcp) y a PyPI, y se detuvo en npm, de modo que npm, la imagen MCP de ghcr.io, el registro MCP, el JetBrains Marketplace y kshana.dev nunca la recibieron. 0.27.4 lleva el mismo motor, con la corrección de la publicación que se describe a continuación, a todos los canales.

Corregido#

• El paso de publicación de npm nombra el tarball con una ruta explícita. npm lee un npm-dist/kshana-0.27.3.tgz sin ruta como la abreviatura de GitHub owner/repo, de modo que el trabajo de npm de v0.27.3 intentó clonar github.com/npm-dist/kshana-0.27.3.tgz y falló con «Permission denied (publickey)». El tarball en sí se había compilado y atestado. El paso publica ahora ./npm-dist/*.tgz. Todo lo posterior a npm en el orden de publicación (la imagen MCP, el complemento de JetBrains, la comprobación de paridad de canales y el sitio) se omitió, tal como está diseñado.

Cambiado#

• Los catálogos de unidades de telecom-timing y gnss-ins quedan exentos de la detección de copiar y pegar, con la misma política y la misma prueba de justificación que los demás catálogos. La puerta de calidad de SonarCloud se había puesto en rojo por duplicación en código nuevo (4,0 % frente a 3 %), y cada bloque duplicado era una fila de unidades o una entrada de máscara de ITU-T.

0.27.3 - 2026-09-25#

Añadido#

• scenarios/small-uas-jammed-nav.toml: cuánto aguanta la navegación de un dron pequeño tras sufrir jamming en GNSS. Ejecuta una unidad inercial microelectromecánica (MEMS) de clase controlador de vuelo, una Bosch BMI088, frente a una unidad de grado táctico. La señal GNSS (Sistema Global de Navegación por Satélite) es nominal durante 100 s y luego se deniega durante 60 s (jamming-demo.toml muestra por qué lo hace un inhibidor cercano). Los sesgos del BMI088 son los residuos que quedan tras la calibración de arranque, tomados de los coeficientes de temperatura de su hoja de datos (BST-BMI088-DS000-19 rev 1,9): 0,015 °/s por K para el giroscopio y < 0,2 mg por K para el acelerómetro. En el archivo se señalan dos suposiciones: un calentamiento de 10 K tras la calibración y un calentamiento continuado de 1 K por minuto en vuelo. La deriva en vuelo es el error que el filtro no puede aprender antes de que empiece el jamming, y es lo que pone fin a la navegación a ciegas. Todas las cifras son modeladas; validarlo requiere registros de vuelo de un entorno con jamming. kshana example small-uas-jammed-nav lo imprime.

• Cada sensor de gnss-ins puede fijar su propio prior de filtro ([imu_quantum.filter_prior] o [imu_classical.filter_prior], con sigma_accel_bias y sigma_gyro_bias). El valor por defecto no cambia, de modo que todo escenario existente da el mismo resultado. El sesgo residual del giroscopio de una unidad de grado de consumo queda unas 26 sigmas fuera del valor por defecto de grado táctico, donde el filtro nunca lo aprendería. Se rechaza un prior que no sea finito y positivo, y el resultado repite el prior cuando se ha fijado uno.

• kshana example [<name>] entrega a quien usa el registro un escenario que ejecutar. Quien usa cargo install kshana tiene el ejecutable y ningún directorio scenarios/, así que el primer comando que daba cada guía de inicio rápido le fallaba. La interfaz de línea de comandos (CLI) incorpora ahora los 75 escenarios de referencia que se ejecutan por sí solos, byte a byte, compilados desde scenarios/ (src/bundled_scenarios.rs; la tabla reside en el binario de la CLI, así que ni el wheel de Python ni el módulo de WebAssembly crecen). kshana example los enumera; kshana example clock-holdover > clock-holdover.toml escribe uno. Los otros dos archivos son solo del repositorio: lunar-llr-datum lee datos archivados de telemetría láser lunar que se distribuyen únicamente con el repositorio, y quantum-pnt-demonstrator.suite es un manifiesto de estudio que ejecuta tres archivos hermanos con --study. Pedir cualquiera de los dos explica por qué y termina con 2 en lugar de imprimir algo que no puede ejecutarse por sí solo. tests/cli_first_run.rs mantiene la tabla alineada con el directorio en ambos sentidos, de modo que un archivo de escenario nuevo que ni está incluido ni se nombra como solo del repositorio falla.

• Cada figura de mérito de un resultado de reloj, órbita, hybrid o fusion indica ahora si es VALIDATED o MODELLED, en el propio resultado. El documento de resultados incorpora un bloque figure_tiers, siempre su última clave. Enumera cada cifra notificada (por ejemplo quantum.fom.timing_p95_ns) con su nivel (VALIDATED significa comprobado frente a una referencia independiente externa, MODELLED significa un modelo de primeros principios que se prueba internamente) y la fila de la matriz de verificación de la que se lee el nivel. El nivel procede de src/verification.rs a través de src/fom_label.rs, de modo que no hay una segunda tabla que se desfase. Antes, las palabras «validated» y «modelled» aparecían cero veces en un resultado de clock-holdover, y quien leyera el JSON (JavaScript Object Notation) en bruto no tenía forma de distinguirlos. Las cifras de posición de hybrid y fusion no tienen una fila de la matriz que las posea, así que se enumeran bajo untiered en lugar de asignarles un nivel. El bloque no contiene números. Está demostrado que es aditivo, no supuesto: quitarlo devuelve el documento anterior al cambio byte a byte, para los cinco tipos (una prueba del motor), y los dos arneses golden (tests/registry_golden.rs, tests/cross_platform_golden.rs) eliminan ahora exactamente esta clave, y solo cuando es la última, y luego calculan el hash del resto frente a sus constantes congeladas sin cambios. Una lista en cada arnés fija qué escenarios deben llevar el bloque, de modo que la exclusión no pueda ampliarse sin que se note.

• Un tipo telecom-timing responde en las unidades de un ingeniero de temporización: error de tiempo, error máximo de intervalo de tiempo (MTIE) y desviación de tiempo (TDEV), cada uno con un PASS o un FAIL y un margen frente a las máscaras del Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones (ITU-T). Las máscaras se transcriben de las ediciones en vigor: G.8272 (07/2025) para las clases A y B del reloj de referencia de tiempo primario (PRTC), G.8272.1 (2024) Amd. 1 (07/2025) para el PRTC mejorado en modo bloqueado y en holdover (incluida su envolvente de error de tiempo, que sube de 30 ns a 100 ns a lo largo de un periodo de holdover que fija el tiempo que el reloj estuvo bloqueado), G.8273.2 (2023) Amd. 2 (11/2025) para los relojes de frontera y esclavos de tiempo de telecomunicaciones, clases A a D, y G.8271.1 (2022) Amd. 3 (05/2025) para los límites de red en el punto de referencia C. Toda entrada que esas Recomendaciones dejan «para estudio posterior» está ausente, no estimada, y docs/TELECOM-TIMING.md enumera cada número con su tabla o cláusula y cada elemento que se dejó fuera. El informe también da el tiempo hasta superar cada presupuesto de error de tiempo: por defecto, el valor por defecto de holdover del ePRTC de 100 ns, una asignación de holdover de red de 400 ns, el límite del punto C de 1.100 ns y el requisito extremo a extremo de clase 4 de 1,5 microsegundos.

  La entrada es un holdover sintético o una serie propia. El sintético usa uno de cuatro preajustes de oscilador (un oscilador de cuarzo termostatizado, un patrón de rubidio, un patrón de cesio y un reloj atómico a escala de chip), cada uno con las cifras de estabilidad, envejecimiento y temperatura de una hoja de datos de Microchip concreta. Cómo esas cifras se convierten en ruido de frecuencia blanco, flicker y de recorrido aleatorio, en envejecimiento y en un término de temperatura se indica en cada informe y se etiqueta como MODELLED. Una serie propia son pares [time_s, time_error_ns], en línea (así se ejecuta en el navegador) o, en las compilaciones nativas, desde un archivo de valores separados por comas. La tabla MTIE/TDEV, con el límite de cada máscara seleccionada a su lado, se escribe como el artefacto CSV de la ejecución.

  scenarios/telecom-prtc-holdover-24h.toml es un holdover de rubidio de 24 horas con envejecimiento, flicker y un ciclo diario de temperatura: su mayor error de tiempo es 603,2 ns, cruza 100 ns a los 8.206 s de la pérdida y se mantiene dentro de 1,5 microsegundos todo el día, y no satisface la envolvente de holdover del PRTC mejorado, como corresponde a un reloj que no es de clase cesio. scenarios/telecom-tie-ingest.toml muestra la entrada en línea. El MTIE y el TDEV que informa el tipo se comprueban con el paquete allantools sobre una serie de holdover de 2 048 muestras incorporada al repositorio, exactamente para el MTIE y con 1.1e-15 para el TDEV, de modo que la matriz gana una fila VALIDATED y dos MODELLED (la transcripción de las máscaras y los preajustes) y queda ahora en 171 filas: 65 VALIDATED, 102 MODELLED, 4 PARTNER. La cobertura de unidades de campo pasa de 60 de 61 tipos a 61 de 62, y de 1.742 a 1.788 campos descritos. El tipo es nuevo y aditivo: no se mueve ningún escenario existente, fijación ni cifra publicada.

• El playground ejecuta el motor en un Web Worker en segundo plano, de modo que un escenario lento ya no congela la página. web/engine-worker.mjs aloja el motor de WebAssembly y web/engine.mjs le reenvía toda ejecución de escenario: ejecuciones, barridos de parámetros y las exportaciones SP3 / OMM / OEM / CSV. Una ejecución que dura más de 150 ms muestra un estado de ocupado (Run desactivado, «Running… N s») y un botón Cancel que termina y vuelve a crear el worker; un navegador que no puede iniciar un worker de módulo recurre a la antigua ruta del hilo principal. cislunar-arc-recovery, que se dejó fuera del catálogo porque congelaba la página, vuelve a estar en él, etiquetado como lento: tarda unos 13 s en Chrome (cuatro llamadas al motor de unos 3 s cada una), durante los cuales la página sigue respondiendo.

• Cada magnitud notificada de cislunar-observability lleva ahora una unidad, una clase de procedencia y una definición: es el penúltimo tipo de la lista de exenciones de todo el crate. Los 41 campos numéricos del documento RELEASED están descritos, de modo que la cobertura de unidades de campo pasa de 59 de 61 tipos a 60 de 61 y de 1.698 a 1.742 campos descritos, con el trabajo pendiente sin definición sin cambios en 239.

  Esto estaba bloqueado por la fijación que congela el documento publicado, que nombraba units como una clave que el documento nunca debía ganar. Añadir una habría supuesto eliminar esa aserción y volver a establecer la línea base de tres hashes en tres archivos, algo indistinguible de encubrir una regresión. En su lugar, las dos fijaciones que miden este documento demuestran ahora que la adición es aditiva: cada una retira de nuevo el bloque units y vuelve a calcular el hash frente a la constante congelada antes de que existiera el bloque, y ambas constantes no cambian. Una mutación confirma que la garantía es real: si se mueve un valor publicado y se restablece la línea base del hash del documento completo como haría una corrección descuidada, la retirada y el nuevo cálculo del hash siguen fallando. La tercera fijación, en el arnés genérico del registro golden, se restablece en línea con las seis hermanas que se restablecieron por exactamente este motivo, y su literal expect_summary, que sí contiene valores, no se mueve.

• realtime-frame-eop informa de con qué verdad de referencia se puntuó cada fila de orientación de la Tierra y con qué frecuencia se activó la alternativa. table3_joint_eop[].{ut1, polar_motion,combined} ganan truth_source y truth_fallback_rows. El suelo final se puntúa frente al final del Bulletin B y solo puede usar épocas que publiquen uno; cada fila dN se puntúa frente a truth_pm()/truth_ut1(), que recurren al valor rápido del Bulletin A. En el extracto incluido de 2026 eso son 12 de 31 muestras a un día, frente a 0 en el suelo, de modo que la fila del suelo y las filas de predicción contiguas se apoyan en una verdad de referencia mensurablemente distinta, algo que el informe ahora declara en lugar de dejarlo para inferirlo de un recuento de muestras que sube donde los horizontes anidados dicen que no puede.

• moonlight-service-volume emite una línea base kepleriana de tamaño equiparado. ephemeris_comparison.keplerian_matched vuelve a ejecutar la constelación ilustrativa con el número de satélites propio del conjunto RETRIEVED, y solo está presente cuando los números difieren. El número forma parte de la geometría de ese diseño (RAAN y anomalía media se reparten ambos como 360k/n), de modo que sin él un conjunto recuperado de cinco satélites se puntuaba frente a uno ilustrativo de ocho y el diseño se confundía con el tamaño. Para el conjunto de referencia LANS de cinco satélites, 8,68 de los 14,24 puntos de la brecha de cobertura resultan ser los tres satélites que faltan y solo 5,56 puntos el diseño; para las cuatro naves que de verdad están en órbita lunar, un conjunto de cuatro satélites diseñado a propósito alcanza el 4,86 % donde ellas alcanzan el 0 %. Una prueba fija que la fila equiparada es una constelación reconstruida y no la configurada con otra etiqueta, que es como se escribió al principio y lo que entonces informaba la ejecución.

• Nueve tarjetas de capacidades en el sitio público, que cubren 22 filas de la matriz de verificación que se publicaron sin una tarjeta a nivel de producto. El motor había acumulado una familia de capacidades (la comprobación ARAIM frente a vectores de referencia publicados del Working Group C, la geometría real de constelaciones lunares recuperadas, el contorno de denegación lunar con una banda de C/N₀ medida, el paso de la planificación VLBI a la covarianza de estación, el traspaso óptico y de RF con inyección de fallos entre modalidades, la predicción en tiempo real de la orientación de la Tierra frente al Bulletin A archivado, el reparto de apertura entre navegación y comunicaciones, la navegación a ciegas INS/TRN y la cobertura de unidades y procedencia), cada una con una fila de la matriz y un escenario incluido, y ninguna nombrada en kshana.dev. La cobertura de tarjeta a fila pasa de 72 de 168 filas a 94.

• Ocho escenarios añadidos al catálogo del playground. El botón Run de una tarjeta de capacidad solo aparece cuando web/app.js también contiene el archivo; seis tarjetas nombraban un escenario que no contenía, de modo que se mostraban sin forma de ejecutarlas; una de ellas, la referencia de telemetría láser real, estaba en ese estado desde que se publicó. tests/scenario_examples_doc_sync.rs controla ahora la invariante en ambas mitades: el destino run de una tarjeta debe estar incluido en scenarios/ y ofrecido por el catálogo. Probado por mutación frente a ambos modos de fallo.

• moonlight-service-volume emite su geometría por satélite como <scenario>.table.csv cuando se configura un sitio de exportación (G11). Es el mayor array que publica el crate (2304 filas en la tabla conjunta de comunicaciones y navegación publicada) y solo llegaba a los consumidores dentro de JSON, la forma que truncó la curva de 57 puntos de un escenario hermano a 23 puntos bajo una columna que afirmaba contenerlos todos. Una fila por enlace, el número de filas en la línea de cabecera, las columnas de antena presentes solo cuando se configuró una antena. Una ejecución sin sitio de exportación no cambia ni un byte y no escribe ningún archivo.

• El SBOM describe ahora lo que se distribuye: 60 componentes pasaron a ser 66. scripts/gen-sbom.sh enumeraba todos los paquetes de la resolución con las características por defecto, incluidas las dev-dependencies. Eso incluía sgp4 y chrono, crates solo de prueba que no se compilan en ningún artefacto, en la lista de materiales, y dejaba fuera la cadena --features python que enlaza el wheel de PyPI (pyo3, pyo3-ffi, pyo3-macros, pyo3-macros-backend, pyo3-build-config, portable-atomic, target-lexicon, heck), que es la frontera de funciones externas de ese wheel. El script recorre ahora el grafo de resolución desde el paquete kshana solo por aristas normales y de compilación, sobre la unión de los conjuntos de características por defecto, python y wasm (el paquete de npm lleva este mismo SBOM), para todas las plataformas de destino. El veredicto fijado de ajuste a la norma de CycloneDX se restablece como nueva línea base mediante su generador incorporado al repositorio: 60 → 66 componentes, 53 → 60 expresiones de licencia compuestas, y sigue sin haber errores de esquema una vez que estas se colocan en la forma estándar expression.

• La tabla CSV de reproducibilidad llega a todas las puertas de entrada, no solo a la CLI y al wheel de Python. El servidor MCP gana una séptima herramienta, export_table_csv, que ejecuta un escenario y devuelve la tabla estable byte a byte que escribe la CLI como <scenario>.table.csv, o un error que nombra los tipos que publican una (realtime-frame-eop, lunar-time-budget, lunar-jamming y moonlight-service-volume solo cuando se fijan export_site_lat_deg + export_site_lon_deg). El módulo de WebAssembly gana table_csv, que devuelve el mismo texto o undefined. La prueba de ida y vuelta de MCP y las pruebas del enlace de Python fijan ahora el CSV devuelto byte a byte frente a tests/golden/realtime-frame-eop.csv, y fijan que RunOutput.write_csv devuelve los bytes escritos, y 0 sin crear ningún archivo para un tipo sin tabla. Toda superficie que indica el número de herramientas de MCP o las enumera dice ahora siete.

• run_all en el módulo de WebAssembly: una ejecución del motor para todas las salidas. run, chart_svg, summary y table_csv ejecutan cada una el escenario desde cero, de modo que el playground pagaba cuatro ejecuciones completas por clic: unos 12 s en lugar de 3 s para cislunar-arc-recovery en un navegador. run_all devuelve {json, svg, summary, csv} a partir de una sola ejecución, y el playground la usa ahora. Coincide byte a byte con las cuatro llamadas separadas.

Corregido#

• REVISIÓN: el acoplamiento del sesgo del giroscopio en el filtro GNSS/INS tenía el signo equivocado, y cambian las cifras de corte de gnss-ins. El filtro de Kalman extendido (EKF) de estado de error mantiene ambos sesgos inerciales como residuos (valor verdadero menos la estimación en curso, realimentados sumando). La columna del acelerómetro impulsaba el error de velocidad con +C_b^n b_a, pero la columna del giroscopio impulsaba el error de actitud con −C_b^n b_g. Un sesgo residual del giroscopio hace girar en realidad la actitud calculada en +C_b^n b_g, de modo que cada estimación del sesgo del giroscopio empujaba en el sentido equivocado. El paquete solo se mantenía estable porque su prior por defecto del sesgo del giroscopio (1e-4 rad/s, 1 sigma) era lo bastante estrecho para mantener quietos esos estados. Con un prior más amplio el filtro divergía incluso cuando el sesgo real del giroscopio era cero: 93 m de error fusionado en el corte pasaron a ser 4,3 km. Las cifras publicadas de scenarios/gnss-ins.toml cambian como sigue:

  gnss-ins.toml	antes (≤ 0.27.2)	después
  IMU de átomos fríos, RMS del corte fusionado	96,1 m	1,9 m
  IMU de átomos fríos, navegación a ciegas dentro de especificación (50 m)	30 s	60 s (todo el corte)
  IMU táctica, RMS del corte fusionado	62,5 m	3,1 m
  IMU táctica, navegación a ciegas dentro de especificación (50 m)	37 s	60 s (todo el corte)

  Las cifras en funcionamiento libre (130,7 m y 314,3 m) no cambian; nunca usaron el filtro. La lectura anterior del paquete, según la cual la navegación a ciegas fusionada está limitada por un suelo de actitud en el traspaso y por tanto no mejora con un sensor mejor, era un artefacto de este error y se retira. Con sesgos constantes y sin ruido, el filtro los aprende mientras hay GNSS, de modo que la navegación a ciegas fusionada es un mejor caso. La referencia externa de filterpy (tests/gnss_ins_sensor_fusion_reference.rs) solo comprueba las actualizaciones de medida, por lo que nunca vio la propagación. Dos pruebas comprueban ahora el signo directamente y ambas fallan con el antiguo. La primera, en closed_loop.rs, introduce un sesgo residual conocido del giroscopio a través del strapdown y exige que el filtro prediga el error de actitud resultante con una diferencia de 2 % como máximo. La segunda exige que un prior amplio aprenda un sesgo del giroscopio de 1e-3 rad/s y se mantenga dentro de 6 m. El golden multiplataforma de gnss-ins se vuelve a fijar por este motivo y por ningún otro.

• Cada guía de inicio rápido de los registros se ejecuta ahora tal como está escrita en una máquina limpia. Medido antes de este cambio, los ejemplos de crates.io y de PyPI (Python Package Index) leían scenarios/clock-holdover.toml, que una instalación desde el registro no tiene, y el ejemplo de npm fallaba en Node.js con TypeError: fetch failed, porque el init() del paquete obtiene su binario de WebAssembly y el fetch de Node no puede leer un archivo local. Ahora:

  • README.crates.md y README.pypi.md llevan ese escenario en línea, como ya hacía README.npm.md. El bloque de Rust es un programa completo con su propio main, porque la línea # Ok::<…> oculta para rustdoc con la que terminaba se muestra en crates.io y no compila al pegarla. tests/readme_code_fences_doc_sync.rs lo sigue compilando byte a byte, y ahora también rechaza una línea oculta en el bloque.
  • README.npm.md separa el navegador de Node.js y ofrece una receta para Node que lee el binario del disco y lo pasa a initSync. La prueba de sincronización de documentos acepta initSync como el cargador que genera wasm-bindgen.
  • Los tres incorporan el escenario con sus cadenas de procedencia sin abreviar, de modo que el hash del escenario es 5ba83a232b94 en todas las superficies. El ejemplo de npm las abreviaba, lo que le daba un hash distinto del de la CLI.
  • Reproducido a partir de compilaciones locales de este árbol: un proyecto nuevo de cargo new con una dependencia por ruta del crate empaquetado compiló y ejecutó el ejemplo de Rust; un wheel compilado con maturin a partir de los fuentes empaquetados, instalado en un entorno virtual nuevo, ejecutó el ejemplo de Python; y el paquete de wasm-pack --target web, empaquetado e instalado con npm, ejecutó la receta de Node. Los tres imprimieron la misma línea de resumen.

• cargo run -- <scenario.toml> funciona desde un clon. Cargo.toml fija default-run = "kshana". Sin ello, cargo se negaba con «could not determine which binary to run», lo que ocurría con cada línea cargo run -- de la documentación.

• Los errores del primer minuto de la CLI dicen qué hacer a continuación. Una ruta de escenario que no existe añade ahora una indicación que apunta a kshana example, y un segundo argumento posicional imprime el texto de uso además de nombrar el argumento. --help, --version, el error de opción desconocida (salida 2) y el ok: de una línea de --validate en caso de éxito ya estaban en main. tests/cli_first_run.rs los cubre ahora todos, ya que antes ninguna prueba ejecutaba el binario para ninguno de ellos.

• list_kinds() en Python está documentado como que devuelve una única cadena JSON, no una lista. Devuelve los mismos metadatos que scenario_kinds(), serializados, de modo que iterarla recorre caracteres. Conserva su retorno de cadena para no romper a los llamadores existentes. kshana.pyi, el comentario de documentación del enlace, docs/PYTHON_API.md y README.pypi.md lo indican ahora y remiten a scenario_kinds().

• Los tres README de los registros desarrollan cada abreviatura en su primer uso. PNT se desarrolla ahora en el eslogan, donde aparece por primera vez, y CLI, TOML, JSON, SVG, CSV, CSAC, HTML, URL y API se desarrollan en los archivos que los usan. El encabezado de la tabla de referencias independientes ya no dice «CI-gated» antes de que se defina CI.

• Se corrigió una cifra publicada: la disponibilidad de ARAIM de doble constelación sobre los TLE de GPS + Galileo de Celestrak incorporados al repositorio. docs/CAPABILITY.md indicaba que agrupar Galileo eleva la disponibilidad de 0,21 a 0,67 con un VAL de 12 m y que el modo robusto a fallos de constelación está limitado con solo dos constelaciones. Eso procedía de tests/araim_dual_real_data.rs propagando cada satélite desde su propia época de TLE (parse_propagators descarta la época), y las épocas de esos archivos abarcan 70,6 h (GPS) y 335,7 h (Galileo), de modo que los satélites estaban en instantes mutuamente inconsistentes. La prueba conserva ahora cada época (parse_tle) y evalúa cada satélite en un mismo instante UTC común, la última época de TLE del conjunto (2026-06-07T07:21:04). La disponibilidad medida sobre la misma cuadrícula de 24 h y 289 muestras pasa a ser 0,993 solo con GPS (era 0,208), 1,000 agrupada (era 0,671) y 0,990 en doble robusto a fallos de constelación (era 0,031); en el límite APV-I el modo doble pasa de 0,180 a 1,000. La conclusión se invierte: en un cielo consistente, dos constelaciones sostienen la hipótesis de fallo de constelación con un VAL de 12 m. Se obtienen las mismas cifras con la primera época de TLE como referencia. Una autocomprobación de la prueba fija su bucle de disponibilidad muestra a muestra a araim_dual_constellation_availability, de modo que la única diferencia es la alineación temporal. docs/CAPABILITY.md y docs/REAL_TLE_GUIDE.md §3 llevan las nuevas cifras; la entrada de 0.13.0 de más abajo se deja como se publicó.

• Las superficies públicas ya no anuncian RINEX 4 como validado. El motor rechaza ahora un archivo de navegación RINEX 4 por su nombre en lugar de decodificarlo mal, pero la cuadrícula de normas seguía mostrando una tarjeta «RINEX 3 / 4» con una etiqueta validated, ligada a la evidencia RINEX 3 del analizador de navegación. La tarjeta es ahora «RINEX 3», y el README, docs/CAPABILITY.md, docs/STANDARDS.md, ROADMAP.md y el resumen de capacidades indican lo que es cierto: los archivos de observación RINEX 3.0x se analizan, se espera que el formato de observación 4,00 también, pero no se ha leído con el código ningún archivo 4,00, y los archivos de navegación RINEX 4 se rechazan.

• --validate indica cuándo «ok» significa que no había nada que comprobar. Aproximadamente dos tercios del catálogo no publican ningún campo obligatorio (esos paquetes ejecutan su configuración de referencia desde un cuerpo vacío), de modo que el lint solo podía imprimir «ok» para ellos, con las mismas palabras que usaba tras comprobar seis campos. La línea de éxito indica ahora el número de campos obligatorios que encontró presentes, o que el tipo no exige ninguno.

• scripts/gate.sh rechaza un REPEAT o TEST_THREADS no numérico. Con bash 3,2, REPEAT=no hacía que la comparación numérica diera error y se evaluara como falsa, de modo que la puerta anunciaba «repeatability loop SKIPPED (REPEAT=0)» para un valor que no era 0 y aun así escribía un recibo. Ahora ambos parámetros terminan con 2 salvo que sean enteros simples.

• La MSRV se indica como 1,85 en todos los lugares donde una persona la lee. Cargo.toml pasó a 1,85 en la última versión; la insignia del README, el texto de instalación y de resolución de problemas, codemeta.json y la propia justificación del crate MCP seguían diciendo 1,75.

• RunOutput.__repr__ en el enlace de Python informa de bytes, no de «chars». Imprimía len() de cadenas UTF-8, que es un recuento de bytes: 710 «chars» para una tabla de 708 caracteres.

• El README ya no documenta --study --study-name juntos. --study-name es un indicador de un solo escenario, ignorado con --study (el binario avisa). Los dos ejemplos para copiar y pegar de README.md y README.crates.md muestran ahora solo el comando de estudio.

• La evidencia de estabilidad de reloj del sitio indica ambas tolerancias observadas. La serie de cesio 5071A se reproduce hasta ≤ 3e-5 y PHASE.DAT hasta ≤ 5e-5; el párrafo daba 3e-5 para ambas.

• Dos archivos de salida del motor ya no se rastrean. scenarios/quantum-pnt-demonstrator.study.{json,html} fueron estampados por el motor 0.20.0 con todas las figuras de mérito vacías, y el propio comando de estudio del README los sobrescribía, ensuciando el árbol y bloqueando la puerta de envío. *.study.json / *.study.html se ignoran ahora como las otras cuatro salidas del motor.

• Un barrido de semilla en el playground ya no falla en cada ejecución. El barrido recorría linealmente el parámetro entero seed (1, 10,9, 20,8, …), y el motor, al leerlo como u64, rechazaba cada valor fraccionario. Los parámetros enteros recorren ahora números enteros distintos.

• Cada descarga del playground dice qué motor y qué entrada la produjeron. Unos pocos tipos (p. ej. realtime-frame-eop) no emiten engine_version ni scenario_hash, así que sus descargas se llamaban simplemente kshana-csv.csv. El nombre recurre ahora a la versión del motor cargado y a una huella FNV-1a-64 de 12 caracteres hexadecimales del texto del escenario.

Cambiado#

• El crate publicado tiene menos de la mitad de su tamaño anterior, y cargo install kshana compila solo la CLI. El paquete incluía los artículos, sus paquetes de envío, los artefactos de las figuras de los artículos, los cuadernos, docs/, los scripts de mantenimiento y los programas de ejemplo. Ninguno de ellos lo compila la biblioteca ni la CLI. También incluía los tres generadores internos de src/bin/ (crossover_study, gen_validation_artifacts, validation_report), de modo que una instalación desde el registro compilaba e instalaba cuatro ejecutables, tres de ellos útiles solo dentro de un checkout. Esos árboles y los tres fuentes de generador quedan ahora excluidos. Cargo enumera los binarios de un paquete a partir de los archivos que contiene, así que el manifiesto publicado nombra solo kshana. En un clon los generadores se siguen encontrando automáticamente, de modo que cargo run --bin <name> y el trabajo de versión que ejecuta validation_report no cambian. Medido con cargo package: 763 archivos, 16,7 MiB, 6,8 MiB comprimidos antes; 591 archivos, 10,5 MiB, 3,0 MiB comprimidos después. Su compilación de verificación, que compila solo los archivos empaquetados, pasa. cargo install --path sobre el crate empaquetado instaló un ejecutable, kshana.

• Una salida que un ingeniero de temporización puede leer: se acabó p95 0.0ns, se acabó security 0.000 sin ataque, y los recuentos del sitio coinciden con los README. Es una revisión de presentación. No cambia ningún número publicado; los valores JSON son idénticos, como demuestran los hashes golden de más arriba.

  • El resumen de una línea imprimía el error de temporización del percentil 95 (p95) del reloj óptico como 0.0ns mientras la tabla contigua mostraba 1.20e-4 ns. Una cifra de temporización distinta de cero demasiado pequeña para un decimal se imprime ahora con tres cifras significativas (p95 1.20e-4ns); un cero exacto sigue imprimiéndose como 0.0. El informe HTML (HyperText Markup Language), la tabla comparativa del estudio y el informe descargable del playground usan la misma regla, de modo que ninguna cifra distinta de cero se imprime tampoco como 0.000.
  • security es una cota analítica de detectabilidad de suplantación que solo significa algo frente a un ataque configurado. Los tipos clock, orbit, hybrid y fusion no configuran ninguno, así que su resumen imprime ahora security n/a (no attack) en lugar de un número como 0.000 que se lee como una detección fallida. El valor permanece en fom.security, marcado applicable: false con el motivo en figure_tiers, y las tablas del informe muestran «not applicable». El tipo spoof sigue puntuando la detección.
  • Dos fijaciones de resumen en tests/registry_golden.rs se movieron exactamente por estos dos motivos y por ningún otro: golden_clock (el p95 cuántico y ambos valores de security) y golden_orbit (ambos valores de security; sus valores p95 son exactamente cero). Sus hashes de documento completo no se movieron. Los resúmenes esperados del README, de los tres tutoriales y de sus escenarios didácticos se actualizan para coincidir, y tests/tutorials.rs comprueba las copias didácticas frente al motor.
  • El recorrido guiado del playground ya no se abre en la primera carga. Su modal capturaba los primeros clics y su foco desplazaba la página lejos de donde había aterrizado el visitante. Se inicia desde el botón «Take the 60-second tour» o desde el botón flotante Tour.
  • La página ya no se desplaza hacia los lados en un teléfono. A 390 px, la fila de la marca y el botón de GitHub sumaban unos 410 px de contenido, un desbordamiento de 4 px; la cabecera encaja ahora desde 320 px, y la tabla de figuras de mérito se desplaza dentro de su propia caja en lugar de ensanchar la página.
  • El explorador de capacidades encabezaba con su propio recuento de tarjetas («46 capability cards … 17 backed by an external oracle») junto a README que dicen 64 de 168. Ahora encabeza con la matriz de verificación, leída del web/data/verification-matrix.json generado (la misma matriz a la que están fijados los recuentos del README), y nombra después las tarjetas como la capa de resumen que son. web/counts.test.mjs, un paso nuevo del flujo de integración continua (CI), comprueba la aritmética y contrasta README.md y las descripciones de la página; tests/web_validation_counts_doc_sync.rs fija el cableado desde el lado de Rust.

• La descripción pública encabeza ahora con temporización y holdover, el dominio mejor validado. La apertura del README y docs/POSITIONING.md presentan Kshana como un motor de evidencias de resiliencia PNT abierto, reproducible y con etiquetas de procedencia: primero la temporización y el holdover de infraestructuras críticas (los estimadores de Allan, Allan modificada, desviación de tiempo y error máximo de intervalo de tiempo, y la inversión de la varianza de la deriva en holdover, son las filas VALIDATED que lo respaldan), lo cuántico como un método neutral de comparación cuántico frente a clásico cuyos resultados se etiquetan MODELLED, y la navegación lunar / cislunar y de espacio profundo como capacidades mantenidas y no como titular. Ambas páginas dicen ahora lo que Kshana no es (no es un simulador de señal de radiofrecuencia ni un banco con hardware en el bucle, ni un sustituto de MATLAB/Simulink, STK u Orekit) y remiten al nuevo tipo telecom-timing y a docs/TELECOM-TIMING.md. Se elimina la antigua frase «no existe una buena herramienta abierta»: una búsqueda que no encuentra nada no es evidencia de que no exista nada. ROADMAP.md gana un orden de prioridades sin fechas (primero la temporización, segundo la comparación cuántica, lo lunar mantenido) y elimina tres elementos obsoletos (las sistemáticas de Coriolis y de desplazamiento lumínico, las condiciones iniciales NRHO y el escenario lunar, todos ya publicados); la línea del README «Coriolis y desplazamiento lumínico siguen en la hoja de ruta» se corrige de la misma manera.

• docs/CAPABILITY.md dejó de quedarse corto. La fila de marcos fijos a la Tierra decía «none» mientras la matriz califica GCRS→ITRS como VALIDATED; ahora dice «full», y la fila de marcos básicos registra la comprobación cruzada con ANISE como entregada. El modo guiado figuraba como hoja de ruta; el playground ha publicado controles deslizantes guiados y un recorrido guiado. Un barrido frente a src/verification.rs corrigió cinco filas más que eran anteriores a sus validaciones: el modelo de fuerzas de Cowell y la determinación de órbita por lotes/secuencial frente a Orekit 12,2, los pases de estación terrestre frente al detector de elevación de Orekit, el núcleo de dilución de la precisión frente a gnss_lib_py, y la importación OEM frente al analizador independiente oem; la fila de verificación y validación nombra ahora las protecciones que comprueban que existe cada prueba citada.

• El glosario explica qué dice un archivo de resultados. docs/GLOSSARY.md incorpora entradas en lenguaje llano para los términos de salida (holdover, p95, integridad, la puntuación de seguridad, PDOP, sigma_y, q_wf), los términos de temporización de telecomunicaciones (error de tiempo, max|TE|, cTE, dTE, MTIE, TDEV, PRTC, ePRTC, T-BC, T-TSC, OCXO, CSAC) y los tres niveles de evidencia (VALIDATED, MODELLED, PARTNER).

• Las abreviaturas se desarrollan en su primer uso en todos los documentos públicos escritos a mano. El README y 24 archivos de docs/ tenían varios cientos de abreviaturas usadas antes de su expansión, o sin ella; cada una se expande ahora donde aparece por primera vez en ese archivo. Los tres archivos generados (docs/VERIFICATION-MATRIX.md, docs/MODELLED-RATIONALE.md, docs/SCENARIOS.md) se dejan como están: se escriben a partir de src/verification.rs y api::list_scenario_kinds(), de modo que su redacción tiene que cambiar en el origen.

• La cobertura de líneas tiene una medición de registro. docs/COVERAGE.md registra 95,63 % (37.697 de 39.419 líneas) del trabajo coverage de CI en b1d350d, y tests/coverage_figure_doc_sync.rs fija a él las cinco superficies públicas «~96%»: la única cifra de titular que se mantenía a mano, y que ya se había movido una vez sin que nadie lo notara.

• Nuevas puertas de sincronización de documentos para superficies que nada leía. tests/readme_code_fences_doc_sync.rs comprueba cada import { … } from "kshana" de un bloque JavaScript frente a las exportaciones de WebAssembly, y fija byte a byte el ejemplo de Rust de README.crates.md a una copia que compila el binario de pruebas. tests/security_md_doc_sync.rs falla si src/lib.rs pierde #![forbid(unsafe_code)] o si SECURITY.md deja de indicarlo. tests/no_overclaims.rs analiza ahora también web/README.md y los tres README de los registros, y toda norma del sitio debe indicar explícitamente su proof.

• Las dos comprobaciones de reloj con hardware real se ejecutan en un runner. realdata-clock.yml (mensual y bajo demanda) obtiene las series 5071A y PHASE.DAT y ejecuta ambas pruebas con KSHANA_REQUIRE_REALDATA=1, de modo que una entrada ausente hace fallar en lugar de omitirse. Ambos scripts de obtención están fijados a un único commit de allantools y verifican SHA-256.

• El stub de tipos de Python se comprueba frente al wheel compilado (mypy.stubtest en el trabajo de enlaces), que es como csv/write_csv se publicaron sin stub.

• El glosario define URE, EOP, FoM, CTI y TIB, que el README y el registro usaban sin desarrollar.

• El contrato de campos publicado de cada tipo es ahora cierto, y una prueba lo mantiene así. Cambiaron cinco de los 61 tipos. Los tipos con un required_fields no vacío pasan de 21 a 22: ephemeris exige ahora tle|orbit+epoch (un kind = "ephemeris" desnudo solía pasar --validate y luego fallar la ejecución), y quantum-trade añade candidate_adev_taus+candidate_adev_values|candidate_clock_class, que su ejecución ya exigía. Una entrada obligatoria puede usar | (uno de estos) y + (todos estos juntos); --validate entiende ambos. lunar-joint-od-clock, pvt y earth-gnss-lunar publican 9 campos opcionales reales que habían omitido. docs/SCENARIOS.md dice ahora que kind es obligatorio para todo tipo excepto clock. tests/required_fields_are_true.rs comprueba cada tipo frente a su escenario incluido: quitar cualquier entrada obligatoria debe hacer fallar la ejecución, y un documento que contenga solo los campos obligatorios debe ejecutarse.

• Las notas de JetBrains Marketplace están controladas por una puerta. scripts/check-version-sync.sh falla ahora salvo que la entrada <change-notes> más reciente de plugin.xml nombre la versión que se distribuye; siete versiones publicadas habían servido sin cambios las notas de 0.22.0.

• La cifra de cobertura del informe técnico es la medida. paper/kshana-technical-report.md decía «cerca del 97 %»; ahora dice cerca del 96 % (95,63 % medido, docs/COVERAGE.md) y es la sexta superficie que fija la prueba de cobertura.

• El cliente del motor fuera del hilo principal está probado (web/engine.test.mjs, en CI): lista de despacho permitido, cancelación y reaparición, las tres rutas alternativas al hilo principal y recuperación tras fallo, frente a un worker simulado.

• No se publica nada hasta que la confirmación etiquetada haya pasado sus pruebas, y una versión no está terminada hasta que todos los registros la sirven. El orden es ahora etiquetar, verificar, publicar, paridad, sitio, en una sola ejecución de release.yml (docs/RELEASING.md).

  • La publicación espera al veredicto. publish.yml, mcp-publish.yml y jetbrains-plugin.yml ya no se inician con el envío de la etiqueta; release.yml los invoca desde trabajos que tienen needs: verify. Antes competían con él: en v0.27.2, crates.io, npm y el Python Package Index (PyPI) habían publicado todos dentro de los 4,5 minutos posteriores a la etiqueta, y verify terminó 84 minutos después; en v0.27.0, npm y PyPI publicaron mientras fallaba el trabajo de crates.io. Un reintento manual sobre una etiqueta queda retenido por el nuevo scripts/check-release-verdict.sh, que exige un verify en verde para esa confirmación exacta desde la interfaz de Actions y falla cerrado ante cualquier otra cosa.
  • Todo se compila antes de subir nada, y crates.io, cuyo paso de empaquetado es el que falló a mitad de una versión, publica primero.
  • La ausencia de un token de registro hace fallar el trabajo en lugar de omitir la subida y notificar éxito.
  • Una comprobación de paridad tras la publicación. scripts/check_channel_parity.py consulta crates.io (kshana y kshana-mcp), npm, PyPI (la distribución de código fuente y los seis wheels de plataforma) y ghcr.io hasta que cada uno sirve la versión, o hace fallar la ejecución; docs.rs y el registro del Model Context Protocol (MCP) se informan, pero no son obligatorios. Ejecutada contra versiones pasadas, encuentra que 0.22.0 falta en npm y PyPI, 0.23.0 en PyPI y 0.27.0 en crates.io.
  • Binarios de línea de comandos precompilados para macOS (Apple silicon e Intel) y Windows x86-64, nombrados por destino (kshana-aarch64-apple-darwin y así sucesivamente), junto al kshana de Linux, cuyo nombre no cambia. Un archivo SHA256SUMS cubre todos los recursos, y verify-release lo comprueba y ejecuta los binarios de macOS y Windows en sus propios sistemas.
  • kshana.dev muestra una versión, no main. Antes se volvía a desplegar con cada envío a main mientras sus páginas nombraban la última versión. pages.yml compila ahora solo una etiqueta de versión: la versión lo lanza una vez que todos los canales sirven la versión, y un lanzamiento manual vuelve a desplegar la última versión (o una indicada).
  • Una única fuente de wheels. La matriz de seis destinos copiada a mano de publish.yml desaparece; ahora invoca wheels.yml, de modo que la puerta de etiquetas de auditwheel y la comprobación de reproducibilidad byte a byte evalúan los wheels que recibe PyPI, y un fallo en cualquiera de las dos detiene la versión.
  • Herramientas de compilación fijadas. Cada flujo de trabajo solicita Rust 1.93.0 (el trabajo msrv, su propia versión); publish.yml y pages.yml habían solicitado @stable, y el registro de v0.27.2 muestra a rustup instalando 1.98.1 y luego compilando con 1.93.0 solo porque rust-toolchain.toml tiene prioridad sobre él. wasm-pack se fija a 0.13.1 (la versión que compiló v0.27.2, que eligió el script instalador sin fijar) con una comprobación de suma de verificación, y mcp-publisher a 1.8.1 con su SHA-256 publicado. scripts/check-toolchain.sh falla ahora si un flujo de trabajo pide otro compilador o canaliza un script descargado a un shell. No se eliminó ni se relajó ningún trabajo de verificación, fijación golden ni script de puerta local.

Seguridad#

• Cada GitHub Action de terceros se fija por SHA de commit: 93 referencias en 15 flujos de trabajo, 92 de ellas nuevas, con la etiqueta conservada como comentario final para que Dependabot la actualice. La excepción es dtolnay/rust-toolchain, cuya etiqueta es el selector de la cadena de herramientas.

• Las capas base de la imagen del servidor MCP se fijan por digest multiarquitectura, y Dependabot vigila ahora el Dockerfile de mcp/kshana-mcp, de modo que las capas del sistema operativo siguen recibiendo actualizaciones de seguridad, mediante un PR revisado.

• La comprobación de etiqueta frente a manifiesto se ejecuta en los dos flujos de publicación que distribuyen la versión de la etiqueta. mcp-publish.yml (imagen ghcr, registro MCP) y jetbrains-plugin.yml (Marketplace) compiten con publish.yml en lugar de esperarlo, de modo que una etiqueta mal cortada solo se controlaba en uno de los hermanos. Ahora ambos ejecutan scripts/check-version-sync.sh antes de compilar.

• Se corrigen cuatro avisos de seguridad que Dependabot emitió el día en que se activaron sus alertas. El servidor MCP pasa de rmcp 1,7 a 2,2: tres avisos contra rmcp < 2,1 (una fuga de la tabla de sesiones de Streamable-HTTP, la falta de validación de recurso protegido de OAuth, y cabeceras personalizadas que siguen una redirección entre orígenes), ninguno alcanzable aquí, ya que el servidor habla solo stdio, pero un crate publicado no debería fijar un SDK vulnerable. Las macros de rmcp 2 necesitan Rust 1,88, así que ahora solo kshana-mcp declara rust-version = "1.88"; la biblioteca kshana se queda en 1,85. Se aplica el único cambio de API (Content → ContentBlock), y las pruebas de ida y vuelta pasan. La acción de análisis de SonarQube pasa de v5 a v6, lo que corrige un aviso de inyección de argumentos (≥ 4,0, < 6,0).

0.27.2 - 2026-09-22#

Añadido#

• Cada elemento de Rust que cita una fila de la matriz de verificación se resuelve ahora contra el crate. La protección existente comprobaba las citas con forma de ruta de archivo; 63 de las 164 filas que no son del socio nombran su evidencia como un elemento del propio crate: navsignal::code_tests, integrity::tpl_scalar::tests, api::tests::tracking_loop_kind_round_trips_through_the_dispatch, y un token sin sufijo .rs era invisible para un analizador de rutas. Esas filas podrían haber nombrado un módulo renombrado, un módulo de pruebas vaciado o una función que nunca existió, y todas las puertas habrían seguido en verde.

  tests/verification_rows_name_a_test_that_exists.rs resuelve a través del árbol de módulos las 339 citas de este tipo, exige que toda fila que no sea del socio nombre al menos una prueba que lleve realmente #[test], y exige que las filas del socio no nombren ninguna. Se usaron cuatro mutaciones para evaluarla: renombrar un módulo citado, apuntar la única cita de prueba de una fila a una función que no es una prueba, renombrar el mod tests real y quitarle los atributos #[test]; cada una se pone en rojo en la aserción que le corresponde.

  Una fila ya estaba mal: Alternative / complementary PNT citaba tests/*, un glob, que no es una cita. Ahora nombra tests/alternative_complementary_pnt_reference.rs y los tres módulos de prueba del propio crate que la respaldan.

• Las figuras publicadas se vuelven a comprobar contra el motor en cada compilación (tests/published_figures_still_reproduce.rs). Los tres gráficos de demostración del README son la propia salida chart.svg del motor y nada volvió a ejecutar el escenario; los dos estudios de cruce del artículo se generaron una vez y se incorporaron al repositorio; y el README indica cuatro figuras de mérito en prosa junto a scenario-fom.png. Las tres están ahora fijadas a la salida del motor en vivo.

  Conciliarlas sacó a la luz el resultado útil: los gráficos de demostración se habían dibujado con el motor 0.22.0 y el JSON de cruce del artículo con 0.20.0, y con 0.27.1 todos los valores representados en los cinco artefactos son idénticos: los tres SVG de gráficos difieren de una ejecución nueva exactamente en dos caracteres cada uno, el sello de versión del pie. Los gráficos se han vuelto a renderizar para que el pie sea cierto. El JSON del artículo se deja deliberadamente sellado como 0.20.0: es el registro de la ejecución cuya figura incorpora un artículo publicado, y volver a sellarlo afirmaría una procedencia que el PDF no tiene. La protección afirma en su lugar la propiedad más fuerte: que el motor actual sigue reproduciendo cada valor publicado.

Corregido#

• Los análisis de SonarCloud se registraban como VERSION=not provided, de modo que el periodo de código nuevo previous_version nunca avanzaba: seguía anclado en el análisis del 2026-07-02, evaluando ochenta y dos días de trabajo como un único delta y midiendo 7877 líneas duplicadas «nuevas» frente a un umbral del 3 %. El análisis pasa ahora la versión del crate. La duplicación subyacente es real y esto no la oculta: se concentra en los registros declarativos de FieldUnit repetidos en ensemble, hybrid, fusion, inertial y report, y en la tabla de verificación de 168 filas, y se nombra aquí como trabajo pendiente en lugar de excluirla de la medición.

• scripts/gate.sh no tenía un bloqueo de escritor único, y cada ejecución escribía el mismo registro. No es una cuestión de orden: los campos integration_binaries, tests_passed y tests_ignored del recibo se leen DE ese registro, y el gancho de pre-push confía en el recibo. Una puerta que se había matado pero cuyo binario de pruebas seguía vivo siguió escribiendo en el archivo que la ejecución siguiente acababa de truncar, de modo que los recuentos de una ejecución podían haberse dado por buenos como los de otra, autorizando un envío con el respaldo de una suite que nunca se ejecutó sobre el árbol que se enviaba. Ahora hay una puerta por checkout (se niega con salida 75 junto a una viva, y borra un bloqueo obsoleto cuyo pid ya no existe) y un registro por ejecución, con target/gate-run.log actualizado a partir de la ejecución que termina al salir. Se prueban ambos sentidos: un pid vivo rechaza, uno muerto se borra.

• src/verification.rs afirmaba que sus pruebas «do not prove the named test/oracle strings resolve to live code». Ahora dos protecciones hacen exactamente eso, de modo que el documento del módulo decía lo contrario de la verdad; ahora indica qué se comprueba por máquina y qué se deja al juicio humano. Una referencia obsoleta a verification::gen (el módulo es artifacts) se corrige en la propia documentación de la protección hermana.

Cambiado#

• main se reescribió el 2026-09-22 y se envió con force-push. Diez commits pasaron a ser cuatro. La reescritura integró cada commit que dejó una puerta en rojo en el commit que la puso en verde, de modo que todo commit de main tiene ahora un árbol que pasa, y eliminó las ejecuciones canceladas que un grupo de concurrencia de toda la rama había ido dejando en cada commit sustituido.

  No se descartó nada. Los commits anteriores a la reescritura siguen siendo alcanzables mediante las etiquetas que apuntan a ellos, y el árbol final es idéntico byte a byte al árbol del que partió la reescritura: git diff entre la antigua punta y la nueva está vacío salvo por los tres archivos de flujo de trabajo que cambia esta versión.

  Los SHA sustituidos, para quien conserve una referencia a alguno:

  antiguo	asunto
  9733177	docs(changelog): disclose the authorship rewrite and the two dangling crate sha1s
  5d16ea8	fix(docs): the engine-flow diagram said 6 figures of merit; the engine scores 7
  148d31d	fix(test): two more cross-platform pins, and two wrong assumptions of my own
  a3a2667	feat(web): surface the lunar cluster on the site — seven capability cards
  1e8bec6	docs(lunar): document 42 public fields and ratchet the ceiling down to 985
  7bba514	chore(release): v0.27.0
  3154548	test(docs): guard the distribution diagram, the last unguarded one
  7864142	chore(release): v0.27.1

  Las etiquetas v0.27.0 y v0.27.1 deliberadamente NO se movieron. Siguen apuntando a 7bba514 y 7864142, los commits exactos cuyos árboles produjeron los artefactos que ahora están en vivo en crates.io, npm, PyPI, ghcr.io y el registro MCP. El .cargo_vcs_info.json de un crate registra el sha1 desde el que se empaquetó, los registros son inmutables, y la atestación de procedencia de compilación SLSA sobre los recursos de la versión v0.27.1 está ligada a ese commit. Mover las etiquetas habría dejado cada uno de esos artefactos publicados apuntando a un commit que ya no existe. Dejarlas mantiene alcanzables los commits antiguos y resolviéndose cada cadena de procedencia publicada, al precio de dos etiquetas que ya no son ancestros de main, razón por la cual existe esta versión: v0.27.2 da a main una etiqueta propia, empaquetada desde un commit que está en ella.

  Esta es la segunda reescritura divulgada de este historial; la primera, el 2026-09-21, canonicalizó la autoría y consta en las notas de 0.27.0 con sus propios dos sha1 de crate colgantes. Aquí se divulga cada reescritura, porque un repositorio que vende procedencia verificable no puede mover en silencio el suelo bajo un artefacto publicado.

0.27.1 - 2026-09-22#

Corregido#

• El crate publicado no compilaba. src/lunar_orientation.rs contiene un include_str! de nivel superior de tests/fixtures/llr_geometry/de440_moon_pa.csv, y el manifiesto excluye /tests/fixtures del paquete, de modo que al tarball que recibía crates.io le faltaba un archivo que la propia biblioteca incorpora. La publicación de v0.27.0 falló su compilación de verificación por ese motivo y ninguna 0.27.0 llegó a crates.io; npm y PyPI, cuyos trabajos no dependen de él, publicaron con normalidad. La exclusión lleva ahora una excepción para ese único catálogo.

  Cualquier otro include_str! de un fixture en src/ está dentro de un módulo #[cfg(test)] y por tanto nunca llega a la biblioteca empaquetada. Solo lo hace uno de nivel superior.

• Nada en CI ejecutaba cargo package, por lo que un tarball que no puede compilar lo descubrió primero el trabajo de publicación, después de que otros dos registros ya lo hubieran distribuido. Un trabajo package compila ahora el tarball exacto en cada envío.

Cambiado#

• Las fijaciones de emisión de lunar-frame-realisation ya no se mueven con un cambio de versión. El pie del SVG lleva la versión del motor, de modo que cada versión restablecía tres hashes (dos veces en un día) y una fijación que se vuelve a tomar por rutina deja de leerse. La cadena de versión se normaliza a un marcador antes de calcular el hash, y se afirma por separado que la emisión indica la versión en ejecución, de modo que ese hecho se comprueba con más precisión de la que el hash lo comprobó nunca.

0.27.0 - 2026-09-22#

Añadido#

• lunar-llr-datum: el datum del marco lunar a partir de una campaña de observación real. lunar-frame-campaign sustituyó una transformación de Helmert inyectada por una campaña simulada y lo dijo: su red de estaciones, su calendario y su sigma por observación son entradas ilustrativas. Este escenario elimina la simulación de los dos lugares donde un calendario y un modelo de error entran en la respuesta. Las épocas son los tiempos de transmisión de 337 puntos normales archivados de telemetría láser lunar de ILRS (2015-04-08 .. 2015-06-27, Grasse MeO 7845 y Matera MLRO 7941, los cinco conjuntos de retrorreflectores), y cada peso de observación es la propia precisión archivada de ese punto normal, bin_rms / sqrt(n_raw): una mediana de 5,13 mm de distancia de ida, tomada del archivo y no elegida aquí. Las coordenadas de estación proceden de IERS ITRF2020 y las de los reflectores de la Tabla 7 de JPL DE430; cada fixture registra una URL, una fecha de obtención y un SHA-256 y se regenera desde su fuente mediante un generador incorporado al repositorio que verifica la fuente y aborta en lugar de emitir un número. El informe nombra qué enlaces están medidos y cuáles siguen modelados, y los modelados están medidos: la distancia de ida observada menos calculada sobre los datos reales es de 156.494 m RMS, lo que el mismo conjunto de pruebas confirma frente a JPL Horizons en el mismo intervalo (195.655 m RMS vector, peor época 0,054°, dentro de los ~0,3° que la serie lunar analítica incorporada se atribuye a sí misma). Aditivo: un tipo nuevo, un lector nuevo (realdata::llr_crd) y un módulo nuevo (lunar_llr); los paquetes existentes de marco lunar quedan fijados bit a bit.

• sigma_ure_m como parámetro de escenario en lunar-integrity y moonlight-service-volume. La precisión de distancia de la señal en el espacio era una constante en tiempo de compilación (LUNAR_SIGMA_URE_M), de modo que un barrido del volumen de servicio solo podía responder supera/no supera con un único valor fijo. Los niveles de protección son exactamente lineales en ella, así que exponerla convierte el barrido en un requisito de precisión de distancia sobre todo el volumen. El valor por defecto reproduce el comportamiento anterior bit a bit.

• Exportación de geometría por satélite en moonlight-service-volume: export_site_lat_deg + export_site_lon_deg añaden un array per_sat_geometry que da azimut, elevación y distancia oblicua a cada satélite en cada época para un sitio selenográfico indicado, más el indicador de visibilidad. El resumen agregado de cobertura colapsa deliberadamente la geometría por satélite, pero la distancia oblicua es exactamente lo que consume un balance de enlace, de modo que un análisis conjunto de comunicaciones y navegación no podía hacerse solo con el resumen. Desactivado salvo que se den ambas coordenadas; puramente aditivo.

• lunar_service::topocentric, el asistente público de ángulos de visión que hay detrás de la exportación.

• Una fila de la matriz de verificación para la nueva capacidad de geometría.

• El diagrama de antena real en la exportación de geometría. El motor lleva desde P1 un diagrama de apertura circular con iluminación uniforme (antenna::pattern_gain_dbi, la forma de Airy [2·J₁(x)/x]²) y nada fuera de antenna.rs lo usaba: en su lugar hacía el trabajo una ganancia en el eje combinada con una regla empírica de ganancia a ancho de haz. Una tabla opcional export_antenna en moonlight-service-volume (leída solo cuando se fija el sitio de exportación) da ahora a cada fila exportada el ángulo fuera del eje en el satélite y la ganancia de transmisión hacia el sitio según ese diagrama, y añade un bloque antenna_pattern que informa del recuento dentro del haz con el diagrama real junto al recuento dentro del haz con la aproximación simétrica (θ₃dB[deg] = √(31000/G_lin)), con la diferencia como corrección nombrada. Se emiten ambos números; ninguno sustituye al otro. Medidos con la propia apertura lunar representativa del motor (plato de 1 m, 2,4 GHz, η = 0,60) sobre un sitio polar sur y la capa ilustrativa de clase LCNS, los dos difieren en más de un satélite: el diagrama real sitúa 0 de 76 enlaces visibles dentro del haz de potencia mitad, y la aproximación afirma 28: una corrección de −2,33 satélites por época, con 3 en la peor época. La aproximación lleva una eficiencia de apertura propia (0,641 frente a la regla de 70·λ/D grados con la que normalmente se cita, 0,920 frente a una apertura circular uniforme), de modo que en un plato con η = 0,60 devuelve un haz 1,238× demasiado ancho; el bloque emite ambas eficiencias implícitas en lugar de dejarlas para inferirlas. Puramente aditivo: medido sobre el punto de trabajo documentado, 597 hojas preexistentes, 0 cambiadas, 0 eliminadas, 494 añadidas.

• antenna::symmetric_beamwidth_rad, antenna::symmetric_relation_implied_efficiency, antenna::within_half_power_beam, antenna::HALF_POWER_DROP_DB, antenna::SYMMETRIC_GAIN_BEAMWIDTH_CONST_DEG2, antenna::UNIFORM_APERTURE_HPBW_COEFF y lunar_service::nadir_off_boresight_rad, las piezas públicas que hay detrás. El diagrama también está ahora anclado frente a las constantes de Airy publicadas y no solo frente a sí mismo: el cruce de potencia mitad se localiza por bisección y se compara con x = 1.61634, lo que hace que el ancho exacto de potencia mitad sea 1.02899·λ/D y registra con honestidad que el coeficiente convencional 1.02 sitúa pattern_gain_dbi en −2,955 dB, no en −3,010 dB.

• Una tabla de reproducibilidad en formato largo para lunar-time-budget. Las salidas con valores de array del escenario (la cuadrícula de tiempos de promediado, las siete curvas x(τ) por término y su total de raíz de la suma de cuadrados) solo llegaban a los consumidores como arrays JSON. Una tabla publicada se truncó a 400 caracteres y publicó 23 de sus 57 tiempos de promediado bajo una columna que afirmaba contenerlos todos, y el manuscrito reconstruyó las curvas por término a partir de formas cerradas porque el motor nunca las emitía. Una ejecución normal escribe ahora también <scenario>.table.csv con una fila por (índice de cuadrícula, tiempo de promediado, término), que no puede truncarse en algo que aún parezca completo. El índice de cuadrícula es una clave de unión exacta; τ se escribe con 13 cifras significativas y cada x con 7, de modo que los bytes no se bifurcan entre compilaciones del mismo código fuente. Puramente aditivo: el JSON del informe es idéntico byte a byte.

• El informe de hybrid-optical-rf se describe ahora a sí mismo. Un bloque link_configuration repite las entradas de enlace resueltas (longitud de onda de la portadora, apertura de transmisión y de recepción, distancia, anchura de pulso, tiempo de integración, eficiencias y pérdidas) con los valores por defecto aplicados, de modo que un artículo indica la configuración con la que se ejecutó en lugar de citar un valor por defecto leído del código fuente. Un bloque units da la unidad y la clase de procedencia de cada magnitud que un artículo probablemente citará. Las trazas de covarianza del traspaso son la razón de que exista: se emitían como un variance desnudo y un manuscrito dedujo metros cuadrados a partir de una comprobación de consistencia interna. La deducción era correcta, que es exactamente por lo que era un defecto: nada habría detectado que estuviera mal. Puramente aditivo: medido en cuatro configuraciones, 456 campos preexistentes, 0 cambiados, 0 eliminados, 196 añadidos.

• Una fila de la matriz de verificación para la tabla de reproducibilidad del presupuesto de tiempo, con honestidad InternalConsistency / MODELLED: el total se comprueba frente a la raíz de la suma de cuadrados de los términos del mismo archivo, que comparte las definiciones de términos del propio motor y por tanto no es una referencia independiente. En conjunto, estas añaden tres filas. El total acumulado de esta sección sin publicar es 168 filas: 64 VALIDATED, 100 MODELLED, 4 PARTNER.

Cambiado#

• La autoría de los commits en todo el historial es ahora una única identidad, y dos crates publicados apuntan a un commit que ya no existe. El 2026-09-21 se reescribió el historial de git de modo que todo commit humano está escrito y confirmado por ashfordeOU <236818772+ashfordeOU@users.noreply.github.com>. Antes llevaba tres grafías de una misma persona: 688 commits como ashfordeOU <contact@ashforde.org>, 34 como Chakshu Baweja <contact@ashforde.org> y 94 ya canónicos. El único commit de dependabot[bot] se dejó deliberadamente con su propio autor: reetiquetar la actualización de dependencias de un bot afirmaría la autoría de un trabajo que nadie hizo aquí.

  No cambió ningún contenido. La reescritura tocó solo las cabeceras de autor y de committer, y eso es comprobable en lugar de afirmado: el árbol de cada etiqueta y de cada rama es idéntico bit a bit a lo que era antes. v0.26.0 sigue resolviéndose al árbol 92284e9420605568f1bfabb78cd95d383b40f3e2, exactamente como antes.

  Lo que costó. El nombre de un commit es un hash sobre su árbol, sus padres y sus cabeceras de autor, de modo que cambiar un ancestro renombra a todos sus descendientes. El commit de la versión v0.26.0 era dce2dbf7700788cf6de46260c14673c0e5347360 y ahora es d4921f3025569e00e425e1747d0acfc261e96e18. Dos artefactos registraron el nombre antiguo en el momento de la publicación y no pueden corregirse, porque una versión publicada en un registro es inmutable por diseño:

  • kshana 0.26.0 en crates.io: .cargo_vcs_info.json registra dce2dbf…
  • kshana-mcp 0.26.0 en crates.io: el mismo sha1, path_in_vcs: mcp/kshana-mcp

  Nada más resulta afectado. El paquete de npm no registra ningún gitHead, y la distribución de PyPI no registra ningún commit; ambos se comprobaron en lugar de suponerse.

  No hay ninguna reparación que haga que dce2dbf… nombre el commit reescrito: esa cadena es la ascendencia antigua, y la única forma de que se resuelva es mantener publicado el historial anterior a la reescritura, lo que restablecería la autoría que la reescritura eliminó. La procedencia de 0.26.0 pasa por tanto por la etiqueta y no por el sha1 registrado, y la etiqueta entrega los mismos bytes con los que se compiló el crate. La siguiente versión registra un commit válido sin que haga falta ninguna acción.

Corregido#

• realtime-frame-eop tomaba por defecto un archivo de EOP sin filas de predicción (G12). El escenario incorporaba como valor por defecto sin conexión un extracto finals2000A de cinco filas solo finales, de modo que una ejecución simple informaba predicted_rows.n = 0 y la tabla por horizonte se apoyaba en pares de 5, 4, 3 y 2. El motor siempre podía leer una fila de predicción: la entrada simplemente no tenía ninguna. El valor por defecto es ahora el extracto IERS 2026 literal (tools/finals2000A_2026.txt, MJD 61173–61204): 20 finales del Bulletin B y 12 filas del Bulletin A solo de predicción, de modo que una ejecución simple sin argumento de archivo y sin red informa predicted_rows.n = 12 y una tabla por horizonte con n = 20 / 31 / 30 / 29, y también se rellenan la comparación con el predictor operativo y la concordancia con las predicciones publicadas del propio producto. El extracto de 45 filas de largo intervalo se midió como alternativa y se descartó: también es solo final, de modo que habría dejado predicted_rows.n en 0. Esto mueve números publicados, bajo la regla R4 y con autorización del fundador: diez de las 22 celdas del p4_frame_eop.csv publicado y 24 de las 42 celdas rellenas de tests/golden/realtime-frame-eop.csv. El suelo de polo medido rápido menos final pasa a 0,0678 mas (desde 0,0769 mas), que es el valor que la propia tabla de movimiento polar del artículo P4 ya publica con n = 20: ambos coinciden ahora en lugar de diferir en un 13,5 %. Todas las demás cifras que P4 imprime de esta tabla no cambian con la precisión impresa. La enumeración completa de antiguo → nuevo, incluidos los campos que no se movieron, está en docs/revisions/G12-default-eop-cell-changes.md. El extracto solo final sigue distribuyéndose, fijado byte a byte y ejercitado: un recuento nulo de filas de predicción en él es una propiedad del archivo, y una prueba lo sigue demostrando.

• Un límite obsoleto de satélites en moonlight-service-volume. El escenario limitaba n_sats a 12 aunque su propio constructor de constelaciones admite 24 y una prueba afirma 24, de modo que todo recuento solicitado por encima de 12 se reducía en silencio y un barrido del número de satélites devolvía valores idénticos por encima de 12, indistinguibles de una saturación geométrica genuina. Ahora el límite es el del constructor. Es un cambio de comportamiento solo para n_sats > 12.

• El mismo límite obsoleto en lunar-differential-pnt. lunar_dpnt limitaba n_sats a 12 con la misma consecuencia, y esta llegó a una tabla publicada: dpnt_nsats_sweep.csv contiene una fila n = 16 idéntica byte a byte a su fila n = 12, porque el motor devolvía una respuesta de doce satélites bajo una etiqueta de dieciséis. Ahora el límite es el del constructor, 24, y una nueva prueba lo fija: cada constelación mayor debe informar de su propio recuento y mejorar estrictamente el nivel de protección, de modo que el límite no pueda reaparecer sin ser advertido. Esto modifica números publicados: el nivel de protección de n = 16 pasa de 16,92 m a 14,57 m. Barrida hasta 24, la curva es estrictamente monótona (11,94 m con 24 satélites, un 29,5 % mejor que con 12), por lo que no hay saturación en 12: la meseta aparente era el límite. Cambio de comportamiento solo para n_sats > 12.

0.26.0 - 2026-09-18#

Una versión de documentación, transparencia y playground. Sin cambios en el comportamiento del motor: la matriz de verificación se mantiene en 102 filas: 56 VALIDATED, 42 MODELLED, 4 PARTNER, sin cambios respecto a 0.25.0.

Añadido#

• rustdoc a nivel de crate (//! en lib.rs) que cubre los puntos de entrada, el modelo de honestidad y de niveles, y la reproducibilidad, de modo que docs.rs abre en una página de inicio real y no en un muro de módulos sin más.
• docs/SCENARIOS.md: una referencia por tipo para los 50 tipos de escenario, generada a partir de api::list_scenario_kinds() (la única fuente de verdad) por gen_validation_artifacts y protegida por tests/scenarios_reference_doc_sync.rs, de modo que no puede desviarse del despachador.
• Documentación de módulos para los 11 módulos públicos antes sin documentar (allan, estimator, fom, hybrid, inertial, models, report, run, scenario, timetransfer, types).
• Fuentes bibliográficas para cinco módulos de fórmulas que enunciaban una ecuación pero no citaban ninguna referencia: batch_ls (Tapley/Schutz/Born; Bjorck), cr3bp (Szebehely; Koon et al.), detection (Kay), attitude_budget (Wertz; Sidi), reentry (Allen-Eggers, NACA TR-1381).
• Un archivo security.txt publicado en kshana.dev para la divulgación coordinada.
• Nivel de validación por ejecución en el playground. La tabla de figuras de mérito de una sola ejecución incluye ahora una etiqueta VALIDATED/MODELLED por cada figura, leída de la misma consulta fomTier() que usa el informe descargable (que refleja src/fom_label.rs, derivado a su vez de la matriz de verificación), de modo que el nivel mostrado junto a un número en vivo nunca puede discrepar del registro.
• lunar-attack-surface en el menú del playground: los 50 tipos despachables están ahora a un clic (antes 49/50).
• Cinco tarjetas de capacidad ejecutables más (meteorología espacial, evaluación de degradaciones de RF, resiliencia, interoperabilidad CCSDS OEM, KIF), con lo que las tarjetas ejecutables pasan de 11 a 16. Las tarjetas solo de API o de biblioteca mantienen un enlace honesto a la documentación en lugar de un falso botón de ejecución.

Cambiado#

• La cobertura de documentación se controla ahora de forma progresiva en CI. check-doc-coverage.sh compila la biblioteca con missing_docs, cuenta las advertencias y falla solo si el recuento supera un tope fijado (986). Un #![warn(missing_docs)] estricto bajo -D warnings habría convertido unos 1000 elementos públicos hoy sin documentar en una rotura de compilación de la noche a la mañana; así, los nuevos elementos públicos sin documentar hacen fallar la compilación mientras el atraso existente se va saldando de forma deliberada.

Corregido#

• La fila de la herramienta MCP list_scenario_kinds anunciaba "unos 17 tipos de escenario integrados" mientras que api::list_scenario_kinds() exponía 50 desde hacía tiempo: un documento dirigido a agentes que subestimaba la capacidad real en un factor de tres. Fijado al recuento real.
• Se regeneró la referencia independiente de ajuste a la norma del SBOM CycloneDX para el grafo de dependencias actualizado (60 componentes). El veredicto de ajuste a la norma no cambia: cero errores de esquema normalizados y todos los identificadores atómicos de licencia siguen dentro de la enumeración oficial de SPDX.

0.25.0 - 2026-07-15#

Añadido#

• Cinco capacidades promovidas a VALIDATED externamente, cada una contrastada ahora con una implementación independiente de terceros de la misma magnitud definida de forma única (no circular, con fixtures regenerables sin conexión):
  • Conversión de ley de potencias IEEE-1139 a desviación de Allan frente a las formas cerradas de allantools para los cinco tipos de ruido (tests/powerlaw_oadev_reference.rs);
  • Pesos del conformador de haz CRPA MVDR / de anulación de norma mínima frente a LAPACK de numpy/scipy (tests/crpa_reference.rs);
  • Determinación de actitud Wahba / TRIAD / QUEST frente al SVD de SciPy Rotation.align_vectors con observaciones sin ruido (tests/wahba_reference.rs);
  • Intercambio de bloques de covarianza CCSDS 502,0 OEM con ida y vuelta a través del analizador de la biblioteca independiente oem (tests/ccsds_oem_covariance_reference.rs);
  • el núcleo de estadísticos de detección de adquisición de ley cuadrática (Marcum-Q generalizada / P_d / P_fa / umbral) frente a SciPy ncx2/chi2 (tests/acquisition_reference.rs). La matriz de validación verificada por máquina pasa a 56 VALIDATED · 42 MODELLED · 4 PARTNER en 102 filas (antes 51 · 47 · 4). Se conservan las salvedades honestas de alcance; por ejemplo, la promoción de la adquisición cubre solo el núcleo de estadísticos de detección; CFAR/pérdida por desajuste de muestreo sigue siendo MODELLED.
• Figuras de mérito en el dominio de la posición (fom::positioning_performance): CEP, SEP y 2DRMS exactos a partir de la covarianza ENU de posición 3-D de una solución de navegación más un nivel de protección horizontal. CEP/SEP son los errores radiales medianos exactos (no la regla lineal 0.589·(σ₁+σ₂)), contrastados con los cuantiles rayleigh/maxwell de scipy.stats y con una mediana Monte-Carlo independiente en NumPy (tests/positioning_fom_reference.rs). Sustituye al anterior stub honesto de no implementado: la firma de la función cambió, de () que devolvía un error a (cov_enu, hpl_m) que devuelve un PositioningFom.
• Grados de libertad equivalentes (EDF) del intervalo de confianza completados para todos los estimadores de la familia Allan (assurance::uncertainty::edf): el EDF de Allan modificada, de Hadamard y de varianza total usa ahora el algoritmo de EDF combinado de Greenhall y Riley y la forma TOTVAR de la Tabla 7 de NIST SP 1065 (antes solo estaba implementado el EDF de Allan solapada; los demás lo reutilizaban en silencio), contrastado con allantools edf_greenhall/edf_totdev (tests/uncertainty_edf_reference.rs).
• Contrastes externos independientes para las capacidades de geometría PNT lunar, DOP, EOP, DRO y medición de distancia por RF (tests/validate_p*.rs, con fixtures y generadores de referencias independientes en tests/fixtures/{p1_footprint,lunar_service,eop_prediction,rf_ranging_precision,dro_family_jpl,p2_independent_dop}/). Cada contraste somete una capacidad modelled ya publicada a una referencia independiente producida por una implementación distinta, de modo que la coincidencia no es circular: la huella orbital de transmisión/captura frente a scipy.special.j1 (Cephes, una Bessel J1 genuinamente distinta); el DOP de geometría de balizas de superficie frente a una resolución independiente de (HᵀH)⁻¹ en NumPy; el crecimiento del error de predicción por persistencia de UT1/EOP frente a un nuevo análisis independiente en NumPy de las mismas filas IERS finals2000A literales; la familia de órbitas retrógradas distantes planas frente a la Three-Body Periodic Orbit Database de NASA/JPL; y el presupuesto de precisión de medición de distancia por RF frente a una referencia de primeros principios. Constituyen evidencia de regresión adicional para módulos existentes; añadir estas pruebas de contraste no reetiqueta por sí mismo ninguna capacidad (las cinco promociones anteriores son cambios de estado independientes, respaldados por referencias independientes, en src/verification.rs).
• Escenario lunar-attack-surface (src/attack_surface.rs, kind = "lunar-attack-surface"): una ejecución P1 compuesta y accesible desde binario (CLI / Python / MCP / wasm mediante run_toml) de seguridad de la señal lunar que une el déficit de potencia del presupuesto de enlace y su banda de sensibilidad de 12–18 dB, la potencia de transmisión de jamming/spoofing necesaria frente a la distancia de separación, la huella orbital de captura bajo un patrón de antena real, el resultado de enganche por captura de spoofing del lazo de seguimiento, el alcance del horizonte en un cuerpo sin atmósfera y el presupuesto de autenticación OSNMA/TESLA. Un cuerpo vacío reproduce la línea base P1.
• Banda de sensibilidad del déficit de potencia (linkbudget::deficit_sensitivity_band, deficit_power_factor): un barrido genuino de varios ejes (referencia × EIRP × distancia oblicua) construido sobre sweep::SweepAxis y evaluado mediante received_signal_power_dbw, que reproduce la banda P1 de 12–18 dB y concilia las cifras de factor lineal de 32× (redondeada) / 36× (sin redondear).
• Cubo tridimensional de captura de spoofing (spoof_capture::capture_cube): añade el eje de desfase de portadora/Doppler al mapa de captura (J/S × desfase de código × desfase de portadora, tiempo de enganche por celda); el corte de portadora cero se reduce exactamente al capture_map en 2-D.

Cambiado#

• La detección con una red dispersa de monitores (monitor_network) compone ahora el estadístico físico de AGC de spoof_monitors y la cuadrícula de visibilidad selenográfica de lunar_service para obtener el estadístico de detección y la geometría de cada estación, en lugar de parámetros libres y un solapamiento ad hoc de círculos máximos; las probabilidades de detección por monitor y de la red siguen siendo las formas cerradas chi-cuadrado/Marcum-Q de detection. Los campos SurfaceMonitor / SpoofEvent cambiaron a magnitudes físicas (lat/lon/alt/potencia).

Corregido#

• Dimensionamiento de la sobrecarga de autenticación OSNMA/TESLA (nma_budget): las porciones de campo OSNMA por página (HKROOT de 8 bits + MACK de 32 bits por página de 2 s) estaban etiquetadas por error como totales por subtrama, con lo que se subestimaba la sobrecarga 15× (1,33 bit/s). Se corrigió a los totales publicados en el SIS-ICD por subtrama de 30 s (HKROOT 120 + MACK 480 bits ⇒ 20 bit/s). La consecuencia se expone ahora con honestidad: con una tasa de navegación AFS de 50 bit/s la sobrecarga de autenticación supone un coste de primer orden de ≈40 %, no unos pocos puntos porcentuales despreciables; el campo auth_latency se documenta como el retardo de divulgación de la clave (una cota inferior del tiempo hasta la primera posición autenticada de extremo a extremo).

0.24.0 - 2026-07-09#

Una versión de capacidades amplia. Incorpora dos conjuntos de análisis plenamente validados externamente —una familia completa de análisis de decisión multicriterio (MCDA) y los estimadores de deriva de Allan / estabilidad de reloj a τ largo— y abre una nueva capa de escenarios ejecutables de presupuesto de tiempo lunar, marco en tiempo real/EOP, híbrido óptico/RF, observabilidad cislunar y resiliencia ante conflictos de PNT por capas sobre el sustrato, además de un sustrato de capacidades de baliza de superficie lunar y de seguridad de la señal. La matriz de validación verificada por máquina crece a 51 VALIDATED · 47 MODELLED · 4 PARTNER en 102 filas (antes 40 · 47 · 4 en 91): las once filas nuevas son validaciones con referencia independiente externa de los estimadores de análisis de decisión y de temporización, contrastadas con bibliotecas independientes (SciPy, pymcdm, pyDecision, allantools) con tolerancia estrecha, mientras que la nueva superficie de capacidades PNT se presenta con honestidad como MODELLED. Como siempre, ninguna afirmación numérica de un modelo se eleva sin un conjunto de datos externo que la respalde.

Añadido#

Escenarios ejecutables: cada uno es un tipo de escenario registrado (kind), despachado por el motor y comprobado de extremo a extremo en CI por tests/determinism.rs (que ejecuta todos los scenarios/*.toml incluidos y falla de forma estricta ante cualquier fixture no ejecutable):

• Resiliencia ante conflictos de PNT por capas (conflict-resilience, src/conflict_resilience.rs): un motor de resiliencia Monte-Carlo con semilla para una arquitectura PNT multicapa, con un modelo de supervivencia por vector con degradación gradual del §4,2 (cuatro vectores de amenaza con nombre, la forma cerrada de supervivencia de PNT utilizable a la que converge cada Monte-Carlo por capa, emitida en el JSON de resultados) y una procedencia documentada, protegida contra desviaciones, de los parámetros de amenaza (src/conflict_threat_params.rs). Arquitecturas MODELLED; la convergencia del Monte-Carlo de supervivencia a la forma cerrada es el núcleo validado.
• Observabilidad cislunar (cislunar-observability, src/cislunar_observability.rs): un espectro de autovalores del gramiano de observabilidad a lo largo de un arco, un generador de semillas de órbita retrógrada distante (DRO) corregido diferencialmente y un contraste independiente con un filtro de información de raíz cuadrada (SRIF) cuya covarianza a posteriori pasa a ser finita exactamente con rango observable completo. Constelación MODELLED; los invariantes de rango/gramiano/STM/SRIF son el núcleo validado.
• Continuidad e integridad híbridas heterogéneas óptico/RF (hybrid-optical-rf, src/hybrid_integrity.rs, src/optical_availability.rs, src/optical_linkbudget.rs, src/cross_raim.rs): disponibilidad e integridad entre dominios cuando se combinan PNT óptico y de RF. MODELLED.
• Presupuesto de tiempo lunar endógeno (lunar-time-budget, src/lunar_time_budget.rs) y presupuesto de marco / EOP en tiempo real (realtime-frame-eop, src/realtime_frame_eop.rs, src/frame_eop.rs): los presupuestos P3/P4 de tiempo lunar y de orientación terrestre, derivados de forma endógena de la cadena de temporización en lugar de afirmados. MODELLED.

Conjuntos de análisis validados externamente: capacidades de biblioteca que entran cada una en la matriz como nuevas filas VALIDATED (contrastadas con una referencia independiente externa, no con una autocomprobación):

• Conjunto completo de análisis de decisión multicriterio (MCDA) (src/mcda/): las cuatro familias de métodos: agregación de valor (WSM, WPM, WASPAS), sistema de razones (MOORA) y proporcional (COPRAS), distancia al ideal (TOPSIS), programación de compromiso (VIKOR) y sobreclasificación (PROMETHEE II con seis formas de criterio generalizado, concordancia/discordancia de ELECTRE I), además de los pesos de prioridad por autovector de Perron de AHP con la puerta de razón de consistencia de Saaty (CR < 0,10), la utilidad MAUT, la extracción del frente de Pareto y el análisis de sensibilidad de los pesos. Los nueve agregadores reproducen pymcdm / pyDecision y el autovector de AHP coincide con SciPy/LAPACK, todo con < 1e-9 (tests/mcda_*_reference.rs). El tornado de sensibilidad también se presenta dentro del escenario de resiliencia ante conflictos.
• Estimadores de deriva de Allan y de estabilidad de reloj a τ largo (src/allan.rs): MTIE (el estadístico de deriva de error de tiempo pico a pico de ITU-T G.810/G.823/G.8261 en el que se basan las máscaras de sincronización), la deriva en el dominio del tiempo MDEV y TDEV, y los estimadores de rango extendido Theo1 / TOTVAR. VALIDATED frente a allantools con la serie NIST SP 1065; el híbrido ThéoH sin sesgo construido sobre TOTVAR sigue siendo, con honestidad, MODELLED.
• Arnés de aseguramiento / referencias independientes externas (src/assurance/): un arnés de referencias independientes conectado directamente a la puerta de honestidad de CI, un registro de procedencia W3C-PROV con una raíz de Merkle determinista, y grados de libertad equivalentes de Greenhall más intervalos de confianza chi-cuadrado sobre los estimadores de estabilidad.
• Punto de extensión PackRegistry / ExternalPack (src/registry.rs, src/api.rs): un punto de despacho para que los paquetes de capacidades se encaminen por un único registro (el despacho integrado está en la ruta crítica de la CLI; los paquetes externos al árbol se conectan tras un ExternalPack::register_into con valor por defecto), protegido por una suite de ajuste a la norma de identidad byte a byte de referencia y por controles de CI independientes / wasm32.

Sustrato de capacidades modelled: nuevos módulos de biblioteca que alimentan los escenarios anteriores y futuros (todavía no son un tipo de escenario independiente, kind):

• DOP de balizas de superficie lunar (src/lunar_beacon.rs) con presupuesto de precisión realizada, barrido de N satélites y mapa de GDOP, además de unas efemérides lunares perturbadas (src/lunar_perturbed.rs) y geometría de horizonte sin atmósfera / inversa de potencia de spoofing / banda de déficit AFS (src/jamming.rs, src/linkbudget.rs). Reutiliza el núcleo de DOP validado con gnss_lib_py.
• Ingesta de DEM en formato LOLA + línea de visión sobre el terreno (src/realdata/lola_dem.rs).
• Defensa de seguridad de la señal en tres capas: captura de spoofing, integridad entre sensores y dimensionamiento de la red de monitores (src/spoof_capture.rs, src/cross_sensor_integrity.rs, src/monitor_network.rs), con una huella de antena de haz orbital y un presupuesto de autenticación OSNMA (src/antenna.rs, src/nma_budget.rs). MODELLED.

Cambiado#

• La matriz de validación y todos los artefactos derivados se regeneraron a partir de la única fuente de verdad (src/verification.rs): el registro del sitio, los diagramas del mapa de módulos y de la procedencia de la validación, y las cadenas de recuento del README y de cada superficie indican ahora 51 / 47 / 4 de 102 (antes 40 / 47 / 4 de 91); la guarda de honestidad de los recuentos analiza ahora todo el historial de git, y las cifras del README se unifican en la paleta oscura de la marca.
• Un único controlador de integración adaptativa compartido respalda ahora tanto integrate como integrate_dopri (src/integrator.rs), con lo que se elimina el integrador de pasos duplicado.
• Se añadió a CI el análisis estático de SonarQube Cloud (Rust + cobertura importada), con insignias de calificación de seguridad / mantenibilidad / fiabilidad en el README.

Un pasaje que nombra a clientes de IA de terceros se omite aquí; está en CHANGELOG.md en GitHub.

• Disciplina de versiones y empaquetado: CI registra un entorno de despliegue por cada publicación de paquete/registro, y el trabajo independiente público centrado queda al margen de los lentos binarios de validación.
• La guarda de higiene de no atribución se limita únicamente a los marcadores de autoría, de modo que nombrar un host de integración o un producto ya no hace fallar la compilación.
• Documentación: la sección Citing del README enumera ahora los cuatro preprints de arXiv publicados, y la capacidad de DOP de balizas de superficie queda documentada en la fila lunar.

Corregido#

• Contadores de bucle enteros para los bucles dirigidos por valores en coma flotante (Sonar S2193).
• Inversa chi-cuadrado precisa con pocos grados de libertad mediante refinamiento de Newton en la ruta de intervalos de confianza de aseguramiento.
• kshana.dev: la sección de normas se abre ahora por defecto y se corrigió el valor alternativo del recuento del registro; se sincronizaron las cadenas obsoletas del README y del sitio relativas a la capa de observabilidad.

0.23.0 - 2026-06-29#

Una versión de capacidades que añade una capa general de información de Fisher / observabilidad de Cramér–Rao y diseño óptimo de experimentos, y la versión en la que se apoya el artículo sobre observabilidad de PNT lunar. La matriz de validación verificada por máquina crece a 40 VALIDATED · 47 MODELLED · 4 PARTNER en 91 filas (antes 39 · 46 · 4 en 89): el nuevo motor de estimación se contrasta con una referencia independiente externa y es VALIDATED; su aplicación lunar es, con honestidad, MODELLED. Como siempre, ninguna afirmación numérica de un modelo se eleva sin un conjunto de datos externo que la respalde.

Añadido#

• src/fim.rs: información de Fisher, cotas de Cramér–Rao y diseño óptimo de experimentos. Un motor general y reutilizable de teoría de la estimación: la matriz de información de Fisher M = HᵀWH a partir de un jacobiano de medida y de pesos; un resolutor simétrico de autovalores (Jacobi cíclico); la cota inferior de Cramér–Rao mediante la inversa, o mediante la pseudoinversa de Moore–Penrose más una base del espacio nulo cuando la información tiene rango deficiente (el caso de red libre / defecto de datum); y métricas de diseño óptimo de experimentos D, A, E y T con un selector best_design sobre geometrías candidatas. VALIDATED frente a NumPy (eigh/inv) y las cotas de forma cerrada publicadas de Kay (1993) con 1e-9 (tests/fim_observability_reference.rs), por lo que entra en la matriz como una fila con referencia independiente externa y no como una autocomprobación.
• Observabilidad de OD conjunta lunar (lunar_observability en src/lunar_combination.rs, presentada en el informe de combinación lunar): aplica el motor FIM/CRLB a la solución conjunta de órbita y reloj para poner de manifiesto el defecto de datum de estación absoluta, la restauración de su rango a medida que se añaden estaciones de línea base con la Tierra, la CRLB alcanzada de la posición de la estación y el acondicionamiento E-óptimo. Con honestidad MODELLED: el motor de estimación está validado externamente, pero la red lunar a la que se aplica es una simulación representativa, y ningún conjunto de datos actual puede convertir esa geometría en una medición.
• Geometría representativa de órbita lunar elíptica congelada (ELFO) para el escenario de combinación lunar (orbit_ecc, orbit_inc_deg, orbit_argp_deg, orbit_planes; la colocación circular sigue siendo la predeterminada) y un campo de observabilidad sin VLBI en el informe, de modo que pueda mostrarse que el resultado del defecto de datum es válido para cualquier geometría. La misma escala 3→1→0 y el mismo umbral de tres estaciones se mantienen en una ELFO de la familia Moonlight/LCNS, y con tres líneas base VLBI con la Tierra la posición absoluta de la estación es observable con una cota submétrica, fijado por elfo_geometry_confirms_the_observability_structure. Sigue siendo MODELLED.

Cambiado#

• La matriz de validación y todos los artefactos de evidencia generados se regeneraron a partir de la única fuente de verdad (src/verification.rs): el registro (web/data/verification-matrix.json), docs/VERIFICATION-MATRIX.md, docs/MODELLED-RATIONALE.md, las figuras de desglose de validación y de tipo de referencia independiente, y las cadenas de recuento del README en todas las superficies de distribución indican ahora 40 / 47 / 4 de 91.

0.22.1 - 2026-06-29#

Una versión de parche solo de empaquetado. Sin cambios en el motor, los escenarios ni los resultados; la matriz de validación se mantiene en 39 VALIDATED · 46 MODELLED · 4 PARTNER en 89 filas.

Corregido#

• Publicación en npm: el paquete repository.url, derivado del manifiesto del crate, usaba el propietario de GitHub con mayúsculas incorrectas (AshfordeOU), lo que hacía fallar la verificación de procedencia sigstore de npm (que compara el propietario distinguiendo mayúsculas de minúsculas). El manifiesto repository usa ahora el ashfordeOU canónico en minúsculas, de modo que el package.json generado coincide con el sujeto de la procedencia y la versión de npm se publica.

Cambiado#

• La compilación de la wheel fija codegen-units = 1 para que la wheel manylinux sea reproducible byte a byte entre recompilaciones (la comprobación de reproducibilidad de recompilar y comparar).

0.22.0 - 2026-06-29#

Una versión de consolidación centrada en la evidencia, la procedencia y la disciplina de distribución. La matriz de validación verificada por máquina crece a 39 VALIDATED · 46 MODELLED · 4 PARTNER en sus 89 filas (antes 15 · 42 · 4 en 61), gracias a la validación cruzada de capacidades modelled con referencias independientes externas. Cada artefacto distribuido lleva ahora una atestación criptográfica de procedencia de compilación SLSA, incluye un SBOM CycloneDX y se publica de forma sincronizada en todas las superficies. Ninguna afirmación numérica de un modelo se eleva sin un conjunto de datos externo que la respalde; las capacidades nuevas siguen siendo, con honestidad, MODELLED.

Añadido#

• Dinámica de actitud (src/attitude_dynamics.rs, MODELLED): ecuaciones de Euler del sólido rígido libre de pares + cinemática de cuaterniones (RK4), con autopruebas de leyes de conservación (norma del cuaternión, energía cinética, |Iω|, precesión del trompo simétrico).
• Validación cruzada de capacidades modelled con referencias independientes externas, que lleva la matriz de validación a 39 filas VALIDATED, cada una respaldada por un conjunto de datos externo (la puerta de honestidad de CI prohíbe un estado VALIDATED sin él). Las validaciones más recientes con referencia independiente externa: la curva de estabilidad medida de un reloj óptico (el ajuste de la curva ADEV de quantum_trade reproduce la σ_y(τ) publicada del reloj de red óptica de ⁸⁸Sr de Norcia et al., Science 366:93 (2019), Zenodo 10.5281/zenodo.3382347, CC-BY-4.0, incluida en tests/fixtures/optical_clock_adev/); la generación del código de ensanchamiento GPS L1 C/A (el LFSR G1/G2 de src/sdr.rs reproduce los octales de fase de código de la Tabla 3-Ia de IS-GPS-200 para los PRN 1–9); y el lector de elevación digital SRTM sobre terreno real (src/altpnt/terrain.rs lee una tesela SRTM v3 de NASA/USGS de dominio público incluida en el repositorio, N36W117 / Death Valley, y sitúa Badwater Basin dentro de su banda de levantamiento documentada).
• Nuevas capacidades MODELLED, cada una contrastada internamente con una forma cerrada o con una ruta de código hermana: dinámica de movimiento relativo de Clohessy–Wiltshire / Hill, geolocalización pasiva de emisores por TDOA/FDOA, determinación de actitud Wahba/TRIAD/QUEST, resolución de ambigüedad entera de fase de portadora GNSS (LAMBDA), apuntamiento en plano B y asistencia gravitatoria de cónicas empalmadas, conformación de haz de matriz CRPA antijamming, estadísticos de adquisición GNSS de ley cuadrática, ambigüedad de franjas / rango dinámico de sensores inerciales cuánticos, ruido de reloj de ley de potencias IEEE-1139 + suelo de flicker-FM e intercambio de bloques de covarianza CCSDS-OEM.
• Registro de evidencias de fuente única con documentos de verificación generados y una guarda contra desviaciones; un registro de validación navegable en kshana.dev con enlaces profundos de evidencia por tarjeta.
• Metadatos de cita legibles por máquina: codemeta.json (CodeMeta 2,0) y .zenodo.json, fijados al manifiesto de Cargo mediante tests/citation_metadata_doc_sync.rs.
• Procedencia de la cadena de suministro: atestación de procedencia de compilación SLSA para el tarball del crate, las wheels, el sdist y el tarball de npm; publicación de confianza OIDC en PyPI; SBOM CycloneDX incluido en la wheel y en el paquete de npm; diferencia de compilación reproducible y verificación posterior a la versión.
• Descubribilidad: robots.txt, sitemap.xml y metadatos Open Graph / JSON-LD en kshana.dev; una figura validation-breakdown generada a partir de la matriz.
• README por superficie para crates.io / PyPI / npm con una guarda de honestidad de los recuentos.

Cambiado#

• La referencia independiente de la transferencia de tiempo por efecto Sagnac se elevó a ExternalDataset: la corrección Sagnac de una circunnavegación ecuatorial se contrasta ahora con los 207,4 ns publicados por Ashby (Living Reviews in Relativity 6:1, 2003, Ec. 1,29; reproducido con < 0,05 ns). La capacidad compuesta de transferencia de tiempo sigue siendo, con honestidad, MODELLED.
• Documentación, diagramas y figuras actualizados a la matriz vigente (39/46/4/89): el diagrama de procedencia de la validación, la figura oracle-kind-stacked (ahora generada a partir de la matriz con una guarda de CI contra desviaciones), VALIDATION/PROVENANCE/CAPABILITY/QUANTUM-MODELS/WHEEL_TAGS, los documentos de arquitectura y de tutorial, y el total del registro de kshana.dev.
• Se reformateó el árbol de fuentes con el rustfmt fijado (toolchain 1.93.0): puro estilo, sin cambios de comportamiento.
• Versionado sincronizado. Todas las superficies de distribución (crate, PyPI, npm, crate MCP + imagen OCI, plugin de JetBrains) llevan ahora la misma versión que el motor, algo que scripts/check-version-sync.sh impone en CI.
• El plugin de JetBrains pasó a la licencia AGPL-3.0-only (la versión publicada 0.1.1 aún anunciaba Apache-2.0) y ahora deriva su versión de Marketplace de la etiqueta de la versión.
• Refuerzo de robustez: los unwrap ajenos a las pruebas se eliminaron o se justificaron; clippy::unwrap_used se aplica solo al código que no es de prueba.
• Reforma de kshana.dev con la prueba por delante: héroe dominante, diagramas de arquitectura y figuras de resultados, i18n, y secciones de registro y de normas plegables y adaptables.

Corregido#

• Efemérides precisas SP3: se aplica la corrección de nodo de rotación terrestre de IGS durante la interpolación.
• Imágenes de los registros: los README de PyPI/crates.io/npm usan URL absolutas para las imágenes; las rutas relativas de imagen del README principal se mostraban como imágenes rotas en la página de PyPI de 0.21.0. Una guarda de CI (tests/surface_readme_image_urls_doc_sync.rs) evita la regresión.
• CI: fmt + clippy en verde; se deja de compilar contra datos reales excluidos por git.

Pruebas#

• La covarianza del reloj de Kalman sigue siendo semidefinida positiva y simétrica (prueba de propiedades, tests/property.rs).
• Guardas de sincronización de documentación: todas las cadenas públicas de recuento de validación, los metadatos de cita, la figura generada y las URL de imágenes de los README de cada superficie están fijadas a su fuente de verdad.

0.21.0 - 2026-06-26#

Esta versión añade dos conjuntos de aplicaciones MODELLED al motor abierto: un demostrador de PNT con tecnología cuántica (transferencia de tiempo cuántica de confianza, navegación cuántica sin GNSS, detección cuántica de fallos/anomalías) y un conjunto de PNT lunar / cislunar (tiempo coordenado lunar, VLBI lunar, OD+reloj conjuntos, realización de marco, volumen de servicio, PNT diferencial, exportación de interoperabilidad), cada uno ejecutable desde un único tipo de escenario (kind) y cada uno con un registro honesto TradeEvidence más un registro de representatividad / brechas hasta el vuelo. También incorpora seis nuevas validaciones con referencia independiente externa, que llevan la matriz de validación verificada por máquina a 15 VALIDATED · 42 MODELLED · 4 PARTNER en sus 61 filas. Las nuevas cifras de aplicación son MODELLED a partir de parámetros ilustrativos de fuentes públicas —sin TRL, herencia de vuelo, certificación ni respaldo de ninguna agencia— y los núcleos validados que reutilizan están etiquetados como tales.

Añadido#

• Conjunto de demostradores de PNT con tecnología cuántica (quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect). Tres áreas de aplicación MODELLED ejecutables detrás del motor, cada una con TradeEvidence más un registro de representatividad / brechas hasta el vuelo:
  • Transferencia de tiempo cuántica de confianza (src/timetransfer_chain.rs): un presupuesto bidireccional de reloj de red óptica + enlace fotónico frente a CSAC + RF, que reutiliza el nivel de protección de temporización, con una FoM de seguridad frente a ataques de retardo/repetición (1 − P_md) y detección de anomalías de reloj + latencia de CUSUM.
  • Navegación cuántica sin GNSS (src/quantum_nav_od.rs): una navegación inercial a la deriva con interferómetro de átomos fríos frente a un INS de grado de navegación durante una interrupción de GNSS, con la salvedad honesta de que, sin una posición externa, el sesgo del acelerómetro sigue siendo inobservable y por tanto el error sigue creciendo.
  • Detección cuántica de fallos / anomalías (src/quantum_faults.rs): un catálogo de fallos etiquetados con un AUC de ROC con IC por bootstrap y un fallo mínimo detectable con una tasa de falsa alarma fija.
  • Una biblioteca compartida de modelos de error de dispositivos cuánticos (src/quantum_devices.rs) y un banco unificado de comparación cuántico frente a clásico (src/qtrade.rs) sustentan los tres.
• Conjunto de PNT lunar / cislunar. Siete tipos de escenario (kind) ejecutables MODELLED por capas sobre el núcleo CR3BP: Tiempo Coordenado Lunar (tasa secular LTC/TCL − TT, src/lunar_time.rs), observable geodésico de retardo de VLBI lunar (src/lunar_vlbi.rs), estimador por lotes de OD + reloj multitécnica conjunta (src/lunar_combination.rs), realización de marco de referencia (Helmert de 7 parámetros + enlace WGCCRE de la IAU 2015, src/lunar_frame_realise.rs), análisis de volumen de servicio de clase Moonlight / LCNS (src/lunar_service.rs), PNT diferencial lunar (src/lunar_dpnt.rs) y una exportación de interoperabilidad alineada con LunaNet / IOAG (CCSDS-OEM + escala de tiempo lunar en el sobre KIF, src/lunar_interop.rs). Todo MODELLED a partir de parámetros ilustrativos de fuentes públicas; no validado frente a seguimiento real de VLBI / Gateway; sin afiliación ni respaldo de ninguna agencia.
• Seis nuevas validaciones con referencia independiente externa (la matriz de validación cuenta ahora 15 validadas):
  • ADEV / HDEV en un reloj real de cesio 5071A: validado frente a las referencias de puntos por década de Stable32 (tests/cs5071a_reference.rs).
  • OADEV / MDEV / TDEV sobre la referencia PHASE.DAT de Stable32: validado frente a las tablas publicadas de Stable32 (tests/phasedat_reference.rs).
  • AUC de ROC de detección de anomalías sobre telemetría real de ESA OPS-SAT: validado frente a scikit-learn (tests/opssat_ad_reference.rs).
  • Síntesis de funcionales de gravedad ICGEM: validada frente al estándar de gravedad normal GRS80 (γ de Somigliana con 3.5e-12; mapa de perturbación EGM2008, tests/icgem_gravity_reference.rs).
  • Modelo ionosférico de difusión Klobuchar: validado frente a RTKLIB (tests/klobuchar_reference.rs).
  • Núcleo de detección RAIM (171 casos, tests/raim_reference.rs) y nivel de protección SBAS DO-229E con datos reales de EGNOS (fork SBAS-PL de RTKLIB, tests/sbas_reference.rs): ambos validados frente a sus referencias independientes externas.
• Registro de representatividad y brechas hasta el vuelo (src/representativeness.rs). Un registro estructurado que emite cada demostrador: qué es representativo, qué está simplificado y qué separa el modelo del vuelo; el complemento honesto de cada comparación MODELLED.
• Agregación de estudios y ergonomía de la CLI. Un manifiesto de conjunto de escenarios con agregación de estudios en un solo comando, metadatos de estudio estables por hash + --study-name, análisis estático de escenarios con --validate y exposición del nivel de validación por FoM en los informes de estudio.

Cambiado#

• kshana.dev rediseñado en torno a un eje de dominio compartido: capacidades y validación reunidas en un único explorador de dominio con vocabulario común, las nuevas islas validadas visibles, un instrumento de la Tierra animado y fiel a la superficie terrestre, una llamada a la acción para solicitar un estudio, y la marca y los enlaces de Ashforde OÜ.
• README + ARCHITECTURE auditados en cuanto a exhaustividad y honestidad: se corrigieron los recuentos obsoletos de validados (ahora 15 referencias independientes externas), se ampliaron los diagramas y se citan los preprints sobre el Nivel de Protección de Temporización Condicional (arXiv:2606,24210) y la brecha de optimismo por degradaciones de RF (arXiv:2606,22054).
• Las fuentes de paper/ y el flujo del borrador de JOSS se mantienen en el repositorio público.

0.20.0 - 2026-06-22#

Esta versión añade cuatro capacidades de estudio al motor abierto —un Nivel de Protección de Temporización condicional, una puntuación de resiliencia de PNT alineada con un marco, una evaluación de la brecha de optimismo por degradaciones de RF y un front end de receptor definido por software / datos reales—, cada una reproducible con un solo comando y que escribe un artefacto determinista byte a byte. Todos los estudios son MODELLED (calibración sintética o con conjuntos de datos públicos), llevan su procedencia honesta (versión del motor, semillas, hash de configuración) y sus etiquetas de validación, y no son certificaciones.

Añadido#

• Nivel de Protección de Temporización condicional (tpl). Una cota, limitada por holdover, del error de tiempo no detectado bajo spoofing de GNSS, con un umbral mínimo de monitor de k sigmas, una varianza de deriva de van Loan durante la latencia de detección y un tiempo hasta la alarma de CUSUM. Calibrado con un ataque real registrado (JammerTest 2024, escenario 2.1.1) mediante cargo run --release --example tpl_jammertest, que reproduce su tabla de referencia a partir de escalares recuperados de la grabación pública (el conjunto de datos en bruto no se redistribuye).
• Puntuación de resiliencia de PNT alineada con un marco + estudio de inestabilidad de decisiones (resilience). Modelo de arquitectura, puntuación alineada con RPCF, símplex de ponderación de Dirichlet, inestabilidad por tau de Kendall y tasa de cambio del top-1, y colapso de la diversidad de modo común (Hill-N2), con cargo run --release --example resilience_report -- paper-artifacts/resilience-study.json. Tabla de correspondencias en docs/RESILIENCE-CROSSWALK.md.
• Estudio de la brecha de optimismo por degradaciones de RF (impairment_study, impairment_ml, eval_stats). Un panel de 13 detectores sobre un corpus sintético con parámetros fundamentados, una brecha de optimismo dentro y fuera de la distribución, tendencias de leyes de escala con una hipótesis nula de permutación y un predictor de degradación por exclusión de uno, mediante cargo run --release --example optimism_study -- paper-artifacts/optimism-study.json.
• Front end de receptor definido por software (sdr) y adaptadores de datos reales (realdata/). De IQ/IF en bruto a tomas del correlador y SQM, más adaptadores de ingesta (RINEX, u-blox UBX, GnssLogger, JammerTest, Yunnan, SatGrid) y ejemplos de sondeo. Leen grabaciones que el usuario aporta en local; no se incluye ninguna grabación en el repositorio.
• Artefactos de estudio incluidos en el repositorio. Los archivos deterministas byte a byte optimism-study.json y resilience-study.json se versionan ahora en paper-artifacts/ para poder comprobar las cifras de los estudios sin recompilar; siguen siendo regenerables con los generadores anteriores. Los conjuntos de datos en bruto quedan fuera del repositorio (/realdata-cache/).

Cambiado#

• La versión pasó a 0.20.0 en Cargo.toml, CITATION.cff y README; los artefactos del estudio de cruce se regeneraron para que su sello coincida con la versión publicada.

0.19.0 - 2026-06-18#

Cambiado#

• Cambio de licencia de Apache-2.0 a la GNU AGPL-3.0-only, con una licencia comercial disponible en Ashforde OÜ (licencia dual). El motor abierto sigue siendo plenamente abierto y verificable públicamente; el copyleft de red de la AGPL (§13) implica que un derivado cerrado o alojado debe volver al código abierto o adquirir una licencia comercial. Esto defiende el núcleo validado frente a la bifurcación con cierre, a la vez que mantiene la credibilidad de un motor público, ejecutable y auditable. Véanse LICENSE (AGPL) y el nuevo LICENSING.md (qué cubre cada licencia y cuándo se aplica).
  • LICENSE contiene ahora el texto de la AGPL-3.0; las cabeceras SPDX de todas las fuentes se actualizaron a AGPL-3.0-only; NOTICE, README, GOVERNANCE, GLOSSARY, el sitio web y los metadatos de crate/paquete (Cargo.toml, pyproject.toml, CITATION.cff, el crate MCP + la imagen) se actualizaron en consecuencia.
  • Los términos para colaboradores (CONTRIBUTING.md) licencian ahora las aportaciones entrantes bajo la AGPL y otorgan a Ashforde OÜ el derecho a incluir las aportaciones en la edición con licencia comercial, de modo que la licencia dual siga funcionando.
  • Política de dependencias sin cambios pero justificada de nuevo (deny.toml, GOVERNANCE): las dependencias siguen siendo permisivas (Apache/MIT/BSD/ISC). La AGPL se admite solo para el propio crate de kshana: una dependencia con copyleft contaminaría la edición comercial y rompería la licencia dual.
  • Nota para quienes dependen de Kshana: este es un cambio de licencia a copyleft. Quienes se apoyaban en los términos permisivos de Apache-2.0 pueden seguir usando la última versión con Apache-2.0 (v0.18.0 y anteriores, tal como se publicaron); desde v0.19.0 en adelante rige AGPL-3.0 / licencia comercial.

Seguridad#

• Se actualizó pyo3 de 0,24 a 0,29 para eliminar RUSTSEC-2026-0176 / RUSTSEC-2026-0177 (GHSA-36hh-v3qg-5jq4 / GHSA-chgr-c6px-7xpp) de los análisis externos de OSV/dependencias. Ambos son avisos a nivel de función cuyas funciones afectadas (BoundList/TupleIterator::nth/nth_back, PyCFunction::new_closure) Kshana nunca llama, y pyo3 es una dependencia opcional (de la característica python), por lo que la exposición real era nula; pero la actualización mantiene un análisis limpio para los auditores posteriores. Se migró src/python.rs a la API de pyo3 0,29 (tipo de retorno Bound para scenario_kinds; skip_from_py_object explícito en la pyclass RunOutput). Las 11 pruebas del binding de Python pasan con la extensión recompilada.

0.18.0 - 2026-06-17#

Añadido#

• Once nuevos tipos de escenario ejecutables: demostradores de dos licitaciones, un puente de interoperabilidad CCSDS y un conjunto de análisis de misión / entorno de primer orden (todos MODELLED, aditivos; los golden de reproducibilidad existentes no cambian). Cada uno se puede despachar desde CLI / Python / WASM / MCP, incluye un scenarios/<kind>.toml y lleva una etiqueta MODELLED explícita en su JSON de resultados y en su resumen de una línea (una prueba por tipo en tests/dominance_demonstrators.rs afirma que la etiqueta está presente y que la salida nunca contiene la cadena VALIDATED):

  • impairment-eval (src/impairment_eval.rs): banco de evaluación de detección de degradaciones de RF con aprendizaje automático: un corpus sintético etiquetado + un arnés de ROC/AUC independiente del detector + un informe de brecha de optimismo dentro y fuera de la distribución (solo características operativas, nunca datos de campo/IQ).
  • quantum-trade (src/quantum_trade.rs): comparación de PNT cuántico frente a clásico con ingesta de ADEV medida y una envolvente de resiliencia sin GNSS.
  • space-weather (src/space_weather.rs): índices solares/geomagnéticos (tabla IAGA Kp↔ap, Ap diario, F10.7a centrada de 81 días), temperatura exosférica de Jacchia-71 y un acoplamiento de densidad termosférica dirigido por la actividad sobre una atmósfera estática (NO es un modelo de densidad absoluta NRLMSISE).
  • oem-interop (src/oem.rs): puente de importación y ida y vuelta de CCSDS 502,0 OEM para efemérides de GMAT / Orekit / STK (el lector parse_oem, inverso exacto del escritor).
  • launch-window (src/launch.rs): acimut de lanzamiento de dos cuerpos (sin Az = cos i/cos lat), Δv de cambio de plano, bonificación por rotación del emplazamiento y geometría de oportunidades diarias.
  • reentry (src/reentry.rs): corredor de reentrada balística de Allen-Eggers: deceleración máxima, velocidades de g máxima y de calentamiento máximo, altitud de g máxima.
  • eo-coverage (src/eo_payload.rs): geometría de franja / GSD / acceso / revisita de observación de la Tierra (triángulo espacial de SMAD).
  • space-packet (src/space_packet.rs): codificación/decodificación de la cabecera primaria de CCSDS 133.0-B Space Packet con ida y vuelta exacta a nivel de bit.
  • attitude-budget (src/attitude_budget.rs): par de gradiente de gravedad de 3-DOF + presupuesto de error de apuntamiento RSS (presupuesto escalar previo al hardware, no un lazo de control).
  • passes (src/passes.rs): predicción de pasos de salida/puesta de una estación terrestre (AOS/TCA/LOS, elevación máxima, acceso).
  • link-budget (src/linkbudget.rs): ecuación de enlace unidireccional de CCSDS-401 / DSN-810-005 (C/N₀ = EIRP − FSPL − L_other + G/T − k, FSPL / Eb·N₀ / margen / cierre).

• UKF híbrido cuántico + clásico de 17 estados con acoplamiento estrecho, ofrecido como escenario ejecutable (MODELLED). Un nuevo tipo de escenario hybrid-ukf (src/fusion/hybrid_ukf.rs, scenarios/hybrid-ukf.toml) que convierte el filtro de Kalman unscented (UKF) GNSS/INS de acoplamiento estrecho de 17 estados, antes solo disponible por API (src/fusion/tightly_coupled17.rs), en un escenario que los bindings de CLI/Python/WASM/MCP pueden despachar. El vector de error de 17 estados son los 15 estados de error del INS (posición, velocidad, desalineación de actitud, sesgo de acelerómetro y de giróscopo) aumentados con la corrección del sesgo del acelerómetro derivada del CAI —el interferómetro de átomos fríos (src/inertial/quantum_imu.rs) fija el suelo de paseo aleatorio de velocidad q_va, de modo que la deriva a largo plazo en navegación a la deriva es la limitada por el sensor cuántico— y un reloj de 2 estados de fase + frecuencia cuyo ruido de proceso procede del motor de reloj de parámetros q (clock_state::q_from_allan, que asigna el perfil de desviación de Allan de un reloj a las PSD q_wf/q_rw, escaladas a unidades de distancia). La plataforma cuenta con ayuda de GNSS durante un tramo inicial (el filtro aprende los sesgos, la velocidad y el reloj) y luego avanza a la deriva durante una interrupción de GNSS solo con la IMU de CAI + el reloj, de modo que la ejecución demuestra una hibridación de IMU clásica a corto plazo + cuántica a largo plazo. La figura de mérito es la autoconsistencia del filtro: NEES agrupado (Normalised Estimation Error Squared, sobre el subconjunto estimable de posición/velocidad/reloj) y NIS de blancura de la innovación (Normalised Innovation Squared) sobre un conjunto Monte-Carlo, contrastados con sus bandas χ² del 95% (Bar-Shalom §5,4). El filtro ajustado cae dentro de las bandas; un filtro deliberadamente desajustado (los controles q_factor / r_factor) queda señalado: una puerta objetivamente comprobable y discriminante, no un sello automático. La comprobación de NEES / blancura de la innovación es la REFERENCIA INDEPENDIENTE ESTADÍSTICA: una afirmación de autoconsistencia (la covarianza que informa el filtro coincide honestamente con la dispersión de sus propios errores bajo el ruido modelado), NO una garantía de precisión en el mundo real. Alcance honesto: todo es modelled / simulación; las entradas del CAI y del reloj son valores acotados y representativos de la literatura, no hardware medido; el hardware del CAI y su Key-Person siguen siendo del socio; nada de lo aquí expuesto implica TRL > 3, herencia de vuelo ni validación externa (el JSON de resultados y el resumen de una línea llevan estas etiquetas de forma explícita). La trayectoria única, a velocidad constante y nivelada, deja los estados de actitud y de sesgo de la IMU solo débilmente observables, por lo que NEES se evalúa sobre los 8 estados estimables; una trayectoria con maniobras para lograr observabilidad plena de los 17 estados está en la hoja de ruta. Añade además la instrumentación de consistencia Ukf::update_stats (devuelve el NIS de cada actualización) y TightlyCoupled17::{update_gnss_nis, nees, nees_subset}. Todos los escenarios existentes no se ven afectados (aditivo; los golden de reproducibilidad no cambian).

• Navegación secuencial (recursiva) referenciada al terreno: SITAN como filtro en ejecución. Un nuevo tipo de escenario terrain-slam (src/altpnt/sequential.rs, scenarios/terrain-slam.toml) que ejecuta el modelo de medida existente de altímetro frente a DEM época a época con el motor SIR de particle_filter, en lugar de la búsqueda por lotes de lo grueso a lo fino que terrain-nav usa para recuperar un único desfase constante del INS. En cada punto de ruta la nube se propaga con el incremento informado por el INS (corrompido a su vez por el crecimiento de deriva por paso), se repondera según la coincidencia con el terreno y se remuestrea ante degeneración; así, una deriva del INS variable en el tiempo se sigue a lo largo de la trayectoria, algo que un ajuste de desfase constante no puede hacer por construcción. Sobre el DEM sintético la estimación recursiva se mantiene acotada y reconverge (final ≈ 70 m) mientras que la solución inercial sin ayuda diverge sin cota hasta ≈ 5 km; el error por época sigue la distintividad del terreno (avanza a la deriva con el INS sesgado sobre collados llanos y se reengancha sobre relieve distintivo), y el monitor de tamaño efectivo de muestra confirma una nube sana. Alcance honesto: el mapa es conocido y fijo: localización recursiva frente a un DEM almacenado (la mitad de localización del SLAM de terreno), no estimación conjunta del mapa; no circular por construcción (la rampa de deriva inyectada es la verdad independiente). Todos los escenarios existentes no se ven afectados (aditivo; los golden de reproducibilidad no cambian).

• Eje de resiliencia sin GNSS + porciones de demostrador FutureNAV (src/holdover.rs, y cimientos de la envolvente de resiliencia en src/impairment_eval.rs, src/quantum_trade.rs, src/navsignal.rs, src/inertial/quantum_imu.rs, con porciones de verificación de FutureNAV en src/verification.rs). Compone los bloques de PNT alternativo —holdover de reloj, seguimiento de señal, navegación inercial a la deriva, terreno— en una única narrativa de resiliencia ante interrupciones de GNSS. MODELLED; aditivo.

• Kshana Interchange Format (KIF): un sobre de artefacto versionado y autodescriptivo (src/interchange.rs). Una envoltura etiquetada con esquema alrededor de los resultados de escenarios, de modo que un artefacto almacenado lleve consigo su tipo, la versión de esquema y las etiquetas MODELLED/VALIDATED, y los sobres antiguos sigan siendo legibles con compatibilidad hacia delante. Aditivo; el JSON de resultados existente no cambia.

• Modulación / seguimiento de señal de navegación + corrector diferencial de halo/NRHO en CR3BP (src/navsignal.rs, src/cr3bp.rs). Un modelo de primer orden de modulación y seguimiento de señal de navegación, y un corrector diferencial del problema restringido circular de tres cuerpos para órbitas halo / halo casi rectilíneas, incorporado al eje existente de capacidades de espacio profundo. MODELLED.

• Modo de evaluación de desplazamiento de distribución + control de escala de severidad del corpus para impairment-eval (src/impairment_eval.rs). Añade una partición explícita dentro/fuera de la distribución y una escala de severidad del corpus ajustable al arnés de brecha de optimismo ROC/AUC (solo características operativas, nunca datos de campo/IQ).

• ROI de coste por cobertura + asignación del impacto en la integridad de fallos de detección (src/frugal.rs, src/integrity_impact.rs). Una óptica de ROI de ingeniería frugal (coste por unidad de cobertura) y una asignación de la tasa de fallos de detección al impacto en la integridad. MODELLED; aditivo.

• Hoja de parámetros citada del modelo de error del interferómetro de átomos fríos (CAI) (src/inertial/quantum_imu.rs). Una hoja de parámetros acotada y con referencias bibliográficas para el modelo inercial del CAI: las entradas son citadas, no hardware medido (sin afirmación de TRL ni de vuelo); alimenta el suelo de paseo aleatorio de velocidad de hybrid-ukf.

• Gobernanza del proyecto. GOVERNANCE.md, que documenta el modelo de decisión y la frontera entre lo abierto y lo cerrado; la fila de comunidad/gobernanza del mapa de capacidades pasa de none → partial para reflejarlo.

Corregido#

• Nivel de protección de integridad ARAIM: sesgo nominal (b_nom) y σ_URA ahora aplicados. El nivel de protección MHSS resta ahora la proyección unilateral del sesgo nominal b_k = Σ_i |s_i|·b_nom por cada modo de fallo, y usa la sigma de integridad σ_URA (distinta de la sigma de precisión σ_URE) transportada en el Integrity Support Message. Esto hace el nivel de protección más conservador y acorde con las normas y, por tanto, cambia los valores de PL que informan los escenarios de integridad existentes. El ISM/escenario gana los campos #[serde(default)] sigma_ura_m / b_nom_m, de modo que las entradas que los dejan sin definir conservan el comportamiento anterior. Véase docs/ARAIM_REFERENCE.md para la fórmula b_k restaurada y la nota honesta de implementación.

• Consistencia χ² del monitor de spoofing. parity_raim_test usa ahora la ruta compartida de χ² inversa de raim::chi2_quantile, lo que elimina una segunda implementación divergente de χ² para que RAIM y el monitor de spoofing por paridad coincidan en sus umbrales.

• gravity-map-nav conectado al despachador de la CLI. El escenario antes solo era accesible mediante la API; ahora se despacha como un kind= igual que cualquier otro escenario.

• Exactitud de la documentación y de los recuentos. Los recuentos de tipos de escenario del README están ahora fijados a api::list_scenario_kinds().len() mediante una prueba scenario_count_doc_sync, de modo que el recuento documentado ya no puede desviarse del despachador.

0.17.0 - 2026-06-14#

Añadido#

• PNT de espacio profundo y de Marte: motor abierto de navegación radiométrica + simulación GSE. Un eje de capacidad nuevo y totalmente aditivo sobre el núcleo validado en la Tierra (todo escenario terrestre existente es idéntico byte a byte: los golden de reproducibilidad pasan sin cambios y sin regeneración). Añade: un núcleo de dinámica multicuerpo (Body{mu, re, zonals, gravity, rotation, IAU-pole} con gravedad teseral GMM-3 de Marte, un marco de Marte fijo al cuerpo según la IAU, una costura EphemerisProvider enchufable, fechas julianas en dos partes con precisión submicrosegundo y TT↔TDB); observables radiométricos (tiempo de luz iterativo + retardo de Shapiro, Doppler y distancia a dos, una y tres vías mediante la resolución de dos tramos de Moyer, retorno coherente del transpondedor, medición de distancia regenerativa/PN según CCSDS 414, Δ-DOR según CCSDS 506, medios de plasma solar/tropo/iono); análisis y emisión de CCSDS-TDM (503); un filtro de información de raíz cuadrada de dinámica reducida con aceleraciones empíricas RTN, un reloj de a bordo de tres estados y un modelo de arrastre de Marte; un estimador de fusión conjunta de una vía + dos vías; la superficie de escenarios mars-pnt (constelación de relé + LMO/transferencia/ superficie) en CLI, Python, WASM, MCP y el playground; y un simulador de rendimiento GSE de extremo a extremo (geometría → balance de enlace → observables → SRIF → covarianza). Nivel de validación: validado por simulación: OD sintética en bucle cerrado (Mars-LMO ≈ 0,2 m) y autoconsistencia analítica, con la dinámica de Marte centrada en el Sol comprobada de forma independiente frente a DE440 de JPL (xval/anise-mars-od, condicionada a los kernels: 137 m en un arco de 1 día, el residuo honesto de n-cuerpos no modelados). Las precisiones de espacio profundo notificadas son figuras de mérito de simulación / covarianza, no resultados de misiones reales; la validación con datos reales de seguimiento de DSN/ESTRACK sigue en la hoja de ruta. ANISE (MPL-2.0, edition-2024) queda confinado a un crate de comprobación cruzada excluido del workspace, de modo que la puerta de licencias de cargo deny y el trabajo MSRV-1.75 no se tocan.
• Trazas en tierra con la exactitud de una agencia a partir de la orientación terrestre real del IERS. El escenario ephemeris admite un campo opcional eop_finals2000a (el cuerpo incorporado de un archivo finals2000A real del IERS) y reduce la traza en tierra mediante el UT1−UTC y el movimiento polar por época interpolados a partir de él (la misma EopSeries que usa precise_od), sustituyendo los escalares nominales dut1_s/xp_arcsec/yp_arcsec. Los datos viajan en el escenario, de modo que la ejecución sigue siendo reproducible y no necesita sistema de archivos (funciona en el playground de WASM). Un indicador kshana --eop <finals2000A> incorpora un archivo real al escenario desde la CLI. Cierra la asimetría por la que solo precise_od consumía datos reales de orientación terrestre.

Corregido#

• Consistencia de marco en la tasa de distancia. La estación terrestre se proyecta ahora al marco inercial mediante la inversa exacta de la reducción del satélite (frames::itrf_to_teme, deshaciendo el movimiento polar y la rotación sidérea) en lugar de una rotación GMST ciega al movimiento polar, de modo que ambos extremos comparten un marco. El efecto sobre el Doppler notificado queda por debajo del suelo de validación, pero elimina una discrepancia real de marco y una afirmación excesiva de «exacto» en el código fuente.
• carrier_hz se valida. Una frecuencia de portadora nula o no finita devuelve ahora un error en lugar de producir en silencio un Doppler nulo (había hecho infinito λ = c/portadora), igual que la protección ya existente de step_s.

0.16.0 - 2026-06-11#

Añadido#

• Validación del modelo de fuerzas por ajuste de efemérides, contrastada con productos reales de agencias. Un nuevo estimador por lotes de mínimos cuadrados (src/precise_od.rs) con matriz de transición de estado variacional y edición de valores atípicos, impulsado por un modelo de fuerzas completo (PreciseForceModel: geopotencial EGM2008, terceros cuerpos, mareas sólidas + oceánicas + atmosféricas y aceleraciones empíricas CPR/2 por revolución), alimentado por un analizador real de orientación terrestre IERS finals2000A. Validado frente a órbitas de referencia publicadas: Galileo MEO hasta 13 cm tras el ajuste, Swarm-A LEO de ESA y LRO lunar (selenocéntrico, gravedad GRAIL, marco del cuerpo IAU-2015; dinámica reducida 6,6 m, honestamente por encima del objetivo de 5 m en la vía abierta; la vía ANISE/DE440 de grado DE que lo alcanza es un crate excluido del workspace).
• Escenario spoof-detect: un detector integrado de suplantación multicapa que combina paridad RAIM por época, monitores de AGC y de calidad de señal (SQM) y una decisión fusionada, validado frente a los parámetros publicados de escenario de TEXBAT (Humphreys et al., ION GNSS 2012), incluido el caso difícil alineado con la portadora.
• Escenario ephemeris: estado, marcos, traza en tierra y Doppler. Propaga un satélite (TLE→SGP4 o una órbita analítica) y emite, en cada paso, el estado inercial TEME y GCRS (posición y velocidad), la posición terrestre fija ITRF/ECEF, la traza en tierra subsatélite WGS-84 (latitud / longitud / altitud) y el acimut / elevación / distancia topocéntricos con tasa de distancia y Doppler desde una estación terrestre. Accesible desde la CLI, Python, WASM y el servidor MCP, y distribuido como el preajuste «Ground track» del playground web, donde la traza se dibuja sobre un mapa del mundo real (costas Natural Earth 1:110m, incorporadas; sin red ni dependencia externa).
• Exportación CCSDS OEM (--export-oem / export_oem = true): el Orbit Ephemeris Message con velocidad que consumen GMAT / Orekit / STK, a la par de los exportadores SP3 y OMM existentes.
• Mareas terrestres sólidas, oceánicas (FES2004) y atmosféricas (Ray 2001 S2) sobre el geopotencial (IERS Conventions cap. 6), integradas en el modelo de fuerzas.
• Wheels ARM64: la compilación de PyPI produce ahora también wheels de Linux aarch64 (manylinux_2_28), macOS arm64 y Windows arm64.
• Informe técnico ampliado (preprint) enlazado desde el README, y el artículo de JOSS preparado para su envío (ORCID del autor, compilado a PDF en CI en cada cambio).

Cambiado#

• Marcos validados al milímetro frente a vectores publicados de Vallado. La reducción TEME→PEF/ITRF, la cadena completa GCRS→ITRS CIO IAU 2006/2000A y la conversión ECEF→geodésica WGS-84 están ahora fijadas al ejemplo resuelto de Vallado et al. (AIAA 2006-6753) con sus EOP del IERS, y no solo a la autoconsistencia interna.
• Comprobaciones cruzadas independientes de escalas de tiempo. ERA y las escalas UTC/TAI/TT coinciden con hifitime a menos de 1 µs, y las efemérides planetarias DE440 coinciden con JPL Horizons (posiciones geocéntricas de la Luna y el Sol), ambas como puertas de CI siempre activas.
• El playground web oculta la pestaña de figuras de mérito cuando un resultado no lleva filas de figuras de mérito, de modo que los paquetes solo de gráfico (ephemeris, RAIM, spoof) se abren en su gráfico (en ephemeris, la traza en tierra) en lugar de una tabla vacía.
• Los controles deslizantes guiados del playground y el barrido de parámetros funcionan ahora para el escenario de efemérides / traza en tierra: sus parámetros (latitud / longitud de la estación, paso de tiempo, duración, UT1−UTC) son ajustables, y un barrido puede representar la geometría del paso (elevación máxima, Doppler máximo, altitud, velocidad) frente a cualquiera de ellos, por ejemplo la elevación máxima frente a la latitud de la estación. La pestaña Sweep se muestra ahora solo cuando un escenario es realmente barrible, de modo que ningún paquete ofrece un control que no representa nada.
• Se documentó la aproximación SGP4 DUT1 ≈ 0 en el punto de llamada a GMST (un error de rotación ≤ ~13″, muy dentro del propio error de modelo de SGP4) y se actualizó CAPABILITY.md.

0.15.1 - 2026-06-09#

Añadido#

• El complemento de JetBrains Kshana — PNT simulator está ya publicado y aceptado en el JetBrains Marketplace. El README, kshana.dev y la documentación de distribución enlazan a él directamente.

Corregido#

• La publicación en el registro MCP ya se completa con éxito: el description de server.json superaba el límite de 100 caracteres del registro (HTTP 422). Se acortó, y se alineó el nombre del servidor (y la etiqueta de propiedad de la imagen) con el espacio de nombres canónico io.github.ashfordeOU/kshana-mcp.
• La publicación en JetBrains Marketplace ya se completa con éxito: CI volvía a subir la misma versión del complemento que se había listado a mano, algo que el Marketplace rechaza. La versión del complemento sube a 0.1.1, y la protección de idempotencia trata ahora también una respuesta «already contains version» como un éxito sin efecto.
• Invalidación de caché de kshana.dev: las cadenas de consulta con sello de versión de style.css/app.js siguen la versión, de modo que los visitantes que vuelven siempre reciben la compilación actual.

0.15.0 - 2026-06-08#

Añadido#

• kshana-mcp: Kshana como servidor del Model Context Protocol (MCP) (mcp/kshana-mcp/). Un crate independiente, excluido del workspace (el SDK rmcp es edition 2024), que expone el motor validado a agentes y asistentes de IA (Cursor, JetBrains AI Assistant / Junie y cualquier cliente MCP) por stdio. Herramientas: run_scenario, list_scenario_kinds, validate_scenario, export_sp3, export_omm, cada una un envoltorio fino sobre kshana::api.
• Complemento para IDE de JetBrains (ide/jetbrains/). Clic derecho en un escenario .toml → Run Kshana Scenario; las figuras de mérito y el JSON de resultados llegan en flujo a una ventana de herramientas de Kshana. Complemento de Kotlin de plataforma pura, que funciona con cualquier IDE de JetBrains 2024,3+.
• Distribución pública + autopublicación en cada versión para ambos:
  • kshana-mcp en crates.io (cargo install kshana-mcp) mediante publish.yml.
  • kshana-mcp como imagen OCI multiarquitectura en ghcr.io (docker run ghcr.io/ashfordeou/kshana-mcp) mediante un nuevo mcp-publish.yml.
  • kshana-mcp en el registro MCP oficial mediante GitHub OIDC (cero secretos); la entrada del registro (server.json) usa el tipo de paquete OCI con un propietario verificado por etiqueta.
  • el complemento de IDE en el JetBrains Marketplace mediante publishPlugin (condicionado a token, firma opcional de desarrollador) en cada etiqueta de versión.

0.14.1 - 2026-06-08#

Añadido#

• Validación cruzada independiente de marcos de referencia con ANISE/SPICE (xval/anise-frames/). Un crate independiente, excluido del workspace, contrasta la reducción CIO IAU 2006/2000A de kshana (kshana::cio::gcrs_to_itrs_matrix, GCRS→ITRS) con ANISE (la reimplementación en Rust puro de NAIF/SPICE), que rota GCRF→ITRF93 a partir de earth_latest_high_prec.bpc de JPL, con los mismos parámetros de orientación terrestre IERS finals2000A aplicados a ambos lados, en ocho épocas trimestrales 2020–2023. Las dos realizaciones independientes del marco coinciden con una rotación relativa máxima de 0,028″: ≤ 0,86 m en tierra, ≤ 0,93 m en LEO, ≤ 3,6 m en órbita GNSS, alcanzando con amplio margen la comprobación cruzada de marcos «< 10 m» que figura desde hace tiempo en la ROADMAP (complementa, y no sustituye, a los anclajes bit a bit existentes de SOFA/ERFA). El crate está aislado porque anise + hifitime son MPL-2.0 / edition-2024 y nunca deben entrar en el grafo de dependencias de kshana publicado, en su Cargo.lock, en la puerta de licencias de cargo deny ni en la compilación MSRV; ANISE se fija con default-features = false. Incluye un binario frame-xval (obtiene el BPC de ~5 MB, imprime una tabla, escribe report.{json,md}), una puerta de pruebas que se omite sola sin kernel o sin red, y un trabajo de CI opcional solo workflow_dispatch (nunca bloquea main). Documentado en docs/VALIDATION.md (fila CIO) y ROADMAP.md.

Corregido#

• Playground apto para móviles. Se corrigió el desbordamiento horizontal de .panel del playground en teléfonos (un elemento de rejilla CSS con min-width: auto por defecto se renderizaba ~100 px más ancho que el viewport) mediante min-width: 0 y controles con ancho protegido; verificado limpio a 360 / 390 / 414 / 768 px. Se alinearon los botones de acción «Pin to compare» / «Download report» (cajas de margen iguales en la fila flex). Se agrandaron los botones de ejecución, los controles deslizantes, los selectores y los enlaces de navegación hasta el mínimo de objetivo táctil de ~44 px de WCAG 2.5.5 / Apple-HIG en teléfonos y dispositivos táctiles, sin cambiar el tamaño en escritorio.

0.14.0 - 2026-06-08#

Corregido#

• Refuerzo de robustez a partir de una pasada adversaria de pruebas de choque. (1) sbas_protection_level rechaza ahora elevación/acimut/varianza no finitos y diagonales de covarianza negativas o no finitas (una geometría casi singular ampliada por una σ pequeña podía antes colarse por la puerta del pivote absoluto y devolver un VPL NaN / un HPL absurdo como un Some válido: un fallo silencioso de integridad). (2) El propagador numérico (propagate/propagate_dopri) falla cerrado ante un estado inicial no finito en lugar de hacer girar el controlador adaptativo para siempre. (3) El asistente de celdas DEM ya no entra en pánico con una rejilla de una sola muestra (1×N). (4) El acimut de lunar_look_angle se mantiene estrictamente en [0, 360). (5) SphericalHarmonicField::from_gfc rechaza GM/radio no físicos (NaN / no positivos).

Añadido#

• Binario validation_report + artefacto de versión: un generador sin dependencias que emite un resumen de validación HTML de una página, listo para imprimir, que indexa cada validación impuesta por CI (SGP4 666/666, EGM2008, marcos bit a bit, Allan del NIST, hojas de datos de IMU, ARAIM/SBAS, reproducibilidad en 3 SO, cobertura) con su prueba y su referencia independiente externa. El flujo de trabajo de versión genera kshana-validation-summary.html y lo adjunta (con procedencia SLSA) a cada versión etiquetada.
• pytest de interoperabilidad con numpy + refuerzo de wheels: tests/python/test_numpy_interop.py (ejecutado en CI) más un contenedor manylinux fijado y un paso de verificación auditwheel show en la compilación de wheels.
• Tutoriales y formación: docs/tutorials/ (tres tutoriales resueltos, escenarios anotados por dominio, ejercicios Tier-1/2/3) con tests/tutorials.rs fijando cada número citado a la salida del motor en vivo.
• Artefactos de envío externo (paper/, notebooks/, submissions/): un borrador de artículo de JOSS, un cuaderno cuántico frente a clásico y kits listos para presentar a awesome-gnss / ESA Navipedia / NASA ASCL / ESA ESSR / ION/IAC, además de FUNDING.yml, que preparan los pasos externos del envío.
• Navegación alt-PNT referenciada al terreno y combinada (módulo altpnt): un navegador de correlación de terreno TERCOM/SITAN sobre un DEM (cargador .hgt + generador de fixtures sintéticos) y un navegador combinado de gravedad + magnético (IGRF) + terreno sin GPS, expuestos como los tipos de escenario terrain-nav y combined-altpnt. Validado por la convergencia de la correlación de terreno (se recupera un desplazamiento inyectado conocido) y por un error acotado del filtro combinado sobre una ventana sin GPS.
• Geometría LunaNet LANS (lunar): sitios lunares de superficie con nombre (Apollo 11/15/16, borde de Shackleton) con coordenadas selenográficas de referencia, ángulos de visión desde la superficie (az/el/distancia), visibilidad/cobertura y DOP del sitio, validados frente al radio de la Luna, las coordenadas publicadas de los sitios y la identidad de elevación de 90° para la vertical radial.
• Playground guiado en el navegador: controles deslizantes de modo guiado, un panel de salida con pestañas, una superposición de recorrido de primera ejecución, modos de barrido de parámetros y de superposición de varias ejecuciones, una vista de órbita 3D en canvas/SVG sin dependencias (el paquete de órbita emite ahora un eci_track aditivo), un modo de incrustación/iframe y la descarga como informe HTML, cada uno con pruebas unitarias de node en CI.
• Modelo de error de IMU validado con hoja de datos (tests/imu_allan_spec.rs): ARW/VRW/inestabilidad de sesgo de ADIS16465/16488/16460 recuperados de la desviación de Allan sintetizada y comprobados frente a las especificaciones del fabricante (identificación NIST SP1065 / IEEE 952).
• Validación de los estimadores de Allan de NIST SP1065 (tests/allan_nist_sp1065_1000point.rs): los cuatro estimadores reproducen las desviaciones de referencia publicadas de 1000 puntos y los límites de confianza de la Tabla 32.
• Niveles de protección SBAS / DO-229E, libre de ionosfera L1/L5 y un mapa de compliance DO-316 (módulo sbas). sbas_protection_level forma la matriz de geometría ponderada a partir de la elevación/acimut de cada satélite y de su presupuesto de error UDRE/GIVE/aerotransportado/tropo, invierte la matriz normal (orbit::invert4 compartida) y proyecta las varianzas a HPL/VPL mediante los factores K de DO-229E (PA 6.0/5.33, NPA 6,18). iono_free_l1l5 añade la pseudodistancia GPS L1/L5 libre de ionosfera (IS-GPS-705, γ₁₅ = 1.79327), validada para cancelar el retardo ionosférico de primer orden independiente del motor. do316_compliance_map traza los requisitos de DO-316/DO-229E hasta las funciones que los implementan. Validado frente a las definiciones cerradas de los factores K, la geometría de referencia inv(GᵀG) de numpy y la identidad de covarianza por dos vías; la comprobación cruzada de ajuste a la norma de los PL publicados con RTKLIB/gLAB está documentada como pendiente de revisión en docs/COMPLIANCE.md.
• Gravedad completa de armónicos esféricos teserales: el campo EGM2008 hasta grado/orden 70. Un nuevo gravity_sh::SphericalHarmonicField evalúa el geopotencial y su aceleración en el marco terrestre fijo a partir de coeficientes C̄_nm, S̄_nm totalmente normalizados, usando la estable recurrencia normalizada de Legendre de Holmes–Featherstone (desnormalizar desbordaría con este grado). Los coeficientes incluidos son el producto EGM2008 de NGA (dominio público, vía ICGEM), incorporados en egm2008_data.rs y reproducidos bit a bit por tools/gen_egm2008.py a partir de tools/egm2008_to70.gfc, que está en el repositorio; cualquier modelo ICGEM .gfc se carga mediante from_gfc. Validado frente a tres referencias independientes: el colapso a masa puntual (solo C̄00 = −μr/|r|³), un campo solo zonal que reproduce el forces::zonal_accel existente hasta ~1e-9, y la aceleración analítica que coincide con el gradiente por diferencias finitas del potencial sumado directamente hasta <1e-6.
• Aceleración de Lense–Thirring (arrastre de marcos) de relatividad general (forces::lense_thirring_accel, IERS 2010 Ec. 10,12), el término gravitomagnético más allá de la corrección de Schwarzschild existente, integrado en el propagador numérico mediante un nuevo indicador ForceModel::lense_thirring(). Validada como lineal en el momento angular de la Tierra y de 1 a 2 órdenes de magnitud por debajo del término de Schwarzschild, el régimen de las mediciones de LAGEOS / Gravity Probe B.
• Un trait Propagator que unifica los propagadores de órbita analítico y numérico. El propagador numérico de modelo de fuerzas de Cowell es ahora un par de primera clase de SGP4: un nuevo tipo NumericalPropagator (estado inicial + ForceModel + Tolerance + elección de duplicación de paso o Integrator de Dormand–Prince) y Sgp4 implementan ambos propagator::Propagator, cuyo state_at(t_seconds) -> StateVector devuelve el estado TEME inercial en unidades del SI (m, m/s), de modo que los dos son intercambiables tras un Box<dyn Propagator>. La implementación de SGP4 es la conversión exacta de km/min a SI del método inherente (verificada por una prueba de igualdad); la implementación numérica supera la misma puerta submétrica de Kepler exacto a través del trait, los dos controladores adaptativos coinciden y un PropagatorError expone el código SGP4 subyacente.

0.13.0 - 2026-06-08#

Esta versión cierra la mayor brecha de corrección del motor: la orientación terrestre y la reducción de marcos de referencia se hacen ahora con calidad de implementación de referencia (validadas bit a bit frente a ERFA/SOFA), la pila de integridad gana ARAIM de doble constelación sobre TLE reales de GPS+Galileo, y las capas de propagación, sensor cuántico, lunar/cislunar y geomagnética se profundizan, junto con una API de Python tipada, un playground de navegador más rico y una matriz de reproducibilidad en tres SO. Aspectos destacados:

• Marcos de referencia, bit a bit. Nutación IAU 2000A y 2000B completas, precesión IAU 2006, reducción GCRS↔ITRS IAU 2006/2000A basada en CIO (X, Y, s), movimiento polar del IERS y marcos de salida TEME→GCRS/ITRS, cada uno validado bit a bit frente a rutinas de referencia ERFA/SOFA.
• ARAIM de doble constelación (GPS + Galileo) sobre TLE reales, con HPL/VPL, salida de diagrama de Stanford y un docs/ARAIM_REFERENCE.md abierto.
• PNT cislunar: un propagador CR3BP Tierra–Luna, marcos MCI↔MCMF, coordenadas selenográficas y un escenario ejecutable de integridad lunar de LunaNet.
• Sensado cuántico: sistemáticas de Coriolis y de AC-Stark para el interferómetro de átomos fríos, un barrido de deriva y validación frente al presupuesto de Freier (2016).
• Modelo geomagnético de campo principal IGRF-14, autocontenido y validado.
• API de Python tipada (PyO3 RunOutput/ScenarioMeta, .data(), scenario_kinds, validate_toml, stubs de tipos) con una compilación de wheels en CI, además de salida de propagador GCRS/ITRS de primera clase y exportación CCSDS OMM.
• Credibilidad y reproducibilidad: una comparación directa de exactitud de SGP4 con el crate independiente sgp4, una puerta de cobertura en CI (~97% de líneas en src/) y una matriz de reproducibilidad en tres SO (ubuntu/macos/windows).

Cambiado#

• Todos los gráficos del playground coinciden ahora con el tema del sitio. Los doce generadores de gráficos SVG (el gráfico de resultado/holdover (src/report.rs + src/chart.rs), el gráfico de desviación de Allan (web/app.js) y cada gráfico de escenario (src/hybrid.rs, jamming.rs, timetransfer.rs, spoof.rs, raim.rs Stanford + disponibilidad, lunar.rs, ensemble.rs, sweep.rs, gnss_sim.rs, fusion/pack.rs, inertial/mod.rs)) usaban paneles azul marino fríos (#0e131b), ejes/texto gris frío y una paleta de series rojo/azul/púrpura discordante. Ahora usan en todas partes la paleta cálida de grafito: paneles --bg, cuadrícula cálida --line, etiquetas --fg, con una asignación coherente de series: cuántico = dorado miel (--accent-bright), clásico = ámbar cálido (--partial), especificación/límite = --crit. Las vistas con codificación de seguridad conservan su significado: el diagrama de Stanford de RAIM sigue siendo verde (disponible) / ámbar (engañoso) / rojo (peligroso) / acero apagado (no disponible), y HPL/VPL se leen como dorado/bronce.
• Los gráficos se describen ahora a sí mismos al guardarse o descargarse. Ambos gráficos incorporan su título en el SVG (el título del gráfico de Allan + el subtítulo «lower is better» antes eran solo HTML alrededor de la imagen, de modo que una imagen guardada no tenía pie), y ambos llevan un pie de procedencia, Kshana v<version> · <scenario-hash> · kshana.dev, de modo que un gráfico descargado se sostiene por sí solo y sigue siendo reproducible.
• Todos los gráficos llevan ahora el pie de procedencia. El pie, Kshana v<version> · scenario <hash> · kshana.dev, se estampa de forma centralizada para todos los tipos de escenario en api::run_toml (antes solo estaba en los gráficos de holdover y de Allan), de modo que cualquier imagen guardada o descargada (desde el playground, desde la exportación .chart.svg de la CLI o desde el cuadro de mando HTML) identifica su versión, la huella del escenario y la fuente. El hash se etiqueta scenario por claridad y procede del scenario_hash del resultado cuando existe, con un respaldo de hash de la fuente para los informes de integridad/lunares. Qué es la huella y por qué está ahí se documenta en la sección «Output» del README y en docs/PROVENANCE.md.

Corregido#

• raim::chi2_quantile y el muestreador de ruido de Stanford de RAIM ya no entran en pánico con entradas fuera de rango / no finitas (un hallazgo de fuzzing dependiente del orden de read_dir procedente de los nuevos escenarios ARAIM). chi2_quantile protege ahora p/k como normal_quantile (devolviendo un valor de frontera en lugar de entrar en pánico con assert!), y el Normal del ruido de Stanford de disponibilidad se limita a una σ estrictamente positiva, de modo que la pila de integridad/ARAIM nunca entra en pánico con escenarios mutados o mal configurados.

Añadido#

• Matriz de CI de reproducibilidad multiplataforma. Un nuevo trabajo reproducibility-matrix ejecuta las pruebas de reproducibilidad en ubuntu-latest, macos-latest y windows-latest en cada envío. Como el JSON de resultados completo no es idéntico byte a byte entre sistemas operativos (divergencia de libm en la última ULP), afirma exactamente la proyección invariante a la plataforma (la huella de la entrada más la forma de la salida, fijada por escenario como golden SHA-256 en tests/golden/ por el nuevo tests/cross_platform_golden.rs) junto con las fijaciones numéricas (golden.rs, hasta 1e-6), los estados SGP4 (sgp4_verification.rs, hasta 2e-5 km) y el determinismo en un mismo proceso (determinism.rs). En conjunto demuestran la reproducibilidad multiplataforma en tres SO sin la fragilidad de calcular hashes exactos de la salida completa byte a byte. docs/REPRODUCIBILITY.md documenta la división.
• Puerta de cobertura de código en CI. Un nuevo trabajo coverage ejecuta cargo-tarpaulin con el motor basado en fuente de LLVM, publica un informe lcov como artefacto de compilación e impone un suelo de cobertura de líneas sobre src/ (excluidas las tablas de datos generadas, el punto de entrada de la CLI, las pruebas y los recursos web). La cobertura de líneas medida es de ~97% en src/ (SGP4 y los módulos de reloj ≥95%); la puerta se fija en 85%, por encima del objetivo de ≥80% y alejada del valor medido, de modo que detecta regresiones sin fallar de forma intermitente. Se publica una insignia de cobertura en el README.
• SGP4/SDP4 cara a cara con el crate independiente sgp4. Una prueba nueva (tests/sgp4_crate_comparison.rs) contrasta el propagador de Kshana con la biblioteca SGP4 de Rust más usada (neuromorphicsystems/sgp4, añadida como dev-dependency solo para pruebas) sobre los mismos 666 vectores de AIAA 2006-6753. Con ambos operando con el modelo de gravedad WGS72 que usan los vectores, las dos implementaciones independientes coinciden a nivel submicrométrico en órbitas cercanas a la Tierra y resonantes y a 4,12 mm en el peor caso en todos los regímenes, y ambas reproducen la tabla de referencia tcppver.out. La tabla de comparación incorporada al repositorio (tests/fixtures/sgp4_comparison.md, regenerada mediante KSHANA_REGEN_FIXTURES=1) desglosa el resultado por régimen (LEO/MEO, espacio profundo, resonancia de ½ día y de 1 día) y anota los cuatro casos deliberadamente patológicos que el crate rechaza en la construcción. Las aserciones en vivo mantienen a ambos dentro de 2e-5 km de la referencia y coincidiendo entre sí dentro de 4e-5 km: una protección contra regresiones, no un hecho aislado. Esto es linaje competitivo: corrección frente a una base de código independiente, no solo frente a una tabla estática. (El from_elements por defecto del crate usa WGS84 y por tanto difiere de la referencia WGS72 en ~km, algo que se señala con honestidad en la prosa de la tabla.)
• La exportación CCSDS OMM es ahora accesible de extremo a extremo. El escritor de OMM (src/omm.rs) no tenía antes ninguna ruta de CLI/API; los elementos medios de un escenario orbit pueden publicarse ahora como un catálogo OMM CCSDS 502.0-B-2 (un mensaje OMM KVN por satélite definido por TLE) mediante kshana <orbit.toml> --export-omm out.omm, o bien export_omm = true en el escenario escribe automáticamente <scenario>.omm (a imagen del --export-sp3 existente). Cada mensaje lleva el número de catálogo NORAD real del satélite, el designador internacional COSPAR (YYYY-NNNP) y la época (en forma CCSDS de día del año), analizados de la línea 1 del TLE por el nuevo tle::parse_tle_identity; la línea de nombre se convierte en OBJECT_NAME (o, si no, en OBJECT <id>). CREATION_DATE es la época del escenario, no la hora de reloj, de modo que la salida es reproducible. API nueva: api::export_omm / api::auto_export_omm, OmmFile::from_tle_block, OrbitClockScenario::to_omm_string. Un escenario sintético Walker o RINEX (sin elementos medios de TLE) da error en lugar de emitir un archivo vacío. Validado frente a la instantánea incorporada de 30 satélites gps-ops (tests/sp3_export_roundtrip.rs).
• Lecturas interactivas al pasar el cursor por los gráficos del playground. Mover el cursor sobre un gráfico ajusta una retícula a la muestra más cercana y muestra una información emergente con el valor (web/hover.mjs, integrada en web/app.js). En el gráfico de Allan lee τ y el σ_y(τ) de cada reloj; en los gráficos de escenarios de series temporales (clock holdover, dead-reckoning, time-transfer, PNT híbrido, GNSS/INS) lee el tiempo y el valor de cada suite en las unidades propias del gráfico (ns / m / ps / utilización), analizado del resultado para que la lectura coincida con la curva. Los diagramas especializados (RAIM, spoof, sweep) no reciben superposición. Los gráficos siguen siendo <img> blob autodescriptivos: la superposición es una retícula transparente + información emergente por encima, de modo que la descarga, la comparación y la exportación no se tocan. La matemática de coordenadas (muestra más cercana, cursor→fracción del gráfico, análisis de polilíneas) tiene pruebas unitarias (web/hover.test.mjs, ejecutadas en CI).
• Modo de comparación A/B en el playground. Se fija cualquier ejecución como línea base A, se ejecuta un segundo escenario y ambos se muestran lado a lado con una tabla de diferencias de figuras de mérito (holdover, RMS/p95 de temporización, disponibilidad) que colorea al ganador por métrica (web/compare.mjs, integrada en web/app.js; lógica de diferencias con pruebas unitarias en web/compare.test.mjs, ejecutadas en CI). Todos los valores se insertan como texto y todos los gráficos mediante <img> blob, de modo que nada de una cadena de escenario se inyecta nunca como marcado.
• Botones de descarga de gráficos (SVG + PNG). Cada gráfico del playground tiene ahora una barra de herramientas «Download SVG / PNG» acorde con el tema (web/chartdl.mjs, integrada en web/app.js). SVG devuelve el original fiel y escalable; PNG rasteriza esa misma imagen autodescriptiva a 2x para diapositivas y documentos. Los archivos se nombran con su procedencia (kshana-<chart>-v<version>-<scenario-hash>.<ext>) y la lógica de nombre de archivo y tamaño tiene pruebas unitarias (web/chartdl.test.mjs, ejecutadas en CI).
• Modelo geomagnético de campo principal IGRF-14 (src/igrf.rs). El campo estándar de armónicos esféricos de la IAGA (grado/orden 13, época 2025,0 + variación secular 2025–2030; coeficientes generados por máquina a partir del igrf14coeffs.txt oficial mediante tools/gen_igrf.py en src/igrf_data.rs, reproducibles bit a bit). Una síntesis normalizada de Schmidt devuelve el vector de campo (norte/este/abajo) y los elementos derivados (declinación, inclinación, intensidad horizontal/total) en cualquier lugar/fecha geodésicos, además del polo geomagnético y la intensidad del dipolo: la contrapartida magnética del correlador de mapas de gravedad para la navegación PNT alternativa. Validado de forma autocontenida: la síntesis coincide con el dipolo inclinado exacto en forma cerrada, el campo analítico completo de grado 13 coincide con una diferencia finita del potencial escalar, el eje del dipolo reproduce el polo geomagnético conocido (~80,7°N, −72,7°E) y una intensidad de ~29,7 µT, y el campo global es físico.
• Enlaces de Python tipados (src/python.rs). Además de run/run_full, de cadena de entrada y cadena de salida, el módulo expone ahora una clase tipada RunOutput (.json, .svg, .summary y un acceso .data() que devuelve el resultado analizado a un dict nativo de Python, sin volver a analizar JSON y envolvible en NumPy), además de run_typed, scenario_kinds() (lista analizada de dicts de metadatos) y validate_toml() (una lista de mensajes de error que no lanza excepciones). Incluye un stub de tipos PEP 561 (kshana.pyi + py.typed) para mypy/pyright/editores y una guía de inicio rápido docs/PYTHON_API.md. Las funciones existentes no cambian.
• Marcos de salida de primera clase para los propagadores (enum Frame de src/orbit.rs + position_in_frame + state_gcrs). Cualquier Propagator (Kepler, SGP4, RINEX, GLONASS, SP3) puede ahora emitir su posición en TEME, GCRS (≈ J2000) o ITRS (fijo a la Tierra): TEME de forma nativa, GCRS mediante la reducción validada TEME→GCRS e ITRS encadenándola con la rotación gcrs_to_itrs CIO IAU 2006/2000A, y su estado GCRS completo (posición + velocidad) mediante state_gcrs. La salida inercial de la fecha ya no es solo TEME.
• Reducción celeste a terrestre IAU 2006/2000A basada en CIO (src/cio.rs). La cadena GCRS↔CIRS↔ITRS moderna y sin equinoccio: coordenadas del CIP X, Y leídas de la matriz de sesgo-precesión-nutación IAU 2006/2000A (reutilizando la precesión FW validada + la nutación 2000A con el ajuste P03 de eraNut06a), la serie de 66 términos del localizador de CIO s (eraS06, generada por máquina a partir de la referencia ERFA mediante tools/gen_s06.py en src/cio_s06_data.rs, reproducible bit a bit), la matriz GCRS→CIRS (eraC2ixys), el ángulo de rotación de la Tierra (eraEra00) y la rotación completa GCRS→ITRS (eraC2tcio, compuesta con el movimiento polar del IERS existente). Validada bit a bit frente a los vectores de prueba publicados de eraXys06a (X=0.5791308482835292617e-3, Y=0.4020580099454020310e-4, s=-0.1220032294164579896e-7 a JD_TT 2453736,5), eraC2ixys y eraEra00. Se muestra que la cadena CIO y la reducción TEME heredada de equinoccio/GMST-1982 coinciden salvo por su diferencia documentada de convención de tiempo sidéreo de ≈2·(ecuación de los equinoccios). Esta es la reducción rigurosa que la vía de equinoccio/GMST aproximaba.
• Serie completa de nutación IAU 2000A (nutation_iau2000a de src/nutation.rs, nutation_matrix_2000a). El modelo MHB2000 completo, con 678 términos lunisolares + 687 planetarios, exacto a < 0,1 mas, junto a la truncación 2000B de 77 términos existente. Las tablas se generan por máquina a partir de la referencia nut00a de IAU SOFA / ERFA mediante tools/gen_nut00a.py en src/nutation_iau2000a_data.rs (el generador reproduce el archivo incorporado bit a bit), y toda la serie, incluidos los dos conjuntos de argumentos fundamentales IERS-2003 y MHB2000 y las longitudes planetarias, está validada bit a bit frente al vector de prueba publicado de eraNut00a (Δψ = −0.9630909107115518e-5, Δε = 0.4063239174001679e-4 a JD_TT 2453736,5, hasta 1e-13 rad). La reducción TEME→GCRS por defecto conserva la serie 2000B (~1 mas, por debajo de la simplificación de rotación del marco de velocidad de la cadena); nutation_matrix_2000a expone la matriz de la fecha de < 0,1 mas para quien la necesite.
• Escenario ejecutable de integridad lunar (kind = "lunar-integrity", scenarios/lunanet-araim.toml). Conecta el paso de nivel de protección del polo sur lunar (src/lunar.rs LunarScenario → south_pole_hpl_pass) con el ejecutor de escenarios, con un LunarReport JSON y un gráfico SVG de HPL frente al tiempo, de modo que el caso de integridad cislunar es accesible directamente desde la CLI. Deja ver con honestidad la brecha: con el σ_URE de LANS de 30 m, el HPL del polo sur (≈ 260–450 m) supera un límite de alerta de 50 m (0 % disponible); la integridad PNT lunar aún no se alcanza.
• Disponibilidad de ARAIM de doble constelación sobre TLE reales de GPS+Galileo y conexión con el ejecutor de escenarios (src/raim.rs, src/orbit.rs, scenarios/araim-gps-galileo.toml). Añade araim_dual_constellation_availability (el motor ARAIM avanzado, con fallos de un solo satélite y de toda la constelación, ejecutado sobre una cuadrícula de tiempo) y visible_positions_labeled, y lo conecta con el ejecutor IntegrityScenario mediante un indicador araim_dual, de modo que un estudio ARAIM multi-GNSS es accesible directamente desde TOML. Una prueba con datos reales (tests/araim_dual_real_data.rs) sobre instantáneas incorporadas de Celestrak GPS+Galileo del 2026-06-07 muestra que agrupar Galileo eleva la disponibilidad de ARAIM de 0,21 a 0,67 con un VAL exigente de 12 m (10,5→21,8 satélites a la vista), mientras que el modo robusto a fallos de constelación queda fundamentalmente limitado con solo dos constelaciones: la razón cuantitativa por la que la integridad robusta de doble constelación empuja hacia una tercera constelación o hacia SBAS. Residuo honesto: la reproducción numéricamente exacta de la Tabla A-3 de la EU ARAIM TN frente a una única época fijada a una versión, y un registro de fixture en Zenodo.
• Problema circular restringido de tres cuerpos (CR3BP) para el sistema Tierra–Luna (src/cr3bp.rs). Un núcleo nuevo de dinámica cislunar que los propagadores de dos cuerpos/SGP4 no pueden ofrecer: ecuaciones de movimiento en marco rotatorio (cr3bp_accel), un propagador RK4 (propagate_cr3bp), la integral de la constante de Jacobi (jacobi_constant) y los cinco puntos de Lagrange (lagrange_points). Validado frente a anclajes en forma cerrada / publicados: los puntos colineales Tierra–Luna (L1 ≈ 0,83692, L2 ≈ 1,15568, L3 ≈ −1,00506), los equiláteros exactos L4/L5 = (½−μ, ±√3/2, 0), los cinco confirmados como equilibrios del campo, Jacobi conservada a la precisión del integrador durante la propagación, y la fuerza restauradora fuera del plano que hace posibles las órbitas halo/NRHO. Esta es la base para representar una NRHO real. Residuo honesto: condiciones iniciales NRHO 9:2 periódicas corregidas diferencialmente, el modelo excéntrico/de efemérides (DE) y la transformación desnormalizada a los marcos selenocéntricos de src/lunar.rs.
• Movimiento polar del IERS y reducción TEME→ITRF (src/frames.rs). Añade polar_motion_matrix (iauPom00 de SOFA: W = Rx(−y_p)·Ry(−x_p)·Rz(s′) con el localizador TIO s′), pef_to_itrf / itrf_to_pef y teme_to_itrf, la rotación TEME→PEF basada en GMST seguida del movimiento polar, que completa una posición terrestre fija con precisión ITRF sobre el teme_to_ecef solo de GMST (el movimiento polar es un efecto de decenas de metros al radio orbital). x_p/y_p son magnitudes observadas del IERS que aporta quien llama. Residuo honesto: una cadena totalmente basada en CIO (X, Y, s) y una comprobación cruzada numérica de ANISE/SPICE de <10 m siguen siendo trabajo posterior.
• Sistemáticas del interferómetro de átomos fríos, barrido de deriva y validación con un dispositivo publicado (src/inertial/quantum_imu.rs, docs/QUANTUM.md). Amplía el acelerómetro CAI de primeros principios con las dos sistemáticas deterministas principales: la fase de Coriolis/rotación Φ_cor = 2·k_eff·v_⊥·Ω·T² (coriolis_phase, con el sesgo de aceleración equivalente 2·Ω×v mediante coriolis_accel_bias) y la fase de desplazamiento lumínico AC-Stark Φ_LS = (δ_LS,1 − δ_LS,3)/Ω_eff (ac_stark_phase, que se cancela por simetría π/2–π–π/2 para un desplazamiento constante). Añade cai_drift_sweep (deriva de posición por navegación a ciegas frente al tiempo de ciclo, el núcleo de una comparación cuántico frente a clásico) y una prueba de validación frente al gravímetro móvil de Freier et al. 2016 (arXiv:1512,05660): el suelo de ruido de proyección cuántica modelado queda por debajo del ruido de corto plazo publicado de 96 nm/s²/√Hz, y a unos ~2 órdenes de magnitud de él. docs/QUANTUM.md actualizado. Residuo honesto: sistemáticas de frente de onda/apuntamiento del haz, resolución de la ambigüedad de franjas, la reproducción exacta de las pruebas de vuelo de CARIOQA-PMP / Boeing-AOSense (requiere PSD de plataforma publicadas) y un preajuste para el playground de JS.
• Reducción de marcos cislunares y un paso de integridad en el polo sur lunar (src/lunar.rs). Amplía el motor ARAIM lunar con la rotación MCI↔MCMF (inercial centrado en la Luna ↔ fijo a la Luna) (mci_to_mcmf / mcmf_to_mci, un modelo simplificado de rotación media a la tasa sidérea lunar), latitud/longitud/altitud selenográficas (mcmf_to_selenographic / selenographic_to_mcmf) y south_pole_hpl_pass: un receptor aterrizado en la región Artemis frente a un conjunto representativo de relés LunaNet durante un paso de 24 h, que cuantifica con honestidad la brecha de integridad: con el σ_URE nominal de LANS de 30 m, el nivel de protección es finito pero supera un límite de alerta de operaciones de superficie de 50 m. Residuo honesto: la efeméride precisa de la NRHO de LANS (una órbita cislunar de 3 cuerpos), la libración física / el polo lunar con precesión (DE421/SPICE) y un escenario TOML de LunaNet siguen siendo trabajo posterior.
• Mensaje de soporte de integridad ARAIM, SVG del diagrama de Stanford y la referencia abierta de ARAIM (src/raim.rs, docs/ARAIM_REFERENCE.md). Añade un IntegritySupportMessage explícito (σ_URA / σ_URE / b_nom / P_sat / P_const, con los valores de referencia GPS+Galileo de WG-C y conversores .fault_priors() / .dual_fault_priors() hacia los motores araim_raim de fallo único y araim_dual_raim de toda la constelación), un renderizador autónomo stanford_svg del diagrama de integridad de Stanford (las cuatro zonas, el límite PL = error, las guías del límite de alerta, un marcador codificado por color por época) y docs/ARAIM_REFERENCE.md, que documenta el algoritmo, el ISM, las hipótesis de fallo, el contrato de nivel de protección y el beneficio de la doble constelación. Las pruebas demuestran la ganancia de geometría/redundancia (agrupar una segunda constelación estrecha el HPL de fallo único) y la tolerancia a fallos de constelación (el usuario de doble constelación sobrevive a la pérdida de una constelación entera; un usuario de una sola constelación no). Residuo honesto: reproducir numéricamente la Tabla A-3 de la EU ARAIM TN / la cifra de disponibilidad del 15–25 % frente a una instantánea real de TLE fijada a una versión, un registro de fixture en Zenodo y conectar araim_dual_raim con el ejecutor de archivos de escenario.
• Nutación IAU 2000B y reducción inercial completa TEME→GCRS/J2000 (src/nutation.rs). Añade la segunda y la tercera pieza de una reducción inercial de marcos verdadera sobre la precesión IAU 2006 ya incluida: la serie de nutación lunisolar MHB2000 de 77 términos (nutation_iau2000b, la truncación estándar IAU 2000B exacta a ~1 mas) con los argumentos fundamentales de Delaunay y la matriz de nutación iauNumat de SOFA, y la cadena de Vallado AIAA-2006-6980 TEME→TOD (ecuación de los equinoccios) → TOD→MOD (nutación) → MOD→GCRS (sesgo-precesión) expuesta como teme_to_gcrs(r, v, jd_tt) / gcrs_to_teme. La serie, los argumentos y las constantes de unidades se transcriben de la referencia nut00b de IAU SOFA / ERFA y se validan bit a bit frente al vector de prueba publicado de eraNut00b (Δψ, Δε hasta 1e-13 rad). Residuo honesto: la serie completa IAU 2000A de 678 términos (<0,1 mas), una comprobación cruzada numérica de ANISE/SPICE de <10 m y el movimiento polar siguen siendo trabajo posterior (véase ROADMAP.md).

0.12.0 - 2026-06-06#

Esta versión incorpora el primer propagador de órbita no analítico de Kshana: un integrador de Cowell con un modelo de fuerzas jerárquico de seis perturbaciones (dos cuerpos + zonal J2–J6 + tercer cuerpo Sol/Luna impulsado por la época + presión de radiación solar con sombra cónica de umbra/penumbra + arrastre atmosférico + la corrección relativista postnewtoniana de Schwarzschild) impulsado por la elección de dos integradores adaptativos (duplicación de paso RK4 y el par embebido Dormand–Prince RK5(4)), junto con una capa de maniobras / diseño de trayectorias (impulsos instantáneos y finitos, un resolvedor de Lambert de Izzo y un barrido porkchop), una capa alt-PNT de correlación de mapas de gravedad que recupera una traza de 60 minutos sin GPS con menos de 500 m, una cadena de determinación de órbita por lotes + secuencial y un UKF completo GNSS/INS fuertemente acoplado de 17 estados con navegación a ciegas CAI cuántica. Toda capacidad numérica está fijada frente a la verdad analítica o a una forma cerrada deducida a mano; las perturbaciones desactivadas por defecto dejan intactos los golden publicados.

Añadido#

• Corrección relativista postnewtoniana (de Schwarzschild) (forces::relativistic_accel + propagator::ForceModel::relativity). Añade la perturbación de relatividad general dominante en una órbita cercana a la Tierra, el principal motor del avance relativista del perigeo, en la forma β = γ = 1 de IERS / Montenbruck–Gill a = (μ/c²r³)·{[4μ/r − v²]·r + 4(r·v)·v}. Como el arrastre atmosférico, es dependiente de la velocidad, de modo que viaja en el miembro derecho del integrador (r, v) mediante [accel_rv], opcional y desactivada por defecto. Validada de forma autocontenida: en una órbita circular se reduce a la forma cerrada 3μ²/(c²r³)·r̂ (puramente radial y hacia fuera, con componentes fuera del eje exactamente cero); su razón respecto a los dos cuerpos es el ≈1.9·10⁻⁹ de los manuales en LEO (la firma de μ/(c²r)); un caso de velocidad radial coincide con el μ(4μ + 3v²r)/(c²r³) simplificado a mano; y en el propagador perturba la órbita sin disiparla: el semieje mayor se conserva muy por debajo de un metro/día, lo contrario estructural de la caída monótona del arrastre. Como está desactivada por defecto, los golden de dos cuerpos/J2/zonales no se tocan. El ajuste de parámetros PPN (β,γ) y el término de arrastre de marcos de Lense–Thirring siguen siendo trabajo posterior.
• Modelo de sombra cónica de umbra+penumbra (forces::conical_shadow), ahora usado por la presión de radiación solar. Mejora el eclipse binario de cilindro umbral a un factor ν ∈ [0,1] suave: el Sol y la Tierra se modelan como discos de radios angulares aparentes a = asin(R☉/d☉), b = asin(Rₑ/|r|) con separación aparente de centros c, y ν es uno menos la fracción del disco del Sol que oculta el disco de la Tierra (el área de solapamiento lenticular entre círculos): sol pleno para c ≥ a+b, umbra total para c ≤ b−a, anular para c ≤ a−b y una penumbra continua entre medias. srp_accel lo usa ahora, de modo que la fuerza SRP se atenúa suavemente a través del eclipse en lugar de activarse y desactivarse. Añade el forces::SOLAR_RADIUS nominal de la IAU. Validado de forma autocontenida: ν = 1 a pleno sol y ν = 0 en lo profundo de la umbra (exacto), una penumbra suave y monótona (ν sube de 0 → ~½ en c = b → 1 a lo largo de la banda [b−a, b+a]), y la penumbra cónica se extiende más allá del cilindro umbral (un punto que el cilindro binario considera plenamente iluminado es 0 < ν < 1 para el cono). El cylindrical_shadow más simple sigue disponible; el oscurecimiento del limbo solar y la sombra de la Tierra achatada siguen siendo trabajo posterior.
• Integrador embebido Dormand–Prince RK5(4) (integrator::dopri54_step / integrator::integrate_dopri + propagator::propagate_dopri). Añade el par embebido estándar de tableau de Butcher de Dormand–Prince (1980) junto al controlador existente de duplicación de paso RK4: siete etapas FSAL dan una solución de 5.º orden y una estimación de error de 4.º orden a partir de un mismo conjunto de evaluaciones (7 frente a 11 llamadas de función por paso), una estimación de error local más barata. El controlador adaptativo reutiliza la misma norma de error RMS y el controlador de paso 0.9·(1/err)^(1/5), de modo que es una alternativa directa; propagator::propagate_dopri lo expone en el modelo de fuerzas de la órbita. Validado de forma autocontenida: la estimación de error embebida es O(h⁵) (reducir a la mitad el paso la reduce unas ~32×); DP5(4) integra y' = y hasta e y el oscilador armónico durante 50 periodos conservando la energía hasta <1e-6; alcanza el mismo punto final con la misma tolerancia en menos evaluaciones de función que la duplicación de paso (sin sacrificar exactitud); y propagate_dopri supera la misma puerta de verdad analítica que la vía RK4 (submétrico frente a la solución exacta de Kepler de variable universal en una órbita LEO de 24 h), mientras que los dos controladores coinciden a <1 m en una órbita J2..J6 (sin forma cerrada). Pares embebidos superiores (RKF7(8) / DOP853) siguen siendo trabajo posterior.
• Arrastre atmosférico incorporado al propagador como su primera fuerza dependiente de la velocidad (forces::atmospheric_density + forces::drag_accel + propagator::ForceModel::drag). Añade la atmósfera exponencial por tramos de la Tabla 8-4 de Vallado ρ = ρ0·exp(−(h−h0)/H) (28 bandas desde el nivel del mar hasta más allá de 1000 km, acotada por debajo de la superficie) y el arrastre cuadrático a = −½ · ρ(h) · (C_D·A/m) · |v_rel| · v_rel frente a la atmósfera corrotante v_rel = v − ωₑ ẑ × r (forces::EARTH_ROTATION_RATE = 7.2921151467e-5). Como el arrastre depende de la velocidad, ForceModel gana un nuevo accel_rv(t, r, v) y el miembro derecho del integrador pasa ahora la velocidad (f(t,[r;v]) = [v; a(t,r,v)]); el accel_at solo de posición no cambia, de modo que los términos conservativos y los golden no se tocan. Validado de forma autocontenida: la densidad se ancla en el valor de 1,225 kg/m³ a nivel del mar, se acota por debajo de la superficie, decrece monótonamente a través de LEO, se sitúa en la banda de media solar de ~1e-12 kg/m³ a 400 km, y su altura de escala local recuperada (≈ 58 km a 400 km) es física; el arrastre se opone a la velocidad relativa corrotante con la magnitud LEO de ~2e-6 m/s² para C_D·A/m = 0.02 m²/kg; y, la firma clave, el arrastre es disipativo: una órbita de 300 km pierde energía específica monótonamente y su semieje mayor decae unos ~km/día acotados, mientras que la línea base en vacío conserva la energía hasta <1e-9. La densidad termosférica NRLMSISE-00 (la cláusula de densidad de arrastre de < 5 %) sigue siendo trabajo posterior.
• Presión de radiación solar incorporada, impulsada por la época, al modelo de fuerzas del propagador (forces::srp_accel + propagator::ForceModel::solar_radiation). Añade el modelo SRP de bola de cañón a = ν · P☉ · cᵣ · (A/m) · (AU/d)² · d̂ con un factor de eclipse de sombra cilíndrica (forces::cylindrical_shadow, ν ∈ {0.1}): la presión de radiación P☉ = Φ☉/c a partir de la irradiancia solar total moderna de 1361 W/m² (≈ 4,5398·10⁻⁶ N/m²), la caída de flujo (AU/d)² inversa del cuadrado y el empuje radial alejándose del Sol. Viaja en el mismo miembro derecho impulsado por la época que el tercer cuerpo, muestreando el Sol ephem una sola vez en la época avanzada epoch_jd_tt + t/86400 compartida entre el tercer cuerpo del Sol y la SRP. Componible: with_zonals_j2_j6().third_body(true, true, epoch).solar_radiation(1.5, 0.02). Validado de forma autocontenida frente a firmas deducidas a mano: la presión de radiación a 1 AU se fija en sus ≈ 4,5398·10⁻⁶ N/m² de los manuales; la SRP de un satélite LEO plenamente iluminado es idéntica bit a bit a la fórmula de bola de cañón, apunta alejándose del Sol y se sitúa en la banda de ~1,36·10⁻⁷ m/s² para cᵣ = 1,5, A/m = 0,02 m²/kg; duplicar la distancia al Sol divide la magnitud por cuatro (inverso del cuadrado); la sombra cilíndrica eclipsa solo el cilindro umbral (en sentido antisolar y a menos de un radio terrestre de la línea Tierra–Sol) y da una SRP exactamente cero en eclipse; y en el propagador la SRP perturba una órbita LEO en una cantidad pequeña y acotada que escala ~linealmente con A/m, mientras que un modelo sin perturbaciones sigue siendo independiente del tiempo bit a bit, dejando intactos los golden de dos cuerpos/J2/zonales. La umbra/penumbra cónica (ν suave ∈ [0.1]), el arrastre atmosférico y la validación cruzada externa con GMAT/Orekit siguen siendo trabajo posterior.
• Tercer cuerpo Sol/Luna impulsado por la época, incorporado al miembro derecho variable en el tiempo del propagador (propagator::ForceModel::third_body / accel_at). La perturbación de tercer cuerpo ya no es un término de fuerza independiente: ahora el propagador de Cowell la integra como una fuerza genuinamente variable en el tiempo: cada evaluación del miembro derecho muestrea las posiciones del Sol/Luna de ephem en la época avanzada epoch_jd_tt + t/86400 (reutilizando precession::julian_centuries_tt para la conversión día↔siglo), de modo que los perturbadores se mueven a lo largo de sus órbitas durante la integración en lugar de quedar congelados al comienzo. Componible con cualquier modelo de gravedad (ForceModel::with_zonals_j2_j6().third_body(true, true, epoch)). Validado de forma autocontenida: el término del Sol del miembro derecho es idéntico bit a bit a third_body_accel evaluado en la posición de la efeméride para ese instante tanto en t = 0 como en t = 1 day (lo que demuestra exactamente el cableado 86400 s ↔ 1 día ↔ 1/36525 siglo), el perturbador avanza ~2,6·10⁹ m/día entre muestras (no está congelado), las magnitudes mareales instantáneas en LEO alcanzan las bandas de los manuales de ~5·10⁻⁷ m/s² (Sol) y ~1,1·10⁻⁶ m/s² (Luna, ≈ 2× el Sol), cada cuerpo perturba de forma medible la trayectoria de un día y permanece acotado, y el mismo estado inicial propagado en épocas separadas un cuarto de año da una trayectoria distinta (el eje mareal gira 90°), mientras que un modelo sin ninguno de los dos cuerpos activado es independiente del tiempo bit a bit, dejando intactos los golden de dos cuerpos/J2/zonales. La exactitud de efemérides de grado DE y la validación cruzada externa con GMAT/Orekit siguen siendo trabajo posterior.
• Efeméride lunar de baja precisión (ephem::moon_position), que completa el par de tercer cuerpo Sol/Luna. Añade la serie lunar de baja precisión de Montenbruck & Gill (§3.3.2) junto al modelo del Sol, de modo que forces::third_body_accel, agnóstico respecto al cuerpo, puede ahora ser impulsado por cualquiera de los dos astros sin ningún kernel DE/SPK externo. Validada de forma autocontenida frente a firmas lunares deducidas a mano: la distancia geocéntrica se mantiene dentro de la envolvente real de perigeo/apogeo (~356.500–406.700 km) a lo largo de un mes y su media mensual recupera el semieje mayor de ~384.400 km; la latitud eclíptica nunca supera la inclinación orbital lunar de ~5,3° (comprobado proyectando sobre el polo de la eclíptica en coordenadas ecuatoriales, lo que valida a la vez la serie de latitud y la rotación de la oblicuidad); la dirección de la Luna regresa a menos de 1° tras un mes sidéreo (27,3217 d) y su movimiento diario se mantiene en la banda física de 12–15°/día; y la perturbación lunar de tercer cuerpo sobre un satélite LEO tiene la magnitud de los manuales de ~1,1·10⁻⁶ m/s² (≈ el doble que la del Sol). La exactitud de posición de grado DE, el arrastre atmosférico y la SRP siguen siendo trabajo posterior.
• Gravedad de tercer cuerpo (Sol) con una efeméride incorporada de baja precisión (forces::third_body_accel, ephem::sun_position). Añade la perturbación de tercer cuerpo al modelo de fuerzas: a = GM₃·((s−r)/|s−r|³ − s/|s|³) (atracción directa menos el término indirecto que debe restar el marco geocéntrico), con la posición del Sol aportada por la serie analítica de baja precisión de Montenbruck & Gill del nuevo módulo ephem: sin necesidad de ningún kernel DE/SPK externo para una ejecución de baja fidelidad. Validada de forma autocontenida: la aceleración coincide con el gradiente exacto de su propio potencial perturbador (third_body_potential), la perturbación se anula en el geocentro y tiene la magnitud de los manuales de ~5·10⁻⁷ m/s² en un satélite LEO, y la efeméride del Sol alcanza anclajes J2000 deducidos a mano: distancia del perihelio ≈ 1,471·10¹¹ m, declinación ≈ −23° cerca del solsticio de diciembre, un movimiento aparente de ≈ 1°/día (≈ 90° por cuarto de año) y una distancia que permanece dentro de la envolvente de órbita terrestre de 0,983–1,017 AU a lo largo de un año completo. Entrega la mitad de tercer cuerpo del paso de modelo de fuerzas del hito del propagador numérico (la Luna se entrega en una entrada complementaria más arriba); la exactitud de posición de grado DE, el arrastre atmosférico y la SRP siguen siendo trabajo posterior.
• Modelo de fuerzas de armónicos zonales J2–J6 (forces::zonal_accel / zonal_potential). Amplía el modelo de fuerzas del propagador de Cowell más allá de J2 hasta el campo zonal completo de la Tierra hasta el grado 6 (el J2..J6 no normalizado estándar publicado de EGM-96), integrado en el propagador como ForceModel::with_zonals_j2_j6(). La aceleración es el gradiente analítico exacto del potencial perturbador zonal R(r) = −(μ/r)·Σ Jₙ(Re/r)ⁿPₙ(z/r) (polinomios de Legendre por recurrencia ascendente), validado de tres maneras independientes: se reduce al j2_accel validado con 666 vectores hasta la precisión de máquina cuando se restringe a [J2]; coincide con el gradiente numérico de su propio potencial en todo el campo J2..J6 (la comprobación de referencia de los campos conservativos); y los términos impares de J3 frente a los pares de J2/J4..J6 muestran su (anti)simetría norte–sur característica bajo z → −z, la asimetría en forma de pera. Una órbita J2..J6 propagada conserva la energía total (cinética + central + potencial zonal) hasta ~1e-8 en un día y perturba la órbita solo J2 en una cantidad pequeña distinta de cero. Esto entrega el paso 2 («armónicos zonales J2–J6») del hito del propagador numérico; el campo teseral EGM de alto grado, el arrastre, la SRP, el tercer cuerpo y la validación cruzada externa con GMAT/Orekit siguen siendo trabajo posterior.
• Propagador numérico de órbita (de Cowell) (src/propagator.rs). El primer propagador no analítico de Kshana (el resto de la pila de órbitas es SGP4/SDP4 analítico): conecta el modelo de fuerzas de dos cuerpos + J2 (src/forces.rs) con el controlador adaptativo RK4 de duplicación de paso (src/integrator.rs) como f(t,[r;v]) = [v; a(r)], con un interruptor ForceModel. Validado frente a una verdad analítica más fuerte de lo que sería una herramienta numérica cruzada: la órbita sin perturbar reproduce la solución exacta de Kepler de variable universal a nivel submétrico en una órbita LEO de 24 horas (una puerta más estricta que el «frente a una referencia numérica < 10 m» con que se formula el hito), la energía específica y el momento angular se conservan hasta ~1e-9 en términos relativos, y la regresión nodal de J2 reproduce la j2_secular_rates en forma cerrada hasta la teoría de primer orden (dentro del 2 %, el residuo O(J2²)). Añade también solve_kepler_checked, un resolvedor de Newton de la ecuación de Kepler que devuelve Err en lugar de una respuesta silenciosamente errónea cuando no converge dentro de un presupuesto acotado de iteraciones (el caso e = 0.999 cercano al perigeo). Alcance honesto: el modelo de fuerzas es solo de dos cuerpos + J2; el campo teseral EGM de alto grado (200×200 + cargador), el arrastre (NRLMSISE-00), la SRP, las fuerzas de tercer cuerpo y una validación cruzada externa con GMAT/Orekit siguen siendo trabajo posterior.
• Correlación de mapas de gravedad sin GPS de 60 minutos hasta < 500 m (run_gps_denied_gravity_nav). Profundiza la capa alt-PNT hasta el objetivo de validación Quantum Wayfarer de ESA NAVISP: un vehículo recorre una traza de ~700 km durante una interrupción de GNSS de una hora completa, con su solución inercial derivando hasta ≈ 70 km, y un gravímetro de átomos fríos más un correlador de partículas/rejilla jerárquico de grueso a fino recupera la deriva constante del INS hasta ≈ 145 m (< 500 m), una reducción de > 480×. El suelo real de ruido blanco del gravímetro se inyecta como una secuencia determinista con semilla, de modo que al correlador nunca se le entrega una verdad sin ruido y aun así la ejecución es exactamente reproducible (verificado idéntico bit a bit, y estable a unos pocos metros entre realizaciones de ruido). Una prueba de grado de regresión muestra que el refinamiento es necesario: una única rejilla gruesa se estanca en ~2 km, y solo el refinamiento de tres etapas rompe la barrera de 500 m. Escenario nuevo incorporado al repositorio scenarios/gps-denied-gravity-nav.toml. La fila docs/CAPABILITY.md sigue siendo con honestidad parcial (todavía sin mapa EGM2008 incluido), con su evidencia actualizada al resultado de 60 min < 500 m. El alcance honesto no cambia: campo de armónicos esféricos de grado bajo + mascons sintéticos; un Monte-Carlo sobre realizaciones del error de representación del mapa es trabajo posterior.
• Registro de afirmaciones excesivas + protección contra regresiones (docs/CLAIMS-VS-REALITY.md, tests/no_overclaims.rs). Cierra la línea de honestidad/retirada de afirmaciones: las catorce afirmaciones excesivas que catalogó una auditoría anterior (OC-0…OC-13) están ya todas en GREEN: las afirmaciones fuertes (OC-0 Kalman acoplado de reloj+posición, OC-2 jamming J/S→C/N₀→pérdida de enganche, OC-7 física CAI de Mach–Zehnder, OC-8 HPL/VPL de ARAIM) están sustituidas por capacidades distribuidas y probadas y no por una redacción suavizada, y las demás filas se han corregido para coincidir con el código. Una nueva prueba de CI analiza las superficies públicas en vivo (README, CAPABILITY, GLOSSARY, web/) y falla si reaparece sin matices alguna frase retirada de afirmación excesiva simple, de modo que una fila GREEN no pueda retroceder en silencio. La FoM de «integridad» por ejecución sigue etiquetada con honestidad como autoconsistencia del filtro (no integridad aeronáutica); el HPL/VPL real de ARAIM se presenta por separado para que nunca se confundan.
• Navegación por correlación de mapas de gravedad (alt-PNT sin GPS). El nuevo src/gravimeter.rs añade la capa de capacidad alt-PNT que reclaman los estudios de correlación de mapas de gravedad Quantum Wayfarer / QT-CCI de ESA NAVISP: un modelo de medida de gravímetro de átomos fríos cuyo suelo de ruido blanco se deriva de la ASD del acelerómetro CAI (σ = ASD/√τ); un campo de anomalías de gravedad de armónicos esféricos de grado bajo y totalmente normalizado (validado frente a las funciones de Legendre en forma cerrada P̄₁₁=√3·cosφ, P̄₂₀=(√5/2)(3sin²φ−1), P̄₂₂=(√15/2)cos²φ y una anomalía de un solo término deducida a mano de 1,897 mGal) más mascons sintéticos para los rasgos locales de grado alto; y un filtro de partículas de correlación de mapas de gravedad (que compone mapmatch + particle_filter) que recupera una traza sin GPS a partir de la secuencia de anomalías que atraviesa. Un benchmark NAVISP incorporado al repositorio (scenarios/gravity-map-nav.toml) reduce una deriva inercial libre de ~73 km a unos pocos km. Alcance honesto: Kshana no incluye el conjunto completo de coeficientes EGM2008 de 2190°; el campo es de grado bajo + mascons, no un mapa real de alta resolución; el cargador EGM/EIGEN, el mapa magnético, el SLAM asistido por terreno y la conexión kind= del motor de escenarios con un gráfico SVG de deriva siguen siendo trabajo posterior. docs/CAPABILITY.md «Gravity-map / alt-PNT navigation» → parcial.
• Modelado de maniobras y cabeza de puente del diseño de trayectorias. El nuevo src/maneuver.rs añade la primera capa de diseño de trayectorias por encima de SGP4: nodos de ΔV impulsivos que aplican una discontinuidad de velocidad y propagan una covarianza de 6×6 (quemado determinista ⇒ transición de estado identidad; la covarianza del error de ejecución rota desde el marco del quemado, ECI o LVLH, hacia el bloque de velocidad), una integración de quemado finito (empuje constante sobre un arco de quemado con la masa como estado) cuyo ΔV logrado se comprueba frente a la ecuación del cohete de Tsiolkovsky en forma cerrada con una diferencia inferior al 0,01 %, un resolvedor de Lambert de una sola revolución de Izzo-2015 (r1, r2, tiempo de vuelo ⇒ v1, v2), un propagador de Kepler exacto de variable universal (verdad de dos cuerpos) y un barrido porkchop que traza una cuadrícula de época de lanzamiento × época de llegada hasta C3 de salida y V∞ de llegada, emitido como un array JSON 2-D para el renderizado de contornos en el navegador. La validación es autocontenida y más fuerte que una lectura de tutorial: cada salida de Lambert se devuelve por el propagador de Kepler (debe volver a aterrizar en r2), y el mínimo del porkchop se comprueba frente al suelo analítico de C3 de la transferencia de Hohmann para dos órbitas circulares coplanarias. Kshana la sitúa como la capa de simulación de rendimiento por encima de GMAT/Orekit, no como un sustituto (las ramas de varias revoluciones y una efeméride planetaria real quedan fuera de alcance). Diez pruebas.
• UKF GNSS/INS fuertemente acoplado completo de 17 estados con navegación a ciegas CAI cuántica. El nuevo src/fusion/tightly_coupled17.rs lleva el estado completo de navegación inercial que estima un filtro fuertemente acoplado, [position, velocity, attitude-error, accelerometer bias, gyro bias, clock bias, clock drift] (17 estados), propagado por la mecanización strapdown impulsada por la fuerza específica y la velocidad angular medidas, con la rotación cuerpo→inercial de ángulo pequeño C ≈ I + [ψ×] de modo que el error de actitud se acopla a la aceleración horizontal (el acoplamiento estándar de inclinación del INS). Durante una interrupción de GNSS navega a ciegas solo con la IMU; el ruido de proceso de paseo aleatorio de la velocidad es el q_va derivado del acelerómetro de interferómetro de átomos fríos (crate::inertial::quantum_imu), de modo que la deriva de la navegación a ciegas es la limitada por el sensor cuántico: una interrupción de 120 segundos queda acotada a unos cientos de metros frente a los kilómetros que alcanzaría un INS libre de grado de navegación. La actualización de pseudodistancia/tasa de distancia se ejecuta por el filtro de Kalman unscented (UKF) compartido (con α = 1 para pesos bien condicionados con este tamaño de estado). Cinco pruebas: identidad del modelo de medida, integración a velocidad constante con IMU perfecta, ayuda de GNSS, estimación del sesgo del acelerómetro y el benchmark de interrupción de 120 s limitada por CAI.

0.11.0 - 2026-06-05#

Cambiado#

• Un encuadre honesto para el posicionamiento cuántico. El descriptor principal es ahora un «simulador de resiliencia PNT con modelos de rendimiento de sensores cuánticos» de forma coherente en el eslogan del README, la línea de cita, CITATION.cff (título + resumen) y la ilustración del banner, en sustitución de la redacción comercial más laxa «simulador PNT híbrido cuántico/clásico». La sección What it is / is not del README gana una declaración de alcance explícita «It is not (yet)» (no es un motor de física de interferometría atómica de primeros principios, no es un receptor GNSS/solucionador PVT, no es una herramienta de diseño de misiones), y un nuevo ROADMAP.md de nivel superior convierte la capa de física cuántica en un elemento P2 (fase CAI de Mach–Zehnder, ruido de proyección, tensor de vibración) para que los lectores sepan que la física de primeros principios está prevista y por llegar, no abandonada. Sin cambio de comportamiento ni de API.

Añadido#

• Estudio comparativo de diseño de constelaciones: barrido de diseños Walker con un frente de Pareto, JSON de tiempo de revisita y una validación submétrica de la fórmula de Walker. src/walker.rs gana walker_design_sweep, que ejecuta una cuadrícula planes × sats_per_plane (p. ej. un estudio de 3×3) con una inclinación fija y tabula, por diseño, la fracción de cobertura, el PDOP del peor caso y el intervalo de revisita máximo/medio; pareto_front marca los diseños no dominados (menos satélites, más cobertura, menor PDOP, revisita más corta), y WalkerDesignReport::to_json serializa las celdas y el frente de Pareto, con los campos de tiempo de revisita incluidos, como JSON. Una validación nueva fija el generador a la fórmula de Walker i:T/P/F: se muestra que los satélites de la misma ranura en planos adyacentes se transforman unos en otros mediante una rotación exacta R_z(2π/P) con menos de 1 km a lo largo de 24 h completas de propagación SGP4 (la respiración de corto periodo de J2 es de modo común y se cancela), y se confirma que las ranuras dentro del plano están espaciadas 2π/S en media. Se apoya en la instantánea real de Celestrak gps-ops del 2021-07-28 incorporada al repositorio (scenarios/orbit-sgp4-gps.toml, ejercitada por las pruebas de cobertura de escenarios y de ida y vuelta de SP3).
• Transferencia avanzada de tiempo y frecuencia: TWSTFT, vista común GNSS, PPP, óptica, ajuste de ley de potencias IEEE-1139 y un conjunto de relojes. El nuevo src/timetransfer_adv.rs construye los métodos operativos de transferencia sobre las formas cerradas de Sagnac/vista común incluidas y las herramientas de estabilidad de Allan. twstft_sagnac da la corrección de Sagnac de la transferencia bidireccional de tiempo y frecuencia por satélite (TWSTFT) como la suma del bucle de tres saltos, igual a la forma cerrada del BIPM Δt = 2·A·ω_E/c² exactamente (contrastada con el independiente twstft_sagnac_bipm); run_twstft emite una serie T_A − T_B de un día y su TDEV. gnss_common_view_series toma diferencias simples de dos estaciones terrestres sintéticas para que el reloj del satélite se cancele. iono_free_combination + ppp_receiver_clock son la combinación libre de ionosfera de PPP y la resolución del reloj del receptor frente a una verdad sintética de grado SP3, cancelando exactamente la ionosfera de primer orden. rytov_variance, fried_parameter y el modelo lognormal_fading de media unitaria modelan el centelleo inducido por turbulencia de un enlace óptico en espacio libre. fit_power_law_psd es un ajuste completo por mínimos cuadrados de h_α de cinco coeficientes IEEE-1139 de la curva de varianza de Allan (los cinco procesos de ruido canónicos a la vez) con el proceso dominante informado por década de τ. ensemble_timescale forma una escala de tiempo en papel ponderada por la inversa de la varianza cuya desviación de Allan queda estrictamente por debajo del mejor reloj que contribuye. 31 pruebas unitarias; los objetivos de validación son formas cerradas y una verdad sintética: sigue pendiente una ingesta real de Circular-T del BIPM / SP3 del IGS.
• Mapas de ionosfera IONEX: analizador de archivos, interpolación temporal y mapeo de oblicuidad de la trayectoria oblicua. src/ionex.rs gana parse_ionex, que lee el formato de archivo IONEX (definición de la rejilla de cabecera + bloques START/END OF TEC MAP) en una secuencia de IonexMap, normalizando el orden de latitudes de norte a sur del archivo en una TecGrid de paso positivo y escalando los valores por 10^EXPONENT. interpolate_tec_in_time mezcla dos mapas sucesivos hasta una época de consulta, y obliquity_factor / slant_tec proyectan el TEC vertical sobre un rayo oblicuo mediante el factor de capa fina de una sola capa M(z) = 1/cos z′ (sin z′ = (Rₑ/(Rₑ+H))·sin z). Junto con el modelo de rejilla incluido, esto convierte un mapa global de ionosfera medido del IGS en un retardo oblicuo utilizable.
• Diseño de constelaciones: dimensionado de calles de cobertura + comparación de multiconstelaciones. src/walker.rs gana min_satellites_streets_of_coverage, un resolvedor idealizado del mínimo de satélites de calles de cobertura: a partir del semiángulo de cobertura incluido λ y del semiancho de calle c, dimensiona la constelación casi polar para cobertura global continua simple como p = ⌈π/(2c)⌉ planos (p. ej. un plano de 4 satélites a altitud GPS necesita 2 planos, 8 satélites), e informa None cuando los satélites son demasiado dispersos para formar una calle continua. compare_constellations es la herramienta de comparación de multiconstelaciones: puntúa cada diseño Walker con nombre sobre la misma estación/ventana mediante pdop_sweep y devuelve su cobertura / PDOP / tamaño lado a lado. Alcance honesto: la corrección exacta de la costura de Rider en el límite de planos contrarrotantes y un globo de cobertura 3-D son trabajo posterior.
• Detección de spoofing multicapa: detector de paridad de consistencia RAIM + fusión de capas. src/spoof_monitors.rs gana la tercera y última capa de detección y la etapa de fusión: parity_raim_test ajusta por mínimos cuadrados la solución de posición/reloj a un conjunto redundante de pseudodistancias y contrasta la suma de cuadrados de los residuos ponderados restantes con su umbral χ²(m−4): señala un subconjunto sesgado de satélites mientras deja correctamente un sesgo de modo común (absorbido por el reloj del receptor) invisible para RAIM, sin disimularlo. fuse_spoof_layers combina las capas de paridad, AGC y SQM en una única decisión ponderada que registra qué capas se activaron. Un Monte-Carlo caracteriza el detector: P_fa ≈ 0,068 empírica frente a un punto de diseño de 0,05, con la detección fallida cayendo de 0,885 con un sesgo de spoofing de 2σ a 0,16 con 8σ. Alcance honesto: la validación cruzada frente a vectores de prueba de spoofing publicados concretos (Spirent / ION GNSS+) necesita esos conjuntos de datos externos y sigue siendo trabajo posterior.
• Conjunto de validación de Kalman acoplado frente a desacoplado. Un Monte-Carlo de 100 ensayos en src/fusion/coupled.rs cuantifica el valor de llevar la covarianza cruzada posición↔reloj: una línea base desacoplada fiel en línea (validada bit a bit frente al CoupledPntFilter incluido) procesa los mismos datos con los bloques cruzados a cero, y tras pseudodistancias casi degeneradas más una corrección solo de reloj, el filtro acoplado recupera la posición con 2,97 m RMS frente a los 48,8 m del filtro desacoplado, ganando en 97 de 100 ensayos: la corrección de reloj afina la posición solo a través de la correlación que descarta el paquete desacoplado. Esto completa el conjunto de validación de corrección de Kalman (forma de Joseph, seguridad PSD, consistencia NEES/NIS y ahora el conjunto del filtro acoplado).
• Cadena de determinación de órbita (por lotes + secuencial). Un nuevo src/orbit_determination.rs recupera el estado orbital [r, v] de un satélite a partir del seguimiento de distancia desde estaciones terrestres, componiendo tres piezas incluidas: el modelo de fuerzas de dos cuerpos + J2 (src/forces.rs) y el integrador RK4 (src/integrator.rs) propagan un estado candidato a lo largo del arco, un modelo de medida de distancia predice la distancia a cada estación, y el corrector por lotes de Gauss–Newton (src/batch_ls.rs) lleva el candidato al estado de mejor ajuste (determine_orbit_batch). La misma dinámica y el mismo modelo de distancia impulsan también una determinación recursiva secuencial con el filtro de Kalman unscented (UKF) incluido (determine_orbit_sequential). Cuatro pruebas lo validan: predicción de distancia a lo largo del arco; recuperación por lotes a nivel submétrico / mm·s⁻¹ con distancias sin ruido; recuperación por lotes a ~2 m con un residuo posterior al ajuste en el suelo de ruido de 5 m (la firma de un ajuste de mínimos cuadrados consistente); y recuperación secuencial a decenas de metros. Alcance honesto: las mediciones de tasa de distancia/Doppler y de ángulo, una matriz analítica de transición de estado J2 y el enmascaramiento de visibilidad de estaciones son trabajo posterior.
• Navegador UKF GNSS/INS fuertemente acoplado. Un nuevo src/fusion/tightly_coupled.rs conecta el núcleo de Kalman unscented incluido (src/fusion/ukf.rs) con un navegador fuertemente acoplado operativo sobre el [px,py,pz,vx,vy,vz,b,d] de ocho estados (posición/velocidad ECEF más sesgo y deriva del reloj del receptor en unidades de distancia). Ingiere las mediciones brutas de los satélites, pseudorange (ρ = |p − sᵢ| + b) y range_rate/Doppler (ρ̇ = (p − sᵢ)·(v − ṡᵢ)/|p − sᵢ| + d), en lugar de una corrección de posición ya formada, de modo que TightlyCoupled (con propagate/propagate_orbital/ update_gnss) sigue corrigiendo con menos de cuatro satélites y navega a ciegas por las interrupciones de GNSS con su dinámica propagada. Cinco pruebas lo validan de extremo a extremo, incluidos los escenarios de aceptación del hito: la geometría de pseudodistancia/Doppler frente a valores calculados a mano; convergencia sin ruido a nivel submétrico con cinco satélites; un caso de tres satélites que converge de ~212 m a ~13 m donde ni siquiera puede formarse un PVT instantáneo; una interrupción de 120 segundos a velocidad constante dentro de 50 m; y, la aceptación principal, un paso LEO curvo de 30 minutos (órbita real de dos cuerpos + J2) con una interrupción de GNSS de 120 segundos, mantenido en 0,77 m RMS en el paso y 2,9 m en el peor caso durante la interrupción. Esa navegación a ciegas orbital compone el modelo de fuerzas de gravedad incluido (src/forces.rs) y el integrador RK4 (src/integrator.rs) en el modelo de proceso del UKF (propagate_orbital), de modo que el filtro sigue la curvatura de la órbita, algo que una navegación a ciegas a velocidad constante no puede (la curvatura sola es de ~58 km en 120 s en LEO). Alcance honesto: la navegación a ciegas orbital usa el modelo de fuerzas de dos cuerpos + J2 en lugar de la fuerza específica bruta de la IMU (para una plataforma orbital sin propulsión coinciden); incorporar un estado de error de IMU strapdown y correcciones iono/tropo en el bucle es trabajo posterior.
• Modelo de medida de correlación de mapas (navegación referenciada al terreno / a la gravedad). Un nuevo src/mapmatch.rs aporta el modelo de medida que convierte el filtro de partículas de remuestreo por importancia secuencial incluido (src/particle_filter.rs) en un navegador operativo sin GPS: field_likelihood (una verosimilitud gaussiana de coincidencia de campo) y map_match_likelihood, que muestrea cualquier campo de referencia georreferenciado, elevación del terreno (TRN) o anomalía de gravedad, en la posición de una partícula y la pondera por su acuerdo con el valor medido del vehículo. El campo es cualquier muestreador Fn(lat, lon) -> value, de modo que se compone con la rejilla bilineal de src/ionex.rs o con una clausura. Dos pruebas lo anclan: la verosimilitud alcanza su pico (=1) con una coincidencia perfecta y cae a e^(−½) a una sigma, y un filtro de partículas sobre un parche distintivo de terreno sintético recupera la posición verdadera con una diferencia de 0,1. Alcance honesto: los mapas de referencia reales (elevación SRTM, anomalía de gravedad EGM/EIGEN) y sus cargadores son trabajo posterior.
• Integridad PNT cislunar (ARAIM lunar). Un nuevo src/lunar.rs aplica el motor ARAIM MHSS del lado terrestre a un servicio de navegación lunar de estilo LunaNet con los parámetros lunares (σ_URE ≈ 30 m frente a los 0,6 m de GPS, P_sat ≈ 1e-4): constantes lunares, una base Este/Norte/Arriba selenocéntrica y un asistente de geometría del cielo, y lunar_araim (HPL/VPL). Tres pruebas lo anclan: la base selenocéntrica ortonormal, la geometría de distancia oblicua y el escalado lineal exacto del nivel de protección con σ_URE (los 30 m lunares dan un nivel de protección 50× mayor que la misma geometría con los 0,6 m de GPS: la razón cuantitativa de que la integridad PNT lunar sea difícil). Alcance honesto: la efeméride precisa de la NRHO de LANS, el presupuesto de error de la señal en el espacio y la reducción de marcos MCI↔MCMF son trabajo posterior.
• Fechas julianas en dos partes (de alta precisión). Un nuevo src/jd2.rs añade Jd2, una fecha juliana dividida en un day entero y un frac fraccionario en [0,1) (la convención de SOFA/hifitime), con new/from_parts/add_seconds/diff_seconds/total. Las diferencias de épocas cercanas siguen siendo exactas hasta el suelo de f64 donde una JD de un solo f64 pierde ~50 µs cerca de J2000. Cuatro pruebas lo anclan: el viaje de ida y vuelta, la normalización de la fracción, la recuperación exacta del microsegundo (con el fallo del f64 único demostrado al lado) y la aritmética de segundos aditiva/reversible.
• Escritor CCSDS OMM (Orbit Mean-Elements Message). Un nuevo src/omm.rs complementa el escritor de efemérides oem con el mensaje de elementos medios: OmmFile::from_tle proyecta los elementos medios SGP4/TLE a las unidades de OMM (movimiento medio en rev/día, ángulos en grados, más BSTAR), y to_omm_kvn serializa la forma KVN CCSDS 502.0-B-2 de la vía de normalización, de modo que una órbita de Kshana pueda ser consumida por cualquier herramienta que reconozca OMM en lugar de como un TLE a medida. Dos pruebas anclan la conversión de unidades TLE→OMM (≈ 15,5 rev/día, inclinación de 51,6°, etc.) y la presencia de las palabras clave KVN obligatorias. Alcance honesto: aquí se entregan la forma KVN y la correspondencia con TLE; la representación XML (ndm/omm) y un viaje de ida y vuelta con un analizador de referencia son trabajo posterior.
• Filtro de partículas de remuestreo por importancia secuencial. Un nuevo src/particle_filter.rs añade el estimador no lineal y no gaussiano que está detrás de la navegación asistida por mapas y sin GPS (correlación de mapas referenciados al terreno o a la gravedad): predict (propagar partículas por la dinámica + ruido de proceso gaussiano), update (repesar por una verosimilitud de medida por partícula), resample sistemático, el monitor de degeneración effective_sample_size y la estimación de media ponderada. Seis pruebas anclan exactamente el núcleo determinista: ESS que abarca 1…N, remuestreo sistemático que elige índices en proporción al peso, la combinación convexa de la media ponderada, una verosimilitud gaussiana que atrae la estimación hacia la medida, el comportamiento de remuestreo a uniforme y el determinismo de predict con semilla. Alcance honesto: aquí se entrega el motor; los mapas de referencia (elevación SRTM, anomalía de gravedad EGM) y el modelo de medida de mapa son trabajo posterior (el muestreador de rejilla+bilineal de ionex serviría igualmente para un mapa de gravedad/terreno).
• Mapas de TEC de la ionosfera de estilo IONEX. Un nuevo src/ionex.rs añade la alternativa de ionosfera medida al modelo de Klobuchar difundido: una TecGrid (una cuadrícula regular de latitud/longitud de TEC vertical, un mapa global de la ionosfera del IGS) con interpolación bilineal en un punto de perforación (vtec_at, acotada fuera de la cuadrícula) y el retardo de primer orden Δ = 40.3·TEC/f² (vtec_to_delay_m, delay_at). Cuatro pruebas lo respaldan: 1 TECU ≈ 0.162 m en L1 con el escalado 1/f², interpolación exacta en los nodos, puntos medios bilineales que promedian las esquinas y consultas fuera de la cuadrícula acotadas en el borde. Alcance honesto: aquí se incluyen la cuadrícula y la interpolación; el análisis del formato de archivo IONEX, la interpolación temporal entre mapas y la función de mapeo oblicuo quedan como trabajo posterior.
• Correcciones geométricas de transferencia de tiempo (Sagnac + vista común GNSS). Un nuevo src/timegeo.rs añade los dos efectos deterministas que debe tener en cuenta una comparación real de relojes, como complemento del modelo estocástico bidireccional de timetransfer: sagnac_correction (Δt = (ω_E/c²)·(x₁y₂ − x₂y₁), el retardo de la Tierra en rotación: decenas de ns para líneas base continentales) y common_view_offset, la diferencia simple de vista común GNSS que cancela exactamente el error de reloj del satélite y recupera el desfase entre estaciones. Tres pruebas los respaldan con referencias exactas: el efecto Sagnac de ≈ 33 ns de un cuarto de vuelta ecuatorial, la antisimetría y los casos radial/polar nulos, y la cancelación exacta del reloj del satélite. Alcance honesto: un presupuesto completo de retardos de transpondedor/hardware de TWSTFT y una solución de transferencia de tiempo PPP libre de ionosfera quedan como trabajo posterior.
• Modelo de fuerzas orbitales (dos cuerpos + J2). Un nuevo src/forces.rs añade el modelo de aceleración que integra un propagador numérico: two_body_accel (−μ·r/|r|³), la perturbación de achatamiento j2_accel (la forma cerrada en ECI) y gravity_accel, que las suma; se combina con src/integrator.rs como f(t,[r;v]) = [v; a(r)]. También expone las tasas seculares analíticas de J2 (j2_secular_rates): la regresión nodal Ω̇, la rotación apsidal ω̇ y la deriva de la anomalía media Ṁ. Seis pruebas respaldan la física con referencias exactas: μ/r² para el término de dos cuerpos, la forma cerrada de J2 en el ecuador (~10⁻³ de la magnitud de dos cuerpos), la inclinación crítica (63,4349°) que congela el perigeo (ω̇ = 0), la regresión nodal de la ISS (Ω̇ ≈ −5°/day) y la deriva hacia el este de una órbita heliosíncrona retrógrada. Alcance honesto: solo dos cuerpos + J2; J3–J6, la resistencia atmosférica, la SRP y el tercer cuerpo quedan como trabajo posterior.
• Enlaces permanentes compartibles de escenarios. Un nuevo src/permalink.rs añade un códec Base64 RFC 4648 sin dependencias (alfabeto estándar +/ con relleno y un alfabeto seguro para URL -_ sin relleno) y envoltorios encode_scenario / decode_scenario, de modo que un TOML del playground pueda codificarse en un parámetro de consulta ?s= y compartirse como URL. Se expone al navegador como los enlaces wasm encode_permalink / decode_permalink. Cuatro pruebas lo respaldan con los vectores canónicos de la RFC 4648 ("foobar" → "Zm9vYmFy", etc.), un viaje de ida y vuelta de un escenario seguro para URL (sin +///= que escapar), el rechazo de símbolos no válidos y un viaje de ida y vuelta de los 256 bytes. Alcance honesto: aquí se incluyen el códec y los enlaces; la interfaz del botón Compartir del playground, el gráfico multiserie Plotly/D3 y el modo de comparación A/B quedan como trabajo posterior.
• Mínimos cuadrados por lotes de Gauss–Newton (el corrector diferencial por lotes). Un nuevo src/batch_ls.rs añade el núcleo de estimación en el que se apoya una determinación de órbita por lotes (o cualquier ajuste de parámetros): gauss_newton linealiza un modelo h(x) suministrado por el usuario con un jacobiano de diferencias finitas centrales, forma y resuelve las ecuaciones normales ponderadas (HᵀWH)·Δx = HᵀW·(z − h(x)) (reutilizando la inversa de matriz ya probada) e itera hasta la convergencia con pesos por medida. Cuatro pruebas lo respaldan: un ajuste lineal de una recta que alcanza la solución exacta de mínimos cuadrados ponderados, un ajuste no lineal a·exp(b·t) que recupera los parámetros verdaderos, una multilateración de distancias en 3-D que recupera una posición conocida a partir de distancias sin ruido (la variante de determinación de órbita) y el rechazo de entradas subdeterminadas o incoherentes. Alcance honesto: este es el motor genérico del corrector; el modelo de medida específico de órbita (distancia/tasa de distancia/azimut-elevación), la matriz de transición de estado analítica de J2 y la validación con casos publicados quedan como trabajo posterior.
• Monitores de spoofing en la capa de RF (potencia AGC y SQM). Un nuevo src/spoof_monitors.rs añade dos detectores independientes de spoofing en el extremo de entrada del receptor, que complementan el monitor de spoofing temporal asistido por reloj de spoof: un monitor de potencia AGC (suma incoherente de potencias combine_power_dbm + AgcMonitor) que señala el exceso de potencia recibida que añade un transmisor de spoofing por encima de un margen configurable en dB, y un monitor de calidad de señal (autocorrelación triangular del código bpsk_autocorr + SqmMonitor) que señala el desequilibrio del correlador Early-menos-Late que introducen el multitrayecto, el meaconing o la repetición. Cuatro pruebas respaldan las formas cerradas exactas (3,01 dB para una duplicación de la potencia, el agregado 10·log10(N), el R(τ)=1−|τ| triangular y el umbral de alerta Early/Late del 10 %). Alcance honesto: el detector completo de spoofing por paridad de coherencia RAIM, la fusión multicapa de las salidas de los monitores y la validación con vectores de spoofing publicados de Spirent/ION GNSS+ quedan como trabajo posterior.
• Integrador numérico adaptativo de EDO. Un nuevo src/integrator.rs añade la primera pieza de un propagador numérico (la propagación orbital de Kshana es, por lo demás, analítica SGP4/SDP4): un paso genérico de Runge–Kutta de cuarto orden (rk4_step) sobre cualquier sistema de primer orden y' = f(t, y) y un controlador adaptativo (integrate) que controla el error local mediante duplicación de paso (extrapolación de Richardson) con el controlador de paso estándar 0.9·(tol/err)^(1/5) y la lógica de aceptación/rechazo. Seis pruebas lo respaldan con soluciones exactas: la exponencial y' = y → e hasta < 1e-9, la reducción del error de ~16× por cada paso reducido a la mitad que demuestra la convergencia de cuarto orden, la conservación de la energía y del retorno del oscilador armónico durante un período completo y el controlador adaptativo que alcanza una tolerancia estricta con pasos variables. Alcance honesto: este es el núcleo del integrador y su control de error; las tablas encajadas Dormand–Prince RK5(4)/RKF7(8) y el modelo jerárquico de fuerzas orbitales (dos cuerpos + J2–J6 + resistencia atmosférica + SRP + tercer cuerpo) que lo convierten en un NumericalPropagator quedan como trabajo posterior.
• Filtro de Kalman unscented (UKF, de puntos sigma). Un nuevo src/fusion/ukf.rs añade el filtro de Kalman unscented escalado (Julier y Uhlmann; Wan y van der Merwe) como estimador general de n estados sobre funciones de proceso y de medida suministradas por el usuario: el estimador de puntos sigma que usa un navegador GNSS/INS fuertemente acoplado cuando el modelo de pseudodistancia/Doppler es muy no lineal y el jacobiano de un EKF se degrada. Incluye el álgebra lineal densa de apoyo (factor de Cholesky para la dispersión de los puntos sigma, inversa de Gauss–Jordan para la covarianza de la innovación) y una actualización P⁺ = P⁻ − K S Kᵀ sin forma de Joseph. Seis pruebas lo fijan, y las principales aprovechan la propiedad exacta de que, para un modelo lineal, la transformada unscented reproduce el filtro de Kalman con precisión numérica (predicción, actualización y un ciclo completo de predicción + actualización, todos contrastados con un KF lineal calculado a mano, además de una comprobación analítica de la posterior bayesiana en 1-D y las identidades de Cholesky/inversa). Alcance honesto: este es el motor del estimador; el navegador GNSS/INS fuertemente acoplado de 17 estados, el modelo de medida de pseudodistancia/Doppler y el escenario de validación de interrupciones siguen como trabajo posterior.
• Niveles de protección ARAIM de doble constelación. Un nuevo araim_dual_raim amplía el RAIM avanzado de fallo único (araim_raim) con el modo de fallo de toda la constelación del ARAIM de la UE / DO-316: junto a las hipótesis sin fallo y por satélite, cada constelación (etiquetada por satélite) aporta una hipótesis que elimina todos sus satélites a la vez, con a priori P_const (un nuevo DualFaultPriors { p_sat, p_const }). Cada hipótesis añade un término a la misma suma de integridad MHSS, de modo que VPL/HPL son las cotas más pequeñas cuyo P_HMI total satisface el presupuesto sobre los fallos sin fallo + de SV único + por constelación (el reparto de falsas alertas de Bonferroni se hace sobre las N + C hipótesis). Con P_const = 0 el resultado es idéntico bit a bit a araim_raim; un usuario de una sola constelación obtiene None frente al fallo de su propia constelación (no se la puede excluir), que es precisamente la razón por la que importa la cobertura de doble constelación. Cuatro pruebas cubren la equivalencia, el ensanchamiento del nivel de protección, la indisponibilidad de una sola constelación y la validación de entradas, reutilizando la maquinaria existente de subsoluciones por separación de soluciones.
• Precesión IAU 2006 (ángulos de Fukushima–Williams y matriz de sesgo-precesión). Un nuevo src/precession.rs implementa la precesión IAU 2006 (P03; Capitaine, Wallace y Chapront 2003): los cuatro ángulos de Fukushima–Williams (γ̄, φ̄, ψ̄, ε̄_A) como polinomios en siglos julianos TT (fw_angles) y la matriz de rotación de sesgo-precesión de GCRS a media de la fecha construida con ellos mediante la construcción iauFw2m de SOFA (precession_matrix, con auxiliares gcrs_to_mod / mod_to_gcrs). Es la primera pieza de marco inercial sobre la reducción frames ya existente basada en GMST. Ocho pruebas validan con anclajes de forma cerrada: la oblicuidad media de J2000 ε̄ = 84381.406″ = 23.4392794°, los términos constantes publicados de los ángulos, la acumulación de la precesión general ψ̄ ≈ 5039.998″ a lo largo de un siglo, la ortonormalidad de la matriz y det = +1, el valor casi identidad (solo sesgo del marco) en J2000 y el ángulo de rotación neto de ≈ 1.40° por siglo. Alcance honesto (ROADMAP.md): solo precesión; la nutación IAU 2000A de 678 términos, la cadena completa TEME→GCRS y una comprobación numérica cruzada con SOFA/ANISE de µas/<10 m quedan como trabajo posterior.
• Física de primeros principios del acelerómetro de interferómetro de átomos fríos (CAI). src/inertial/quantum_imu.rs modela desde primeros principios, y no a partir de una hoja de datos, un interferómetro atómico Mach–Zehnder de tres pulsos: vector de onda efectivo k_eff = 4π/λ, fase del interferómetro Φ = k_eff·a·T², ruido de proyección cuántica (shot) σ_Φ = 1/(C·√N), sensibilidad a la aceleración por disparo, caída del contraste C(t) = C₀·e^(−t/τ) y, lo esencial, CaiAccelerometer::q_va(), que deriva la PSD de aceleración blanca que el AccelModel clásico ya consume a partir del número de átomos, el tiempo de interrogación y el contraste. El modelo cubre ahora también el acoplamiento de vibraciones, el término dominante en los dispositivos reales: la función de transferencia aceleración→fase del interferómetro |H(ω)| = (4/ω²)sin²(ωT/2) (accel_transfer_function), la varianza de fase para PSD blanca σ_Φ² = k_eff²·S_a·T³/3 (vibration_phase_variance_white, con una comprobación cruzada numérica por integral de banda vibration_phase_variance_band), la beam_axis_projection de rango 1 a lo largo del haz y CaiAccelerometer::vibration_phase_noise / vibration_limited_accel (esta última se reduce al suelo √(S_a/(3T)), independiente de k_eff). Once pruebas verifican a mano la física (Rb-87 k_eff ≈ 1.61×10⁷, Φ(1 g) ≈ 1.58×10⁴ rad, σ_a ≈ 0.13 µg/disparo de suelo de ruido shot frente a un suelo de vibración de ≈ 5,9 µg, y las leyes de escala 1/T², 1/√N y T³). Alcance honesto en docs/QUANTUM.md: abarca el suelo de ruido de proyección y el régimen limitado por vibraciones por encima de él; el ruido de fase del láser, los sistemáticos de Coriolis y de desplazamiento luminoso y los escenarios de validación PHARAO/CARIOQA quedan como trabajo posterior.
• Acelerómetro cuántico CAI integrado en el escenario inercial. Un acelerómetro de un escenario de navegación inercial a estima se resuelve ahora en un nuevo ImuKind: Classical (el sensor existente con coeficientes de hoja de datos) o QuantumCai cuando lleva un bloque opcional [cai] (CaiCfg: longitud de onda, separación de pulsos, número de átomos, contraste, tiempo de ciclo y una vibration_psd opcional de la plataforma). La PSD de paseo aleatorio de velocidad q_va de un sensor quantum_cai se deriva de la física del interferómetro (el suelo de ruido shot más, cuando se da una PSD de vibración, la contribución limitada por vibraciones en cuadratura) en lugar de un coeficiente suministrado, y la procedencia de la ejecución registra que el ruido se deriva de la física. El campo cai es skip_serializing_if = "Option::is_none", de modo que los escenarios existentes lo omiten y se serializan de forma idéntica byte a byte (el hash del escenario no cambia). Cinco pruebas cubren la derivación, la suma cuadrática de vibraciones, la selección Classical/QuantumCai, la serialización estable del hash y una ejecución de extremo a extremo impulsada por CAI.
• Optimizador de diseño de constelaciones y geometría de calles de cobertura. src/walker.rs incorpora optimize_walker_design, un optimizador de cuadrícula sin gradiente que recorre el espacio de diseño {planes × sats × inclination} y devuelve el mejor diseño Walker bajo un DesignObjective elegido (MinSatellitesForCoverage, MaxCoverage o MinWorstPdop) sobre el barrido de PDOP ya validado (una prueba confirma que devuelve el ganador por fuerza bruta). A ello se suman las formas cerradas analíticas de calles de cobertura coverage_half_angle_rad (λ = arccos(Re/r·cos ε) − ε) y street_half_width_rad (cos c = cos λ / cos(π/s), Rider/Beste), verificadas a mano con la geometría de los manuales y que detectan el hueco por falta de población. El solucionador completo de Rider de cobertura global con mínimo de satélites, un globo 3-D en el playground y una comprobación cruzada de DOP con una herramienta externa siguen como trabajo posterior.
• Exportación de efemérides precisas SP3 desde la CLI. Un escenario de órbita/constelación propagado puede ahora escribirse en un archivo SP3-c: kshana <orbit.toml> --export-sp3 out.sp3, o bien export_sp3 = true en el escenario escribe automáticamente <scenario>.sp3 (api::export_sp3 / auto_export_sp3, OrbitClockScenario::to_sp3_string, epoch opcional). Una prueba de ida y vuelta (tests/sp3_export_roundtrip.rs) propaga la instantánea real de Celestrak gps-ops, la exporta, la vuelve a analizar y confirma que las posiciones ECEF recuperadas coinciden con la referencia SGP4 durante 24 h con < 0,5 m (muy por debajo de la tolerancia de 10 m propia de TLE). El README documenta el papel de interoperabilidad (RINEX → RTKLIB/gLAB, SP3 → productos de órbita precisa de Ginan).
• Filtro de Kalman acoplado de reloj + posición (covarianza entre bloques). src/fusion/coupled.rs CoupledPntFilter es un único filtro apilado [pos, vel, phase, freq] (actualizaciones en forma de Joseph) cuya medida de pseudodistancia ρ = g·pos + c·phase + noise acopla de verdad los bloques de posición y de reloj, a diferencia de los dos filtros independientes de dos estados del paquete de fusión heredado, que mantienen la covarianza entre bloques exactamente en cero. Validado: una pseudodistancia compartida hace que P[pos,phase] sea distinto de cero; dos geometrías distintas resuelven conjuntamente desfases inyectados de posición y reloj que una sola distancia no puede separar; una corrección solo de reloj afina la posición mediante la covarianza cruzada (la ventaja que los filtros desacoplados no pueden ofrecer); y el NEES de Monte Carlo es coherente con χ²(4). Esta es la realización de 1 grado de libertad (la dimensionalidad del paquete de fusión); la extensión 3-D de 8 estados y su integración en el paquete ejecutable se registran como trabajo posterior.
• Monitorización de la salud por coherencia del filtro de Kalman (NIS/NEES). La actualización de covarianza del filtro de reloj de dos estados está ahora en forma estabilizada de Joseph `P⁺ = (I−KH)P(I−KH)ᵀ
  • KRKᵀ, which stays positive-semidefinite under extreme Q/R ratios (Cholesky-checked in CI at R=1e-26 / Q≈1e-30). A new src/filter_health.rsruns a Monte-Carlo consistency assessment (Bar-Shalom §5.4): pooled **NIS** (normalised innovation², target 1) and **NEES** (normalised estimation error², target 2) against 95% χ² bands, surfaced as afilter_health { nis_mean, nis_chi2_lower_95, nis_chi2_upper_95, nees_mean, nees_chi2_lower_95, nees_chi2_upper_95, consistent } block in the clock result JSON and as a green/amber card in the playground. A Q/R-mismatch sweep test proves the monitor flips to inconsistent when the process noise is mistuned by ×0.1–×10. Adds a general χ² quantile (detection::chi2_inv_cdf`, Wilson–Hilferty, table-checked).
• docs/PROVENANCE.md: una tabla de procedencia citable. Reúne todos los parámetros de sensores (relojes, inerciales, transferencia de tiempo), los modelos físicos/algorítmicos (órbita, sistemas de tiempo, marcos, iono/tropo, integridad, detección, jamming, Allan) y los conjuntos de datos de validación (AIAA 2006-6753, Celestrak gps-ops) con su fuente publicada (hoja de datos, artículo, ICD o norma) y una etiqueta honesta de madurez (calificado para vuelo / laboratorio en tierra / objetivo espacial sobre hardware en tierra). Se enlaza desde la introducción del README y la tabla de documentación; complementa las cadenas provenance por ejecución que ya viajan en el JSON de resultados.
• API tipada de escenarios. El despacho se hace ahora sobre una enumeración tipada ScenarioKind en lugar de una comparación de cadenas kind sin tipo (ScenarioKind::classify + despacho exhaustivo), de modo que añadir un paquete queda comprobado en compilación. Nuevas superficies tipadas junto a run_toml, que sigue devolviendo cadenas sin cambios: run_scenario(src) -> Result<RunOutput, KshanaError> con una taxonomía de errores estructurada (InvalidInput / NonConvergence / Unsupported / IoError, cada una con un kind_tag() estable); un rasgo Scenario y un punto de extensión ExternalPack (el paquete jamming se conecta a través de él como ejemplo resuelto); y la introspección list_scenario_kinds() (nombre, descripción y campos obligatorios/opcionales por tipo de escenario). Los enlaces de Python y WebAssembly incorporan list_kinds() y error_kind(). Documentado en docs/ARCHITECTURE.md.
• Constelación GPS real + cobertura de la envolvente operativa. scenarios/orbit-sgp4-gps.toml incluye ahora una instantánea real de Celestrak gps-ops (2021-07-28, 30 satélites) en lugar de TLE Walker sintéticos, con strict_checksum = true para que solo se cargue cuando todas las sumas de comprobación de los TLE sean válidas; scripts/fetch_tles.sh documenta la actualización reproducible y el README atribuye el crédito a la fuente de datos abiertos. El nuevo tests/scenario_coverage.rs ejercita cada paquete con ≥5 variantes de la envolvente comprobando que la salida sea finita y acotada, confirma que el suelo de flicker-FM degrada de forma medible la marcha libre de un reloj cuando está activado (ahora fijado en tres escenarios incluidos) y confirma que el filtro de fusión converge con un sesgo de acelerómetro realista distinto de cero (dentro de 3× del caso con sesgos nulos), con lo que se cierra la brecha de realismo de que «la fusión solo funciona con sesgos puestos a cero». docs/VALIDATION.md incorpora una tabla de Envolvente operativa.
• Simulación GNSS en el dominio de las medidas (tipo de escenario gnss-sim). Un modelo directo a nivel de pseudodistancia: por cada satélite visible sintetiza ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath y el Doppler en L1, con la ionosfera monofrecuencia de Klobuchar (IS-GPS-200 §20.3.3.5.2.5) y la troposfera cenital de Saastamoinen proyectada con la función de mapeo de Niell (1996), expuestas como bloques TOML [iono] y [tropo]. Los residuos alimentan el RAIM instantáneo para obtener HPL/VPL por época, y una matriz JSON gnss_measurements[] recoge la pseudodistancia, el Doppler, el C/N₀ y las correcciones iono/tropo de cada SV. Una ejecución sin ruido reproduce la geometría y las correcciones con precisión submilimétrica (prueba de CI). Nuevos src/gnss_sim.rs y scenarios/gnss-sim-raim.toml.
• Detector estocástico de spoofing temporal (tipo de escenario spoof). El paquete de spoofing ejecuta ahora un detector real en lugar de una comparación determinista entre rampa y cota: cuatro formas de inyección (linear_ramp, step_jump, meaconing, replay), una prueba de energía χ²₁ bilateral / Neyman–Pearson sobre el estadístico del monitor asistido por reloj, con el umbral fijado a partir de un presupuesto objetivo de falsa alarma target_pfa, y la probabilidad de detección fallida P_md notificada tanto en forma cerrada como por Monte Carlo (mc_runs ensayos por hipótesis; ambas coinciden hasta unos pocos ×1/√N). La cifra de mérito de Seguridad es ahora 1 − P_md a la magnitud operativamente dañina (la de la especificación). Nuevos src/detection.rs (funciones de cola gaussiana, prueba NP/de energía, P_fa/P_md por Monte Carlo) y scenarios/spoof-meaconing.toml. Compatible con versiones anteriores: un [attack] rate_ns_per_s a secas se sigue aceptando como rampa lineal.

Cambiado#

• Definición de la cifra de mérito de Seguridad (tipo de escenario spoof): de la cota analítica de detectabilidad 1 − min_detectable/threshold a 1 − P_md del detector estocástico. El campo security del paquete de reloj sigue siendo el proxy analítico más rápido.

Añadido (continuación)#

• Modelo de jamming de RF (tipo de escenario jamming). Un modelo de interferencia basado en el balance del enlace que convierte la potencia y la geometría de un jammer en pérdida de enganche por satélite: la relación jammer-señal a partir de la pérdida de trayecto en espacio libre y la ganancia de la antena receptora por dirección, el C/N₀ efectivo mediante la ecuación estándar antijamming (ganancia de procesamiento por desensanchamiento × el factor de separación espectral Q; Kaplan y Hegarty §9,4) y un umbral de seguimiento configurable, puntuado sobre una constelación Walker como cifra de mérito availability_under_jamming. Nuevos src/jamming.rs y scenarios/jamming-demo.toml. El alcance honesto (sin multitrayecto, sombra del terreno, AGC ni anulación adaptativa) está documentado en docs/CAPABILITY.md / docs/VALIDATION.md.
• Barrido genérico de parámetros N-D sobre cualquier tipo de escenario (sweep-nd). El barrido N-D anterior era solo del paquete de reloj. sweep-nd varía claves TOML con puntos de un escenario [base] sobre el producto cartesiano de sus ejes, vuelve a despachar cada nodo de la cuadrícula por la ruta de ejecución normal y lee una o varias métricas del resultado mediante una ruta JSON con puntos, de modo que funciona con todos los paquetes (inercial, gnss-ins, integridad, spoof, …) sin acoplarse al tipo Rust de cada paquete. Los nodos de la cuadrícula se evalúan en paralelo entre hilos del SO en destinos nativos (sin dependencias añadidas); wasm recurre a la ejecución secuencial. Determinista y por filas, con independencia del número de hilos. Nuevo ejemplo scenarios/sweep-nd-inertial.toml.
• Modelo determinista de errores de IMU configurable por TOML en el paquete gnss-ins. La cadena de errores strapdown de tres ejes (factor de escala, desalineación, sensibilidad a g, cuantización, rampa de velocidad; IEEE Std 952-1997 §A.2, Groves 2013 §4,3) es ahora accesible por sensor desde un archivo de escenario mediante un bloque opcional [imu_*.error_model], superpuesto a los sesgos constantes de arranque. Si se omite el bloque, cada sensor queda como una fuente pura de sesgo constante, de modo que las ejecuciones gnss-ins existentes no cambian. Así se conecta el modelo de errores, antes solo de biblioteca, a un paquete ejecutable y a una cifra de mérito.

0.10.0 - 2026-06-04#

Cambiado#

• Validación con datos reales. El analizador de navegación RINEX multi-GNSS, el propagador RK4 de GLONASS y el lector de SP3 se ejercitan ahora con archivos genuinos del IGS/DLR (un archivo real de navegación difundida RINEX 3 mixto y un producto de órbitas IGS SP3-c), y no solo con muestras de elaboración propia, comprobando conjuntos de satélites no vacíos y posiciones ECEF finitas y de tamaño físicamente razonable. Los archivos de prueba son solo para pruebas (excluidos del crate publicado); véase tests/fixtures/igs/NOTICE.
• RAIM sobre geometría de órbitas de referencia reales. Los núcleos de RAIM instantáneo, de separación de soluciones (MHSS) y de niveles de protección ARAIM están ahora validados con la geometría real de órbitas precisas IGS (SP3), y no solo con constelaciones sintéticas: la geometría de línea de visión se construye a partir de la primera época SP3 en una estación terrestre real, y las pruebas comprueban niveles de protección de orden métrico y disponibles para APV-I, que un sesgo de pseudodistancia de 60 m dispara el monitor χ², que la separación de soluciones identifica el satélite con fallo y que los niveles de ARAIM satisfacen el P_HMI asignado. Se cierra así la brecha de validado solo sobre geometría sintética (la paridad de gLAB en el dominio del receptor sobre un arco RINEX completo sigue siendo un elemento de la hoja de ruta: requiere una solución de pseudodistancia).

Añadido#

• Intervalos de confianza por nodo para el barrido de parámetros N-D (sweep::nd_sweep_ensemble). Cada nodo de la cuadrícula del barrido cartesiano N-dimensional puede evaluarse ahora como un conjunto Monte Carlo de semillas, que notifica la media, los percentiles y un IC bootstrap por percentiles del 95 % de la métrica en cada nodo (para ambos relojes): un barrido estadísticamente honesto en lugar de una sola realización por nodo. Reutiliza la maquinaria de conjunto/bootstrap (metric_stat); determinista; runs = 1 se reduce exactamente al nd_sweep de una sola semilla. (Queda por generalizar el barrido a todos los paquetes, ligado al refactor del Scenario tipado, y la ejecución en paralelo.)
• Validación cruzada con NaveGo del pipeline de ruido de IMU (tests/navego_imu_crossval.rs). Una comprobación cruzada externa con NaveGo (la herramienta de código abierto de INS/GNSS de R. Gonzalez): reproduce el viaje de ida y vuelta sintético de navego_example_allan.m sobre su perfil de referencia publicado del Microstrain 3DM-GX3-35, y confirma que nuestro estimador de ADEV solapado recupera los coeficientes de paseo aleatorio de velocidad y de ángulo de NaveGo (ADEV(1 s) = σ·√dt) con un error inferior al 5% y con la pendiente de ruido blanco −1/2 esperada. (El registro .mat del STIM300 grabado, de 40 MB, no se ingiere: depende del formato binario.)
• Actualización GNSS/INS fuertemente acoplada (pseudodistancia). GnssInsEkf::update_tightly_coupled (y el envoltorio ClosedLoopInsGnss::fuse_tightly_coupled) implementan la medida en el dominio de la distancia que antes estaba sin implementar: la innovación es la distancia predicha desde la posición del INS hasta cada satélite frente a la pseudodistancia medida, con un jacobiano de línea de visión sobre el error de posición. Como cada satélite es una medida escalar, el filtro sigue corrigiendo con menos de cuatro satélites, donde no existe una solución PVT débilmente acoplada. Cinco pruebas cubren la anulación con cuatro satélites, la corrección con dos satélites (sin PVT posible), la observabilidad a lo largo de la línea de visión con un solo satélite y la validación de entradas. Solo pseudodistancia; la fase de portadora y un estado explícito del reloj del receptor siguen en la hoja de ruta. Se elimina la característica de cargo tight_coupling, que no se usaba (y que condicionaba el antiguo código de error provisional).
• Paquete de escenarios GNSS/INS débilmente acoplado (kind = "gnss-ins", src/fusion/pack.rs). Conecta el navegador strapdown de tres ejes y el EKF de estado de error de 15 estados (closed_loop / gnss_ins_ekf) en un escenario ejecutable con una figura de mérito: el EKF disciplina la mecanización con fijaciones GNSS ruidosas mientras hay cobertura y luego avanza por inercia durante la interrupción, con lo que sustituye el reinicio por ajuste a la verdad del paquete escalar heredado de 1 grado de libertad por una fusión genuina. El resultado informa de la serie fusionada de error horizontal, la FoM de posición puntuada (disponibilidad / RMS en la interrupción / holdover) y el RMS del INS libre en lazo abierto como comparación; un par de IMU cuántica/clásica se diferencia solo en el sesgo verdadero. Se despacha desde el punto de entrada de CLI/Python/wasm con un ejemplo en scenarios/gnss-ins.toml. Planteamiento honesto: solo acoplamiento débil, una trayectoria determinista, y el error fusionado en la interrupción está limitado por un suelo que fija el error de actitud en el traspaso (por lo que no se afirma que escale con el sesgo); los hallazgos sólidos son que la fusión supera a la navegación a estima sin ayuda para un sensor con sesgo y que un sensor con menor sesgo tiene la mejor deriva sin ayuda.
• Diseño de constelaciones sobre el núcleo SGP4 validado (src/walker.rs). Un nuevo módulo walker emite un patrón Walker-delta diseñado (i: T/P/F) como elementos medios de SGP4, de modo que la constelación sintética se propaga por la misma ruta SGP4 validada hasta 4,12 mm frente a los vectores de AIAA 2006-6753, y no con el generador kepleriano analítico. Encima de él: pdop_sweep tabula la cobertura y el PDOP mediano/peor sobre una malla de diseño {planes × sats × inclination}, y coverage_revisit informa de la fracción de cobertura y de los huecos de revisita (peor/media) en un punto del suelo. Validado mediante las monotonías físicas que debe cumplir un estudio de compromiso (más satélites ⇒ mayor cobertura, menor PDOP, revisita más corta). Además, se añade como fixture solo de pruebas una instantánea TLE genuina de Celestrak gps-ops (2021-07-28, 30 satélites GPS operativos), y la ruta de geometría TLE real → SGP4 → ECEF se valida con ella (toda la capa MEO a menos del 1%, nueve satélites todos a la vista con un PDOP de 1,64), junto a las rutas de datos reales SP3 y RINEX ya existentes.
• Grados de libertad efectivos específicos de cada tipo de ruido para los intervalos de confianza de Allan. allan::edf_overlapping_adev implementa las formas cerradas de la Tabla 5 de NIST SP 1065 (el conjunto simple de Stable32) para los cinco tipos canónicos de ruido de ley de potencias (PM blanco/flicker, FM blanco/flicker y FM de paseo aleatorio), y sustituye el recuento conservador sin solapamiento como grados de libertad de χ². Un nuevo enum PowerLawNoise y classify_power_law identifican el tipo dominante a partir de la pendiente de la desviación de Allan modificada del registro (la MDEV distingue el PM blanco del flicker donde la ADEV no puede), y overlapping_adev_curve ahora adjunta a cada punto de la curva ADEV exportada el tipo de ruido identificado, su edf y una banda de confianza del 95% (AdevPoint añade noise/edf/ci_lo/ci_hi, de forma aditiva con valores por defecto de serde). Validado de dos maneras: las cinco fórmulas coinciden con valores evaluados a mano hasta 1e-12, y un conjunto Monte Carlo de 4 000 registros de FM blanco confirma que la fórmula predice el edf de chi cuadrado real del estimador con una diferencia de hasta el 20% (y que supera claramente al recuento conservador). Ocho pruebas nuevas.
• Modelo estocástico de transferencia de tiempo bidireccional. timetransfer::TwoWayLink sustituye el muestreador solo de ruido blanco por un modelo con fundamento físico: el retardo recíproco de trayecto (de modo común) se cancela en la estimación (m_AB - m_BA)/2 (two_way_offset_estimate, de modo que dos medidas unidireccionales independientes se promedian a 1/sqrt(2)), y el residuo es el retardo diferencial no recíproco, modelado como un proceso coloreado de FM blanco + FM de paseo aleatorio (el ClockModel validado), lo que da a la serie de error de sincronización una firma de Allan realista (sigma_y^2(tau) = q_rw*tau/3) en lugar de ruido blanco plano. LinkCfg añade q_wf_s/q_rw_s (valor por defecto de serde 0 ⇒ el comportamiento heredado solo de ruido blanco, bit a bit), la FoM del enlace informa de adev_tau0 (la desviación de Allan del modelo en el paso base), y el escenario timetransfer y la CLI lo exponen. FoM de referencia (golden) vuelta a fijar. Seis pruebas derivadas a mano (cancelación de modo común, la ganancia bidireccional de sqrt(2), la ley tau/3 del RWFM mediante el propio step() del enlace, equivalencia con el comportamiento heredado en q=0, determinismo y exposición de la FoM de extremo a extremo).
• Paridad numérica con Stable32 para los estimadores de la familia de Allan (NBS14). tests/allan_reference.rs valida los estimadores de ADEV solapada, ADEV modificada, desviación de tiempo y Hadamard solapada frente a las desviaciones de referencia de Stable32 para el conjunto de datos canónico NBS14 (W. J. Riley, Handbook of Frequency Stability Analysis, NIST SP 1065, ~p.107) con tau = 1, 2 y una tolerancia relativa de 1e-4; la concordancia real es de ~1e-6. Esto fija la matemática de los estimadores frente a la implementación de referencia de facto, y no solo frente a la autoconsistencia analítica de los propios estimadores. Solo se usan los números de referencia públicos; no se usa código de terceros.
• Diagrama de integridad de Stanford vertical exportado por el escenario integrity. El tipo de escenario integrity ejecutable exporta ahora un diagrama de Stanford(-ESA) vertical junto al mapa de disponibilidad HPL/VPL: en cada época protegida, una extracción de error de distancia sin fallo, con semilla y reproducible, se traslada a través de la geometría a un error de posición vertical real y se clasifica frente al VPL y al límite de alerta vertical (Available / System-Unavailable / Misleading / Hazardously-Misleading). El diagrama (puntos por época + recuentos por región) va en el JSON del resultado, y los recuentos de eventos de integridad / HMI en el resumen de la CLI, de modo que el clasificador de Stanford, antes solo disponible en la biblioteca, es accesible de extremo a extremo. IntegrityScenario añade un campo seed (por defecto 0) que controla la realización del error; el propio mapa de disponibilidad sigue dependiendo solo de la geometría y es independiente de la semilla.
• Presupuesto de riesgo de integridad (P_HMI) de ARAIM para los niveles de protección. raim::araim_raim deriva los niveles de protección horizontal y vertical a partir de un presupuesto explícito de riesgo de integridad, en lugar de un multiplicador K_md fijo: para la solución con todos los satélites a la vista y para cada subsolución que excluye un satélite, construye en cada eje la terna (prior, detection threshold, σ) por modo, y luego araim_protection_level resuelve el menor PL cuya probabilidad sumada de información peligrosamente engañosa (araim_integrity_risk, P_HMI = Σ_k p_fault,k · Q((PL − T_k)/σ_k), Blanch et al. Baseline ARAIM) satisface el P_HMI asignado. El resultado informa del riesgo de integridad que los niveles alcanzan realmente, de modo que el usuario puede intercambiar integridad por límite de alerta de forma explícita. Seis pruebas derivadas a mano (formas cerradas de un solo modo sin fallo y con umbral, suma y monotonía multimodo, protección sin fallo de extremo a extremo con un presupuesto 10⁵× más estricto que eleva el PL, detección/identificación de fallos y el suelo de redundancia de seis satélites). El MHSS de fallo único es la línea base de ARAIM; los fallos simultáneos de subconjuntos de varios SV, el modo de fallo de toda la constelación y la validación con el conjunto de datos de referencia de gLAB son extensiones documentadas.
• Compensación de coning/sculling de dos velocidades para la mecanización strapdown. inertial::mechanization::coning_sculling_compensate extrae los términos de coning (actitud) y de rotación+sculling (velocidad) de alta tasa a partir de los incrementos ordenados de IMU de los subintervalos de una actualización gruesa, de modo que un NavState::step_increments de tasa moderada reproduce el movimiento rectificado por vibración que un paso grueso sobre las sumas en bruto pierde. Una prueba de validación aplica un entorno de coning+sculling de 10 Hz durante 60 s y compara la verdad de tasa fina, la integración gruesa ingenua y la integración gruesa con el plegado: el plegado reduce el error de posición en ~18× (de metros de deriva ingenua a menos de un decímetro), lo que confirma que los términos de coning/sculling son determinantes. Un alias de tipo ScalarErrorBudget da su nombre real al AccelModel heredado de 1 grado de libertad, distinto del navegador de tres ejes NavState.
• Analizador de archivos de observación RINEX. El nuevo módulo rinex_obs lee el archivo de observación RINEX 3.0x / 4,00 (las medidas reales del receptor), con lo que completa el par RINEX junto al analizador del mensaje de navegación ya existente. parse_obs decodifica la cabecera (versión/tipo, las listas SYS / # / OBS TYPES por sistema con líneas de continuación, posición aproximada, intervalo, instante de la primera observación) y los registros por satélite de cada época: pseudodistancia, fase de portadora, Doppler e intensidad de señal, indexados por su código de observación RINEX 3 (C1C, L1C, …) con los indicadores de pérdida de enganche (LLI) y de intensidad de señal (SSI); un campo en blanco se conserva como ausente y no como cero. Alcance real: esto es la ingesta en formato estándar (entra un registro de observación real de RTKLIB/gLAB/estación IGS y salen medidas tipadas), no un motor de posicionamiento: aquí no hay solución de pseudodistancia, PPP ni RTK.
• Escritor de CCSDS OEM (Orbit Ephemeris Message). El nuevo módulo oem exporta una constelación propagada como un mensaje OEM CCSDS 502.0-B 2,0 válido, el formato KVN de efemérides que ingieren GMAT, Orekit, STK y la mayoría de las herramientas de dinámica de vuelo. OemFile::from_propagators muestrea el estado inercial (TEME) de cada satélite, posición y velocidad, tomado directamente del propagador sin rotación a ejes fijos a la Tierra, a diferencia de la exportación SP3, sobre una malla temporal, y OemFile::to_oem_string serializa la cabecera CCSDS_OEM_VERS/CREATION_DATE/ ORIGINATOR más un segmento META_START … META_STOP por satélite (OBJECT_NAME/OBJECT_ID/CENTER_NAME/REF_FRAME = TEME/TIME_SYSTEM = GPS/ START_TIME/STOP_TIME) seguido de sus líneas epoch X Y Z X_DOT Y_DOT Z_DOT (km, km/s). La CREATION_DATE la aporta quien llama, nunca el reloj de pared, de modo que la salida es idéntica byte a byte entre ejecuciones (el contrato de reproducibilidad). Es la contrapartida de efemérides de naves de la exportación SP3 de GNSS: ahora una órbita de Kshana puede entregarse a una herramienta de dinámica de vuelo en un formato estándar.
• Efemérides precisas SP3 como fuente de propagación. Sp3File::interpolator construye un Sp3Interpolator por satélite que rellena la posición entre las épocas tabuladas de SP3 con un polinomio de Lagrange de 9.º orden (práctica estándar del IGS) y la rota al marco TEME compartido, expuesto como Propagator::Sp3Precise. Un archivo de órbitas precisas de un centro de análisis o del IGS puede ahora alimentar la misma cadena de geometría/visibilidad/integridad que los propagadores de difusión y analíticos. Ida y vuelta validada: una órbita kepleriana escrita en SP3 y releída a través del interpolador coincide con la original a menos de un metro en los nodos y a menos de 100 m a mitad de intervalo. La interpolación del reloj es lo siguiente.
• Efemérides de difusión de GLONASS (completa la navegación RINEX multi-GNSS). Nuevo módulo glonass: GLONASS no difunde elementos keplerianos sino un vector de estado fijo a la Tierra en PZ-90 (posición, velocidad, aceleración lunisolar). parse_glonass_nav lee los registros R de RINEX 3, y la posición del satélite en cualquier instante se obtiene mediante integración de Runge–Kutta de 4.º orden de las ecuaciones de movimiento del ICD de GLONASS (gravedad central + J2 + términos de Coriolis/centrífugo de la rotación terrestre + la aceleración difundida). Expuesto como Propagator::Glonass, de modo que los satélites GLONASS fluyen por la cadena de constelación/visibilidad/integridad junto a los sistemas keplerianos; un único bloque de constelación rinex puede ahora mezclar GPS, Galileo, QZSS, BeiDou y GLONASS.
• Navegación RINEX multi-GNSS (GPS, Galileo, QZSS, BeiDou). El analizador de navegación RINEX 3 decodifica ahora registros de Galileo (E), QZSS (J) y BeiDou (C, MEO/IGSO) junto a los de GPS (G); comparten la disposición kepleriana y el algoritmo de usuario, y cada uno se evalúa con su propia constante gravitacional y su propia velocidad de rotación terrestre (μ de Galileo/BeiDou, Ω̇ₑ de BeiDou). Un archivo de constelaciones mixtas los entrega todos, y fluyen por la cadena de constelación/visibilidad/integridad como Propagator::Rinex. Los satélites geoestacionarios de BeiDou usan una rotación de coordenadas distinta y se omiten hasta disponer de un fixture de referencia con el que validarlos. El recorrido de registros usa recuentos de líneas por sistema, con lo que se corrige un error latente por el que los registros GLONASS/SBAS de cuatro líneas se omitían como si tuvieran ocho. GLONASS (un modelo de vector de estado) es lo siguiente.
• Lector y escritor de efemérides precisas SP3-c/d. El nuevo módulo sp3 analiza archivos de órbitas precisas SP3 del IGS o de centros de análisis (parse_sp3), el producto posprocesado de posición/reloj en ECEF que los motores PPP (Ginan, RTKLIB, gLAB) tratan como referencia, en un Sp3File estructurado (cabecera, malla de épocas, posición por satélite km→m, reloj µs y velocidad dm/s→m/s para productos V), y conserva los valores centinela de dato erróneo de SP3. También se cubre el sentido inverso: Sp3File::from_propagators construye un SP3 a partir de una constelación propagada (TEME→ECEF por época) y to_sp3_string lo serializa, de modo que las órbitas de Kshana pueden exportarse en el formato que ingieren las herramientas PPP externas: el viaje de ida y vuelta lectura↔escritura. La interpolación de épocas y una fuente de propagador SP3 son lo siguiente.
• Efemérides de difusión RINEX como fuente de constelación ejecutable. Una constelación acepta ahora un bloque rinex en línea (texto de navegación GPS RINEX 3) junto a la opción tle ya existente, de modo que un archivo de difusión real maneja un escenario de extremo a extremo desde la CLI, Python o el playground del navegador: entra RINEX, sale geometría PNT. El nuevo scenarios/orbit-rinex.toml demuestra la disponibilidad GNSS y el DOP con ocho satélites GPS construidos directamente a partir de registros de difusión. (Solo GPS LNAV; multi-GNSS y SP3 son lo siguiente.)
• Efemérides de difusión RINEX como fuente de propagación. Un RinexEphemeris analizado se convierte ahora en un orbit::Propagator (Propagator::Rinex): la posición es la órbita de difusión de IS-GPS-200 rotada de ECEF al marco inercial TEME compartido (sv_position_teme, con tiempo GPS→UT1 correcto respecto a los segundos intercalares), la velocidad se obtiene por diferencia finita central, y se da el periodo orbital kepleriano. Los datos de difusión GPS reales pueden ahora alimentar la misma cadena de geometría, visibilidad e integridad (RAIM) que los propagadores analíticos SGP4/keplerianos. (Todavía no se expone como tipo de escenario de archivo RINEX; eso y multi-GNSS/SP3 son lo siguiente.)

0.9.2 - 2026-06-03#

Añadido#

• DOI de archivo. Las versiones se depositan ahora en Zenodo y se les asigna un DOI citable.

0.9.1 - 2026-06-03#

Cambiado#

• Documentación. Se ha renovado el README hasta un nivel institucional: una visión general de las capacidades de toda la pila de v0.9.0, una sección de versionado y versiones, una cabecera limpia con la nueva marca y una línea de estado concisa. Sin cambios en el motor.

0.9.0 - 2026-06-03#

Esta versión añade tres áreas sustanciales de capacidad sobre el sustrato SGP4 de 0.8.0: un INS strapdown genuino de tres ejes, un EKF de estado de error GNSS/INS débilmente acoplado con realimentación en lazo cerrado, RAIM real de instantánea y de separación de soluciones (al estilo ARAIM) con HPL/VPL y un escenario integrity ejecutable, y el primer paso de la interoperabilidad con formatos GNSS (ingesta de efemérides GPS RINEX-3).

Añadido#

• Analizador del mensaje de navegación GPS RINEX 3 (src/rinex.rs). Primer paso hacia la interoperabilidad con formatos GNSS: parse_nav lee un archivo de navegación RINEX 3.x y decodifica cada registro de efemérides de difusión GPS (G), el bloque de ocho líneas SV/época + BROADCAST ORBIT, en un RinexEphemeris de elementos keplerianos y correcciones de reloj, con nombres de campo y unidades según IS-GPS-200. Gestiona el formato de coma flotante de Fortran con exponente D (parse_d) y la disposición de columnas de ancho fijo; los registros de sistemas distintos de GPS se omiten, no se rechazan, de modo que un archivo mixto sigue entregando sus efemérides GPS. Cuatro pruebas: análisis del exponente D (incluidos blancos y errores), un registro completo decodificado frente a valores de campo conocidos con una comprobación de cordura del semieje mayor GPS (√A² ≈ 26.560 km), omisión de los no GPS y el caso de archivo vacío.
• Efemérides de difusión GPS → posición ECEF (src/rinex.rs). RinexEphemeris::sv_position_ecef(t_tow) evalúa la posición del satélite en ejes fijos a la Tierra a partir de las efemérides analizadas mediante el algoritmo de usuario de IS-GPS-200 §20.3.3.4.3.1: solución de Newton de la ecuación de Kepler para la anomalía excéntrica, las correcciones de segundo armónico del argumento de latitud / radio / inclinación y la rotación a ECEF teniendo en cuenta la rotación terrestre desde la época de referencia (con el μ y el Ω̇ₑ de GPS que exige la especificación, y un plegado de tk por cambio de semana). Tres pruebas: el radio geocéntrico se mantiene en la banda GPS (≈ 26.560 km), la velocidad en ejes fijos a la Tierra es de ~3,9 km/s, y evaluar con una semana completa de diferencia reproduce la misma posición.
• Sesgo de reloj del SV GPS con la corrección relativista (src/rinex.rs). RinexEphemeris::sv_clock_bias_s(t_tow) evalúa el polinomio de reloj de difusión af0 + af1·Δt + af2·Δt² en torno a Toc más el término relativista de excentricidad F·e·√A·sin Ek (IS-GPS-200 §20.3.3.3.3.1). Un nuevo EpochUtc::gps_time_of_week convierte la época de calendario del registro en tiempo de semana GPS mediante aritmética de día juliano desde la época GPS (1980-01-06), y la resolución de Kepler se comparte con la evaluación de la posición. Pruebas: el tiempo de semana GPS para un domingo/martes/sábado (límites de semana), y el sesgo de reloj dominado por af0 con un término relativista presente y acotado. El retardo de grupo L1 TGD se expone, pero deliberadamente no se incorpora. Alcance real: una fuente Propagator, Galileo/BeiDou/GLONASS y SP3 siguen siendo pasos futuros. (docs/CAPABILITY.md actualizado en consecuencia.)
• Tipo de escenario integrity ejecutable por el usuario (scenarios/integrity-raim.toml). La capacidad de disponibilidad RAIM es ahora accesible desde la CLI/TOML como cualquier otro paquete: kind = "integrity" analiza un IntegrityScenario (órbita del usuario, una o más constelaciones GNSS, máscara de elevación y la configuración de integridad (sigma, P_fa, P_md, AL_H, AL_V)), ejecuta constellation_raim_availability y emite el mapa de disponibilidad HPL/VPL por época como JSON más un SVG autocontenido: niveles de protección a lo largo del tiempo frente a los límites de alerta, con una franja de disponibilidad verde/roja. kshana scenarios/integrity-raim.toml escribe el JSON, el gráfico y un informe HTML. El escenario incluido (Walker de 24 satélites, medición de distancias de doble frecuencia de 1 m, límites APV-I) informa de una disponibilidad de ~95 %; documenta que el RAIM de frecuencia única no alcanza el límite vertical de APV-I con una sola constelación, razón por la que la guía vertical usa SBAS/doble frecuencia/ARAIM. Las pruebas cubren el despacho, el JSON del mapa de disponibilidad y el SVG.
• Disponibilidad RAIM ejecutable sobre una constelación (src/raim.rs). El módulo de integridad no tenía quien lo llamara; constellation_raim_availability lo convierte en un punto de entrada genuino de extremo a extremo: en cada época de una malla temporal propaga los satélites visibles (los mismos Propagator SGP4/keplerianos que usa el motor), calcula los niveles de protección sin fallo y juzga la disponibilidad frente a los límites de alerta horizontal/vertical, y devuelve un RaimAvailabilityReport serializable con serde (por época n_visible/HPL/VPL/available más la fracción de disponibilidad). Un RaimConfig agrupa (sigma, P_fa, P_md, AL_H, AL_V), y el raim_availability_epoch por época se expone para quienes llaman y resuelven su propia geometría. Tres pruebas: una época juzgada disponible bajo los límites APV-I con una geometría de diez satélites, convertida en no disponible por un límite imposiblemente estricto, y niveles None con menos de cinco satélites; y una ejecución de extremo a extremo sobre una constelación Walker de 24 satélites que produce un mapa de disponibilidad finito y se serializa. (Seis satélites, el suelo de redundancia del RAIM residual, honestamente no satisfacen APV-I ni siquiera con una medición de distancias de 1 m; la disponibilidad de APV-I necesita la geometría más densa que usa la prueba.)
• Acumulador del diagrama de integridad de Stanford(-ESA) (src/raim.rs). La forma estándar de resumir un monitor de integridad a lo largo de muchas épocas: representa el error de posición real (x) frente al nivel de protección (y) y clasifica cada época, según la diagonal y = x y el límite de alerta, en Available (el PL acota el error, dentro del AL), SystemUnavailable (el PL acota el error pero supera el AL: seguro, inutilizable), MisleadingInformation (PL < error ≤ AL) o HazardouslyMisleadingInformation (PL < error y error > AL: el fallo inseguro). classify_stanford es el clasificador puro; StanfordDiagram acumula puntos (error, PL) frente a un límite de alerta fijo, y expone recuentos por región, disponibilidad, totales de eventos de integridad y puntos serializables con serde para representación gráfica/exportación JSON. Cuatro pruebas: cada región (incluido el límite acotado error == PL), acumulación de recuentos/disponibilidad e ida y vuelta por JSON. Esta es la superficie de informes de los niveles de protección RAIM; conectarla al escenario de constelación y validarla frente a un conjunto de datos público siguen siendo elementos de la hoja de ruta.
• RAIM de separación de soluciones (al estilo ARAIM) (src/raim.rs). Un monitor de integridad de hipótesis múltiples junto al snapshot_raim ya existente de chi cuadrado de residuos/paridad. Para la solución de mínimos cuadrados con todos los satélites a la vista y para cada subsolución que excluye un satélite, forma la separación Δ_k = x_k − x₀, gaussiana de media cero sin fallo y con covarianza Cov(x_k) − Cov(x₀) (la identidad de estimadores anidados, válida porque la solución con todos los satélites a la vista es BLUE), y así detecta un fallo e identifica el satélite averiado (aquel cuya exclusión da la mayor separación normalizada). Los niveles de protección horizontal/vertical siguen la asignación MHSS estándar PL = max(K_md·σ₀, max_k[K_fa·σ_ss,k + K_md·σ_k]), con K_fa = Φ⁻¹(1−P_fa/2), K_md = Φ⁻¹(1−P_md). Nuevas normal_cdf/normal_quantile sin dependencias, construidas sobre la gamma incompleta regularizada que ya existía en el módulo (erf(x) = P(½,x²)). Cuatro pruebas derivadas a mano: CDF normal / cuantil frente a valores de manual (Φ(1,95996)=0,975, la cola de 1e-7 = 5,1993, simetría); una geometría sin fallo que no da alarma y produce HPL/VPL finitos y positivos; un sesgo de 60 σ en un solo satélite que se detecta e identifica correctamente (excluded_sv == 2); y el suelo de redundancia de seis satélites. Cierra, por el lado del algoritmo, la brecha P0 de la auditoría «integridad tautológica: sin RAIM/HPL/VPL reales»; la validación con el conjunto de datos de gLAB y el acumulador del diagrama de Stanford siguen siendo elementos de la hoja de ruta.
• Integración GNSS/INS en lazo cerrado (src/fusion/closed_loop.rs). ClosedLoopInsGnss conecta el núcleo del EKF de estado de error con la mecanización strapdown de tres ejes: cada muestra de IMU se corrige con las estimaciones de sesgo en curso, se mecaniza hacia delante y la covarianza del EKF se propaga en el tiempo con el contexto de navegación correspondiente; cada fijación GNSS de posición/velocidad forma la innovación INS−GNSS y realimenta a la solución el error estimado de posición, velocidad, actitud (ψ, como rotación en cuaternión) y los sesgos de acelerómetro/giróscopo, y reinicia la media del estado de error. Realimentar la actitud (y no solo los sesgos) es necesario para la estabilidad: la inclinación y el sesgo del acelerómetro forman un par acoplado, así que corregir uno sin el otro diverge. INS y GNSS se comparan en un sistema local de plano tangente NED con los propios radios de curvatura de la mecanización (nuevo mechanization::radii_of_curvature; NavState::omega_ie_n/omega_en_n expuestos). Este es el sustituto honesto del reinicio por ajuste a la verdad del paquete híbrido. Tres pruebas: un lazo cerrado que anula un error de posición inyectado de 8 m / −5 m hasta <0,1 m; una solución con ayuda que se mantiene acotada a metros (<6 m) en una trayectoria de conducción mientras un INS en funcionamiento libre diverge más allá de 100 m; y el hito de referencia: el RMS de posición Monte Carlo de la solución fusionada durante una interrupción GNSS de 60 s supera en >2× a un navegador a estima en lazo abierto sin ayuda (≈4× entre semillas). Limitación honesta documentada en el módulo: en modo débilmente acoplado el sesgo del acelerómetro y la inclinación solo son débilmente separables (ambos se acoplan a través de la gravedad), por lo que el valor entregado es el estado acotado y corregido y una entrada limpia en la interrupción, no una calibración inercial precisa; una dinámica más rica y la extensión fuertemente acoplada siguen siendo elementos de la hoja de ruta.
• Núcleo del EKF de estado de error GNSS/INS débilmente acoplado (src/fusion/gnss_ins_ekf.rs). Un filtro de Kalman extendido de estado de error de 15 estados, δx = [δp, δv, ψ, b_a, b_g], con la dinámica de error strapdown de Groves 2013 §14,2 (acoplamiento fuerza específica/inclinación, Coriolis, proyección del sesgo del cuerpo a navegación, modelos de sesgo de Gauss–Markov), una transición discreta de primer orden Φ = I + F·dt y una actualización de medida débilmente acoplada de posición+velocidad (H = [I₃ 0 0 0 0; 0 I₃ 0 0 0]) en forma de Joseph. Álgebra lineal densa sin dependencias (inversa de Gauss–Jordan, actualización de covarianza de Joseph). Una característica de cargo tight_coupling condiciona una actualización de pseudodistancia/Doppler documentada, aún no implementada. 7 pruebas con expectativas derivadas a mano: la identidad del producto vectorial/antisimétrico, una inversa 3×3 verificada, la covarianza que se mantiene simétrica/PSD bajo predicción (y la incertidumbre de posición que crece sin ayuda), una fijación de posición que reduce la covarianza de posición, la recuperación exacta de un error de posición conocido con la ganancia de Kalman analítica P/(P+R), y correcciones menores con un ruido de medida mayor. Es el núcleo que sustituirá el reinicio por ajuste a la verdad en lazo abierto del paquete híbrido por una realimentación en lazo cerrado (la conexión al paquete y la validación con NaveGo vendrán después).
• Modelo determinista de errores de IMU para el navegador strapdown de 3 ejes (src/inertial/imu_errors.rs). ImuErrorModel distorsiona un par (ω, f) verdadero en ejes del cuerpo hasta convertirlo en uno medido mediante cinco categorías sistemáticas (IEEE Std 952-1997 §A.2; Groves 2013 §4,3, Tabla 4,1): factor de escala (error de ganancia por eje en ppm), desalineación / acoplamiento cruzado (no ortogonalidad fuera de la diagonal de la terna), sensibilidad a g (un sesgo de velocidad del giróscopo proporcional a la fuerza específica), cuantización (redondeo al LSB de salida) y rampa de velocidad (una deriva lineal en el tiempo, la tercera región de Allan), además de un sesgo constante de arranque. Todos los términos valen cero por defecto, de modo que ImuErrorModel::ideal() es un paso transparente y los escenarios existentes no se ven afectados. Cada fuente de error tiene una prueba de aislamiento (escala lineal hasta <0,01%, desalineación entre ejes por encima del suelo de VRW, sesgo de sensibilidad a g, rejilla de LSB, rampa lineal), y una prueba de extremo a extremo hace pasar un error de navegación por la mecanización a partir de una IMU distorsionada. No modelados: error de rectificación por vibración, deriva por gradiente de temperatura. (El paquete de escenarios inertial incluido sigue ejecutando el presupuesto escalar heredado de 1 grado de libertad; este modelo alimenta la biblioteca de 3 ejes.)
• Compensación de coning y sculling para el integrador strapdown. La ruta de actitud añade el coning_increment de dos muestras (½ Δθ_prev × Δθ_cur); se verifica que una integración de tasa gruesa (30 Hz, 5 muestras/ciclo) de un entorno de coning de 5 Hz sigue la verdad de tasa fina ≥ 3× mejor con la corrección que sumando incrementos de forma ingenua. La ruta de velocidad añade sculling_increment (½ Δθ × Δv, ec. 5,82 de Groves) y resuelve el incremento de velocidad del cuerpo mediante una nueva actualización basada en incrementos NavState::step_increments que usa la rotación relativa al cuerpo Δθ_rel = Δθ_b − C_n^b ζ, de modo que una plataforma fija a la Tierra no incurre en sculling espurio mientras que una vibración genuina activa el término completo.
• Mecanización strapdown completa de tres ejes en el marco NED (src/inertial/mechanization.rs). NavState { q, v_ned, p_llh } avanza con step(gyro_b, accel_f_b, dt) mediante las ecuaciones NED estándar en marco terrestre (Groves §5,4): actitud del cuerpo a NED corregida por la velocidad angular inercial-a-navegación ω_in = ω_ie + ω_en (rotación terrestre + velocidad de transporte); fuerza específica resuelta del cuerpo a NED mediante la DCM; velocidad que integra v̇ = f_n − (2 ω_ie + ω_en) × v + g_n (Coriolis/transporte + gravedad); y posición geodésica mediante los radios de curvatura meridiano/transversal. La gravedad es la gravedad normal (de plomada) en forma cerrada de Somigliana de WGS-84 con una corrección de altitud de aire libre de NIMA, nunca una constante fijada en el código. Es el navegador genuino de tres ejes que sustituye a la ruta escalar de presupuesto de errores de 1 grado de libertad. Verificado con invariantes físicas: una plataforma atornillada a la Tierra en rotación a 45°N (que mide la velocidad de rotación terrestre + 1 g) se mantiene dentro de 1 mm durante 60 s; una fuerza específica horizontal hacia el norte da v_N ≈ a·t y un desplazamiento ½ a t²; la gravedad normal coincide con los valores superficiales conocidos del ecuador, el polo y los 45° y con la tasa de variación de aire libre.
• Representación de actitud de tres ejes para INS strapdown (src/inertial/attitude.rs). Un tipo de cuaternión unitario Quaternion (escalar primero, convención de Hamilton) que lleva la rotación del cuerpo a navegación, con una vista DCM (to_dcm/from_dcm mediante el método de Shepperd), producto de Hamilton, constructores de eje-ángulo y de vector de rotación (mapa exponencial exacto) y cinemática de cuaterniones: tanto una actualización de velocidad RK de primer orden (q̇ = ½ q ⊗ ω) como una actualización de vector de rotación con corrección de coning. El coning_increment de dos muestras (Savage / Bryan–Lewantowski, ½ Δθ_prev × Δθ_cur) aporta el término de acoplamiento cruzado de velocidades de rotación que la navegación a estima escalar omite. Es la base de actitud de la mecanización completa de 3 ejes que sustituye a la ruta heredada de presupuesto de errores de 1 grado de libertad. Verificado frente a rotaciones en forma cerrada: la propagación a velocidad constante coincide con el cuaternión de eje-ángulo hasta 1e-6, las DCM son ortonormales con determinante unitario y el coning se anula para el movimiento de un solo eje. (src/inertial.rs es ahora el directorio de módulo src/inertial/; la ruta pública crate::inertial no cambia.)
• Visibilidad de estaciones terrestres geodésicamente correcta (src/frames.rs). elevation, is_visible y visible_count calculan la elevación de un satélite sobre el horizonte de una estación terrestre respecto a la normal del elipsoide WGS-84 (la vertical local verdadera), y no respecto a la radial geocéntrica: ambas difieren hasta en la deflexión geodésica de ~0,19°, suficiente para que los satélites cercanos al horizonte entren o salgan de una máscara de elevación. Verificado de extremo a extremo (una constelación Walker propagada, rotada de TEME a ECEF y contada desde un emplazamiento geodésico) y frente a la aproximación geocéntrica.

Cambiado#

• Fiabilidad de CI. El trabajo test-python-bindings construye ahora la wheel con PyO3/maturin-action (contenedor manylinux) en lugar de un maturin build directo en el host, con lo que se elimina un conflicto intermitente de rustup rustfmt-preview/cargo-fmt en la imagen del runner. El trabajo deny instala cargo-deny como binario precompilado mediante taiki-e/install-action en lugar de la cargo-deny-action basada en Docker, con lo que se elimina un tiempo de espera agotado en la descarga del registro de Docker Hub. Ninguno de los cambios afecta a las comprobaciones realizadas.

0.8.0 - 2026-06-02#

Añadido#

• La velocidad inercial se expone aguas abajo. Propagator::velocity_eci y Propagator::state_eci (que devuelve StateEci { r_m, v_m_s }) hacen llegar a quienes llaman, en m/s, la velocidad analítica TEME que SGP4 ya calcula y que antes se descartaba; Orbit::velocity_eci da a la ruta kepleriana una velocidad coherente. La prueba de verificación de AIAA 2006-6753 comprueba ahora también la velocidad en cada fila de referencia (peor error de velocidad 1.85e-9 km/s entre los 666 estados) y fija el número de filas comparadas en exactamente 666.

• Análisis de TLE más estricto y sin pánicos. Se exige que las líneas sean ASCII y se segmentan de forma segura (ya no hay pánicos por índice de bytes con entradas multibyte); los elementos se comprueban por rango (inclinación, excentricidad, movimiento medio); la suma de comprobación de la columna 69 puede imponerse mediante ParseOpts { strict_checksum } / parse_propagators_opts y el nuevo indicador strict_checksum de ConstellationCfg (permisivo por defecto).

• Curva de desviación de Allan en la salida. Cada ejecución de reloj informa ahora de una adev_curve ([{tau_s, adev, n_samples}]) y el playground del navegador representa un gráfico log-log «Estabilidad del reloj (ADEV)».

• Validación de la entrada de la malla temporal. TimeCfg::validate rechaza una malla temporal no finita, de valor cero, negativa o excesiva (un paso mayor que la duración, o más de MAX_TIME_STEPS muestras) antes de reservar memoria, de modo que un escenario mal formado devuelve un error en lugar de entrar en pánico o agotar la memoria.

• Conjuntos de Monte Carlo para el paquete inercial. runs = N en un escenario inercial ejecuta N semillas e informa de la media, la desviación típica, los percentiles de cada métrica y un intervalo de confianza del 95% por bootstrap de percentiles (ensemble). Cada ejecución inercial lleva ahora un indicador monte_carlo, de modo que una FoM de una sola realización ya no se confunde con una distribución. (CEP/2DRMS no se informan a propósito: requieren el modelo de 3 ejes de la hoja de ruta.)

• Modo guiado del playground. El playground del navegador ya no te deja ante un muro de TOML en bruto: una franja «Empezar aquí» con tarjetas de escenario de un clic carga y ejecuta un ejemplo resuelto, unos controles deslizantes exponen los parámetros universales (semilla, umbral de temporización) sin tocar el TOML, una nota «Cómo leer esto» explica el resultado, y el TOML completo queda a un solo desplegable de distancia. Cada ejecución es compartible: Copiar enlace para compartir codifica el escenario completo en el fragmento de la URL (no se sube nada), de modo que un enlace reproduce la ejecución exacta al cargarse. El códec tiene pruebas unitarias (web/share.test.mjs, ejecutadas en CI).

• Barridos de parámetros N-dimensionales (src/sweep.rs). nd_sweep evalúa una métrica sobre todo el producto cartesiano de varios rangos SweepAxis (el estudio de compromiso multiparamétrico), en orden de filas y de forma determinista. Aditivo: la API de barrido 1-D existente no cambia. Los intervalos de confianza bootstrap por nodo y la generalización más allá del paquete de reloj siguen en la hoja de ruta.

• RAIM de instantánea real (src/raim.rs). Monitorización autónoma de integridad del receptor genuina en el dominio de la posición: construye la geometría de línea de visión hasta los satélites visibles, forma la solución de mínimos cuadrados y los residuos, ejecuta una prueba de detección de fallos de residuos χ² (umbral exacto a partir de una gamma incompleta χ²/χ² no central sin dependencias) y calcula niveles de protección horizontal y vertical (HPL/VPL) basados en pendiente con el sesgo de detección omitida derivado para los P_fa/P_md configurados. Es distinto de la cifra de Integridad de autoconsistencia del filtro del pipeline de escenarios, y todavía no está conectado a ella; la exclusión de fallos, el presupuesto de límite de alerta/P_HMI y ARAIM siguen en la hoja de ruta.

• Suite de estabilidad de frecuencia: MDEV, TDEV, HDEV + intervalos de confianza (src/allan.rs). Junto a la ADEV solapada: la desviación de Allan modificada (separa el ruido de fase blanco del flicker), la desviación de tiempo (TDEV = tau/sqrt(3) * MDEV) y la desviación de Hadamard (rechaza exactamente la deriva lineal de frecuencia y converge para los tipos de ruido rojo divergentes). Los intervalos de confianza basados en χ² (deviation_ci) usan un par de cuantiles normal/χ² sin dependencias (Acklam + Wilson-Hilferty) con un edf conservador sin solapamiento; el edf específico de cada tipo de ruido y la paridad numérica con Stable32 siguen en la hoja de ruta.

• Reducción de marcos de referencia (src/frames.rs). Rotación TEME↔ECEF basada en GMST (con el mismo tiempo sidéreo IAU-1982 que el propagador), conversión geodésica↔ECEF exacta de WGS-84 con una inversa iterativa inicializada por Bowring (precisión de máquina a todas las altitudes, incluidas MEO/GEO) y un observador geodésico de estación terrestre que devuelve acimut / elevación / distancia en el marco local Este-Norte-Arriba. No se aplican el movimiento polar ni la nutación por debajo del segundo de arco (solo GMST, error inferior al kilómetro en la traza sobre el suelo); una cadena CIO precisa de ITRF está en la hoja de ruta.

• Fundamento de escalas de tiempo (src/timescales.rs). Una API de fecha juliana sin dependencias (civil gregoriana ↔ JD, MJD), el historial completo de segundos intercalares enteros del IERS (UTC↔TAI, 10 s en 1972 hasta 37 s desde 2017), el desfase TAI→TT definido, la corrección UT1 mediante un DUT1 suministrado y el ángulo de rotación terrestre IAU-2000. Es el sustrato temporal sobre el que se apoya la reducción a marcos fijos a la Tierra (prevista). Los instantes son fechas julianas de un único f64 (resolución de ~50 µs cerca de la época actual; una JD de dos partes está en la hoja de ruta), y la era anterior a 1972 de los segundos elásticos no se modela; ambas cosas están documentadas en el módulo.

• Reproducibilidad y procedencia. Un generador determinista de SBOM CycloneDX (scripts/gen-sbom.sh) y una atestación de procedencia de compilación SLSA sobre el binario de la versión y el SBOM; la cadena de herramientas de la versión se fija para coincidir con CI. Las garantías de determinismo, la salvedad de libm entre plataformas y el enfoque de fijación golden se documentan en docs/REPRODUCIBILITY.md.

• Pruebas basadas en propiedades y de fuzzing (tests/property.rs). Pruebas aleatorizadas deterministas (sin nuevas dependencias) afirman invariantes sobre miles de entradas: los analizadores de TLE y de escenarios nunca entran en pánico con entradas basura, no ASCII, mutadas o truncadas; TimeCfg::validate nunca entra en pánico con mallas NaN/inf/negativas; la suma de comprobación del TLE es coherente y solo de la columna 69; las conversiones de ida y vuelta geodésica↔ECEF y la rotación TEME→ECEF conservan la norma en todo el globo y en una amplia banda de altitudes.

Cambiado#

• Las pruebas golden ahora fijan las figuras de mérito campo por campo para los cuatro escenarios de referencia (con una tolerancia que absorbe la variación de libm entre plataformas), en sustitución de las comprobaciones anteriores solo de desigualdad, de modo que una regresión numérica silenciosa se detecta de inmediato.
• schema_version en los artefactos de resultados pasa de 0.1 a 0.7 (estaba congelado mientras el motor avanzaba).
• cargo-deny ahora deniega (en lugar de avisar) las dependencias retiradas (yanked).
• Nuevos documentos: CAPABILITY.md (mapa de alcance honesto), SCHEMA.md (referencia de campos de resultados), INTEGRITY.md, QUANTUM-MODELS.md, REAL_TLE_GUIDE.md. Una protección de CI falla si la insignia de versión del README se desvía de Cargo.toml.

0.7.0 - 2026-06-02#

Añadido#

• Propagación de órbitas SGP4/SDP4. Una implementación completa y sin dependencias del propagador estándar de perturbaciones simplificadas: SGP4 de órbita cercana a la Tierra junto con la extensión SDP4 de espacio profundo (perturbaciones seculares y periódicas lunisolares y resonancia geopotencial de 12 h / 24 h). Está validada frente a los vectores de verificación oficiales de AIAA 2006-6753 («Revisiting Spacetrack Report #3»): los 666 estados de referencia de los casos de órbita cercana, espacio profundo, resonantes y de códigos de error coinciden con un error de posición en el peor caso de unos 4 mm. Es el modelo frente al que se definen los conjuntos de elementos de dos líneas, de modo que representa constelaciones reales, en particular las órbitas GNSS de ~12 h, que son de espacio profundo y resonantes y que el modelo anterior de dos cuerpos + secular J2 no puede capturar.
• Una constelación dada como conjuntos completos de elementos de dos líneas (línea 1 + línea 2) se propaga ahora con SGP4/SDP4; una constelación dada como elementos solo de línea 2 mantiene sin cambios la propagación kepleriana analítica de dos cuerpos. Las dos formas pueden mezclarse en un mismo bloque. Nuevo escenario de referencia orbit-sgp4-gps.toml (una constelación MEO similar a GPS en formato real de dos líneas, propagada con SGP4): basta incorporar un conjunto «gps-ops» actual de Celestrak para estudiar la constelación en vivo.

0.6.0 - 2026-06-02#

Añadido#

• Demostrador de ataque de spoofing activo. Un nuevo tipo de escenario spoof inyecta un spoof de falso tiempo en rampa y ejecuta el monitor de integridad asistido por reloj de cada reloj, e informa de si el spoof se detecta y cuándo, y de si llega sin detectar a la especificación operativa, con lo que la figura de mérito de Seguridad se convierte en una demostración concreta de ataque/defensa. Nuevo escenario de referencia spoof-attack.toml.
• Disponibilidad multiconstelación. Un escenario de órbita puede combinar varias constelaciones (una lista [[constellations]] junto a la [constellation] principal) para la disponibilidad multi-GNSS y la dilución de la precisión, por ejemplo GPS más Galileo. Nuevo escenario de referencia orbit-multignss.toml.

0.5.0 - 2026-06-02#

Añadido#

• Informe de tarjeta de puntuación en HTML. Cada ejecución produce ahora también una tarjeta de puntuación HTML autocontenida y con marca (el resumen de una línea, el gráfico incrustado como imagen data-URI inerte y el JSON completo), escrita por la CLI junto al JSON y al SVG. Un artefacto de un solo archivo, compartible, para el entregable o el anexo de un estudio.
• Estimador conjunto de fusión de sensores. Un nuevo tipo de escenario fusion ejecuta un único filtro de Kalman recursivo como solución de navegación, que fusiona el estado del reloj [phase, frequency] y el estado de posición [position, velocity], disciplinado por GNSS (aprende el desfase de frecuencia y la velocidad) y asistido por transferencia óptica de tiempo durante la interrupción, en lugar de componer predictores independientes. Informa del holdover fusionado de temporización/posición y de una integridad de covarianza conjunta. Nuevo escenario de referencia fusion-pnt.toml.
• Modelo de ruido de IMU más completo. El acelerómetro modela ahora los términos restantes de la varianza de Allan, además del sesgo constante y el paseo aleatorio de velocidad: la inestabilidad del sesgo (un suelo flicker 1/f al coeficiente estándar de inestabilidad de sesgo de Allan, reutilizando la síntesis flicker del reloj) y el paseo aleatorio de aceleración. Nuevos campos opcionales bias_instability y q_aa en los escenarios inerciales; una nueva fijación GNSS recalibra la deriva residual del sesgo.
• Geometría de constelaciones reales a partir de TLE. Una constelación puede darse como un bloque de conjuntos de elementos de dos líneas (el formato estándar NORAD/Celestrak) mediante un campo tle, de modo que la disponibilidad y la dilución de la precisión usan la geometría publicada de una constelación real en lugar de un patrón Walker sintético. El motor lee los elementos keplerianos medios de cada TLE y los propaga con dos cuerpos, no con SGP4, lo que es adecuado para un estudio de instantánea desde una época común. Nuevo escenario de referencia orbit-real-tle.toml.

0.4.0 - 2026-06-02#

Añadido#

• Barridos de parámetros para estudios de compromiso. Un nuevo tipo de escenario sweep hace variar un parámetro (threshold_ns, duration_s, quantum_q_wf o classical_q_wf) a lo largo de un rango lineal o logarítmico y registra una figura de mérito elegida en cada punto para ambos relojes, con lo que produce el gráfico de comparación «¿cómo escala el holdover con la estabilidad del reloj?» que necesita un estudio de compromiso de diseño. Nuevo escenario de referencia sweep-clock-stability.toml.
• Bandas de confianza de Monte Carlo. El escenario de holdover de reloj puede ejecutar muchas realizaciones (nuevo campo opcional runs): cada figura de mérito se informa entonces como una media con una dispersión entre los percentiles 5 y 95, y el gráfico sombrea la envolvente de error del 5–95% alrededor de la mediana de cada reloj. Una sola ejecución sigue siendo lo predeterminado. Nuevo escenario de referencia clock-ensemble.toml.
• Órbitas excéntricas y deriva J2. El tipo de órbita es ahora una órbita kepleriana completa (semieje mayor, excentricidad, inclinación, RAAN, argumento del perigeo, anomalía media), propagada resolviendo la ecuación de Kepler, con regresión nodal secular J2 y precesión apsidal opcionales. Nuevos campos opcionales eccentricity, argp_deg y j2 en los escenarios, y un escenario de referencia orbit-molniya.toml (un usuario de 12 h muy excéntrico y de inclinación crítica). Las órbitas circulares conservan bit a bit la ruta original en forma cerrada.
• El paquete híbrido (PNT combinado) informa ahora de Integridad y Seguridad, de modo que los cuatro paquetes cubren el conjunto completo de figuras de mérito operativas. La Integridad es la contención de la cota de protección del canal de temporización a partir de un estimador de Kalman disciplinado a la verdad mientras el GNSS es nominal y reanclado (de forma más laxa) en cada resincronización óptica; su cota incluye el suelo de ruido de medida del enlace, de modo que un reloj mucho mejor que el enlace se puntúa frente al ruido real de la solución entregada. La Seguridad es la puntuación de detección de spoofing asistida por reloj frente a la especificación de temporización.

Cambiado#

• Las notas de la versión se generan ahora a partir de la sección seleccionada del CHANGELOG correspondiente a la etiqueta (scripts/changelog-extract.sh), de modo que cada versión de GitHub destaca lo que cambió en lugar de listar los commits en bruto.

0.3.0 - 2026-06-02#

Añadido#

• Figura de mérito de Seguridad (antes sin rellenar): una puntuación de detección de spoofing asistida por reloj para los paquetes de holdover de reloj y de órbita. Modela un monitor de integridad que contrasta el tiempo derivado de GNSS con la propia predicción a la deriva del reloj sobre una ventana coherente; el umbral de detección combina el ruido de medida promediado con la incertidumbre de deriva del reloj, de modo que un reloj más silencioso detecta spoofs de tiempo menores y más lentos. La puntuación se informa en [0, 1] relativa a la especificación de temporización, con lo que se completan las seis figuras de mérito operativas.
• Precisión de posición derivada de la geometría para el paquete de órbita: a partir de la geometría de línea de visión hasta los satélites visibles forma la matriz de diseño y su factor de covarianza Q = (HᵀH)⁻¹, y obtiene los factores de dilución de la precisión (GDOP/PDOP/HDOP/VDOP/TDOP). La precisión de posición es el DOP de posición multiplicado por un error equivalente de distancia del usuario configurable (nuevo campo opcional sigma_uere_m del escenario). Un resultado de órbita lleva ahora un resumen de geometría (fracción de muestras con solución, mejor y mediana de PDOP y sigma de posición).
• Un playground en el navegador (web/) que ejecuta el motor en el cliente como WebAssembly: se elige un escenario de referencia o se edita el TOML, se ejecuta y se ven el resumen, el gráfico y el JSON completo, sin subir nada. Un flujo de trabajo pages lo construye y lo publica en GitHub Pages, y una nueva exportación WebAssembly summary respalda la lectura.
• Ejes y rotulados en los gráficos SVG: líneas de cuadrícula, etiquetas numéricas de marcas y un título de eje con unidades (mediante una utilidad compartida chart), de modo que las magnitudes sean legibles.
• Flujo de trabajo de publicación de paquetes (publish) para crates.io, PyPI y npm, cada uno condicionado a su token de registro y activado por una versión publicada.

0.2.0 - 2026-06-02#

Añadido#

• Suelo de FM flicker (1/f) para el modelo de error del reloj, sintetizado como suma de procesos de Ornstein-Uhlenbeck espaciados logarítmicamente y calibrado para que el suelo plano de la desviación de Allan quede en un nivel configurable. Desactivado por defecto; se activa por reloj mediante el campo opcional flicker_floor del escenario.
• Canal de giróscopo para el modelo inercial: el sesgo residual del giróscopo y el paseo aleatorio angular generan un error de actitud (inclinación) que acopla la gravedad a un error horizontal de fuerza específica, el principal mecanismo de crecimiento de error strapdown. Desactivado por defecto; se activa por sensor mediante los campos opcionales gyro_bias y q_arw.
• Estimador de reloj de Kalman de dos estados (fase, frecuencia) con discretización exacta del ruido de proceso de van Loan. La deriva a partir de un estado conocido reproduce exactamente el crecimiento analítico del error de holdover (q_wf*T + q_rw*T^3/3), y además el filtro entrega una cota de incertidumbre de 1 sigma en línea.
• La ejecución del reloj informa ahora de la figura de mérito de Integridad (antes sin rellenar): la fracción de muestras de la interrupción cuyo error permanece dentro de la cota de protección de 3 sigma del filtro, reflejada en el resultado JSON y en el resumen de la CLI.
• Disponibilidad GNSS derivada de la geometría: la propagación de órbitas circulares, un generador de constelaciones Walker-delta y la visibilidad en línea de visión (ocultación por la Tierra más máscara de elevación) producen la línea temporal de disponibilidad a partir de la geometría orbital real. Nuevo tipo de escenario orbit y escenario de referencia orbit-gnss-challenged.toml (una nave dentro de la capa GNSS con cobertura intermitente).
• Extensión opcional de Python (PyO3, abi3) que expone run, run_full y version, empaquetada con maturin (pyproject.toml) y construida para Linux, macOS y Windows por un flujo de trabajo wheels activado por la etiqueta de versión. El binding es una dependencia opcional condicionada por característica: la compilación por defecto, las pruebas y la puerta de auditoría de dependencias no se ven afectadas.
• Módulo opcional de WebAssembly (wasm-bindgen) que expone run, chart_svg y version, construido con wasm-pack bajo la característica wasm; getrandom está condicionado al destino para usar la fuente de entropía del navegador en wasm32.
• Despacho api::run_toml compartido que usan la CLI y ambos bindings, de modo que la línea de comandos y los bindings no puedan desviarse.

Cambiado#

• La puntuación de holdover ahora es consciente de los segmentos: las líneas temporales de interrupción se dividen en segmentos contiguos en cada readquisición de GNSS, y el holdover informado es el peor caso (la deriva más corta) entre ellos. Los escenarios de una sola interrupción no cambian. Se aplica a los puntuadores de reloj, inercial e híbrido.
• El kind informado por el modelo inercial es ahora inertial (antes accelerometer), lo que refleja los canales combinados de acelerómetro y giróscopo.

0.1.0 - 2026-06-01#

Versión inicial.

Añadido#

• Motor de simulación determinista para PNT híbrido cuántico/clásico: una interfaz común de modelos de error, escenarios declarativos de disponibilidad GNSS, estimadores de holdover / navegación a estima y puntuación de figuras de mérito frente a los criterios operativos PNT estándar. Los resultados son reproducibles a partir de scenario + seed + engine version (JSON versionado y autodescriptivo con un hash del escenario) y se representan como gráficos SVG. La CLI despacha los escenarios por kind.
• Cuatro paquetes de sensores, cada uno calibrado con datos publicados y validado frente a la relación estándar:
  • Holdover de reloj: FM blanca, FM de paseo aleatorio y envejecimiento lineal; validado mediante la desviación de Allan solapada (Riley, NIST SP 1065). Reloj atómico a escala de chip frente a reloj óptico de red de estroncio.
  • Navegación inercial a estima: sesgo residual + paseo aleatorio de velocidad, integrados dos veces hasta el error de posición; validado frente a las relaciones de crecimiento del error de Groves. Acelerómetro de átomos fríos frente a acelerómetro de grado de navegación.
  • Transferencia de tiempo: jitter de temporización de un enlace óptico frente a uno de RF → precisión de sincronización → medida de distancia unidireccional.
  • Fusión híbrida (colofón): un conjunto PNT combinado que debe mantener tanto la temporización como la posición, con asistencia opcional del reloj mediante transferencia óptica de tiempo entre satélites.
• Un escenario de referencia citado por paquete en scenarios/, con cada parámetro numérico acompañado de una provenance revisada por pares.
• Salvaguardas de reproducibilidad y de higiene del repositorio; CI (formato, clippy, pruebas, salvaguardas, MSRV) y un flujo de publicación condicionado por etiqueta que vuelve a ejecutar todas las comprobaciones.
• Documentación: README con diagramas de arquitectura, informe del estado de validación, guía de contribución, política de seguridad y código de conducta; licencia Apache-2.0; plantillas de incidencias/PR y configuración de Dependabot.
• Neutral respecto a los proveedores en todo el proyecto; se conservan las citas científicas y metrológicas revisadas por pares.
• Higiene de la licencia Apache-2.0: cabeceras SPDX en todas las fuentes, un archivo NOTICE con aviso de marcas, firma de Developer Certificate of Origin (DCO) en las contribuciones y aplicación por cargo-deny de las licencias y avisos de las dependencias en CI.
• Posicionamiento de núcleo abierto (README): un motor Apache-2.0 gratuito más soporte comercial, integración y extensiones propietarias disponibles de Ashforde OÜ, sostenido por servicios y no por cuotas de licencia.
• CITATION.cff para que el software pueda citarse.