Skip to content Skip to footer

AUSTRALIS · DEVLOG

Cuando la misión empezó a ser más fácil de seguir

Período histórico: 2026-07-06–2026-07-12

Infografía descriptiva de avances documentados de AUSTRALIS del 6 al 12 de julio de 2026: canales públicos activos; política DIY/LatAm con ADR Accepted y Bench ≠ Flight; y MIS-REQ-22 = Proposed — EGSE para meteorología, registro de pasada y park/inhibit en una estación terrena cuyo documento sigue Draft. No representa hardware implementado o validado ni evidencia de ensayo.
Infografía descriptiva de avances documentados de AUSTRALIS del 6 al 12 de julio de 2026: canales públicos activos; política DIY/LatAm con ADR Accepted y Bench ≠ Flight; y MIS-REQ-22 = Proposed — EGSE para meteorología, registro de pasada y park/inhibit en una estación terrena cuyo documento sigue Draft. No representa hardware implementado o validado ni evidencia de ensayo.

Durante la semana AUSTRALIS mejoró su puerta de entrada pública —newsletter, WhatsApp, YouTube y descubrimiento web— y documentó dos criterios técnicos preliminares: instrumentación meteorológica e interlocks para la futura estación terrena, y una política DIY/low-cost con componentes maker/COTS regionalmente accesibles. El repositorio público no registró commits entre el 6 y el 12 de julio; esos cambios documentales se publicaron el 17. No se encontraron resultados documentados de ensayos de misión en la ventana y no aumentó la madurez técnica del vehículo.

El objetivo

AUSTRALIS ya tenía documentación técnica pública, pero todavía era difícil descubrir el proyecto y elegir cómo acompañarlo. La web conservaba páginas de demostración en el sitemap, algunos enlaces de comunidad seguían pendientes y el footer no mostraba de forma confiable todos los canales disponibles.

El objetivo de la semana fue convertir esa presencia dispersa en una ruta pública más clara para seguir los avances, recibir novedades y proponer colaboración.

Qué cambió

Entre el 6 y el 7 de julio se incorporó una sección “Join / Support / Contribute”, se depuraron robots y sitemap para concentrarlos en las páginas reales de AUSTRALIS y se corrigió un problema del footer que impedía mostrar correctamente el newsletter.

También se integraron dos canales públicos:

  • un Canal de WhatsApp para actualizaciones curadas de la misión;
  • el canal de YouTube @AustralisMission, enlazado desde Home, Contact y el footer global.

El 10 de julio también se documentaron dos direcciones técnicas, todavía sin commit público dentro de esta ventana:

  • una política de diseño DIY/low-cost y source-available no comercial, orientada a componentes maker/COTS disponibles en Argentina y Latinoamérica, sin confundir Bench con Flight-Like o Flight;
  • una propuesta de instrumentación meteorológica local para la estación terrena, destinada a registrar el ambiente de cada pasada y aportar entradas a futuros interlocks de park/inhibición.

Fueron cambios de arquitectura, requisitos y documentación, no evidencia de implementación ni de ensayo físico.

Evidencia y madurez

La evidencia de esta semana combina implementación web/comunitaria con arquitectura y requisitos documentales:

  • Home, Contact, Mission y RF/LoRa fueron verificados en HTTP 200 después de los cambios;
  • newsletter, WhatsApp y YouTube quedaron visibles en las rutas públicas previstas;
  • robots y sitemap quedaron concentrados en el dominio y las páginas reales de la misión;
  • el historial público de AUSTRALIS-1 contiene cero commits fechados entre el 6 y el 12 de julio;
  • la memoria técnica del 10 de julio registra los cambios locales de política DIY/LatAm y meteorología de ground segment, integrados públicamente en el commit fd571017… del 17 de julio.

No se encontraron resultados de ensayos físicos, de banco, RF, software de vuelo o misión dentro de la ventana. Los cambios documentales no cerraron un gate ni aumentaron la madurez técnica del vehículo.

Qué aprendimos

Una misión documentada también necesita una interfaz pública coherente. Newsletter, web y canales curados no aumentan la madurez técnica del satélite, pero sí hacen que la evidencia futura pueda encontrarse, entenderse y seguirse sin mezclar anuncios, colaboración y operación técnica.

La decisión de comenzar con un Canal de WhatsApp —en lugar de una comunidad abierta— permitió priorizar privacidad, moderación y actualizaciones verificadas. En ingeniería, la misma disciplina aparece en dos límites: DIY/low-cost no significa flight-ready, y una estación meteorológica documentada no equivale a sensores, umbrales o interlocks validados.

Evolución posterior

El trabajo DIY/LatAm y de estación terrena documentado el 10 de julio se integró al repositorio público el 17 de julio en fd571017…; el snapshot public-v0.2 se publicó después mediante otro commit del mismo día.

La auditoría de fines de julio mantuvo la política DIY/LatAm como ADR Accepted y dejó MIS-REQ-23/24 activos. En cambio, devolvió meteorología a MIS-REQ-22 = Proposed — EGSE: el documento de estación terrena sigue Draft, y sensores, umbrales, park/inhibit, calidad y calibración requieren una ADR Accepted y hazard analysis antes de adoptarse. El proyecto continúa experimental pre-SRR con Gate A Open.

Próximo hito histórico

La próxima ventana pública verificable comienza el 17 de julio: integración al repositorio de los cambios documentados el día 10 y publicación posterior del snapshot public-v0.2. Esa integración pública deberá evaluarse como un período separado, sin reescribir la fecha de origen de las decisiones.

Material visual

La infografía resume de forma descriptiva los avances documentados de la semana: canales públicos activos, la política DIY/LatAm con ADR Accepted y Bench ≠ Flight, y MIS-REQ-22 = Proposed — EGSE para meteorología, registro de pasada y park/inhibit en una estación terrena cuyo documento sigue Draft. Es una síntesis editorial: no representa hardware implementado o validado ni evidencia de ensayo.

Fuentes públicas