docs: guia de desarrollo con lo que se toca y lo que no

GUIA_DE_DESARROLLO.md en la raiz: la regla de oro, el semaforo (rojo:
backend, middleware, modelos, server, CSP, traducciones y hojas del dev;
ambar: una linea de enganche en las vistas del dev; verde: hojas, vistas,
router, workflows y textos propios), como hacer cada tipo de cambio, lo que
hay que comprobar antes de cada commit, como integrar una version nueva del
dev, como probar y la deuda que queda. Enlazada al principio del README.

README.md

@@ -13,6 +13,13 @@
 >
 > **Los fallos de esta rama se reportan aquí, nunca a epsylon.**
 
+> ## Para desarrollar: lee primero la [GUÍA DE DESARROLLO](GUIA_DE_DESARROLLO.md)
+>
+> Qué se puede tocar y qué no. Resumen: **el backend, el middleware, los modelos y
+> las traducciones son del dev y no se tocan**; lo nuestro va en hojas de estilo,
+> vistas y rutas propias, y en las vistas del dev como mucho una línea de enganche.
+> El porqué, con cifras: [docs/FRONTERA_UPSTREAM.md](docs/FRONTERA_UPSTREAM.md).
+
 Versión base: **Oasis 1.3.3** · Rama: `PRUEBAS` ·
 [Documentación completa](https://gitea.laenre.net/hacklab/OASIS_MOBILE/wiki) ·
 [Versión de escritorio](https://gitea.laenre.net/hacklab/OASIS_LINUX)
@@ -193,6 +200,14 @@ OASIS_APK_BASE=/ruta/oasis-v1.3.3.apk ./scripts/release.sh   # compila, verifica
 
 ## Documentación
 
+Para desarrollar en la rama, en el propio repositorio:
+
+| | |
+|---|---|
+| [GUIA_DE_DESARROLLO.md](GUIA_DE_DESARROLLO.md) | Qué se toca y qué no, cómo hacer cada tipo de cambio, comprobaciones antes de cada commit |
+| [docs/FRONTERA_UPSTREAM.md](docs/FRONTERA_UPSTREAM.md) | Cómo cambia el dev cada versión, medido, y el plan para sanear la rama |
+| [docs/USABILIDAD_PAD.txt](docs/USABILIDAD_PAD.txt) | Pruebas de usabilidad en el móvil: lo arreglado y lo pendiente |
+
 Todo lo de arriba, en detalle, está en la
 **[wiki](https://gitea.laenre.net/hacklab/OASIS_MOBILE/wiki)**: