Saltar al contenido principal

22 documentos etiquetados con "politica-desarrollo"

Ver Todas las Etiquetas

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.

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.

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

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