Ciclo de vida de la misión
Un documento de misión tiene dos nociones superpuestas de “estado” en ARGUS:
mission.status— una fase con nombre establecida por el comandante en el formulario de creación/edición:planning | ready | active | completed | aborted.- Estado derivado de timestamps — usado por la lista de operaciones para
mostrar un chip coloreado sin requerir que el comandante actualice el campo de estado:
planned(startOn en el futuro),active(startOn ≤ now, sin finishedOn),finished(finishedOn ≤ now).
Rara vez divergen, pero la lista usa la versión derivada de timestamp para que operaciones sin finalizar
y no promovidas no aparezcan como “active” solo porque alguien estableció status: 'active' mientras
aún planificaba.
Para claridad de documentación y UI, piensa en una misión como moviéndose a través de cinco fases:
planning → ready → active → completed ↘ abortedMás archived como un estado de eliminación lógica separado y aspiracional (ver más abajo).
planning
Por defecto al crear. La fecha startOn puede ser hoy o cualquier día posterior. La misión es
completamente editable vía /operations/{id}/edit. No se despachan side-services. Los miembros de
la organización son notificados de que la operación fue creada (notificación operation_created),
pero nada está “en vivo”.
ready
Una promoción humana usada cuando los briefings están hechos y el equipo está en sus puestos. Actualmente ningún
path de código reacciona distinto a ready vs planning — la bandera es referencia del operador
y futura compuerta de workflow.
active
La operación está en vivo. Los participantes con operations.join pueden hacer clic en LAUNCH LIVE OPS en la
página de detalle para enrutar a /ops/{id}/live — la consola en vivo. Una vez que al menos un
participante está en la consola:
- Se provisiona una sala TACLINK para la operación. Todo el audio, vídeo, entradas de joystick en tiempo real y tráfico de canal de datos (flags, telemetría, alertas) fluyen a través de ella.
- Los docks de DJI asignados a la operación comienzan auto-streaming al ingress WHIP de la consola. Ver auto-stream DJI.
- Si la detección IA está habilitada por stream, se despacha un worker YOLO11 / detección sobre cada tile de stream.
- CAS evalúa la proximidad entre todas las aeronaves rastreadas en el intervalo establecido en el
casConfigde la misión. - Los workflows suscritos a los eventos de esta operación disparan en sus triggers.
La transición de salida de active está controlada por el comandante (vía el desplegable de Status del
formulario de edición) o por admins.
completed
Estado terminal de éxito. Promovido por el comandante cuando los objetivos se cumplen. Cuando el
estado cambia a completed:
- El botón LAUNCH LIVE OPS de la consola en vivo aún enruta, pero los que se unan tarde entran a una sala de solo lectura.
- El informe posterior de IA se vuelve útil de generar
(informe de misión). Antes de
completedaún puedes generar uno — simplemente tiene menos datos. - Las grabaciones marcadas para difuminado de privacidad comienzan el postprocesamiento.
- Los logs de vuelo, comms, flags y tareas permanecen consultables en
missions/{id}/*.
aborted
Estado terminal de fallo. Úsalo para operaciones que terminaron sin cumplir los objetivos (p. ej.
suspendidas por el clima, misión cancelada por HQ superior, aborto por seguridad). Sin limpieza de
efectos secundarios más allá de lo que hace completed — la distinción es operacional, para el
registro posterior a la acción.
Archived / eliminación lógica — aspiracional
Un estado archived con una ventana de restauración de 30 días aparece en discusiones de roadmap pero no
está implementado hoy. La eliminación desde el menú de fila es un deleteDoc(missions/{id})
definitivo — documento y subcolecciones se van inmediatamente, sin recuperación. Considera cualquier doc
de archive / restore como aspiracional.
Quién puede cambiar el estado
- Comandante (o cualquier usuario con
operations.edity propiedad del documento) — puede cambiarmission.statuseligiendo un nuevo valor en el formulario de edición y guardando. No hay un botón dedicado “Iniciar” / “Detener”; todo es a través del desplegable de Status. - Admins de la org — misma capacidad de edición, delimitada por
operationOwnerGuard. - Motor de workflows — los workflows pueden parchear
mission.statuscuando están configurados para ello. Así es como se construyen los patrones de auto-complete-en-vacío o auto-abort-en-HMS-critical.
Qué no cambia el estado automáticamente
Alcanzar startOn o finishedOn no auto-promueve mission.status. El
comandante (o un workflow) debe hacerlo. El chip de timestamp de la vista de lista mostrará la nueva
fase en ese momento, pero el campo status almacenado queda sin cambios.
Timeline y auditoría
Cada vez que mission.status cambia, la actualización se refleja en mission.updatedOn en
el documento. No hay un log dedicado de cambios de estado en una subcolección — el historial de
documentos de Firestore es la pista de auditoría.