Add corporate brain v1 knowledge base

2026-06-20 03:41:50 +00:00
commit 6e53e535d4
24 changed files with 962 additions and 0 deletions
@@ -0,0 +1,7 @@
 # DevSecOps Corporate Brain
 Base de conocimiento oficial de la Software Factory IA Autónoma.
 Este repositorio define estándares, flujos, responsabilidades, arquitectura, seguridad, QA, DevOps y plantillas que deben usar todos los agentes IA.
 Todo agente debe priorizar este conocimiento sobre respuestas genéricas.
@@ -0,0 +1,45 @@
 # Reglas de Coordinación de Agentes
 ## Regla principal
 Ningún agente debe actuar fuera de su responsabilidad principal.
 ## CTO Agent
 Coordina y aprueba. No implementa.
 ## Product Owner Agent
 Define alcance, backlog y criterios. No implementa.
 ## Architect Agent
 Diseña arquitectura. No implementa código completo.
 ## UI/UX Agent
 Diseña experiencia. No implementa lógica.
 ## Backend Agent
 Implementa backend según arquitectura aprobada.
 ## Frontend Agent
 Implementa frontend según diseño y APIs.
 ## DevOps Agent
 Define contenedores, pipelines e infraestructura.
 ## QA Agent
 Define y ejecuta estrategia de pruebas.
 ## Security Agent
 Valida amenazas, vulnerabilidades y controles.
 ## Regla de escalamiento
 Si un agente detecta una decisión fuera de su dominio, debe escalar al CTO Agent.
@@ -0,0 +1,46 @@
 # Estándar de Arquitectura
 ## Principios
 - Simplicidad primero.
 - Escalabilidad justificada.
 - Bajo acoplamiento.
 - Alta cohesión.
 - Separación de responsabilidades.
 - Seguridad desde el diseño.
 ## Arquitectura backend preferida
 - Clean Architecture.
 - DDD cuando exista dominio complejo.
 - CQRS cuando haya separación clara de lectura/escritura.
 - Modular monolith como primera opción si no hay necesidad real de microservicios.
 ## Microservicios
 Solo se recomiendan cuando existan:
 - Equipos separados.
 - Escalamiento independiente.
 - Dominios claramente separados.
 - Ciclos de despliegue independientes.
 ## Multi-tenant
 Evaluar:
 - TenantId compartido.
 - Schema por tenant.
 - Base por tenant.
 Decisión debe justificarse por:
 - Seguridad.
 - Costo.
 - Escalabilidad.
 - Operación.
 - Complejidad.
 ## Decisiones arquitectónicas
 Toda decisión relevante debe documentarse como ADR.
@@ -0,0 +1,50 @@
 # Checklist CTO
 Antes de aprobar una solución validar:
 ## Producto
 - Requerimiento claro.
 - Alcance definido.
 - Criterios de aceptación.
 - Riesgos funcionales.
 ## Arquitectura
 - Capas claras.
 - Patrones justificados.
 - No hay sobrearquitectura.
 - Escalabilidad razonable.
 ## Backend
 - API documentada.
 - Validaciones.
 - Manejo de errores.
 - Seguridad.
 ## Frontend
 - UX clara.
 - Accesibilidad.
 - Manejo de estados.
 - Responsive.
 ## DevOps
 - Docker.
 - Pipeline.
 - Variables.
 - Despliegue reproducible.
 ## QA
 - Pruebas definidas.
 - Criterios verificables.
 - Evidencia requerida.
 ## Security
 - OWASP revisado.
 - Secretos protegidos.
 - Autorización validada.
@@ -0,0 +1,32 @@
 # Estándar Product Owner
 ## Salida mínima esperada
 Todo requerimiento debe transformarse en:
 - Objetivo de negocio.
 - Alcance.
 - Fuera de alcance.
 - Épicas.
 - Features.
 - Historias de usuario.
 - Criterios de aceptación.
 - Dependencias.
 - Riesgos.
 - Prioridad.
 ## Formato de historia
 Como [rol]
 quiero [funcionalidad]
 para [beneficio]
 ## Criterios de aceptación
 Deben ser verificables y claros.
 Ejemplo:
 Dado que soy usuario autenticado,
 cuando creo una orden válida,
 entonces el sistema debe guardar la orden y mostrar confirmación.
@@ -0,0 +1,43 @@
 # Estándar QA
 ## Tipos de prueba
 Toda solución debe considerar:
 - Pruebas unitarias.
 - Pruebas de integración.
 - Pruebas funcionales.
 - Pruebas de API.
 - Pruebas de seguridad.
 - Pruebas de rendimiento.
 - Pruebas de regresión.
 ## Backend
 - xUnit.
 - Moq.
 - Testcontainers cuando aplique.
 - Pruebas de endpoints críticos.
 ## Frontend
 - Jasmine/Jest.
 - Testing Library.
 - Playwright para E2E.
 ## Performance
 - K6 para APIs.
 - JMeter cuando el escenario sea complejo.
 - Métricas de latencia.
 - Throughput.
 - Errores por segundo.
 ## Criterio de aprobación
 No se aprueba una solución sin:
 - Evidencia de pruebas.
 - Casos críticos cubiertos.
 - Errores conocidos documentados.
 - Riesgos aceptados.
@@ -0,0 +1,28 @@
 # Runbook Angular + Docker + Nginx
 ## Objetivo
 Compilar Angular y servirlo usando Nginx en contenedor.
 ## Flujo
 Angular source
 ↓
 npm install
 ↓
 npm build
 ↓
 Docker multi-stage
 ↓
 Nginx Alpine
 ↓
 Imagen final
 ↓
 Deploy
 ## Reglas
 - Usar nginx.conf propio.
 - Configurar fallback para SPA.
 - No exponer source maps en producción si no aplica.
 - Usar variables de entorno por ambiente.
@@ -0,0 +1,26 @@
 # Runbook CI/CD
 ## Pipeline mínimo
 1. Checkout.
 2. Restore dependencies.
 3. Build.
 4. Test.
 5. Static analysis.
 6. Security scan.
 7. Docker build.
 8. Push image.
 9. Deploy.
 10. Smoke test.
 ## Ambientes
 - dev automático.
 - qa con validación.
 - prod con aprobación.
 ## Reglas
 - Ningún despliegue manual a producción.
 - Todo cambio debe venir de repositorio.
 - Todo release debe tener trazabilidad.
@@ -0,0 +1,29 @@
 # Runbook .NET + Docker
 ## Objetivo
 Construir y ejecutar APIs .NET en contenedor.
 ## Flujo
 Código .NET
 ↓
 dotnet restore
 ↓
 dotnet build
 ↓
 dotnet test
 ↓
 dotnet publish
 ↓
 runtime image
 ↓
 container
 ## Reglas
 - Multi-stage build.
 - Usuario no root.
 - Healthcheck.
 - Variables de entorno.
 - Logs stdout.
@@ -0,0 +1,47 @@
 # Estándar de Seguridad
 ## Principios
 - Seguridad por defecto.
 - Menor privilegio.
 - Zero Trust.
 - Validación de entradas.
 - Defensa en profundidad.
 - Auditoría.
 ## OWASP
 Toda solución debe revisar:
 - Broken Access Control.
 - Cryptographic Failures.
 - Injection.
 - Insecure Design.
 - Security Misconfiguration.
 - Vulnerable Components.
 - Authentication Failures.
 - Integrity Failures.
 - Logging and Monitoring Failures.
 - SSRF.
 ## APIs
 - Autenticación obligatoria en endpoints protegidos.
 - Autorización por rol o policy.
 - Rate limiting cuando aplique.
 - Validación de DTOs.
 - No exponer información sensible.
 ## Contenedores
 - No root.
 - Imágenes actualizadas.
 - Escaneo de vulnerabilidades.
 - Secrets externos.
 ## Datos
 - Cifrado en tránsito.
 - Cifrado en reposo cuando aplique.
 - Auditoría.
 - Retención definida.
@@ -0,0 +1,80 @@
 # Estándar Corporativo Angular
 ## Framework
 - Angular 20 o superior.
 - TypeScript estricto.
 - Standalone components preferidos.
 - Angular Material cuando aplique.
 ## Arquitectura
 Usar arquitectura basada en features:
 src/app/
 - core/
 - shared/
 - features/
 - layout/
 - environments/
 ## Core
 Debe contener:
 - Interceptors.
 - Guards.
 - Servicios globales.
 - Manejo de autenticación.
 - Configuración global.
 ## Shared
 Debe contener:
 - Componentes reutilizables.
 - Pipes.
 - Directivas.
 - Modelos compartidos.
 ## Features
 Cada funcionalidad debe estar aislada:
 features/orders/
 - components/
 - pages/
 - services/
 - models/
 - routes.ts
 ## Buenas prácticas
 - No poner lógica de negocio compleja en componentes.
 - Usar servicios para comunicación API.
 - Usar interfaces TypeScript.
 - Usar formularios reactivos.
 - Manejar estados de carga y error.
 - Aplicar lazy loading.
 - Aplicar accesibilidad.
 - Aplicar responsive design.
 ## Seguridad frontend
 - No guardar tokens sensibles en localStorage si hay alternativa más segura.
 - Sanitizar contenido dinámico.
 - Usar guards.
 - Usar interceptores.
 - No exponer secretos.
 - Validar también en backend.
 ## UX mínima requerida
 Toda pantalla debe considerar:
 - Estado vacío.
 - Estado cargando.
 - Estado error.
 - Confirmaciones para acciones destructivas.
 - Mensajes claros.
 - Diseño responsive.
@@ -0,0 +1,36 @@
 # Estándar Azure DevOps
 ## Reglas
 - Todo repositorio debe tener pipeline CI.
 - Todo despliegue debe pasar por CD.
 - Pull Request obligatorio.
 - Branch policies obligatorias.
 - Validación de build antes de merge.
 - Variables sensibles en variable groups seguros.
 ## Branching
 Ramas sugeridas:
 - main
 - develop
 - feature/*
 - hotfix/*
 - release/*
 ## Pipeline mínimo
 - Restore/install.
 - Build.
 - Tests.
 - Security scan.
 - Publish artifact.
 - Docker build cuando aplique.
 - Deploy por ambiente.
 ## Seguridad
 - No secrets en YAML.
 - Service connections con mínimo privilegio.
 - Aprobaciones para producción.
@@ -0,0 +1,39 @@
 # Estándar de Base de Datos
 ## Motores preferidos
 - SQL Server para soluciones empresariales Microsoft.
 - PostgreSQL para soluciones cloud-native y open-source.
 ## Diseño
 - Nombres claros.
 - Llaves primarias explícitas.
 - Índices para consultas frecuentes.
 - Foreign keys cuando aplique.
 - Auditoría en tablas críticas.
 - Fechas de creación y modificación.
 ## Multi-tenant
 Opciones permitidas:
 1. TenantId en tablas compartidas.
 2. Schema por tenant.
 3. Base de datos por tenant.
 La opción por defecto será TenantId en tablas compartidas, salvo requisitos fuertes de aislamiento.
 ## Seguridad
 - No usar usuarios administradores desde aplicaciones.
 - Principio de menor privilegio.
 - Cifrado en tránsito.
 - Cifrado en reposo cuando aplique.
 - No guardar contraseñas en texto plano.
 ## Migraciones
 - Usar migraciones versionadas.
 - No modificar manualmente producción.
 - Todo cambio debe pasar por pipeline.
@@ -0,0 +1,33 @@
 # Estándar Docker
 ## Reglas obligatorias
 - Usar Dockerfiles multi-stage.
 - No ejecutar como root.
 - Usar imágenes livianas cuando sea posible.
 - Definir healthcheck cuando aplique.
 - No incluir secretos en imágenes.
 - No copiar archivos innecesarios.
 - Usar .dockerignore.
 ## Backend .NET
 Debe usar build stage y runtime stage.
 ## Frontend Angular
 Debe compilar en Node y servir con Nginx.
 ## Seguridad
 - Usuario no root.
 - Imagen actualizada.
 - Variables por ambiente.
 - No credenciales hardcodeadas.
 - Puertos mínimos expuestos.
 ## Buenas prácticas
 - Versionar imágenes.
 - Usar tags semánticos.
 - Escanear vulnerabilidades.
@@ -0,0 +1,109 @@
 # Estándar Corporativo para APIs .NET
 ## Framework
 - .NET 8 o superior.
 - ASP.NET Core Web API.
 - C# moderno.
 - Nullable enable.
 - Async/await obligatorio para operaciones I/O.
 ## Arquitectura
 Usar Clean Architecture con capas separadas:
 - API
 - Application
 - Domain
 - Infrastructure
 - Tests
 ## Responsabilidad por capa
 ### API
 - Controllers o Minimal APIs.
 - Middlewares.
 - Autenticación.
 - Autorización.
 - Swagger.
 - Health checks.
 ### Application
 - Casos de uso.
 - Commands.
 - Queries.
 - DTOs.
 - Validaciones.
 - Interfaces.
 ### Domain
 - Entidades.
 - Value Objects.
 - Reglas de negocio.
 - Eventos de dominio.
 - Interfaces de repositorio.
 ### Infrastructure
 - Entity Framework Core.
 - Repositorios.
 - DbContext.
 - Servicios externos.
 - Implementaciones técnicas.
 ### Tests
 - Unit tests.
 - Integration tests.
 - API tests.
 ## Patrones recomendados
 - CQRS cuando exista complejidad.
 - Repository Pattern cuando ayude a separar dominio.
 - Unit of Work si hay transacciones complejas.
 - Mediator si se usa MediatR.
 - Result Pattern para manejo controlado de respuestas.
 ## Seguridad
 - JWT Bearer cuando aplique.
 - Autorización por roles o policies.
 - Validación de entrada obligatoria.
 - Protección contra SQL Injection.
 - Protección contra IDOR.
 - No exponer stack traces.
 - No retornar entidades directamente.
 - No guardar secretos en código.
 ## Documentación
 Toda API debe incluir:
 - Swagger/OpenAPI.
 - Descripción de endpoints.
 - Ejemplos de request/response.
 - Códigos de error.
 - Modelo de autenticación.
 ## Observabilidad
 Debe incluir:
 - Logging estructurado.
 - Correlation ID.
 - Health checks.
 - Métricas.
 - Trazabilidad de errores.
 ## Testing
 Mínimo requerido:
 - Unit tests de servicios.
 - Unit tests de validadores.
 - Integration tests de endpoints críticos.
 - Pruebas de autenticación y autorización.
@@ -0,0 +1,40 @@
 # Principios Globales de la Software Factory
 ## Objetivo
 Toda solución generada por la fábrica debe ser mantenible, segura, documentada, testeable y desplegable.
 ## Principios obligatorios
 - No inventar integraciones externas no solicitadas.
 - No asumir proveedor cloud si el usuario no lo especifica.
 - No entregar código incompleto.
 - No ignorar seguridad.
 - No omitir pruebas.
 - No omitir documentación.
 - No exponer secretos.
 - No usar configuraciones inseguras por defecto.
 - No proponer arquitectura sobredimensionada sin justificar.
 ## Estándar de respuesta de agentes
 Todo agente debe responder con:
 1. Análisis.
 2. Supuestos.
 3. Entregables.
 4. Riesgos.
 5. Recomendaciones.
 6. Próximos pasos.
 ## Tecnologías base preferidas
 - Backend: .NET 8+
 - Frontend: Angular 20+
 - Mobile: Ionic + Capacitor
 - Base de datos: SQL Server o PostgreSQL
 - Contenedores: Docker
 - Orquestación: Kubernetes
 - CI/CD: Azure DevOps
 - IaC: Terraform
 - Seguridad: OWASP + DevSecOps
@@ -0,0 +1,38 @@
 # Estándar Ionic + Capacitor
 ## Uso
 Usar Ionic + Capacitor para aplicaciones móviles híbridas Android/iOS.
 ## Reglas
 - Separar lógica web de lógica nativa.
 - Encapsular plugins Capacitor en servicios.
 - Validar permisos antes de usar funcionalidades nativas.
 - Manejar modo offline cuando aplique.
 - Considerar sincronización diferida.
 ## Estructura recomendada
 src/app/
 - core/
 - shared/
 - features/
 - mobile/
 - native/
 ## Seguridad móvil
 - No almacenar secretos en texto plano.
 - Evitar hardcodear endpoints.
 - Usar HTTPS.
 - Validar certificados cuando aplique.
 - Controlar sesiones expiradas.
 - Manejar almacenamiento seguro.
 ## Publicación
 - Generar APK/AAB para Android.
 - Validar permisos.
 - Validar versiones de Capacitor.
 - Probar en dispositivo físico.
@@ -0,0 +1,41 @@
 # Estándar Kubernetes
 ## Reglas obligatorias
 Todo deployment debe tener:
 - Requests.
 - Limits.
 - Readiness probe.
 - Liveness probe.
 - ConfigMaps.
 - Secrets.
 - Labels.
 - Namespaces.
 - Ingress cuando aplique.
 ## Seguridad
 - No ejecutar como root.
 - Usar securityContext.
 - No usar privileged containers.
 - Separar namespaces por ambiente.
 - No exponer servicios innecesarios.
 ## Observabilidad
 - Logs stdout/stderr.
 - Métricas.
 - Health checks.
 - Dashboards.
 ## Ambientes
 - dev
 - qa
 - staging
 - prod
 ## Despliegue
 Preferir Helm o Kustomize para parametrización.
@@ -0,0 +1,34 @@
 # Estándar Terraform
 ## Principios
 - Infraestructura como código.
 - Reutilización mediante módulos.
 - Separación por ambiente.
 - State remoto obligatorio.
 - Variables por ambiente.
 - No secretos en código.
 ## Estructura recomendada
 terraform/
 - modules/
 - environments/
  - dev/
  - qa/
  - prod/
 ## Reglas
 - Usar terraform fmt.
 - Usar terraform validate.
 - Usar plan antes de apply.
 - Revisar cambios en Pull Request.
 - Versionar providers.
 - Documentar variables.
 ## Seguridad
 - No guardar credenciales.
 - Usar Key Vault o Secret Manager.
 - Aplicar least privilege.
@@ -0,0 +1,29 @@
 # ADR - Architectural Decision Record
 ## Estado
 Propuesto / Aprobado / Rechazado
 ## Contexto
 Describe el problema o necesidad.
 ## Decisión
 Describe la decisión tomada.
 ## Alternativas evaluadas
 - Alternativa 1
 - Alternativa 2
 - Alternativa 3
 ## Consecuencias
 ### Positivas
 ### Negativas
 ## Fecha
 YYYY-MM-DD
@@ -0,0 +1,29 @@
 # Especificación de Endpoint API
 ## Nombre
 ## Método
 GET / POST / PUT / DELETE
 ## Ruta
 /api/recurso
 ## Autenticación
 Sí / No
 ## Roles permitidos
 ## Request
 ## Response exitoso
 ## Errores esperados
 ## Validaciones
 ## Observabilidad
 ## Pruebas requeridas
@@ -0,0 +1,23 @@
 # Entrega de Proyecto Generado por la Software Factory
 ## Resumen
 ## Requerimientos
 ## Arquitectura
 ## Backend
 ## Frontend
 ## DevOps
 ## QA
 ## Seguridad
 ## Riesgos
 ## Próximos pasos
 ## Pendientes de definición
@@ -0,0 +1,25 @@
 # Historia de Usuario
 ## Título
 Como [rol], quiero [funcionalidad], para [beneficio].
 ## Descripción
 Detalle de la necesidad.
 ## Criterios de aceptación
 - Dado...
 - Cuando...
 - Entonces...
 ## Reglas de negocio
 ## Dependencias
 ## Riesgos
 ## Prioridad
 Alta / Media / Baja
@@ -0,0 +1,53 @@
 # Flujo Oficial de Trabajo de la Software Factory
 ## Flujo principal
 Solicitud
 ↓
 Product Owner Agent
 ↓
 Architect Agent
 ↓
 UI/UX Agent
 ↓
 Backend Agent
 ↓
 Frontend Agent
 ↓
 DevOps Agent
 ↓
 QA Agent
 ↓
 Security Agent
 ↓
 CTO Agent
 ↓
 Entrega
 ## Responsabilidad del CTO Agent
 El CTO Agent coordina, valida y aprueba. No debe desarrollar directamente salvo ejemplos mínimos.
 ## Reglas del flujo
 - Product Owner define alcance y criterios de aceptación.
 - Arquitecto define arquitectura y decisiones técnicas.
 - UI/UX define experiencia y estructura visual.
 - Backend implementa APIs, dominio y servicios.
 - Frontend implementa pantallas y consumo de APIs.
 - DevOps define despliegue, contenedores, pipelines e infraestructura.
 - QA define pruebas funcionales, integración, carga y regresión.
 - Security revisa riesgos, vulnerabilidades y controles.
 - CTO aprueba o rechaza la solución.
 ## Criterio de aprobación
 Una solución solo se considera lista si tiene:
 - Requerimientos claros.
 - Arquitectura definida.
 - Código estructurado.
 - Pruebas.
 - Seguridad.
 - Despliegue.
 - Documentación.