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/02-arquitectura.md

@@ -160,7 +160,7 @@ uno y esperando. Así heredan las garantías del bridge: orden, reintento y nada
 | ---------------------- | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `ProjectDeletionSaga`  | `ProjectDeletedEvent`                      | `DeleteIssueCommand` por cada ticket, `DeleteReleaseCommand` por cada release y `DeleteSprintCommand` por cada sprint del proyecto                         |
 |                        | `IssueDeletedEvent`                        | `PurgeCommentCommand` por cada comentario, `DropLinksToIssueCommand` en los tickets que lo enlazaban y `DetachFromParentCommand` en los que colgaban de él |
-| `ReleaseArchivedSaga`  | `ReleaseArchivedEvent`                     | `DetachIssueFromReleaseCommand` para sus tickets sin terminar (los terminados se quedan)                                                                   |
+| `ReleaseArchivedSaga`  | `ReleaseArchivedEvent`                     | `DetachIssueFromReleaseCommand` para sus tickets sin terminar, a la release elegida al archivar o a ninguna (los terminados se quedan)                     |
 | `SprintCarryOverSaga`  | `SprintClosedEvent` / `SprintDeletedEvent` | `CarryOverIssueCommand`: lo pendiente pasa al sprint elegido o al backlog; al borrar, todos vuelven al backlog                                             |
 | `CommentersFollowSaga` | `CommentAddedEvent`                        | `WatchIssueCommand`: quien comenta pasa a seguir el ticket                                                                                                 |
 | `PeopleFollowSaga`     | `IssueCreatedEvent`, `IssueAssignedEvent`  | `WatchIssueCommand`: quien abre el ticket y quien lo tiene asignado pasan a seguirlo                                                                       |

docs/03-api.md

@@ -214,6 +214,9 @@ stateDiagram-v2
   `unassign`, sprint o `noSprint`, release o `noRelease`, prioridad, etiquetas que añadir) a hasta 100 tickets. Cada
   uno pasa por los comandos normales (permisos, flujo, sprints y releases abiertos) y puede negarse sin parar al resto;
   la respuesta dice cuáles.
+- **Archivar una release**: `archiveRelease(releaseId, moveTo)` / `POST /api/releases/{id}/archive` (`{ moveTo }`).
+  Sus tickets sin terminar pasan a `moveTo` (otra release abierta del mismo proyecto) o, sin él, se quedan sin release;
+  los terminados se quedan, como registro de lo que salió. Igual que al cerrar un sprint con `carryOverTo`.
 - **Plantillas por tipo**: en la configuración, cada tipo de ticket puede llevar `template` con una descripción
   (hasta 5000 caracteres) y una checklist (hasta 20 pasos). Al crear un ticket de ese tipo, la descripción se usa si
   llega vacía y los pasos se añaden siempre (las importaciones no aplican plantillas).

docs/09-mcp.md

@@ -80,7 +80,7 @@ flowchart LR
 |              | `create_release` / `update_release`                                      | Planificar una release o cambiar su nombre, descripción o fecha                                   |
 |              | `draft_release_notes` / `set_release_notes`                              | Borrador de las notas desde los tickets terminados, y guardarlas                                  |
 |              | `publish_release`                                                        | Publicar (con `force` si quedan tickets sin terminar)                                             |
-|              | `archive_release`                                                        | Archivar una release que no saldrá (sus tickets la dejan)                                         |
+|              | `archive_release`                                                        | Archivar una release que no saldrá; lo pendiente pasa a `moveTo` (otra release abierta) o la deja |
 
 Las de lectura van marcadas como `readOnlyHint`, para que el cliente no pida confirmación al usarlas, y las que borran o
 archivan, como `destructiveHint`, para que la pida. Lo que es de administración (miembros, configuración, visibilidad,

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.