# Cómo trabajamos

## Ramas

- `main` siempre funciona: nadie sube directamente a ella. Todo entra mediante *pull request* revisado por la otra persona.
- Una rama por tarea, creada desde `main` actualizada, con el prefijo del área:
  - `motor/...`: procesado (p. ej. `motor/lectura-dwg`)
  - `app/...`: interfaz y visor (p. ej. `app/visor-ejes`)
  - `pruebas/...`, `docs/...`
- Ramas cortas: mejor varios PR pequeños que uno enorme. Antes de abrir el PR, actualizar la rama con `main`.

```bash
git switch main
git pull
git switch -c app/visor-ejes
# ... trabajo y commits ...
git push -u origin app/visor-ejes
```

## Commits

En español, en imperativo y diciendo qué cambia: `Añade lectura de capas ocultas`, `Corrige escala en planos sin unidades`. Un commit por cambio con sentido propio.

## Issues y tablero

- Cada tarea es un *issue* con etiqueta de área (`motor`, `app`, `pruebas`, `docs`) y asignado a quien la hace.
- El tablero del proyecto en Gitea tiene las columnas **Pendiente · En curso · En revisión · Hecho**.
- Los errores se registran como *issue* con la plantilla de error: son evidencia para el informe de calidad.

## Pull requests

- La descripción dice qué cambia, cómo se ha probado y qué *issue* cierra (`Closes #12`).
- `uv run pytest` debe pasar antes de pedir revisión.
- La otra persona revisa y aprueba. La revisión cruzada es obligatoria: los dos tenemos que entender todo el código para la defensa.

## Contrato motor/aplicación

`motor/api.py` es lo único que comparten las dos partes. Cualquier cambio en él se acuerda antes, se anota en `docs/decisiones.md` y va en un PR propio.

## Documentación continua

- **Decisiones** (`docs/decisiones.md`): cada decisión de diseño o de alcance, con motivo.
- **Bitácora** (`docs/bitacora.md`): qué ha hecho cada uno cada semana.
- **Actas** (`docs/actas/`): una por reunión semanal.
- **Uso de IA** (`docs/uso-ia.md`): cada uso relevante de herramientas de IA.