feat: move unfinished tickets between releases

- Bulk editing gets «Release…» (open releases or none), and the list
  view a release filter, also reachable from each release («Ver en la
  lista», ?release=).
- Archiving a release asks where its unfinished tickets go, as closing
  a sprint does: ReleaseArchivedEvent carries `moveTo` (an open release
  of the same project, or none) and the saga moves them there; finished
  ones stay. In GraphQL, REST and the MCP's archive_release.
- Chapter 10 lists the next features and the ideas to weigh.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/10-futuro.md

@@ -28,17 +28,51 @@ cuando hay pistas, por dónde empezar.
 
 ## 10.3 Siguientes funcionalidades
 
-En orden de lo que más aportaría:
+### Elegidas para la próxima tanda
 
-1. **Asistente en la web** (la base ya está en el MCP):
-   - resumir un ticket largo con sus comentarios;
-   - al crear un ticket, sugerir tipo, prioridad y área, y avisar si se parece a otro que ya existe;
-   - redactar las notas de versión en lenguaje natural a partir del borrador.
-2. **Avisos a Discord, Slack o Telegram**: los webhooks salientes mandan JSON en bruto, que esos chats no muestran
-   bien. Una integración por canal (o un formato por destino en los webhooks) mandaría mensajes ya legibles: «Ana
-   movió WEB-12 a En revisión», con enlace.
-3. **Conector de claude.ai**: el MCP necesitaría el flujo OAuth del protocolo, y Pireon publicar su metadata de
-   autorización y admitir el registro dinámico de clientes.
+En este orden:
+
+1. **Calendario suscribible (ICS)**: una URL privada por persona con las fechas límite, los sprints y las releases de
+   sus proyectos, para Google Calendar, Outlook o Apple Calendar. La URL lleva un token propio (revocable), no el de
+   sesión.
+2. **Notificaciones push (Web Push)**: los avisos de la campana como aviso del sistema, aunque la pestaña esté
+   cerrada. Un _service worker_ en la web (que la deja instalable como PWA), «Activar avisos» en los ajustes de
+   notificaciones, las suscripciones de cada persona guardadas en la API y el envío con Web Push (claves VAPID, dos
+   variables nuevas). En iPhone solo con la web instalada en la pantalla de inicio (iOS 16.4+).
+3. **Campos personalizados por proyecto**: «Navegador», «Cliente», «Entorno»… de texto, número, fecha o lista de
+   opciones, definidos en Configuración; editables en la ficha, filtrables y como columna en la vista de lista.
+
+### Valoradas para después
+
+4. **Dependencias en la hoja de ruta**: las relaciones «bloquea» / «depende de» entre épicas, como flechas en la vista
+   de calendario, para ver qué retrasa a qué.
+5. **Burndown y velocidad de sprint**: puntos pendientes día a día durante el sprint y puntos cerrados por sprint, para
+   planificar el siguiente con datos (el historial de estados ya está en `issue_timeline`).
+6. **Plantillas de proyecto**: crear un proyecto copiando de otro los estados, transiciones, tipos, áreas,
+   automatizaciones y etiquetas.
+7. **Sincronizar con issues de Gitea o GitHub**: hoy los commits y PR se enlazan a tickets; además, que un issue del
+   repositorio cree o actualice un ticket, y al revés.
+8. **Vistas guardadas en «Mi trabajo»**: montar la portada con filtros guardados de varios proyectos («Bugs críticos de
+   todos mis proyectos», «Lo que revisa QA esta semana»…).
+9. **Exportar e imprimir un sprint o una release**: un PDF con los tickets, su estado y las notas, para un cliente o
+   para archivar.
+10. **Asistente en la web** (la base ya está en el MCP): resumir un ticket largo con sus comentarios; al crear un
+    ticket, sugerir tipo, prioridad y área y avisar si se parece a otro; redactar las notas de versión a partir del
+    borrador. Pendiente de decidir la clave de la API de Claude y su coste.
+11. **Avisos a Discord, Slack o Telegram**: los webhooks salientes mandan JSON en bruto, que esos chats no muestran
+    bien. Una integración por canal (o un formato por destino en los webhooks) mandaría mensajes ya legibles: «Ana
+    movió WEB-12 a En revisión», con enlace.
+12. **Conector de claude.ai**: el MCP necesitaría el flujo OAuth del protocolo, y Pireon publicar su metadata de
+    autorización y admitir el registro dinámico de clientes.
+
+### Otras ideas apuntadas, sin decidir
+
+- **Resumen diario por correo**: lo asignado, lo que vence hoy y lo que ha cambiado en lo que sigues, en un solo correo.
+- **Tickets recurrentes**: «revisar copias cada lunes», creados solos con la plantilla del tipo.
+- **Crear tickets por correo**: una dirección por proyecto; lo que llega es un ticket (con adjuntos) y las respuestas,
+  comentarios. Necesita un buzón de entrada.
+- **Tiempo en cada estado**: cuánto pasa un ticket en «En revisión» o «En QA», y dónde se atascan.
+- **Página pública de novedades**: las notas de versión publicadas en una página por proyecto, con RSS.
 
 ## 10.4 Descartado por ahora
 
@@ -68,3 +102,5 @@ Mucho trabajo para lo que aportan hoy; se pueden recuperar si alguien los necesi
 - Ids: `uuid` en todas las tablas de Postgres (el orden de los eventos en `seq`) y, en Mongo, `id` con el uuid del
   dominio más el `_id` `ObjectId` propio.
 - Enlazar tickets y colgar de un padre eligiendo en un selector con búsqueda; casillas de `@pi/ui` en toda la web.
+- Mover tickets entre releases: «Release…» en la edición en bloque, filtro por release en la lista (también desde cada
+  release, «Ver en la lista»), y al archivar una release, elegir adónde va lo pendiente.