Administrador del sistema

El administrador del sistema gestiona la infraestructura de TankOS — usuarios, credenciales y catálogos — con visibilidad de reportes y auditoría. Esta guía te dice qué administras a diario y destaca el invariante que define tu rol: no posees ninguna autoridad operativa.

El administrador en una línea

Gestionas usuarios, sistema, catálogos, API keys y credenciales de dispositivo (MQTT), y tienes visibilidad de reportes y auditoría (eres el único con el export CSV de auditoría). Ves Dashboard y Alarmas en modo solo lectura. Por diseño deliberado, tu rol es sin authorities operativas.

Tareas diarias

Cada tarea enlaza a la página del módulo donde se documenta paso a paso.

Tarea	Qué haces	Módulo
Gestionar API keys	Creas con scopes vía allowlist SoD, revocas inline; la clave se muestra copy-once	Administración
Rotar credenciales MQTT	Rotas las credenciales de dispositivo con un stepper two-secret, también copy-once	Administración
Administrar catálogos	Plantillas de tanque/alarma/strapping, modelos de dispositivo y productos	Catálogos
Revisar auditoría	Listas la bitácora y exportas a CSV (eres el único rol con el export habilitado)	Auditoría
Consultar/generar reportes	Listas y generas reportes (reports:read, reports:generate)	Reportes

El invariante: admin sin authorities operativas (D-03)

El administrador está SIN authorities operativas — mínimo privilegio (D-03)

Por diseño deliberado (decisión D-03, con test de invariante en tiempo de ejecución), el admin no posee ninguna autoridad operativa:

• No crea muestras de laboratorio, ni aforos, ni lotes de custodia.
• No aprueba, no anula ni emite nada (no tiene manual:approve/void, lab:approve/void, ni custody:issue/void).
• No edita ingeniería (no tiene engineering:edit).
• Ve Dashboard y Alarmas en modo solo lectura (ops:view sin ops:override).

Es mínimo privilegio: un administrador comprometido no puede escalar a acciones de producción. El control de credenciales no implica control del flujo custody.

Refuerzo en API keys — una credencial de máquina nunca aprueba ni emite

El mismo principio se refuerza al crear API keys: la allowlist de scopes prohíbe las autoridades sensibles de SoD (custody:issue/void, manual:approve/void, lab:approve/ invalidate/void, custody:plan/gauge). Una credencial de automatización nunca puede aprobar, anular ni emitir — solo enviar o leer. Ver Administración.

Qué puedes y qué NO puedes

Tienes 5 autoridades. La tabla completa de roles × módulos vive en Roles y módulos.

Puedes:

• Configurar el sistema: credenciales de dispositivo, bull-board, export de auditoría (admin:system).
• Gestionar usuarios y API keys (admin:users).
• Administrar catálogos de plantillas (admin:catalogs).
• Ver y generar reportes (reports:read, reports:generate).
• Ver Dashboard y Alarmas (ops:view, solo lectura).

Lo que NO puedes

Todo lo del invariante de arriba: cero operación. No creas muestras/aforos/lotes, no editas ingeniería, no apruebas/anulas/emites. Las acciones de "segundo par de ojos" son del supervisor; la configuración del activo físico es del ingeniero.

Visibilidad de navegación

Estos son los ítems del menú que ves. Los demás módulos no aparecen en tu sidebar.

Grupo	Ítem	Ruta
OPERACIÓN	Dashboard	/dashboard
OPERACIÓN	Alarmas	/alarms
OPERACIÓN	Reportes	/reports
CONFIGURACIÓN	Catálogos	/catalogs
CONFIGURACIÓN	API Keys	/admin/api-keys
CONFIGURACIÓN	Auditoría	/admin/audit

Dashboard y Alarmas son solo lectura para ti

Ves el dashboard y la lista de alarmas, pero no los controles de creación/edición de alarmas (no tienes ops:override). No ves: Laboratorio, las colas de aprobación, Aforo, Custody, Sitios, Patios ni Tanques (ingeniería).