Arquitectura
De la intención de negocio a producción.
La ingeniería de producto AI-native es un lifecycle disciplinado: los agentes ejecutan trabajo significativo en cada etapa mientras conservo criterio de producto, responsabilidad y autoridad de release.
Un lifecycle, seis etapas con responsabilidad.
La secuencia hace visibles decisiones, dependencias, verificación y límites de release. AOHYS es una implementación pública de esta práctica, no el límite de la arquitectura ni un mapa del Development System privado.
Intención de negocio
Escuchar al negocio, aclarar el resultado de usuario, revelar restricciones y hacer grilling del lenguaje ambiguo antes de elegir un camino técnico.
Dominio y decisiones
Modelar el dominio, nombrar conceptos estables, comparar tradeoffs y registrar decisiones que dan forma al producto y al sistema.
Specs y grafo de dependencias
Convertir la dirección acordada en specs, tickets ejecutables, ownership, seams de aceptación y dependencias que conservan el orden correcto.
Implementación con agentes
Agentes especializados investigan, implementan, prueban y revisan trabajo acotado. El orquestador humano integra evidencia y resuelve decisiones que las herramientas no pueden asumir.
Verificación y browser QA
Usar TDD proporcional, linting, type checks, pruebas de comportamiento, revisión independiente y browser QA para verificar el resultado real y visible.
De preview a producción
Construir un Preview Deployment, reunir revisión humana, promover mediante Release Train, verificar el Production Deployment y ejecutar smoke checks.
La arquitectura es una secuencia de tradeoffs.
Ejecución de agentes con responsabilidad humana
Los agentes amplían la capacidad de ejecución, pero no pueden asumir intención de negocio, aceptación de riesgo ni autoridad de release.
Sigo siendo responsable de lo que se construye, cómo se verifica y si está listo para release.
Explicación pública sin publicar la herramienta privada
El lifecycle debe ser inspeccionable sin exponer instrucciones privadas, métodos operativos ni detalles de entrega.
El Development System permanece privado y adaptable; productos entregados y artefactos sanitizados aportan la evidencia.
Preview antes que producción
Un build verde no demuestra que un release funciona en su ambiente real.
Promoción protegida, Preview Deployment, revisión humana y smoke checks vuelven producción una decisión separada.
Notas de operación
Los seams que mantienen conectada la topología.
Responsabilidad humana
Los agentes ejecutan requisitos, modelado, specs, tickets, implementación, pruebas, revisión y QA. Alejandro conserva criterio de producto, integra evidencia y autoriza el release.
Public Source Site y Private Work
El Public Source Site permite inspeccionar decisiones de implementación de AOHYS. Private Work —código de clientes, datos, pantallas operativas, credenciales y Development System— permanece privado.
Release Train
Primero se construye y revisa un Preview Deployment. Producción avanza mediante promoción separada con autoridad explícita, checks de ambiente, verificación de deployment y smoke checks en el dominio canónico.
AOHYS como implementación visible
AOHYS demuestra rutas públicas localizadas, workflows privados autenticados, contenido tipado, observabilidad y una ruta de release protegida. Es un ejemplo concreto de una arquitectura profesional más amplia.
Development System privado
El Development System coordina herramientas y agentes en distintos entornos de coding. Es privado, no open source ni template comercial, y cada equipo debe adaptar su propia práctica.
Feedback de producción
Observabilidad, analíticas, errores, smoke checks y feedback de stakeholders regresan el comportamiento real a la siguiente decisión de producto; release no es el final del lifecycle.
Revisar el source
Este repositorio es una muestra pública funcional. No vuelve públicos código de clientes, código de producto, credenciales, capturas privadas ni datos operativos.