specrails-desktop 2.64.2 → 2.65.1

package/docs/guide/es/pipeline/1-rails-and-jobs.md

@@ -1,4 +1,4 @@
-# Rails y jobs
+# Rails y trabajos
 
 Ya tienes specs en el tablero. Aquí es donde se convierten en código. Un **rail** es el carril que lleva una spec a través de todo el pipeline — Architect → Developer → Reviewer → Ship — ejecutando agentes de IA reales para tu proyecto. En esta página verás cómo lanzar un rail, la ejecución en paralelo y cómo seguir el trabajo en vivo.
 
@@ -32,30 +32,31 @@ Eso es todo. El rail arranca un proceso de la CLI de IA en el contexto de ejecuc
 
 | Control | Qué hace |
 |---------|--------------|
-| **Pastilla de estado** | `idle`, `running` o `failed`. No hay un estado "completed" aparte — un rail vuelve a `idle` cuando su job termina limpiamente. |
+| **Pastilla de estado** | `idle`, `running` o `failed`. No hay un estado "completed" aparte — un rail vuelve a `idle` cuando su trabajo termina limpiamente. |
 | **Lista de specs** | Los IDs asignados a este rail. Arrastra más para añadirlas, o sácalas para desvincularlas. |
 | **Selector de Loop** | El Loop que ejecuta este rail — uno integrado (`Implement` / `Freestyle` / `SDD Quick (OpenSpec)`) o un loop personalizado. Mira la tabla de más abajo. Se recuerda por rail. |
 | **Selector de perfil** | Qué perfil del proveedor se ejecuta (rails Claude). |
 | **Selector de motor** | Qué proveedor ejecuta el rail — Claude o Codex. |
 | **▶ Play / ■ Stop** | Iniciar o cancelar. |
 
-### Qué ejecuta un rail: Loops
+### Qué ejecuta un rail: Loops {#rail-loops}
 
 Un rail ejecuta un **Loop** — la receta del trabajo. Dos loops están **integrados** y cubren los casos comunes:
 
 | Loop integrado | Comando | Qué hace |
 |------|---------|--------------|
-| **Implement** | `/specrails:implement` | Un job que cubre todas las specs del rail. Ejecuta el pipeline completo Architect → Developer → Reviewer → Ship. El predeterminado del día a día. |
+| **Implement** | `/specrails:implement` | Un trabajo que cubre todas las specs del rail. Ejecuta el pipeline completo Architect → Developer → Reviewer → Ship. El predeterminado del día a día. |
+| **Freestyle** | Freestyle | El proveedor del rail implementa cada spec de forma autónoma, **sin** el pipeline; después la verificación y el Loop Decider la refinan hasta que todo pasa. Una ejecución independiente por spec. Funciona con Claude, Codex, Gemini, Kimi y motores locales; el chat interactivo dentro del trabajo es solo de Claude. |
 
-Para ejecutar varias specs, pon las relacionadas (hasta 3) en un mismo rail — `Implement` las ejecuta como un único job conjunto — o reparte las independientes entre varios rails: cada rail con git se ejecuta en paralelo en su propio worktree aislado.
+Para ejecutar varias specs, pon las relacionadas (hasta 3) en un mismo rail — `Implement` las ejecuta como un único trabajo conjunto — o reparte las independientes entre varios rails: cada rail con git se ejecuta en paralelo en su propio worktree aislado.
 
 Los integrados también se pueden editar: edita uno en el Loop Builder y publícalo, y todos los rails que lo eligen ejecutan tu versión (usa **Restaurar original** para volver atrás).
 
 Más allá de los integrados, puedes **construir tus propios loops** — repetir un ciclo verify → fix → verify hasta cumplir un objetivo, encadenar comandos de shell entre pasos de IA y más. Esos loops personalizados aparecen en el mismo selector de Loop. Esa es la siguiente gran idea: [El Loop Builder](the-loop-builder).
 
-## La cola de jobs
+## La cola de trabajos
 
-Cada vez que pulsas Play, la ejecución del rail se convierte en un **job**. La regla más importante que debes interiorizar:
+Cada vez que pulsas Play, la ejecución del rail se convierte en un **trabajo**. La regla más importante que debes interiorizar:
 
 > **Los rails se ejecutan en paralelo.** Cada lanzamiento respaldado por git aísla su trabajo en un worktree de git por spec, así que varios rails pueden ejecutarse a la vez dentro del mismo proyecto sin pisarse. El trabajo nuevo termina en una tarjeta de decisión **En revisión**, donde puedes crear una draft PR o descartarlo; el trabajo de seguimiento para una spec que ya tiene una PR abierta continúa esa rama de PR en lugar de empezar otra vez desde la rama de integración.
 
@@ -67,15 +68,15 @@ No hay ninguna palanca global de concurrencia que ajustar. El único freno autom
 
 ## Verlo en marcha
 
-Encuentra todos los jobs en **Jobs**, en la barra lateral derecha del proyecto — una lista de tarjetas, la más reciente primero. Cada tarjeta muestra una insignia de estado, la insignia de perfil, una insignia de prioridad, la duración, el coste y el comando lanzado. Encima de la lista:
+Encuentra todos los trabajos en **Trabajos**, en la barra lateral derecha del proyecto — una lista de tarjetas, la más reciente primero. Cada tarjeta muestra una insignia de estado, la insignia de perfil, una insignia de prioridad, la duración, el coste y el comando lanzado. Encima de la lista:
 
-- **Chips de filtro por estado** — muestra solo los jobs en un estado concreto.
+- **Chips de filtro por estado** — muestra solo los trabajos en un estado concreto.
 - **Filtro por rango de fechas** — acota a una ventana temporal.
-- **Comparar** — elige dos jobs y velos lado a lado.
+- **Comparar** — elige dos trabajos y velos lado a lado.
 
-Pulsa cualquier tarjeta para abrir la **vista de detalle del job**, donde están el log en streaming en vivo y las métricas en vivo — y donde, en los jobs de Claude, un compositor de chat te permite **hacerle preguntas al agente en marcha o dirigirlo a mitad de ejecución** sin detener nada. Eso es la página siguiente: [La vista de detalle del job](the-job-detail-view).
+Pulsa cualquier tarjeta para abrir la **vista de detalle del trabajo**, donde están el log en streaming en vivo y las métricas en vivo — y donde, en los trabajos de Claude, un compositor de chat te permite **hacerle preguntas al agente en marcha o dirigirlo a mitad de ejecución** sin detener nada. Eso es la página siguiente: [La vista de detalle del trabajo](the-job-detail-view).
 
-## Cancelar un job
+## Cancelar un trabajo
 
 Pulsa **■ Stop** en la cabecera del rail. La app envía `SIGTERM` al subproceso, espera **5 segundos** a que salga limpiamente y luego le aplica `SIGKILL`. No queda nada a medio arrancar.
 
@@ -87,8 +88,27 @@ Si algo parece ir mal:
 - **Pausa automática por presupuesto** — fija un presupuesto diario y la cola se pausará sola cuando el gasto de ese día llegue al tope.
 - **Todo** — cierra la app de escritorio o ejecuta `specrails-desktop stop`.
 
+## Integrar en local con cambios sin commit
+
+**Integrar en local** fusiona una entrega aprobada en tu rama de integración (por ejemplo `main`) en este ordenador, sin PR. No necesitas tener el checkout limpio:
+
+- Los cambios sin commit que no tocan los archivos entregados se quedan tal cual.
+- Si tus cambios tocan los mismos archivos, Specrails los guarda en un git stash llamado `specrails: before integrating #N (…)`, integra y los vuelve a poner. El aviso dice *Guardé tus cambios locales, integré #N y los restauré.*
+- Si al volver a ponerlos hay conflictos con el código integrado, Specrails deja la rama exactamente como se integró y **conserva el stash**: no se pierde nada. La tarjeta muestra *Tus cambios locales están guardados en un stash* con los archivos en conflicto, **Restaurar mis cambios** (reintenta, por ejemplo después de cambiar el código) y el nombre del stash para copiarlo. Después Specrails los restaura por sí mismo en una rama nueva `specrails/restore-local-<id>`, en un worktree aparte: si allí se aplican sin conflictos, hace commit; si no, un resolvedor de conflictos con IA trabaja solo dentro de ese worktree, conservando tu intención y el código integrado, y Specrails hace commit del resultado. La tarjeta lista los archivos restaurados; **Traerlos de vuelta a <rama>** los pasa a tu rama (solo entonces se descarta el stash) y **Descartar la rama restaurada** elimina la rama y conserva el stash. A una misión solo se le informa de lo ocurrido; nunca tiene que ejecutar nada. Las skills y comandos de OpenSpec que genera Specrails (por ejemplo `.claude/skills/openspec-*/SKILL.md`) no cuentan como cambios tuyos: ante un conflicto conservan la versión integrada.
+- Los archivos ignorados nunca se guardan en el stash: si alguno choca con la entrega, Specrails te pide que lo muevas antes.
+- Si la app se detiene entre guardar y restaurar, restaura tus cambios la próxima vez que se abra el proyecto (solo si sigue en la misma rama).
+
+## Previsión de tiempo y coste {#launch-forecast}
+
+Antes de pulsar Lanzar, un rail puede mostrar cuánto suelen tardar las ejecuciones como esta y, cuando tiene sentido, cuánto suelen costar, por ejemplo *Normalmente 6–9 min · $2–4 en ejecuciones como esta*.
+
+El rango es la mitad central de tu propio historial: del percentil 25 al 75 de las ejecuciones completadas en este proyecto con el mismo loop o comando y el mismo motor. Necesita al menos 5 ejecuciones comparables. Hasta entonces la línea dice *Aún no hay suficiente historial* en lugar de adivinar. Solo se usan costes que informó el proveedor; los costes estimados se dejan fuera. Es una estimación, nunca una factura.
+
+La cifra en dólares solo aparece cuando se sabe que el motor factura por uso (por ejemplo, una clave de API). Con un plan de suscripción, o mientras aún no se conoce el modo de facturación, solo se muestra el tiempo. Si el rail tiene varias specs, el rango es para una spec y lo dice con *(por spec)*. Si el gasto de hoy más el extremo alto del rango pudiera alcanzar tu presupuesto diario, la línea añade *Puede pausarse por presupuesto* con un enlace a los ajustes de presupuesto. Si el presupuesto de hoy ya está agotado, Lanzar te pide confirmar antes, porque la ejecución se pausaría hasta que se restablezca.
+
+
 ## A dónde ir después
 
 - [El Loop Builder](the-loop-builder) — qué ejecuta un rail y cómo construir tus propios loops.
-- [La vista de detalle del job](the-job-detail-view) — fases, métricas en vivo, tarjetas de ticket.
+- [La vista de detalle del trabajo](the-job-detail-view) — fases, métricas en vivo, tarjetas de spec.
 - [Elegir un motor por rail](picking-an-engine-per-rail) — Claude o Codex.

package/docs/guide/es/pipeline/2-the-job-detail-view.md

@@ -1,28 +1,28 @@
-# La vista de detalle del job
+# La vista de detalle del trabajo
 
-Pulsa cualquier tarjeta de job en la página **Jobs** y aterrizas aquí: la cabina de mando de una ejecución de rail concreta. Está construida en torno a una promesa — **los números en vivo que ves son reales, nunca estimaciones.** En esta página recorremos las fases, las métricas en vivo, las tarjetas de ticket — y el compositor que te permite **hablar con el job en marcha**.
+Pulsa cualquier tarjeta de trabajo en la página **Trabajos** y aterrizas aquí: la cabina de mando de una ejecución de rail concreta. Está construida en torno a una promesa — **los números en vivo que ves son reales, nunca estimaciones.** En esta página recorremos las fases, las métricas en vivo, las tarjetas de spec — y el compositor que te permite **hablar con el trabajo en marcha**.
 
 ## La distribución
 
-Dos paneles se sitúan encima del log completo en streaming; en un job de Claude en ejecución, un compositor de chat se sitúa debajo:
+Dos paneles se sitúan encima del log completo en streaming; en un trabajo de Claude en ejecución, un compositor de chat se sitúa debajo:
 
 ```
 ┌─────────────────────────────────────────────┐
 │  Cabecera de estado  (icono · duración en vivo · …)  │
 ├─────────────────────────────────────────────┤
-│  Cabecera de tickets  ( #12  #14  #15 )     │
+│  Cabecera de specs  ( #12  #14  #15 )     │
 ├─────────────────────────────────────────────┤
 │                                             │
 │  Log en streaming  (auto-scroll · búsqueda · …)  │
 │                                             │
 ├─────────────────────────────────────────────┤
-│  Compositor  (envía un mensaje al job · …)  │
+│  Compositor  (envía un mensaje al trabajo · …)  │
 └─────────────────────────────────────────────┘
 ```
 
 ## Fases del pipeline
 
-Para los jobs `Implement`, la ejecución avanza por las fases que define el slash command — por defecto:
+Para los trabajos `Implement`, la ejecución avanza por las fases que define el slash command — por defecto:
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -37,31 +37,31 @@ Cada fase es un agente especializado que el motor del rail invoca en el director
 | **Reviewer** | `sr-reviewer` | Revisa el resultado. |
 | **Ship** | (varía) | Cierre final: tests, commit, borrador de PR. |
 
-Qué agente se encarga de cada fase lo decide el **perfil de agentes** del proyecto. El trío base (`sr-architect`, `sr-developer`, `sr-reviewer`) está siempre presente; las reglas de enrutamiento de un perfil pueden añadir agentes o cambiar cuál ejecuta una fase. La barra de progreso de fases solo aparece cuando el comando define realmente fases — los jobs de Freestyle (que se saltan el pipeline) no mostrarán ninguna.
+Qué agente se encarga de cada fase lo decide el **perfil de agentes** del proyecto. El trío base (`sr-architect`, `sr-developer`, `sr-reviewer`) está siempre presente; las reglas de enrutamiento de un perfil pueden añadir agentes o cambiar cuál ejecuta una fase. La barra de progreso de fases solo aparece cuando el comando define realmente fases — los trabajos de Freestyle (que se saltan el pipeline) no mostrarán ninguna.
 
 ## Métricas en vivo — honestas por diseño
 
-La cabecera de estado es el titular. Muestra un icono de estado, una línea de actividad que describe qué está haciendo el job *ahora mismo*, un recuento de pasos dados y una fila de métricas:
+La cabecera de estado es el titular. Muestra un icono de estado, una línea de actividad que describe qué está haciendo el trabajo *ahora mismo*, un recuento de pasos dados y una fila de métricas:
 
 | Métrica | Cuándo ves el valor real |
 |--------|------------------------------|
-| **Duración** | **En vivo.** Un contador de 1 segundo va sumando mientras el job se ejecuta — este es el único número genuinamente en vivo. |
+| **Duración** | **En vivo.** Un contador de 1 segundo va sumando mientras el trabajo se ejecuta — este es el único número genuinamente en vivo. |
 | **Turnos** | Se deriva de forma incremental a partir de los eventos de assistant en streaming según van llegando. |
 | **Tokens** | Se agrega de forma incremental desde el mismo stream (tolerante con eventos a los que les faltan los campos de uso). |
-| **Coste** | Se muestra como `—` hasta que el job termina, y entonces se revela como el `total_cost_usd` autoritativo. |
+| **Coste** | Se muestra como `—` hasta que el trabajo termina, y entonces se revela como el `total_cost_usd` autoritativo. |
 
-El principio de diseño: **ningún número aproximado o estimado a media ejecución.** La duración es real porque es simplemente un reloj. Los turnos y los tokens se acumulan a partir de actividad real en streaming. El coste, deliberadamente, *no* se estima mientras se ejecuta — se muestra como pendiente y solo se resuelve a su cifra final y autoritativa cuando el proveedor la reporta al terminar el job. Si un número parece estar esperando, es intencionado — te estamos mostrando la verdad, no una proyección.
+El principio de diseño: **ningún número aproximado o estimado a media ejecución.** La duración es real porque es simplemente un reloj. Los turnos y los tokens se acumulan a partir de actividad real en streaming. El coste, deliberadamente, *no* se estima mientras se ejecuta — se muestra como pendiente y solo se resuelve a su cifra final y autoritativa cuando el proveedor la reporta al terminar el trabajo. Si un número parece estar esperando, es intencionado — te estamos mostrando la verdad, no una proyección.
 
-La etiqueta y el icono de la cabecera se corresponden con el estado del job, y el panel se renderiza igual para los jobs `running`, `completed` y `failed` — así, la vista de detalle de un job terminado muestra las mismas métricas congeladas en sus valores finales.
+La etiqueta y el icono de la cabecera se corresponden con el estado del trabajo, y el panel se renderiza igual para los trabajos `running`, `completed` y `failed` — así, la vista de detalle de un trabajo terminado muestra las mismas métricas congeladas en sus valores finales.
 
-## Las tarjetas de ticket
+## Las tarjetas de spec
 
-La **cabecera de tickets** se sitúa entre la cabecera de estado y el log. Es una tarjeta de identidad premium que muestra un chip por cada spec que tocó el job — extraídos del comando lanzado, así que reflejan exactamente qué tickets abarcó esta ejecución.
+La **cabecera de specs** se sitúa entre la cabecera de estado y el log. Es una tarjeta de identidad premium que muestra un chip por cada spec que tocó el trabajo — extraídas del comando lanzado, así que reflejan exactamente qué specs abarcó esta ejecución.
 
-- **2–3 tickets** — se muestran como una lista de chips.
+- **2–3 specs** — se muestran como una lista de chips.
 - **4 o más** — se colapsan en un modo compacto `+ N más` con un chevron para expandir, así la cabecera se mantiene ordenada.
 
-Pulsar un chip abre el detalle de esa spec **sobre la página del job** — no pierdes tu sitio ni cambias de ruta. Es una forma rápida de releer qué se supone que tiene que entregar un job mientras lo ves trabajar. (En pantallas de ancho de tablet incluso puedes arrastrar a un lado un modal de ticket para comparar dos specs lado a lado.)
+Pulsar un chip abre el detalle de esa spec **sobre la página del trabajo** — no pierdes tu sitio ni cambias de ruta. Es una forma rápida de releer qué se supone que tiene que entregar un trabajo mientras lo ves trabajar. (En pantallas de ancho de tablet incluso puedes arrastrar a un lado un modal de spec para comparar dos specs lado a lado.)
 
 ## El log en streaming
 
@@ -75,29 +75,29 @@ Esta es la verdad en bruto de lo que está haciendo la IA — cada llamada a una
 
 ## Ejecuciones de loop: el explorador de pasos
 
-Cuando el job es una **ejecución de loop** (ver [El Loop Builder](the-loop-builder)), el log plano deja paso a un **explorador de pasos** que refleja la forma real del loop:
+Cuando el trabajo es una **ejecución de loop** (ver [El Loop Builder](the-loop-builder)), el log plano deja paso a un **explorador de pasos** que refleja la forma real del loop:
 
 - **La franja de resumen** de arriba es el mapa en vivo del loop — un chip por nodo (Paso de IA, Shell, Loop Decider…), en el orden en que fluye el grafo. Los chips se van encendiendo según avanza la ejecución: atenuados mientras esperan, con pulso mientras corren, y después un check o una cruz. El chip de un Decider muestra además el veredicto por el que enrutó — volver atrás o seguir adelante — y un contador de iteraciones (`Iteración 3/10`) lleva la cuenta a la derecha. Pulsa cualquier chip para saltar directo al último paso de ese nodo.
 - **Una caja plegable por paso.** Cada pasada sobre un nodo se convierte en su propia sección, con el número de paso, su nombre, una insignia de iteración, su duración al terminar — y su propio botón de copiar, para que te lleves exactamente la salida de un paso. (El copiar de la barra superior sigue llevándose el log entero.) Todo lo impreso antes del primer paso — el banner de arranque, el aviso de worktree — queda recogido en una sección de **Preparación**.
 - **El modo seguimiento** viene activado por defecto: el paso en ejecución permanece abierto y con auto-scroll mientras los anteriores se pliegan para no estorbar. En cuanto subes el scroll o abres un paso antiguo, el seguimiento se pausa para que puedas leer — una píldora flotante **Reanudar seguimiento** te devuelve al directo. **Expandir todo / Contraer todo** viven en la barra superior, y escribir en el buscador busca en todos los pasos a la vez.
 - **Los pasos interrumpidos también son honestos.** Un paso que nunca llegó a reportar su resultado — la ejecución se canceló o la app se cerró a mitad de paso — se marca como **Interrumpido** con un borde discontinuo, en lugar de fingir que terminó.
 
-Todo lo demás de esta página funciona exactamente igual en las ejecuciones de loop — las métricas en vivo, las tarjetas de ticket, el compositor. Los jobs que no son de loop conservan el log en streaming clásico de arriba.
+Todo lo demás de esta página funciona exactamente igual en las ejecuciones de loop — las métricas en vivo, las tarjetas de spec, el compositor. Los trabajos que no son de loop conservan el log en streaming clásico de arriba.
 
-## Habla con el job en marcha
+## Habla con el trabajo en marcha
 
-Todo job de Claude se ejecuta por defecto como una **sesión en vivo**, así que un compositor de chat se sitúa al pie de esta página — y del modal de job en modo misión. Úsalo para preguntarle algo al agente en marcha («¿por qué falló ese test?») o para dirigirlo a mitad de ejecución («salta el refactor, céntrate en el fix»).
+Todo trabajo de Claude se ejecuta por defecto como una **sesión en vivo**, así que un compositor de chat se sitúa al pie de esta página — y del modal de trabajo en modo misión. Úsalo para preguntarle algo al agente en marcha («¿por qué falló ese test?») o para dirigirlo a mitad de ejecución («salta el refactor, céntrate en el fix»).
 
 Algunas cosas que conviene saber:
 
-- **Los mensajes se encolan, no interrumpen.** Envía mientras el agente está transmitiendo y tu mensaje espera su turno — se ejecuta como el siguiente prompt, y el job sigue con su plan. Un pequeño contador muestra cuántos mensajes hay en cola.
+- **Los mensajes se encolan, no interrumpen.** Envía mientras el agente está transmitiendo y tu mensaje espera su turno — se ejecuta como el siguiente prompt, y el trabajo sigue con su plan. Un pequeño contador muestra cuántos mensajes hay en cola.
 - **La línea de totales es real.** El compositor muestra un resumen en vivo `N turnos · $X`, sumado a partir del uso real de cada turno completado — coherente con la promesa de esta página de no adivinar nada.
-- **Dos formas de terminar una sesión.** La mayoría de los jobs **terminan solos**: en cuanto un turno acaba sin mensajes en cola, la sesión se asienta y el job se completa — tus mensajes son dirección opcional, nunca una obligación. Una acción discreta **Terminar ahora** la cierra antes con todo lo producido hasta el momento. Los jobs **Freestyle** son la excepción: quedan a la espera entre turnos hasta que tú pulsas **Finalize** — ese es su diseño, una sesión de ida y vuelta que cierras cuando terminas.
+- **Dos formas de terminar una sesión.** La mayoría de los trabajos **terminan solos**: en cuanto un turno acaba sin mensajes en cola, la sesión se asienta y el trabajo se completa — tus mensajes son dirección opcional, nunca una obligación. Una acción discreta **Terminar ahora** la cierra antes con todo lo producido hasta el momento. Los trabajos **Freestyle** son la excepción: quedan a la espera entre turnos hasta que tú pulsas **Finalize** — ese es su diseño, una sesión de ida y vuelta que cierras cuando terminas.
 - **En un loop, los mensajes van al paso activo.** En un loop propio o integrado, tu mensaje llega al **paso de IA que está corriendo en ese momento**. Entre pasos (mientras el Loop Decider piensa, o corre un comando de shell) el compositor muestra un breve estado *«Esperando el siguiente paso…»* — tu texto redactado se conserva, y el envío se reactiva cuando arranca el siguiente paso de IA. **Asentar este paso** cierra el paso actual antes de tiempo y deja que el loop avance con lo que produjo.
 
 ## Exportar diagnóstico
 
-Si la [telemetría](../settings/customizing) estaba activada para el job, aparece un botón **Exportar diagnóstico** en la cabecera. Descarga un ZIP que contiene:
+Si la [telemetría](../settings/customizing) estaba activada para el trabajo, aparece un botón **Exportar diagnóstico** en la cabecera. Descarga un ZIP que contiene:
 
 - `job-metadata.json` — comando, estado, perfil, plugins.
 - `telemetry.ndjson` — señales OTLP/JSON sin comprimir.
@@ -107,10 +107,22 @@ Si la [telemetría](../settings/customizing) estaba activada para el job, aparec
 
 Práctico para compartir una ejecución con un compañero o para abrir un informe de bug preciso.
 
+## Cuando una ejecución falla
+
+Cuando un trabajo falla, se detiene o queda bloqueado, el estado final empieza con una **tarjeta de diagnóstico** que cuenta qué pasó en lenguaje claro, por ejemplo *Las pruebas fallaron en la fase Reviewer tras 4 rondas de correcciones*, y por qué cuando la app lo sabe:
+
+- **Pruebas fallidas**: las comprobaciones siguen fallando tras las rondas de correcciones.
+- **Límite del proveedor**: se alcanzó el límite de uso del proveedor de IA. La tarjeta cita cuándo se restablece, con las palabras del propio proveedor.
+- **Entorno**: la máquina no puede ejecutar las comprobaciones (credenciales, una herramienta que falta, un comando de preparación que falla). *Arreglar el entorno* muestra exactamente qué ejecutar o cambiar.
+- **Bloqueada**, **sin tiempo**, **en silencio** y **detenida inesperadamente** nombran el límite o el proceso que paró la ejecución.
+- **Causa desconocida**: la app no adivina. Muestra el final del registro para que lo leas tú.
+
+Bajo el diagnóstico hay hasta tres remedios ordenados, y solo los que pueden funcionar aquí: **Reanudar desde** la fase que se detuvo, **Ejecutar de nuevo**, **Editar la spec y relanzar** (los anexos de la spec llevan tu cambio a la siguiente ejecución), **Arreglar el entorno** y **Abrir el registro en el fallo**. La misma causa aparece como una etiqueta de una línea en la [lista de pendientes](../getting-started/the-dashboard-tour) y la tarjeta de ejecución de la misión muestra la misma tarjeta.
+
 ## A dónde ir después
 
-- [Rails y jobs](rails-and-jobs) — lanzamiento y encolado.
-- [Seguimiento de costes](../analytics/tracking-cost) — convierte los costes por job en analíticas de proyecto.
+- [Rails y trabajos](rails-and-jobs) — lanzamiento y encolado.
+- [Seguimiento de costes](../analytics/tracking-cost) — convierte los costes por trabajo en analíticas de proyecto.
 
 ## Después de reiniciar un workflow
 
@@ -120,4 +132,4 @@ Cuando un paso de decisión se detiene para preguntar, la reanudación reutiliza
 
 ## Conservación del historial
 
-Las ejecuciones guardadas se conservan indefinidamente por defecto. En **Ejecuciones guardadas → Conservación del historial**, un proyecto puede conservarlas entre 1 y 3650 días. Nada se borra en segundo plano: guarda la política, elige **Previsualizar limpieza** y revisa cada ejecución y su motivo antes de **Eliminar historial caducado**. Una ejecución sigue protegida mientras está activa, espera tu respuesta o aprobación, tiene una escritura interrumpida, una entrega abierta o un fork que aún depende de ella. Solo se elimina el historial de ejecución dentro del almacenamiento de Specrails del proyecto; tu repositorio, los worktrees, el log del job y los registros de coste se conservan. Una ejecución caducada aparece como **Caducado** y ya no se puede reanudar ni bifurcar. Las versiones de Core que aún usa una ejecución conservada nunca se eliminan.
+Las ejecuciones guardadas se conservan indefinidamente por defecto. En **Ejecuciones guardadas → Conservación del historial**, un proyecto puede conservarlas entre 1 y 3650 días. Nada se borra en segundo plano: guarda la política, elige **Previsualizar limpieza** y revisa cada ejecución y su motivo antes de **Eliminar historial caducado**. Una ejecución sigue protegida mientras está activa, espera tu respuesta o aprobación, tiene una escritura interrumpida, una entrega abierta o un fork que aún depende de ella. Solo se elimina el historial de ejecución dentro del almacenamiento de Specrails del proyecto; tu repositorio, los worktrees, el log del trabajo y los registros de coste se conservan. Una ejecución caducada aparece como **Caducado** y ya no se puede reanudar ni bifurcar. Las versiones de Core que aún usa una ejecución conservada nunca se eliminan.

package/docs/guide/es/pipeline/3-reviewing-a-delivery.md

@@ -0,0 +1,43 @@
+<!-- guide-revision: mission-first-v1 -->
+
+# Revisa una entrega en la app {#review-a-delivery}
+
+Una entrega lista para revisar tiene dos vistas: **Resumen** (el veredicto, la evidencia y los botones de decisión) y **Cambios** (lo que la entrega cambió de verdad). Abre la revisión desde el botón **Revisar** de la entrega y elige **Cambios**.
+
+## Lee los cambios
+
+La lista de archivos de la izquierda muestra cada archivo cambiado con su estado (añadido, modificado, eliminado, renombrado), sus recuentos de líneas `+` y `−` y una marca cuando lo das por visto. El diff de la derecha carga un archivo cada vez, así que un cambio grande sigue siendo ágil. Alterna entre las disposiciones **Unificado** y **Dividido**; Specrails recuerda tu elección. Un archivo muy grande muestra sus primeras líneas con **Cargar el diff completo del archivo**; un archivo binario se indica como binario.
+
+Los cambios se miden desde el punto en que la entrega se separó de su rama base, así que lo que llegó a la base después no aparece. Si la entrega aún no tiene una rama combinada, puedes elegir la rama de qué spec leer.
+
+## Notas del revisor sobre el código
+
+Los hallazgos del revisor, los riesgos que señaló y los comentarios de revisión que la ejecución debía resolver aparecen bajo la línea a la que se refieren. Las notas que no nombran archivo ni línea se listan encima de la lista de archivos, así que nada se oculta. Las entregas antiguas, y los revisores que no indicaron un lugar, muestran sus hallazgos en esa lista.
+
+## Pide al agente que cambie algo
+
+Selecciona líneas pulsando sus números (Mayús-clic amplía el rango), elige **Pedir un cambio al agente** y describe el cambio. Specrails lo guarda como feedback de revisión en la spec, con el archivo, el rango de líneas y el código seleccionado, y muestra un mensaje con un enlace a la spec. La próxima ejecución sobre esa spec lo recibirá. Para lanzarla ya, usa **Pedir cambios** en el Resumen. Aquí no hay hilos de comentarios entre personas; habla con tu equipo en GitHub.
+
+## Ábrelo en tu editor
+
+**Abrir en el editor** abre el archivo, en la línea seleccionada, en VS Code, Cursor o un IDE de JetBrains. Elige el editor en **Ajustes → Código → Editor**. El archivo se abre desde tu propia copia del proyecto, donde puede que la rama de la revisión no esté activa.
+
+## Elige qué pasa con una entrega {#pr-decision}
+
+Una ejecución terminada te pide una sola cosa: qué hacer con su resultado. La tarjeta muestra un botón principal para el siguiente paso (crear el PR, publicarlo o verificarlo) y, a su lado, **Revisar**, que abre el paquete de revisión en lenguaje claro. Todo lo demás está en **Más acciones**:
+
+- **Cambiar a la rama** pone la rama en la carpeta de tu proyecto para que la pruebes.
+- **Integrar en local** fusiona el resultado en tu rama base en este equipo. No necesita GitHub y confirmas antes.
+- **Descartar** elimina el resultado y su rama. Confirmas antes.
+
+Si una acción falla, el aviso dice qué no se pudo hacer y ofrece **Reintentar**.
+
+## Teclado
+
+| Tecla | Acción |
+| --- | --- |
+| `j` / `k` | Archivo cambiado siguiente / anterior |
+| `n` / `p` | Nota del revisor siguiente / anterior |
+| `v` | Marcar el archivo como visto |
+
+Las teclas se ignoran mientras escribes en un campo. Marcar un archivo como visto es privado: si el archivo cambia en una revisión posterior, muestra **Cambió desde que lo viste** y vuelve a contar como no visto.

package/docs/guide/es/pipeline/4-picking-an-engine-per-rail.md

@@ -1,6 +1,6 @@
 <!-- guide-revision: mission-first-v1 -->
 
-# Elige proveedor y capacidades
+# Elige proveedor y capacidades {#provider-capabilities}
 
 La configuración depende del proveedor elegido. Un nombre de modelo conocido no implica las mismas opciones de razonamiento, salida estructurada o aprobación en todos ellos.
 
@@ -12,7 +12,7 @@ Claude y Codex usan adaptadores distintos. Las combinaciones incompatibles deben
 
 ## Usa el nivel de control adecuado
 
-El proveedor y modelo del rail controlan su ejecución. Los perfiles y el enrutado por rol dependen del proveedor y del flujo de Core que Desktop instaló en el proyecto: revisa la configuración efectiva.
+El proveedor y modelo del rail controlan su ejecución. Freestyle funciona con todos los proveedores CLI y motores locales; solo Claude añade el chat interactivo dentro del trabajo. Los perfiles y el enrutado por rol dependen del proveedor y del flujo de Core que Desktop instaló en el proyecto: revisa la configuración efectiva.
 
 Para comparar ejecuciones, conserva spec, revisión y criterios de verificación. Distingue costes reportados, estimados y no disponibles. Consulta [perfiles](/docs/agents-profiles-and-the-balanced-default) y [consumo](/docs/insights-analytics-and-cost-tracking).
 

package/docs/guide/es/pipeline/5-the-loop-builder.md

@@ -1,4 +1,4 @@
-# El Loop Builder
+# El Loop Builder {#loop-builder}
 
 ## Workflows de Core
 
@@ -56,7 +56,7 @@ Las aristas conectan los pasos en orden. El **Loop Decider** tiene dos salidas e
 
 Dentro de cualquier AI Step o Decider puedes referenciar:
 
-- **Datos de spec** — `{{spec.title}}`, `{{spec.description}}`, `{{spec.ids}}` (los IDs de ticket del rail). Se rellenan a partir de la(s) spec(s) del rail en tiempo de ejecución.
+- **Datos de spec** — `{{spec.title}}`, `{{spec.description}}`, `{{spec.ids}}` (los IDs de spec del rail). Se rellenan a partir de la(s) spec(s) del rail en tiempo de ejecución.
 - **Comandos mágicos** — `{{cmd:implement}}` y compañía se expanden al comando de pipeline correspondiente.
 - **Constantes** — `{{const:NAME}}` toma de la **biblioteca de constantes** global (arrástralas desde la paleta). Los centinelas integrados, como los marcadores PASS/FAIL de verificación, están siempre disponibles; puedes añadir los tuyos y reutilizarlos en todos los loops.
 
@@ -74,7 +74,7 @@ Un loop que nunca para gastaría dinero para siempre, así que cada ejecución t
 El builder te ayuda a dejar un loop correcto antes de que se ejecute siquiera:
 
 - **Validación en vivo** — los problemas (sin Start, un paso huérfano, un prompt vacío, un Decider con ramas faltantes) se señalan en el lienzo y en un panel de problemas.
-- **Vista previa de dry-run** — resuelve el texto exacto de cada paso (datos de spec, constantes y comandos todos expandidos) **sin lanzar nada**, así que ves con precisión qué enviaría cada paso.
+- **Vista previa de simulación** — resuelve el texto exacto de cada paso (datos de spec, constantes y comandos todos expandidos) **sin lanzar nada**, así que ves con precisión qué enviaría cada paso.
 - **Auto-arrange** — ordena el lienzo en vertical, horizontal o como cuadrícula; tu elección se guarda por loop.
 - **Copiar / pegar** — `Cmd/Ctrl + C` / `V` para copiar pasos dentro de un loop o entre loops.
 - **Importar / exportar** — guarda loops en un archivo `.json` e impórtalos de vuelta (los nombres duplicados se omiten, el resto se importa).
@@ -90,7 +90,7 @@ Para ejecutar un loop personalizado:
 2. En la cabecera del rail, abre el **selector de Loop** y elige tu loop publicado.
 3. Pulsa **▶ Play**.
 
-La ejecución se transmite en vivo en la vista **Jobs** con las mismas métricas y el mismo seguimiento de coste que cualquier trabajo de rail — y su log estrena un **explorador de pasos** dedicado: un mapa en vivo de tu grafo con una caja plegable por paso, que sigue al paso en ejecución mientras el loop avanza (ver [La vista de Detalle del trabajo](the-job-detail-view)). En Claude, cada **Paso de IA** es además una sesión en vivo: envíale mensajes desde el compositor del detalle del job para dirigirlo a mitad de paso (entre pasos el compositor espera brevemente, y **Asentar este paso** hace avanzar el loop con lo que el paso produjo). Un loop que se detiene porque alcanzó su tope de iteraciones o de coste se reporta con ese resultado en lugar de un éxito a secas.
+La ejecución se transmite en vivo en la vista **Trabajos** con las mismas métricas y el mismo seguimiento de coste que cualquier trabajo de rail — y su log estrena un **explorador de pasos** dedicado: un mapa en vivo de tu grafo con una caja plegable por paso, que sigue al paso en ejecución mientras el loop avanza (ver [La vista de Detalle del trabajo](the-job-detail-view)). En Claude, cada **Paso de IA** es además una sesión en vivo: envíale mensajes desde el compositor del detalle del trabajo para dirigirlo a mitad de paso (entre pasos el compositor espera brevemente, y **Asentar este paso** hace avanzar el loop con lo que el paso produjo). Un loop que se detiene porque alcanzó su tope de iteraciones o de coste se reporta con ese resultado en lugar de un éxito a secas.
 
 > **Aviso mientras se ejecuta un loop.** No puedes editar ni borrar un loop mientras una de sus ejecuciones está en curso — detén la ejecución primero.
 

package/docs/guide/es/settings/1-themes.md

@@ -1,4 +1,4 @@
-# Temas
+# Temas {#themes}
 
 Haz que Specrails luzca justo como a ti te gusta. La app trae cinco temas cuidados a mano que puedes alternar al instante: sin reiniciar, sin reconstruir nada, sin configuración de por medio.
 

package/docs/guide/es/settings/3-pipeline-telemetry-and-diagnostics.md

@@ -1,10 +1,10 @@
-# Telemetría del pipeline y diagnósticos
+# Telemetría del pipeline y diagnósticos {#telemetry}
 
 La telemetría registra los diagnósticos del pipeline en local. Está **activada por defecto** en los proyectos sin una preferencia guardada. Puedes desactivarla por proyecto; se respeta cualquier elección guardada explícitamente.
 
 ## Qué es
 
-La telemetría captura señales de diagnóstico estructuradas (trazas, métricas y logs) que el CLI de IA emite mientras ejecuta un job del pipeline. Piénsalo como la caja negra de tus ejecuciones del pipeline: tiempos, uso de tokens y actividad paso a paso, capturados en local para que puedas inspeccionar un job después de los hechos.
+La telemetría captura señales de diagnóstico estructuradas (trazas, métricas y logs) que el CLI de IA emite mientras ejecuta un trabajo del pipeline. Piénsalo como la caja negra de tus ejecuciones del pipeline: tiempos, uso de tokens y actividad paso a paso, capturados en local para que puedas inspeccionar un trabajo después de los hechos.
 
 Está construida sobre **OpenTelemetry**, un formato abierto y estándar, así que los datos no quedan encerrados en una caja propietaria.
 
@@ -16,34 +16,34 @@ La telemetría se configura **por proyecto**:
 2. Localiza el interruptor de **Telemetría del pipeline**.
 3. Actívalo.
 
-A partir de ese momento, los jobs del pipeline de ese proyecto registran telemetría. Los demás proyectos no se ven afectados: cada proyecto decide por sí mismo.
+A partir de ese momento, los trabajos del pipeline de ese proyecto registran telemetría. Los demás proyectos no se ven afectados: cada proyecto decide por sí mismo.
 
 ### Qué se cubre
 
-La telemetría se aplica a los **jobs del pipeline** (las ejecuciones de rail en cola Architect → Developer → Reviewer → Ship). Las sesiones interactivas, como el chat y el asistente de configuración, se dejan fuera a propósito: la telemetría está pensada para las ejecuciones del pipeline, repetibles e inspeccionables, no para conversaciones puntuales.
+La telemetría se aplica a los trabajos que pasan por la **cola de trabajos** del proyecto: las ejecuciones del pipeline de la CLI (los rails cuando los Loops están desactivados y los comandos `implement` enviados desde la CLI `specrails-desktop`). Las ejecuciones de loop —la forma predeterminada en que corren los rails— y las sesiones interactivas como el chat, Explore y las misiones no se instrumentan.
 
 ## Dónde viven los datos
 
-Todo se queda en tu máquina, dentro de tu directorio personal (`~/.specrails/`), nunca en tu repo. Las grabaciones en bruto se guardan comprimidas junto a su job, y las más antiguas se condensan automáticamente en resúmenes compactos al cabo de una semana para mantenerlo todo ordenado. No tienes que gestionar nada de esto a mano.
+Todo se queda en tu máquina, dentro de tu directorio personal (`~/.specrails/`), nunca en tu repo. Las grabaciones en bruto se guardan comprimidas junto a su trabajo, y las más antiguas se condensan automáticamente en resúmenes compactos al cabo de una semana para mantenerlo todo ordenado. No tienes que gestionar nada de esto a mano.
 
 ## Exportar un paquete de diagnóstico
 
-Lo más útil que la telemetría desbloquea es la **exportación de diagnóstico**: un único ZIP que empaqueta todo lo relativo a un job para resolver problemas o compartirlo.
+Lo más útil que la telemetría desbloquea es la **exportación de diagnóstico**: un único ZIP que empaqueta todo lo relativo a un trabajo para resolver problemas o compartirlo.
 
-Cuando un job tiene telemetría registrada, aparece un **botón de exportación** en su tarjeta de job. Pulsa para descargar un ZIP que contiene:
+Cuando un trabajo tiene telemetría registrada, aparece un **botón de exportación** en su tarjeta de trabajo. Pulsa para descargar un ZIP que contiene:
 
-- **`job-metadata.json`** — la identidad y los parámetros del job
+- **`job-metadata.json`** — la identidad y los parámetros del trabajo
 - **`telemetry.ndjson`** — las señales registradas en bruto
 - **`logs.txt`** — la salida de log capturada
 - **`summary.md`** — un resumen legible de la ejecución
 
-Si el proyecto usa plugins, el paquete también incluye una instantánea de qué plugins estuvieron activos en ese job.
+Si el proyecto usa plugins, el paquete también incluye una instantánea de qué plugins estuvieron activos en ese trabajo.
 
 Este es el paquete que conviene tener a mano cuando quieres entender una ejecución espinosa, dejar constancia o pasarle los detalles a alguien que te esté ayudando a depurar.
 
 ## Cómo desactivarla
 
-Vuelve a apagar el interruptor cuando quieras. Los nuevos jobs dejan de registrar de inmediato. Lo que ya se capturó se mantiene en disco hasta que se compacta o eliminas el proyecto: nada se envía a ninguna parte ni se pierde a tus espaldas.
+Vuelve a apagar el interruptor cuando quieras. Los nuevos trabajos dejan de registrar de inmediato. Lo que ya se capturó se mantiene en disco hasta que se compacta o eliminas el proyecto: nada se envía a ninguna parte ni se pierde a tus espaldas.
 
 
 ## Evidencia al finalizar

package/docs/guide/es/settings/5-project-environment.md

@@ -1,4 +1,4 @@
-# Entorno del proyecto
+# Entorno del proyecto {#project-environment}
 
 Algunos proyectos necesitan una credencial al ejecutarse, como `NODE_AUTH_TOKEN` para paquetes privados de npm. En **Ajustes del proyecto → Entorno**, añade los **nombres** de las variables que necesitan tus rails y loops. Specrails guarda solo los nombres, nunca los valores.
 

package/docs/guide/es/settings/6-updates.md

@@ -0,0 +1,24 @@
+# Actualizaciones {#updates}
+
+Specrails mantiene al día dos cosas: la propia app **Specrails Desktop** y el framework **specrails-core** que usan tus proyectos. Ambas están en **Ajustes ▸ Actualizaciones**.
+
+## Canal de actualización
+
+Elige con qué rapidez recibes las versiones nuevas:
+
+- **Última** (predeterminado): cada versión en cuanto se publica. Recibes primero las novedades y las correcciones.
+- **Estable**: solo versiones que pasaron al menos una semana en Última con la CI en verde y que después promovieron los mantenedores. Elígelo si tu equipo prefiere menos actualizaciones y bien probadas.
+
+El canal se aplica a la app y a specrails-core. Si specrails-core aún no tiene versión estable, Core sigue Última y la tarjeta de Core te lo indica.
+
+En Estable, si todavía no se ha promovido ninguna versión, **Buscar actualizaciones** te lo dice en lugar de ofrecerte una versión de Última.
+
+## Cómo llegan las actualizaciones
+
+- **Specrails Desktop** comprueba al arrancar y cada 6 horas. Cuando hay una actualización aparece una tarjeta desde la que descargas, instalas y reinicias. También puedes pulsar **Buscar actualizaciones**.
+- **specrails-core** nunca se actualiza solo. Pulsa **Buscar actualizaciones** en la tarjeta de Core y luego **Actualizar** para instalarlo. Tus proyectos pasan al nuevo framework sin reiniciar la app.
+
+## Conviene saber
+
+- Pasar de Última a Estable nunca te baja de versión. Te quedas en la tuya hasta que Estable la alcance.
+- Todas las actualizaciones se firman y se verifican antes de instalarse, en los dos canales.

package/docs/guide/es/settings/7-existing-projects.md

@@ -0,0 +1,33 @@
+# Trabajar en un proyecto existente {#existing-projects}
+
+Estas funciones ayudan a que las ejecuciones respeten un proyecto que ya existe: lo que una spec deja fuera, las preguntas del arquitecto antes de planificar, qué requisitos demuestra de verdad un test, cómo describir el código antiguo antes de cambiarlo y las reglas que tu equipo ya tiene escritas. Cada una necesita una versión de specrails-core que la soporte; mientras tanto su interruptor aparece desactivado con una nota para actualizar Core.
+
+## Fuera de alcance
+
+Cada spec puede listar lo que deliberadamente **no** cambia. Quick y Explore lo rellenan por ti; en la ventana de la spec aparece como **Fuera de alcance** bajo la descripción, un elemento por línea, y puedes editarlo como cualquier otro campo. Los agentes lo reciben con la spec en cada lanzamiento.
+
+## Preguntas del arquitecto en Jira
+
+En **Ajustes ▸ Anclaje en proyectos existentes**, activa **Publicar las aclaraciones del arquitecto en Jira**. Cuando una ejecución se detiene porque el arquitecto necesita una respuesta, o continúa con supuestos, Specrails los publica como un comentario en la issue de Jira enlazada. Responde a ese comentario en Jira: la respuesta se añade a la spec como aclaración y la siguiente ejecución de la spec la lee. Puedes seguir respondiendo a una ejecución pausada desde la app.
+
+## Requisitos demostrados
+
+Cuando un test nombra el requisito que demuestra (`[spec:<capacidad>/<requisito>]` en su título), la página de revisión muestra **Requisitos demostrados X/Y**: qué requisitos demuestra un test que pasa, cuáles aún no tienen uno y cuáles tocó el propio cambio. Analítica muestra lo mismo por loop. Para que CI falle cuando un requisito cambiado no tiene test, añade `specrails-core pipeline trace --check --tests-passed` después de tus tests.
+
+La biblioteca de loops también ofrece **Barrido de drift**, un loop de solo lectura que compara lo que dice cada spec con lo que hace el código y lista cada contradicción. No cambia nada.
+
+## Baseline al tocar
+
+Activa **Baseline al tocar** para que un cambio que llega a código que ninguna spec describe empiece describiéndolo: tests de cómo se comporta hoy, demostrados sobre el código sin cambios, y una spec breve de lo que existe. La página de revisión muestra **Spec creada por donde pasa el trabajo** con el módulo, los requisitos y los tests, y su coste aparece aparte del cambio. Si esos tests fallan sobre el código sin cambios, la ejecución se detiene antes de editar el módulo y lo indica.
+
+## Reglas del proyecto {#project-rules}
+
+**Ajustes ▸ Reglas del proyecto** lista los checks que tu proyecto ya ejecuta (lint, tipos, tests, CI) y cada regla escrita en ficheros como `CLAUDE.md` o `AGENTS.md`, clasificadas en:
+
+- **Aplicada**: un check ya la garantiza.
+- **Automatizable**: un check podría. **Crear spec** la convierte en spec con un clic.
+- **Solo humana**: alguien tiene que mirarla. Aparecen en cada página de revisión bajo **Requiere ojo humano**.
+
+Las reglas que Core aún no pudo clasificar (por ejemplo, justo después de añadir el proyecto, cuando el inventario se hace sin conexión) aparecen como **Sin clasificar**; **Volver a inventariar** con un proveedor configurado las clasifica.
+
+**Volver a inventariar** actualiza la lista. Cuando un proyecto aún no tiene comandos de verificación, los ajustes del agent runtime ofrecen primero estos checks.

package/docs/guide/es/settings/8-accessibility.md

@@ -0,0 +1,23 @@
+# Accesibilidad y personalización {#accessibility}
+
+Specrails se adapta a tu forma de trabajar. Todo esto está en **Ajustes ▸ Apariencia**, se aplica al instante y se guarda en este ordenador.
+
+## Densidad {#density}
+
+**Cómoda** mantiene las tarjetas y las filas con aire. **Compacta** cabe más en pantalla: el tablero de specs empieza en filas compactas, la lista de trabajos usa filas más ajustadas y la historia del trabajo estrecha su línea de tiempo. Una vista guardada del tablero conserva su propio diseño, así que una vista guardada con tarjetas tipo post-it se abre como tarjetas tipo post-it. Si el tablero de este proyecto ya tiene su propio diseño, **Usarla también en el tablero**, bajo la elección, hace que vuelva a seguir la densidad.
+
+## Reducir movimiento {#reduce-motion}
+
+**Seguir el sistema** respeta tu sistema operativo. **Reducir** desactiva animaciones y transiciones dentro de Specrails diga lo que diga el sistema: la píldora del rail queda quieta en su posición, los puntos en vivo dejan de pulsar y el halo del Builder y los efectos de tema se quedan quietos. **Movimiento completo** anima incluso cuando el sistema pide menos.
+
+## Mover una spec con el teclado {#keyboard-moves}
+
+Enfoca una tarjeta de spec en el tablero (Tab o las flechas) y pulsa **M**. Un pequeño selector lista los estados y los rails; elige uno con las flechas y **Intro**. Hace lo mismo que arrastrar la tarjeta hasta allí, incluidas las specs vinculadas a Jira, que se mueven por tu flujo de Jira. Si la tarjeta forma parte de una selección múltiple (**X** selecciona la tarjeta enfocada), el movimiento se aplica a todas las specs seleccionadas. La paleta de comandos ofrece lo mismo como **Mover la spec enfocada…**. **M** no hace nada mientras escribes en un campo.
+
+## Avisos de ejecución para lectores de pantalla {#live-status}
+
+Specrails anuncia los cambios de las ejecuciones mediante una región en vivo educada, para el proyecto que estás viendo: una ejecución iniciado, en pausa, que te necesita, fallido, terminado o con la revisión lista. Las ráfagas se unen y las repeticiones se descartan, así que un rail ajetreado nunca inunda al lector. Los avisos de deshacer ya se anuncian solos.
+
+## Foco de teclado {#focus}
+
+Cada botón, enlace, elemento de menú, tarjeta y fila de árbol muestra un anillo de foco visible cuando llegas con el teclado. La información que antes vivía solo en un tooltip, como la referencia de la spec en la tira de un rail, también está disponible para quien usa teclado o lector de pantalla.