Arquitectura CI/CD — Wiedii
CI/CD es la automatización que compila, prueba y despliega tu código cada vez que subes cambios, sin pasos manuales. El sistema CI/CD de Wiedii es centralizado y gestionado por el equipo de Infraestructura. Los repositorios de desarrollo no contienen configuraciones de pipeline — todo el CI/CD vive en un repo dedicado de infra y se conecta a cada proyecto desde GitLab.
Conducta con IA — verificar, no asumir, preguntar, franqueza
Cómo debe comportarse cualquier herramienta de IA autorizada (Claude Code, Cowork) trabajando para Wiedii — en cualquier área, no solo desarrollo. Es la cara de conducta del whitelist de IA (ver politicas-core / wiedii-core). Actualizado 2026-07-15: Codex, Antigravity CLI y Kiro quedaron fuera de la lista blanca.
Convención de Nombres de Repositorios GitLab
Regla general
Convenciones de Calidad IaC (Terraform/Terragrunt)
📖 En corto: IaC (Infrastructure as Code) es describir la infraestructura —servidores, redes, bases de datos— como código versionado, en vez de configurarla a mano. Terraform (y Terragrunt, que lo organiza) es la herramienta con la que se hace en Wiedii; Checkov y TFLint revisan ese código en busca de fallos de seguridad y estilo. Esta nota es para quien escribe o mantiene repos de infraestructura — no hace falta si tu proyecto no tiene Terraform.
Crear un proyecto desde cero — checklist y consideraciones
🎯 Guía para crear un proyecto/repositorio real desde cero: el paso a paso y qué tener en cuenta. Distinta del onboarding de práctica con el sandbox — para eso ver guia-nuevo-dev y repo-sandbox.
Documentación bilingüe de proyectos (EN canónico + ES)
Toda la documentación de un repositorio Wiedii se mantiene en inglés y español, en archivos independientes (no un solo archivo con ambos idiomas), con navegación enriquecida que enlaza recíprocamente las versiones.
El Trofeo del Testing — Metodología y Política de Testing en Wiedii
Trofeo ≠ TDD. El Trofeo define qué tipo y proporción de pruebas tener; TDD define el ritmo con que se escriben (la prueba antes que el código). Son complementarios: en Wiedii las pruebas se escriben guiadas por TDD y la suite resultante se distribuye según el Trofeo.
Estándar de scripting Bash (referencia)
Un script de Bash es una lista de comandos de terminal guardada en un archivo para ejecutarla de una sola vez. Un linter revisa ese archivo en busca de errores y malas prácticas; un formateador ordena el estilo (indentación, espacios) sin cambiar lo que hace. Esta nota dice qué herramienta se encarga de cada cosa.
Política Cross-Platform — .gitignore, .gitattributes, .editorconfig
Todo repositorio debe tener .gitignore, .gitattributes y .editorconfig configurados para compatibilidad entre plataformas (Windows, Linux, macOS).
Política de Actualizaciones Automáticas — Renovate
Renovate es un bot que abre MRs automáticas para actualizar las dependencias de un repositorio (librerías, imágenes Docker, herramientas) a sus versiones nuevas.
Política de Branching — Git Flow
⚠️ Verificar versiones antes de usar — la versión de git-flow-next documentada aquí puede estar desactualizada. Consultar brew info git-flow-next o git-flow.sh para la versión más reciente. Ver politicas-core.
Política de Commits — Conventional Commits
🔄 Actualizado 2026-07-06 — el mecanismo cambió de czg/commitlint a wietoo. El formato descrito en esta página (tipos, emojis, footer closed #) sigue siendo el estándar vigente y no cambió. Lo que cambió es cómo se aplica wietoo-cli. La nota czg queda como referencia histórica.
Política de Contenedores Docker
⚠️ Verificar versiones antes de usar — los números de versión de imágenes base en esta nota pueden estar desactualizados. Usar docker pull y revisar las notas de lanzamiento oficiales antes de fijar versiones. Ver politicas-core.
Política de CONTRIBUTING.md
Todo repositorio Wiedii debe tener un CONTRIBUTING.md en su raíz. Este archivo es el contrato de contribución del proyecto: explica a cualquier desarrollador (o agente IA) cómo preparar el entorno, crear ramas, escribir commits y abrir un Merge Request.
Política de Git Hooks — Lefthook
Todo repositorio debe tener lefthook.yaml con hooks activos. Los hooks se instalan automáticamente via [hooks].postinstall en mise.toml al ejecutar mise install --yes, con detección de CI para no ejecutarse en pipelines.
Política de Herramientas — mise
⚠️ Verificar versiones antes de usar — los números de versión de herramientas en esta nota pueden estar desactualizados. Usar mise ls-remote | tail -5 para consultar las versiones disponibles. Ver politicas-core.
Política de Linters por Tipo de Proyecto
⚠️ Verificar versiones antes de usar — las versiones de paquetes (ESLint, ruff, PHPStan, etc.) pueden estar desactualizadas. Usar bun info version para npm o mise ls-remote para herramientas. Ver politicas-core.
Política de Monorepo — Nx
Un monorepo es un solo repositorio que contiene varios proyectos o paquetes juntos; Nx es la herramienta que los coordina (compila, testea y cachea solo lo afectado por un cambio).
Política de Protección de Ramas — GitLab CE
Configurar en GitLab → Settings → Repository → Protected branches, tanto para main como para develop:
Política de Versionado — SemVer
- Formato paquetes Go distribuidos por go install — ver abajo)
Políticas de Desarrollo — Core
Estas reglas aplican a todo repositorio Wiedii, sin excepción, tanto para el equipo humano como para agentes de desarrollo.
Seguridad de APIs — Wiedii
Aplica a todo servicio que exponga una API (REST/HTTP). Complementa la seguridad de contenedores (docker) y las políticas core (politicas-core).