ATQ AI Operating System

Objetivo

Describir atlantyqa-universe como un AI Operating System OSS orientado a:

1. modelos de gobierno
2. humanized ops
3. colaboración humano-máquina
4. operación multiplataforma con atq

No es solo un repositorio de scripts. Es una capa de coordinación para personas, agentes, políticas, runbooks y evidencia.

Idea central

atq debe sentirse como la interfaz humana corta del sistema.

La complejidad interna existe, pero no debe ser la primera experiencia del usuario. La entrada correcta es:

• una intención humana clara
• una ruta corta por rol o dispositivo
• una secuencia de validación visible
• una salida trazable

Capas recomendadas

Capa	Qué resuelve	Dónde vive
interface	comandos humanos cortos y entrypoints por rol	scripts/atq, docs/atq/**
governance	HILT, policies, gates, aprobaciones, decisiones	docs/internal/policies/**, gitops/**, .github/**
humanized-ops	runbooks, FSM, live sessions, UX/UI, onboarding	docs/portal/**, docs/ops/**, scripts/proxmox/**
knowledge-os	bitácora, agent-context, datasets, ontologías	docs/internal/**, knowledge/**, schemas/**
runtime-adapters	Proxmox, MicroK8s, Docker, GitHub, devices	scripts/proxmox/**, scripts/microk8s/**
contributor-layer	desarrollo del repo, testing, release, PRs	README.md, GET-STARTED.md, CONTRIBUTING.md

Qué significa "humanize ops"

Humanize ops no es solo poner texto más amable. Significa:

• menos pasos implícitos
• más rutas legibles por rol
• pensamiento crítico explícito
• validación por estados, no por intuición
• carga cognitiva controlada
• evidencia visible antes de promover una decisión

Gobierno humano sobre sistemas AI y móviles

ATLANTYQA parte de una tesis simple:

• los sistemas que nos rodean pueden y deben seguir siendo gobernados por humanos
• el control no debe delegarse a cajas negras sin trazabilidad
• el móvil no puede convertirse en una interfaz de presión, fatiga o obediencia automática

Eso implica:

• rutas cortas y comprensibles en móvil
• una decisión humana visible antes de acciones sensibles
• preguntas socráticas en vez de automatismo opaco
• preservación de evidencia y propiedad intelectual en modo local-first
• protección explícita de salud mental y carga cognitiva en la experiencia de uso

Qué significa "vibe coding" aquí

Usamos vibe coding en sentido práctico y gobernado:

• aprendizaje por doing
• iteraciones cortas
• una meta principal por bloque
• feedback inmediato
• prompts y CLI como interfaz pedagógica
• sin sacrificar trazabilidad ni gates

No es "código por impulso". Es exploración rápida con guardarraíles.

Learning by doing

La unidad mínima de aprendizaje debe ser:

1. entender el objetivo
2. ejecutar una acción pequeña
3. validar el resultado
4. registrar evidencia
5. decidir si avanzar, corregir o bloquear

Ese patrón ya encaja con la FSM operativa del repositorio.

Modelo de uso recomendado

1. Usar atq

Para personas que quieren operar el sistema desde un dispositivo:

• seguir docs/atq/get-started-multiplatform.md
• usar entrypoints cortos
• no entrar directamente en runbooks internos salvo necesidad

2. Operar ATLANTYQA

Para perfiles de gobierno, ops o coordinación:

• usar docs/portal/**
• seguir validación UI/UX, FSM y live session
• aplicar HILT y criterios de aprobación

3. Desarrollar ATLANTYQA

Para contributors del repo:

• seguir GET-STARTED.md
• usar .venv
• validar local-first antes de PR

Regla de diseño documental

La documentación no debe mezclar en la misma capa:

• cómo usar atq
• cómo desarrollar el repo
• cómo operar runbooks internos avanzados

La primera debe ser breve y multiplataforma. La segunda, contributor-first. La tercera, profunda y especializada.

Resultado esperado

Si esta arquitectura está bien aplicada:

• un nuevo colaborador entiende en minutos cómo empezar
• un actor de gobierno entiende dónde decidir
• un junior puede operar por FSM y no por intuición
• atq se percibe como la cara visible del sistema
• los runbooks internos quedan desacoplados de la entrada principal