plano3d/CONTRIBUTING.md

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.

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.