Intranet Transafety 🏠 Inicio Guía Comercial Dev Playbook Onboarding Metodología IA

01 Estructura de ramas

main
Producción
siempre estable
develop
Integración
base de trabajo
feature/*
Nueva funcionalidad
desde develop
hotfix/*
Fix urgente
desde main
RamaPropósitoMerge destinoQuién puede hacer push
mainCódigo en producción. Siempre deployable.Solo vía PR aprobado
developBase de integración. Aquí convergen las features.mainSolo vía PR aprobado
feature/*Una feature o tarea específica.developAutor de la rama
hotfix/*Fix urgente que no puede esperar el ciclo normal.main + developTech Lead o Senior
Regla crítica Nunca se hace push directo a main ni a develop. Todo cambio entra por Pull Request. Sin excepción, ni en urgencias.

02 Nombres de rama

Formato: tipo/descripcion-corta-en-kebab-case

  • feature/rat-riesgos-obligatorios → nueva funcionalidad
  • feature/multi-tenant → nueva funcionalidad
  • feature/audit-cobertura-completa → nueva funcionalidad
  • fix/login-token-expiry → corrección de bug
  • hotfix/brecha-sql-injection → fix urgente de seguridad
  • refactor/rat-service-cleanup → limpieza de código sin cambio funcional
  • docs/actualizar-api-rat → solo documentación
  • test/cobertura-modulo-consent → solo tests
Regla Nombres en minúsculas, guiones medios, sin tildes, sin espacios. Máximo 40 caracteres después del prefijo.

03 Commits

Seguimos Conventional Commits. Formato:

Formato
tipo(módulo): descripción breve en imperativo

# Cuerpo opcional: qué y por qué (no el cómo)
# Máximo 72 caracteres por línea
TipoCuándo usarloEjemplo
featNueva funcionalidadfeat(rat): agregar historial de cambios por campo
fixCorrección de bugfix(auth): corregir expiración de token en Azure AD
refactorReestructuración sin cambio funcionalrefactor(consent): extraer lógica de validación a servicio
testAgregar o modificar teststest(arcop): cubrir caso de solicitud duplicada
docsSolo documentacióndocs: actualizar guía de deploy en README
choreMantenimiento (deps, config)chore: actualizar ruff a v0.4.0
securityFix de seguridadsecurity(auth): sanitizar input en endpoint login
Buenas prácticas Un commit = un cambio lógico. Si el mensaje necesita "y" en el medio, probablemente son dos commits. Usa imperativo: "agregar", "corregir", "extraer" — no "agregué" ni "arreglando".

04 Pull Requests

Cuándo abrir un PR

  • La feature o fix está completo y los tests pasan localmente (make test-unit).
  • Los pre-commit hooks pasan (make pre-commit).
  • El PR tiene una descripción que explica qué cambia y por qué.

Plantilla de PR (ya configurada en el repo)

El repo incluye .github/PULL_REQUEST_TEMPLATE.md. Al abrir un PR en GitHub, se carga automáticamente. Los campos obligatorios:

CampoQué escribir
Qué cambia este PRDescripción en lenguaje humano. Qué funciona ahora que antes no funcionaba.
Tipo de cambioMarcar uno: feat / fix / refactor / docs / test / chore / security.
Módulos afectadosMarcar los módulos que tocaste (auth, rat, arcop, consent…).
ChecklistTodos los ítems deben estar marcados antes de pedir review.
Notas para el reviewerContexto adicional, screenshots, decisiones de diseño no obvias.

Tamaño de un PR

Regla de tamaño Un PR debe poder revisarse en menos de 30 minutos. Si tocás más de 400 líneas o más de 5 archivos de lógica, considerá dividirlo. PRs gigantes no se revisan bien — se aprueban por cansancio.

05 CI / CD

Pre-commit hooks (local, automático)

Se ejecutan antes de cada commit. Si fallan, el commit no se crea. Incluyen:

HookQué hace
Ruff linterDetecta errores de estilo, imports desordenados, código muerto. Aplica fixes automáticos.
Ruff formatterFormatea el código (equivalente a black). Sin discusión de estilo.
MyPyVerifica tipado estático de Python.
BanditEscanea vulnerabilidades de seguridad en el código.
detect-secretsBloquea commits si detecta contraseñas, tokens o claves hardcodeadas.
Tests unitarios rápidosCorre pytest tests/unit antes de cada commit. Si fallan, el commit no pasa.

Comandos de calidad (Makefile)

Terminal
make lint          # Analiza código con ruff
make format        # Formatea código con ruff
make type-check    # Verifica tipos con mypy
make security-scan # Escaneo de seguridad con bandit
make test-unit     # Tests unitarios
make test-all      # Todos los tests (unit + integration + e2e + security)
make coverage      # Genera reporte de cobertura HTML (mínimo: 80%)
Cobertura mínima El proyecto tiene configurado fail_under = 80 en pytest. Si la cobertura cae por debajo del 80%, make coverage falla. Un PR que baja la cobertura no se aprueba.

06 Deploy

AmbienteBase de datosCómo se deployaQuién puede
Local (dev)SQLitemake install + python src/run.pyCualquier miembro del equipo
StagingPostgreSQLDocker Compose + variables en .envSenior + Tech Lead
ProducciónPostgreSQL (Azure)Pipeline CI/CD desde mainSolo Tech Lead

Setup local para nuevos integrantes

Pasos de onboarding técnico
# 1. Clonar el repo
git clone https://github.com/gveraTrnsfty/LeydeProtecciondeDatos.git
cd LeydeProtecciondeDatos

# 2. Configurar entorno virtual
python -m venv venv
venv\Scripts\activate   # Windows
# source venv/bin/activate  # Mac/Linux

# 3. Instalar dependencias y hooks
make install

# 4. Copiar variables de entorno
cp .env.example .env
# Editar .env con los valores que te dará el Tech Lead

# 5. Inicializar base de datos local
flask db upgrade

# 6. Correr el servidor
python src/run.py

# 7. Verificar que los tests pasan
make test-unit
Nunca en el repo El archivo .env está en .gitignore. Nunca lo commiteés. Las credenciales de producción las maneja solo el Tech Lead y están en Azure Key Vault, no en archivos.

07 Roles y responsabilidades

Tech Lead
Gonzalo Vera
  • Decisiones de arquitectura
  • Aprueba merge a main
  • Gestiona deploys a producción
  • Desbloquea al equipo
  • Define prioridades técnicas
Desarrollador Senior
  • Lidera code reviews
  • Aprueba PRs a develop
  • Mentoreo a practicantes
  • Diseña módulos nuevos
Desarrollador / Practicante
Equipo actual
  • Desarrolla features asignadas
  • Escribe tests para su código
  • Abre PRs con descripción completa
  • Participa en code review
  • Señala bloqueos en el daily
Sobre practicantes Los practicantes trabajan siempre en ramas feature/*. No tienen acceso de push directo a develop ni a main. Todo su trabajo entra por PR y requiere al menos una aprobación de un desarrollador senior o el Tech Lead.

08 Estándares de código

Python

ReglaHerramientaConfiguración
Largo de líneaRuffMáximo 120 caracteres (pyproject.toml)
Orden de importsRuff (isort)stdlib → third-party → local. Automático.
FormatoRuff formatterEquivalente a Black. Sin discusión, se aplica automáticamente.
TipadoMyPyTipado en funciones nuevas. Módulos legados: best effort.
SeguridadBanditSeverity medium+. Cero excepciones sin comentario justificado.
No prints en producciónRuff (T20)Usar logging. Los print() fallan en CI.

Estructura de un módulo

Patrón estándar
src/app/
  models/     → Modelos SQLAlchemy (solo definición de datos)
  routes/     → Blueprints Flask (solo HTTP: recibir request, devolver response)
  services/   → Lógica de negocio (aquí va la carne)
  templates/  → HTML Jinja2
  static/     → CSS, JS, imágenes
Principio clave Las rutas no tienen lógica de negocio. Llaman a un servicio y devuelven el resultado. Si una función de ruta tiene más de 20 líneas, es señal de que algo debería estar en services/.

Tests

TipoDóndeQué cubrenCuándo corren
Unittests/unit/Funciones y servicios en aislamientoEn cada commit (pre-commit hook)
Integrationtests/integration/Módulos completos + base de datosAntes de PR a develop
E2Etests/e2e/Flujos completos de usuarioAntes de merge a main
Securitytests/ + BanditVulnerabilidades y escapesEn CI y pre-commit
Regla de tests Cada feature nueva incluye tests unitarios en el mismo PR. No hay "voy a agregar los tests después". Si el PR no tiene tests, no se aprueba.

09 Code review

Proceso

PasoQuiénQué hace
1. Abrir PRAutorCompleta la plantilla, asigna reviewer, agrega el tag de módulo.
2. ReviewReviewer asignadoLee el diff, prueba localmente si hay duda, deja comentarios en línea. Plazo: máximo 24 h hábiles.
3. RespuestaAutorResponde cada comentario — ya sea aplicando el cambio o argumentando por qué no. No se ignoran comentarios.
4. AprobaciónReviewerCuando todos los comentarios están resueltos, aprueba el PR.
5. MergeAutor o Tech LeadSquash merge a develop. La rama feature se elimina.

Cómo dar feedback en un code review

PrefijoSignificadoEjemplo
[blocker]El PR no puede mergearse sin resolverlo.[blocker] Este query es vulnerable a SQL injection, usar parámetros.
[suggestion]Mejora recomendada, no obligatoria.[suggestion] Podrías extraer esta lógica a un servicio para testearla más fácil.
[question]Duda genuina, no crítica.[question] ¿Por qué se usa PATCH acá en vez de PUT?
[nit]Detalle menor de estilo o naming.[nit] Prefiero `get_active_records` sobre `getActiveData`.
Cultura de review El feedback va al código, no a la persona. "Esta función hace demasiadas cosas" es válido. "Este código está mal escrito" no lo es. Los practicantes tienen espacio para aprender — el reviewer explica el porqué, no solo da la solución.

10 Ceremonias de equipo

Planning
Lunes · 60 min · Semana de inicio de sprint
  • Revisar backlog priorizado
  • Cada miembro toma sus tareas
  • Estimar esfuerzo (S/M/L o puntos)
  • Definir Definition of Done por tarea
  • Output: sprint board actualizado
Daily standup
Lunes a viernes · 15 min · 09:30
  • ¿Qué hice ayer?
  • ¿Qué hago hoy?
  • ¿Tengo algún bloqueo?
  • No es espacio de debate técnico
  • Bloqueos se resuelven después, 1:1
Demo / Review
Viernes · 30 min · Cierre de sprint
  • Cada dev muestra lo que completó
  • Se demuestra en el ambiente de staging
  • Feedback inmediato del equipo
  • No se muestra código — se muestra funcionalidad
Retrospectiva
Cada 2 semanas · 30 min · Al cierre del sprint
  • ¿Qué salió bien?
  • ¿Qué podría mejorar?
  • ¿Qué vamos a cambiar?
  • Máximo 3 acciones concretas para el próximo sprint
  • Importante para el piloto con practicantes
Herramientas Daily y reuniones: Microsoft Teams. Gestión de tareas: a definir (GitHub Projects es la opción recomendada dado que el repo ya está en GitHub). Comunicación asíncrona: correo o Teams según urgencia.

11 Piloto con practicantes — Setup inicial

Objetivo del piloto Validar que este playbook es claro, aplicable y completo usando a los practicantes como primer equipo. Su feedback es insumo directo para la versión definitiva del documento.

Qué debe hacer cada practicante en la primera semana

DíaTareaVerificación
Día 1Clonar el repo y completar el setup local (make install)Servidor levanta en localhost:5000
Día 1Correr make test-unit y confirmar que pasanVerde en terminal
Día 2Crear su primera rama feature/practicante-[nombre]-helloRama visible en GitHub
Día 2Hacer un commit pequeño siguiendo Conventional CommitsCommit acepta pre-commit hooks
Día 3Abrir un PR de prueba con la plantilla completaPR creado con todos los campos
Día 3-4Recibir y responder un code review de prácticaAl menos un ciclo de feedback
Día 5Participar en el daily y la retro de fin de semana pilotoPresencia y feedback verbal

12 Checklist de validación del piloto

Al finalizar la primera semana, cada practicante debería poder marcar estos ítems. El Tech Lead los revisa en la retro.

  • Entiendo para qué sirven las ramas main, develop y feature/*
  • Sé cómo nombrar una rama correctamente
  • Escribí al menos un commit usando Conventional Commits
  • El pre-commit hook no me bloqueó por errores de linting o seguridad
  • Abrí un PR con la plantilla completa (todos los campos)
  • Recibí y respondí al menos un comentario de code review
  • Corrí make test-unit y entiendo qué significa la salida
  • Sé qué datos NO puedo commitear (.env, credenciales, datos personales reales)
  • Participé en el daily y sé cuándo señalar un bloqueo
  • Este playbook me fue claro — o documenté qué sección no estaba clara para mejorarla
Resultado esperado Al finalizar el piloto, el equipo tiene una versión revisada de este documento con los puntos confusos corregidos. El playbook es un documento vivo — si algo no está claro, se arregla el documento, no se lo ignora.

13 Qué hace y cómo funciona

Cada vez que alguien abre o actualiza un Pull Request en GitHub, una GitHub Action llama automáticamente a GLM 5.2 (a través de tu plan Z.AI) y deja comentarios de revisión directamente en el PR — igual que si un desarrollador senior hubiera leído el diff y escrito sus observaciones.

Por qué Z.AI Coding Plan y no Claude API El plan Z.AI Coding Plan incluye el uso del modelo dentro del precio mensual fijo ($10–18/mes). No hay cobro por token ni por llamada adicional — el presupuesto es predecible. GLM 5.2 tiene 1M de contexto, está optimizado para código, y es el modelo que ya usás en tu entorno de desarrollo.

Qué revisa automáticamente

CategoríaQué detecta
Bugs potencialesErrores lógicos, condiciones siempre verdaderas/falsas, variables sin usar
SeguridadSQL injection, secretos hardcodeados, inputs sin sanitizar
Calidad de códigoFunciones demasiado largas, duplicación evidente, nombres confusos
TestsCódigo sin cobertura de tests, casos borde no contemplados
Cumplimiento Ley 21.719Configurable — ver sección de system prompt personalizado

Flujo completo

Dev abre PR
feature/* → develop
GitHub Action
lee el diff del PR
GLM 5.2
analiza vía Z.AI API
Comentarios
en el PR automáticamente

14 Setup paso a paso

Paso 1 — Obtener tu API key de Z.AI

  1. Ir a docs.z.ai → iniciar sesión con tu cuenta del Coding Plan
  2. Menú → API KeysCreate new key
  3. Guardar la key — solo se muestra una vez
Endpoint correcto para el Coding Plan El Coding Plan usa un endpoint dedicado, distinto al de la API pública estándar:
https://api.z.ai/api/coding/paas/v4
No uses el endpoint genérico api.z.ai/api/openai/v1 — puede consumir créditos fuera del plan.

Paso 2 — Agregar el secret en GitHub

  1. En el repo LeydeProtecciondeDatosSettingsSecrets and variablesActions
  2. Click en New repository secret
  3. Nombre: ZAI_API_KEY · Valor: tu API key del paso 1
  4. Click Add secret

Paso 3 — Crear el archivo de workflow

Crear el archivo en el repo: .github/workflows/zai-code-review.yml

.github/workflows/zai-code-review.yml
name: Code Review — Z.AI GLM 5.2

on:
  pull_request:
    types: [opened, synchronize]
    branches:
      - develop
      - main

jobs:
  code-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write   # necesario para dejar comentarios

    steps:
      - name: Z.AI Code Review
        uses: tarmojussila/zai-code-review@v0.4.0
        with:
          ZAI_API_KEY: ${{ secrets.ZAI_API_KEY }}
        env:
          ZAI_MODEL: glm-5.2
          ZAI_REVIEWER_NAME: "PrivaSteward AI Reviewer"

Paso 4 — Verificar que funciona

  1. Hacer un commit cualquiera en una rama feature/*
  2. Abrir un PR hacia develop
  3. Ir a la pestaña Actions del PR y ver que el workflow corre
  4. Después de ~30–60 segundos aparecen los comentarios del reviewer en el PR
Primera vez que corre Si el workflow pasa pero no aparecen comentarios, verificar que el repo tiene permisos de pull-requests: write habilitados en Settings → Actions → General → Workflow permissions → "Read and write permissions".

15 Configuración avanzada — System prompt personalizado

El comportamiento del reviewer se puede personalizar completamente con un system prompt propio. Esto es especialmente útil para PrivaSteward porque el código maneja datos personales bajo la Ley 21.719.

.github/workflows/zai-code-review.yml — con prompt personalizado
name: Code Review — Z.AI GLM 5.2

on:
  pull_request:
    types: [opened, synchronize]
    branches:
      - develop
      - main

jobs:
  code-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

    steps:
      - name: Z.AI Code Review
        uses: tarmojussila/zai-code-review@v0.4.0
        with:
          ZAI_API_KEY: ${{ secrets.ZAI_API_KEY }}
        env:
          ZAI_MODEL: glm-5.2
          ZAI_REVIEWER_NAME: "PrivaSteward AI Reviewer"
          ZAI_SYSTEM_PROMPT: |
            Eres un revisor de código experto para PrivaSteward, sistema de
            cumplimiento de la Ley 21.719 de Protección de Datos de Chile.
            Stack: Python 3.11, Flask 3.0, SQLAlchemy.

            En cada revisión evalúa:
            1. SEGURIDAD: SQL injection, inputs sin sanitizar, secretos hardcodeados,
               datos personales expuestos en logs o respuestas HTTP.
            2. PRIVACIDAD (Ley 21.719): cualquier tratamiento de datos personales
               (RUT, nombre, email, salud) debe estar justificado por una base legal
               del RAT. Señalar si el código accede a datos sensibles sin control.
            3. CALIDAD: funciones con más de 20 líneas de lógica de negocio en rutas
               Flask (deben estar en services/), falta de tipado en funciones nuevas,
               print() en vez de logging.
            4. TESTS: código sin cobertura, casos borde no contemplados.

            Formato de respuesta:
            - Usa [BLOCKER], [SUGERENCIA] o [PREGUNTA] como prefijo.
            - Sé concreto y actionable. No repitas lo que ya hace bien el código.
            - Máximo 8 comentarios por PR. Prioriza los más importantes.
Variables de entorno vs. secrets ZAI_API_KEY siempre va como secret (Settings → Secrets). Las otras variables (ZAI_MODEL, ZAI_SYSTEM_PROMPT, ZAI_REVIEWER_NAME) pueden ir directamente en el env: del workflow — no son secretas.

Actualizar el modelo sin tocar el workflow

Para cambiar el modelo sin editar el archivo YAML, se puede usar una variable de Actions (Settings → Variables → Actions → New variable):

VariableValor actualCómo cambiarla
ZAI_MODELglm-5.2Settings → Variables → Actions → editar
ZAI_REVIEWER_NAMEPrivaSteward AI ReviewerÍdem

Si usás variables de Actions en vez de valores hardcodeados en el YAML, referéncialas con ${{ vars.ZAI_MODEL }} en el workflow.

16 Integración con Trello — Descripción de PR automática desde el ticket

Combinando la GitHub Action de Z.AI con la action de Trello, el flujo completo queda así: el desarrollador nombra su rama con el ID del ticket de Trello, y el sistema se encarga del resto.

Convención de nombres de rama (ya definida en este playbook)

Ejemplos
feature/TSF-42-historial-rat
feature/TSF-57-multi-tenant
fix/TSF-61-login-azure-ad

El ID de Trello es la parte TSF-42. La action lo lee del nombre de la rama y busca el ticket automáticamente.

Workflow combinado: Trello + Z.AI review

.github/workflows/pr-automation.yml
name: PR Automation — Trello + Z.AI Review

on:
  pull_request:
    types: [opened, synchronize, closed]
    branches:
      - develop
      - main

jobs:
  # ── Job 1: Llenar descripción del PR desde Trello ──────────────────
  trello-sync:
    runs-on: ubuntu-latest
    if: github.event.action == 'opened'
    permissions:
      pull-requests: write
    steps:
      - name: Trello Card → PR Description
        uses: rematocorp/trello-integration-action@v1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          trello-api-key: ${{ secrets.TRELLO_API_KEY }}
          trello-auth-token: ${{ secrets.TRELLO_TOKEN }}
          trello-board-id: ${{ secrets.TRELLO_BOARD_ID }}
          # La action lee el ID de Trello del nombre de la rama (ej: TSF-42)
          trello-card-position: top
          github-include-pr-branch-name: true

  # ── Job 2: Code review automático con GLM 5.2 ─────────────────────
  zai-review:
    runs-on: ubuntu-latest
    if: github.event.action == 'opened' || github.event.action == 'synchronize'
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Z.AI Code Review — GLM 5.2
        uses: tarmojussila/zai-code-review@v0.4.0
        with:
          ZAI_API_KEY: ${{ secrets.ZAI_API_KEY }}
        env:
          ZAI_MODEL: glm-5.2
          ZAI_REVIEWER_NAME: "PrivaSteward AI Reviewer"

  # ── Job 3: Mover tarjeta Trello al cerrar PR ──────────────────────
  trello-close:
    runs-on: ubuntu-latest
    if: github.event.action == 'closed' && github.event.pull_request.merged == true
    steps:
      - name: Mover tarjeta a Done
        uses: rematocorp/trello-integration-action@v1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          trello-api-key: ${{ secrets.TRELLO_API_KEY }}
          trello-auth-token: ${{ secrets.TRELLO_TOKEN }}
          trello-board-id: ${{ secrets.TRELLO_BOARD_ID }}
          trello-list-name-done: "Done"
          github-include-pr-branch-name: true

Secrets necesarios en GitHub

SecretCómo obtenerlo
ZAI_API_KEYdocs.z.ai → API Keys → Create new key
TRELLO_API_KEYtrello.com/app-key (con tu cuenta Trello)
TRELLO_TOKENEn la misma página de app-key, click "Token"
TRELLO_BOARD_IDURL del tablero: trello.com/b/BOARD_ID/nombre
Resultado final del flujo Dev crea rama feature/TSF-42-historial-rat → abre PR → la descripción se llena con el título y contexto del ticket de Trello → GLM 5.2 revisa el código y deja comentarios → el equipo hace review humano → merge → tarjeta se mueve a Done en Trello. Cero pasos manuales repetitivos.
Limitación conocida La action de Trello llena la descripción solo cuando el PR se abre por primera vez (action == 'opened'). Si la descripción ya tiene texto (porque el dev la escribió manualmente), la action puede sobreescribirla dependiendo de la configuración. Recomendación: dejar la descripción vacía al abrir el PR y dejar que la action la complete.