Add corporate brain v1 knowledge base

README.md

@@ -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.

agents/agent-coordination-rules.md

@@ -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.

architecture/architecture-standard.md

@@ -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.

checklists/cto-review-checklist.md

@@ -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.

product/product-standard.md

@@ -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.

qa/qa-standard.md

@@ -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.

runbooks/angular-docker-nginx.md

@@ -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.

runbooks/ci-cd-standard.md

@@ -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.

runbooks/dotnet-docker.md

@@ -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.

security/security-standard.md

@@ -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.

standards/angular-standard.md

@@ -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.

standards/azure-devops-standard.md

@@ -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.

standards/database-standard.md

@@ -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.

standards/docker-standard.md

@@ -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.

standards/dotnet-api-standard.md

@@ -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.

standards/global-principles.md

@@ -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

standards/ionic-capacitor-standard.md

@@ -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.

standards/kubernetes-standard.md

@@ -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.

standards/terraform-standard.md

@@ -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.

templates/adr-template.md

@@ -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

templates/api-endpoint-template.md

@@ -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

templates/project-output-template.md

@@ -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

templates/user-story-template.md

@@ -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

workflows/software-factory-workflow.md

@@ -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.