specrails-desktop 2.57.0 → 2.58.0

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

@@ -18,12 +18,12 @@ SpecsBoard (izquierda)      Rails (derecha)
 
 Un rail es un **carril de ejecución**. Arrastras una tarjeta de spec desde el SpecsBoard hasta un rail y luego pulsas **▶ Play**. En repositorios git, el rail lanza el pipeline en un git worktree aislado para que la IA pueda editar archivos y ejecutar tests sin tocar tu árbol de trabajo activo. Si el proyecto todavía no es un repo git, Specrails degrada claramente a ejecución en la carpeta compartida y te avisa de que no habrá rama ni tarjeta de PR.
 
-Puedes tener varios rails para organizar el trabajo en carriles con nombre (uno para la funcionalidad en la que estás centrado, otro en cola detrás). Los rails son **dinámicos**: el botón **+ Añadir** de la cabecera de Rails crea un carril nuevo (hasta 12 por proyecto) y los carriles vacíos e inactivos se pueden borrar. Cada rail está respaldado por el servidor, así que tu conjunto de carriles sobrevive a las recargas y es visible para el companion móvil y el agente integrado — el agente incluso puede crear un rail por sí mismo cuando todos los carriles están ocupados. Tienes más sobre multi-rail y procesamiento por lotes en [Batch implement y multifuncionalidad](batch-implement-and-multi-feature).
+Puedes tener varios rails para organizar el trabajo en carriles con nombre (uno para la funcionalidad en la que estás centrado, otro en cola detrás). Los rails son **dinámicos**: el botón **+ Añadir** de la cabecera de Rails crea un carril nuevo (hasta 12 por proyecto) y los carriles vacíos e inactivos se pueden borrar. Cada rail está respaldado por el servidor, así que tu conjunto de carriles sobrevive a las recargas y es visible para el companion móvil y el agente integrado — el agente incluso puede crear un rail por sí mismo cuando todos los carriles están ocupados.
 
 ## Lanzar un rail sobre una spec
 
 1. **Arrastra una tarjeta de spec** desde el SpecsBoard hasta un rail. El ID de la spec aparece en la lista de specs del rail. (¿Prefieres no arrastrar? Usa el popover **Mover a rail** en la tarjeta de la spec — muestra un punto de estado por cada rail para que no dejes trabajo en un carril ocupado.)
-2. **Elige un Loop** en la cabecera del rail. Un rail ejecuta un **Loop** — eso es el trabajo que realiza. El predeterminado es el loop `Implement` integrado; también puedes elegir `Batch`, `Freestyle` o un loop personalizado que hayas construido tú mismo. Mira [El Loop Builder](the-loop-builder).
+2. **Elige un Loop** en la cabecera del rail. Un rail ejecuta un **Loop** — eso es el trabajo que realiza. El predeterminado es el loop `Implement` integrado; también puedes elegir `Freestyle` o un loop personalizado que hayas construido tú mismo. Mira [El Loop Builder](the-loop-builder).
 3. **Pulsa ▶ Play.**
 
 Eso es todo. El rail arranca un proceso de la CLI de IA en el contexto de ejecución correcto y empieza el pipeline.
@@ -34,25 +34,28 @@ Eso es todo. El rail arranca un proceso de la CLI de IA en el contexto de ejecuc
 |---------|--------------|
 | **Pastilla de estado** | `idle`, `running` o `failed`. No hay un estado "completed" aparte — un rail vuelve a `idle` cuando su job 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` / `Batch` / `Freestyle`) o un loop personalizado. Mira la tabla de más abajo. Se recuerda por rail. |
+| **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 y Kimi). |
 | **Selector de motor** | Qué proveedor ejecuta el rail — Claude, Codex, Gemini o Kimi. |
 | **▶ Play / ■ Stop** | Iniciar o cancelar. |
 
 ### Qué ejecuta un rail: Loops
 
-Un rail ejecuta un **Loop** — la receta del trabajo. Tres loops están **integrados** y cubren los casos comunes:
+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. |
-| **Batch** | `/specrails:batch-implement` | Un job que recorre las specs del rail de forma secuencial, en oleadas según sus dependencias. Lo mejor para varias specs relacionadas. |
 | **Freestyle** | Freestyle | Claude o Kimi implementan cada spec de forma autónoma, **saltándose** el pipeline. |
 
+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.
+
 Freestyle usa las herramientas nativas y el catálogo de modelos del proveedor.
 Claude tiene transporte interactivo persistente; Kimi usa un proceso agentic
 `kimi -p` sin stdin persistente.
 
+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
@@ -98,5 +101,4 @@ Si algo parece ir mal:
 
 - [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.
-- [Batch implement y multifuncionalidad](batch-implement-and-multi-feature) — ejecuta varias specs a la vez.
 - [Elegir un motor por rail](picking-an-engine-per-rail) — Claude, Codex, Gemini o Kimi.

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

@@ -22,7 +22,7 @@ Dos paneles se sitúan encima del log completo en streaming; en un job de Claude
 
 ## Fases del pipeline
 
-Para los jobs `Implement` y `Batch`, la ejecución avanza por las fases que define el slash command — por defecto:
+Para los jobs `Implement`, la ejecución avanza por las fases que define el slash command — por defecto:
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -113,5 +113,14 @@ Práctico para compartir una ejecución con un compañero o para abrir un inform
 ## A dónde ir después
 
 - [Rails y jobs](rails-and-jobs) — lanzamiento y encolado.
-- [Batch implement y multifuncionalidad](batch-implement-and-multi-feature) — muchas specs, oleadas por dependencias.
 - [Seguimiento de costes](../analytics/tracking-cost) — convierte los costes por job en analíticas de proyecto.
+
+## Después de reiniciar un workflow
+
+Tras una caída, reanuda el workflow guardado con su configuración y repositorios originales. Una escritura interrumpida exige seleccionar el intento exacto después de revisar el diff del worktree. Los pasos completados se conservan. Una llamada al proveedor cuya respuesta se perdió sigue contabilizada como interrumpida y con consumo desconocido; nunca se presenta como gratuita. Si los registros guardados no permiten demostrar la entrega original, la recuperación muestra un error y conserva el worktree.
+
+Cuando un paso de decisión se detiene para preguntar, la reanudación reutiliza la decisión guardada y transmite la respuesta humana al siguiente paso. No vuelve a llamar al modelo para esa misma decisión. Un prompt pausado sí puede necesitar otro turno del modelo para aplicar tu respuesta.
+
+## 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.

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

@@ -22,14 +22,14 @@ El motor seleccionado ejecuta cada fase del pipeline de ese rail. Si la CLI del
 
 ## En qué destaca cada motor
 
-Los cuatro ejecutan **Implement** y **Batch**:
+Los cuatro ejecutan **Implement**:
 
 | Motor | Recurre a él cuando… | Notas |
 |--------|--------------------|-------|
 | **Claude** | Necesitas coste nativo, interacción persistente o políticas de tools estrictas. | Perfiles, Freestyle y transforms estructurados. |
 | **Codex** | Prefieres la CLI de OpenAI Codex o quieres comparar implementaciones entre proveedores. | `codex` ≥ 0.128.0. Sin reporte de coste nativo — la app rellena el coste desde su tarifario. Los perfiles no aplican. |
 | **Gemini** | Quieres la CLI de Gemini de Google, telemetría nativa o una ejecución más barata para specs rutinarias. | `gemini` ≥ 0.11.0 (define `GEMINI_API_KEY`). Telemetría OTLP nativa. Los perfiles no aplican. |
-| **Kimi** | Quieres Kimi agentic para Implement, Batch, Freestyle o loops sin Decider. | `kimi` ≥ 0.27.0 externo; perfiles/roles y effort low/high/max solo para K3; tokens/coste no disponibles. |
+| **Kimi** | Quieres Kimi agentic para Implement, Freestyle o loops sin Decider. | `kimi` ≥ 0.27.0 externo; perfiles/roles y effort low/high/max solo para K3; tokens/coste no disponibles. |
 
 ### Diferencias de capacidad
 

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

@@ -1,6 +1,18 @@
 # El Loop Builder
 
-Un **rail ejecuta un Loop**. Los loops integrados (`Implement`, `Batch`, `Freestyle`) cubren los casos del día a día, pero el **Loop Builder** te permite diseñar el tuyo propio — un editor visual al estilo n8n para automatizaciones que se repiten hasta cumplir un objetivo. Esta página explica qué es un loop, cómo construir uno y cómo ejecutarlo en un rail.
+## Workflows de Core
+
+Con un motor de Core compatible, un canvas nuevo muestra las diecisiete piezas del catálogo instalado. Haz clic o arrastra una pieza al canvas, selecciónala y completa su formulario. Los proveedores y roles pertenecen al proyecto activo. Cada salida indica un resultado posible: conéctala a otra pieza o a Fin. Cada resultado admite una conexión.
+
+El catálogo incluye prompts, turnos de rol, decisiones, condiciones, verificación, shell, validación y archivo de OpenSpec, aprobaciones, preguntas, pausas, mapas, uniones, componentes, implementación y Fin. Los formularios permiten editar campos opcionales, objetos, listas y diccionarios. **Opciones del workflow** incluye límites de tokens y transiciones y políticas de concurrencia. El límite explícito de transiciones cuenta también las visitas dentro de componentes y ramas.
+
+Crea un cuerpo reutilizable en **Componentes**, declara sus variables de entrada y resultados y selecciónalo en una pieza Componente o Mapear. La navegación vuelve al canvas principal sin perder cambios. El Fin de un componente tiene un resultado de negocio y un `exit` opcional que coincide con una salida declarada.
+
+**Publicar** envía el borrador a Core. Los errores aparecen en el panel de problemas y señalan los nodos afectados. El lanzamiento vuelve a validar la configuración efectiva del proyecto. Core controla el formato y su hash. Si no está disponible, actualiza Core; los loops antiguos conservan su editor y ejecución.
+
+Las secciones siguientes describen los nodos antiguos de Desktop y su uso en rails.
+
+Un **rail ejecuta un Loop**. Los loops integrados (`Implement`, `Freestyle`, `SDD Quick (OpenSpec)`) cubren los casos del día a día, pero el **Loop Builder** te permite diseñar el tuyo propio — un editor visual al estilo n8n para automatizaciones que se repiten hasta cumplir un objetivo. Esta página explica qué es un loop, cómo construir uno y cómo ejecutarlo en un rail.
 
 ## Loops y rails — la relación
 
@@ -10,9 +22,8 @@ Un **loop** es la *receta* del trabajo; un **rail** es el *carril* que la ejecut
    Loop Builder (barra lateral izq.)       Rails (derecha)
    ───────────────────────────             ─────────────
    Implement   (integrado)                 Rail 1
-   Batch       (integrado)     elige en ►     Loop: Verify-until-green
-   Freestyle   (integrado)                    ▶ Play
-   Verify-until-green (tuyo)
+   Freestyle   (integrado)     elige en ►     Loop: Verify-until-green
+   Verify-until-green (tuyo)                    ▶ Play
 ```
 
 - Los loops viven en la sección **Loops** (barra lateral izquierda, junto a tus proyectos) — son **globales**, compartidos entre todos los proyectos.
@@ -25,7 +36,7 @@ Así que: construye un loop una vez y luego elígelo en cualquier rail de cualqu
 
 Pulsa **Loops** en la barra lateral izquierda para ver la biblioteca: los tres loops integrados más los tuyos. Abre uno para verlo, o pulsa **New loop** para empezar desde un lienzo en blanco.
 
-No puedes editar fácilmente un integrado directamente — en su lugar, hazle **Fork**. Eso te da una copia editable de un grafo que funciona desde la que partir, que es la forma más fácil de aprender.
+Los loops integrados son loops reales y editables. Ábrelo con **Edit** y cámbialo como cualquier otro loop: al guardar pasa a Borrador y **Publish** aplica tu versión en **todos los rails, lanzamientos desde el chat del agente y Companion que usan ese integrado**. Mientras tu edición sea un Borrador, los rails siguen ejecutando la última versión publicada, así que nada se rompe a mitad de edición. **Restaurar original** (en la tarjeta o en el builder) devuelve el integrado a su versión por defecto; los integrados no se pueden borrar. ¿Prefieres una copia aparte? Usa **Duplicate**: crea un loop normal y deja el integrado intacto.
 
 ## De qué se compone un loop
 
@@ -93,3 +104,17 @@ La ejecución se transmite en vivo en la vista **Jobs** con las mismas métricas
 - [Rails y trabajos](rails-and-jobs) — lanzar rails y la cola de trabajos.
 - [La vista de Detalle del trabajo](the-job-detail-view) — ver una ejecución en vivo.
 - [Elegir un motor por rail](picking-an-engine-per-rail) — el rail (no el loop) elige el proveedor.
+
+Cuando el Core seleccionado expone límites por invocación, las piezas de prompt, rol y decider ofrecen `timeoutMs` e `idleTimeoutMs`. Usa `0` para desactivar ese temporizador del paso, o elimina el campo para heredar el valor predeterminado. Los presupuestos del workflow completo y la cancelación siguen activos. Si una verificación plantea una pregunta bloqueante, espera tu respuesta antes de aceptar un resultado correcto.
+
+Cuando un grafo antiguo guardado se sustituye por primera vez por piezas de Core, se conserva el grafo original. La biblioteca ofrece entonces **Exportar grafo original**. La exportación tiene un nombre distinto para poder importarla como un borrador independiente sin sustituir el workflow actual. La conversión y las ediciones posteriores nunca publican el loop automáticamente.
+
+Usa **Asignar variables** para conservar estado durante una pausa: asigna valores JSON tipados o ajusta un contador entero existente. Esta pieza no realiza llamadas a la IA. Las actualizaciones se guardan juntas; un contador inválido deja todas las variables intactas. Las variables de un componente mapeado permanecen dentro de ese componente.
+
+En un Decider, **Continuar mientras se cumpla esta condición** protege el trabajo obligatorio pendiente. Por ejemplo, `$vars.failedPass == true` convierte una propuesta de detenerse en continuar hasta que el workflow quite esa marca. La decisión se ejecuta igualmente y el trabajo repetido sin cambios sigue sujeto al límite de falta de progreso. Las preguntas humanas siguen pausando la ejecución hasta recibir respuesta.
+
+Para migrar un loop guardado del motor anterior, elige **Convertir a Core** en la biblioteca. Selecciona el repositorio original si un paso shell no tiene un ámbito explícito. La conversión valida el grafo y guarda un borrador con una copia exportable del original. Revisa las conexiones y publica explícitamente. No se pueden convertir loops en ejecución; se conservan las ediciones en conflicto. Los pasos que escriben requieren comandos reales de verificación y Quick SDD utiliza el OpenSpec incluido en Core. Actualiza Core si la conversión no está disponible.
+
+Para ver qué loops guardados necesitan atención, abre **Comprobación de migración a Core** en la biblioteca de loops y elige **Comprobar**. Muestra los loops que el Core instalado rechaza, los que están listos para convertir y los que necesitan un repositorio u otro arreglo. Nunca convierte ni publica nada por su cuenta.
+
+Un Core futuro que solo ejecute flujos de Core no lanzará en un rail un loop sin convertir. Desktop muestra un mensaje que te lleva a **Convertir a Core**, en vez de empezar una ejecución que fallaría a mitad. Las ejecuciones ya iniciadas conservan la versión de Core que las creó.

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

@@ -52,5 +52,4 @@ El historial del loop conserva el resultado final independientemente de la telem
 opcional del proveedor. Separa ejecución, aceptación de Core y entrega, y distingue
 pasos, evaluaciones del decider y turnos del agente. Los tiempos e intentos por fase
 proceden del registro de Core; no se deduce un coste por fase a partir del total. Con
-runtimes antiguos, la evidencia queda como no disponible. Consulta el resultado de
-Implement en la guía de ejecución por lotes.
+runtimes antiguos, la evidencia queda como no disponible.

package/docs/guide/fr/integrations/7-local-engines.md

@@ -15,7 +15,7 @@ Chaque connexion possède aussi un réglage **Boucle de l'agent**. **Compacte**
 
 ## Ce que vous obtenez
 
-- Rails (implement, batch, freestyle, boucles personnalisées), Explore et specs Quick, chat et missions s'exécutent sur le modèle local.
+- Rails (implement, freestyle, boucles personnalisées), Explore et specs Quick, chat et missions s'exécutent sur le modèle local.
 - Les missions conservent leurs outils Specrails et vos serveurs MCP externes.
 - Les sessions reprennent d'un tour à l'autre ; les jobs interactifs fonctionnent.
 - Le coût est honnête : les tokens sont enregistrés, le coût reste *inconnu* sauf si vous saisissez des tarifs (il est alors marqué *estimé*).

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

@@ -18,12 +18,12 @@ SpecsBoard (gauche)         Rails (droite)
 
 Un rail est une **voie d'exécution**. Vous glissez une carte de spec depuis le SpecsBoard sur un rail, puis vous appuyez sur **▶ Play**. Pour les dépôts git, le rail lance le pipeline dans un worktree git isolé afin que l'IA puisse modifier des fichiers et lancer des tests sans toucher à votre arbre de travail actif. Si le projet n'est pas encore un dépôt git, Specrails dégrade clairement vers une exécution dans le dossier partagé et vous indique qu'aucune branche ni carte de PR n'apparaîtra.
 
-Vous pouvez avoir plusieurs rails pour organiser le travail en voies nommées (une pour la fonctionnalité sur laquelle vous êtes concentré, une autre en attente derrière). Les rails sont **dynamiques** : le bouton **+ Ajouter** de l'en-tête Rails crée une nouvelle voie (jusqu'à 12 par projet) et les voies vides et inactives peuvent être supprimées. Chaque rail est adossé au serveur, donc votre ensemble de voies survit aux rechargements et reste visible pour le companion mobile et l'agent intégré — l'agent peut même créer un rail lui-même quand toutes les voies sont occupées. Plus de détails sur le multi-rail et le batching dans [Batch implement et multi-fonctionnalité](batch-implement-and-multi-feature).
+Vous pouvez avoir plusieurs rails pour organiser le travail en voies nommées (une pour la fonctionnalité sur laquelle vous êtes concentré, une autre en attente derrière). Les rails sont **dynamiques** : le bouton **+ Ajouter** de l'en-tête Rails crée une nouvelle voie (jusqu'à 12 par projet) et les voies vides et inactives peuvent être supprimées. Chaque rail est adossé au serveur, donc votre ensemble de voies survit aux rechargements et reste visible pour le companion mobile et l'agent intégré — l'agent peut même créer un rail lui-même quand toutes les voies sont occupées.
 
 ## Lancer un rail sur un spec
 
 1. **Glissez une carte de spec** depuis le SpecsBoard sur un rail. L'ID du spec apparaît dans la liste de specs du rail. (Vous préférez ne pas glisser ? Utilisez le popover **Move to rail** sur la carte de spec — il affiche un point de statut par rail pour que vous ne déposiez pas de travail sur une voie occupée.)
-2. **Choisissez un Loop** dans l'en-tête du rail. Un rail exécute un **Loop** — c'est le travail qu'il effectue. Par défaut, c'est le Loop intégré `Implement` ; vous pouvez aussi choisir `Batch`, `Freestyle`, ou un loop personnalisé que vous avez construit vous-même. Voir [Le Loop Builder](the-loop-builder).
+2. **Choisissez un Loop** dans l'en-tête du rail. Un rail exécute un **Loop** — c'est le travail qu'il effectue. Par défaut, c'est le Loop intégré `Implement` ; vous pouvez aussi choisir `Freestyle`, ou un loop personnalisé que vous avez construit vous-même. Voir [Le Loop Builder](the-loop-builder).
 3. **Appuyez sur ▶ Play.**
 
 Voilà. Le rail démarre un processus AI CLI dans le bon contexte d'exécution et lance le pipeline.
@@ -34,25 +34,28 @@ Voilà. Le rail démarre un processus AI CLI dans le bon contexte d'exécution e
 |---------|--------------|
 | **Pastille de statut** | `idle`, `running`, ou `failed`. Il n'y a pas de « completed » séparé — un rail revient à `idle` quand son job se termine proprement. |
 | **Liste de specs** | Les IDs assignés à ce rail. Glissez-en d'autres, retirez-les pour les détacher. |
-| **Sélecteur de Loop** | Le Loop que ce rail exécute — un intégré (`Implement` / `Batch` / `Freestyle`) ou un loop personnalisé. Voir le tableau ci-dessous. Persisté par rail. |
+| **Sélecteur de Loop** | Le Loop que ce rail exécute — un intégré (`Implement` / `Freestyle` / `SDD Quick (OpenSpec)`) ou un loop personnalisé. Voir le tableau ci-dessous. Persisté par rail. |
 | **Sélecteur de profil** | Quel profil fournisseur s'exécute (rails Claude et Kimi). |
 | **Sélecteur de moteur** | Quel provider exécute ce rail — Claude, Codex, Gemini ou Kimi. |
 | **▶ Play / ■ Stop** | Démarrer ou annuler. |
 
 ### Ce qu'un rail exécute : les Loops
 
-Un rail exécute un **Loop** — la recette du travail. Trois loops sont **intégrés** et couvrent les cas courants :
+Un rail exécute un **Loop** — la recette du travail. Deux loops sont **intégrés** et couvrent les cas courants :
 
 | Loop intégré | Commande | Ce qu'il fait |
 |------|---------|--------------|
 | **Implement** | `/specrails:implement` | Un seul job couvrant tous les specs du rail. Exécute tout le pipeline Architect → Developer → Reviewer → Ship. Le choix par défaut au quotidien. |
-| **Batch** | `/specrails:batch-implement` | Un seul job qui traite les specs du rail séquentiellement, en vagues tenant compte des dépendances. Idéal pour plusieurs specs liés. |
 | **Freestyle** | Freestyle | Claude ou Kimi implémente chaque spec de manière autonome, en **contournant** le pipeline. |
 
+Pour exécuter plusieurs specs, placez les specs liées (jusqu'à 3) sur un même rail — `Implement` les exécute en un seul job commun — ou répartissez les specs indépendantes sur plusieurs rails : chaque rail adossé à git s'exécute en parallèle dans son propre worktree isolé.
+
 Freestyle utilise les outils et modèles natifs du fournisseur. Claude possède
 un transport interactif persistant ; Kimi utilise un processus agentic
 `kimi -p` sans stdin persistant.
 
+Les loops intégrés sont aussi modifiables : éditez-en un dans le Loop Builder et publiez-le, et chaque rail qui le choisit exécute votre version (utilisez **Restaurer l'original** pour revenir en arrière).
+
 Au-delà des intégrés, vous pouvez **construire vos propres loops** — répéter un cycle verify → fix → verify jusqu'à ce qu'un objectif soit atteint, enchaîner des commandes shell entre les étapes IA, et plus encore. Ces loops personnalisés apparaissent dans le même sélecteur de Loop. C'est la prochaine grande idée : [Le Loop Builder](the-loop-builder).
 
 ## La file d'attente des jobs
@@ -98,5 +101,4 @@ Si quelque chose semble anormal :
 
 - [Le Loop Builder](the-loop-builder) — ce qu'un rail exécute, et comment construire vos propres loops.
 - [La vue détaillée du job](the-job-detail-view) — phases, métriques en direct, cartes de ticket.
-- [Batch implement et multi-fonctionnalité](batch-implement-and-multi-feature) — exécutez plusieurs specs à la fois.
 - [Choisir un moteur par rail](picking-an-engine-per-rail) — Claude, Codex, Gemini ou Kimi.

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

@@ -22,7 +22,7 @@ Deux panneaux se trouvent au-dessus du log en streaming complet ; sur un job Cla
 
 ## Les phases du pipeline
 
-Pour les jobs `Implement` et `Batch`, l'exécution traverse les phases définies par la slash command — par défaut :
+Pour les jobs `Implement`, l'exécution traverse les phases définies par la slash command — par défaut :
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -113,5 +113,14 @@ Pratique pour partager une exécution avec un coéquipier, ou pour déposer un r
 ## Où aller ensuite
 
 - [Rails et jobs](rails-and-jobs) — lancement et mise en file.
-- [Batch implement et multi-fonctionnalité](batch-implement-and-multi-feature) — plusieurs specs, vagues de dépendances.
 - [Suivre le coût](../analytics/tracking-cost) — transformer les coûts par job en analytics de projet.
+
+## Après le redémarrage d’un workflow
+
+Après un arrêt brutal, reprenez le workflow enregistré avec sa configuration et ses dépôts d’origine. Une écriture interrompue exige de sélectionner la tentative exacte après avoir examiné le diff du worktree. Les étapes terminées sont conservées. Un appel au fournisseur dont la réponse a été perdue reste comptabilisé comme interrompu, avec une consommation inconnue ; il n’est jamais présenté comme gratuit. Si les données enregistrées ne permettent pas de prouver la livraison d’origine, la récupération affiche une erreur et conserve le worktree.
+
+Quand une étape de décision pose une question, la reprise réutilise la décision enregistrée et transmet la réponse humaine à l’étape suivante. Elle ne rappelle pas le modèle pour cette même décision. Un prompt en pause peut nécessiter un nouveau tour du modèle pour appliquer votre réponse.
+
+## Conservation de l’historique
+
+Les exécutions enregistrées sont conservées indéfiniment par défaut. Dans **Exécutions enregistrées → Conservation de l’historique**, un projet peut les conserver de 1 à 3650 jours. Rien n’est supprimé en arrière-plan : enregistrez la politique, choisissez **Aperçu du nettoyage** et examinez chaque exécution et sa raison avant **Supprimer les historiques expirés**. Une exécution reste protégée tant qu’elle est active, attend votre réponse ou approbation, a une écriture interrompue, une livraison ouverte ou un fork qui en dépend encore. Seul l’historique d’exécution dans le stockage Specrails du projet est supprimé ; votre dépôt, les worktrees, le journal du job et les coûts sont conservés. Une exécution expirée apparaît comme **Expiré** et ne peut plus être reprise ni forkée. Les versions de Core encore utilisées par une exécution conservée sont toujours gardées.

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

@@ -22,14 +22,14 @@ Le moteur sélectionné exécute chaque phase du pipeline de ce rail. Si la CLI
 
 ## Les points forts de chaque moteur
 
-Les quatre exécutent **Implement** et **Batch** :
+Les quatre exécutent **Implement** :
 
 | Moteur | À privilégier quand… | Notes |
 |--------|--------------------|-------|
 | **Claude** | Vous avez besoin du coût natif, de l'interaction persistante ou de politiques d'outils strictes. | Profils, Freestyle et transforms structurés. |
 | **Codex** | Vous préférez la CLI Codex d'OpenAI ou vous voulez comparer les implémentations entre fournisseurs. | `codex` ≥ 0.128.0. Pas de rapport de coût natif — l'application complète le coût à partir de sa table de tarifs. Les profils ne s'appliquent pas. |
 | **Gemini** | Vous voulez la CLI Gemini de Google, la télémétrie native, ou une exécution moins chère pour les specs de routine. | `gemini` ≥ 0.11.0 (définissez `GEMINI_API_KEY`). Télémétrie OTLP native. Les profils ne s'appliquent pas. |
-| **Kimi** | Vous voulez Kimi agentic pour Implement, Batch, Freestyle ou loops sans Decider. | `kimi` ≥ 0.27.0 externe ; profils/rôles, effort K3 seulement ; tokens/coût indisponibles. |
+| **Kimi** | Vous voulez Kimi agentic pour Implement, Freestyle ou loops sans Decider. | `kimi` ≥ 0.27.0 externe ; profils/rôles, effort K3 seulement ; tokens/coût indisponibles. |
 
 ### Différences de capacité
 

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

@@ -1,6 +1,16 @@
 # Le Loop Builder
 
-Un **rail exécute un Loop**. Les loops intégrés (`Implement`, `Batch`, `Freestyle`) couvrent les cas du quotidien, mais le **Loop Builder** vous laisse concevoir les vôtres — un éditeur visuel, de style n8n, pour de l'automatisation qui se répète jusqu'à ce qu'un objectif soit atteint. Cette page explique ce qu'est un loop, comment en construire un, et comment l'exécuter sur un rail.
+## Workflows Core
+
+Avec un moteur Core compatible, un nouveau canevas affiche les dix-sept étapes du catalogue installé. Cliquez sur une étape ou faites-la glisser, puis remplissez son formulaire. Les fournisseurs et rôles proviennent du projet actif. Reliez chaque sortie nommée à une autre étape ou à Fin ; une sortie accepte une seule connexion.
+
+Les formulaires couvrent les champs facultatifs, objets, listes et dictionnaires de toutes les étapes : IA, conditions, vérification, shell, OpenSpec, approbation, question, pause, parcours, regroupement, composants et implémentation. Les options exposent les limites de jetons et de transitions et la concurrence. Les visites internes aux composants comptent dans la limite.
+
+Créez un corps réutilisable dans **Composants**, déclarez ses entrées et sorties, puis sélectionnez-le dans une étape Composant ou Parcourir. Le fil de navigation revient au canevas principal sans perdre les modifications. Une étape Fin peut choisir une sortie locale avec `exit`.
+
+La publication demande à Core de valider le brouillon et affiche les erreurs sur les étapes concernées. Le lancement valide à nouveau la configuration du projet. Si le moteur est indisponible, mettez Core à jour. Les anciennes boucles conservent leur éditeur et leur exécution ; les sections suivantes les décrivent.
+
+Un **rail exécute un Loop**. Les loops intégrés (`Implement`, `Freestyle`, `SDD Quick (OpenSpec)`) couvrent les cas du quotidien, mais le **Loop Builder** vous laisse concevoir les vôtres — un éditeur visuel, de style n8n, pour de l'automatisation qui se répète jusqu'à ce qu'un objectif soit atteint. Cette page explique ce qu'est un loop, comment en construire un, et comment l'exécuter sur un rail.
 
 ## Loops et rails — la relation
 
@@ -10,9 +20,8 @@ Un **loop** est la *recette* du travail ; un **rail** est la *voie* qui l'exécu
    Loop Builder (barre latérale gauche)    Rails (droite)
    ───────────────────────────             ─────────────
    Implement   (intégré)                   Rail 1
-   Batch       (intégré)      choisir ►       Loop: Verify-until-green
-   Freestyle   (intégré)                      ▶ Play
-   Verify-until-green (le vôtre)
+   Freestyle   (intégré)      choisir ►       Loop: Verify-until-green
+   Verify-until-green (le vôtre)                      ▶ Play
 ```
 
 - Les loops vivent dans la section **Loops** (barre latérale gauche, à côté de vos projets) — ils sont **globaux**, partagés entre tous les projets.
@@ -25,7 +34,7 @@ Donc : construisez un loop une fois, puis choisissez-le sur n'importe quel rail
 
 Cliquez sur **Loops** dans la barre latérale gauche pour voir la bibliothèque : les trois loops intégrés plus les vôtres. Ouvrez-en un pour le visualiser, ou cliquez sur **New loop** pour partir d'un canevas vierge.
 
-Vous ne pouvez pas facilement éditer un intégré directement — à la place, faites un **Fork**. Cela vous donne une copie éditable d'un graphe fonctionnel pour démarrer, ce qui est la façon la plus simple d'apprendre.
+Les loops intégrés sont de vrais loops éditables. Ouvrez-en un avec **Edit** et modifiez-le comme n'importe quel loop : l'enregistrement le repasse en brouillon, et **Publish** applique votre version à **chaque rail, lancement depuis le chat de l'agent et lancement Companion qui utilise ce loop intégré**. Tant que votre modification est un brouillon, les rails continuent d'exécuter la dernière version publiée : rien ne casse en cours d'édition. **Restaurer l'original** (sur la carte ou dans le builder) remet un loop intégré à sa version par défaut ; les loops intégrés ne peuvent pas être supprimés. Vous préférez une copie séparée ? Utilisez **Duplicate** : cela crée un loop ordinaire et laisse le loop intégré intact.
 
 ## De quoi un loop est constitué
 
@@ -93,3 +102,13 @@ L'exécution se diffuse en direct dans la vue **Jobs** avec les mêmes métrique
 - [Rails et jobs](rails-and-jobs) — lancer des rails et la file d'attente des jobs.
 - [La vue détaillée du job](the-job-detail-view) — suivre une exécution en direct.
 - [Choisir un moteur par rail](picking-an-engine-per-rail) — c'est le rail (pas le loop) qui choisit le provider.
+
+Lorsque la version de Core sélectionnée expose les limites par invocation, les blocs prompt, rôle et decider proposent `timeoutMs` et `idleTimeoutMs`. La valeur `0` désactive le temporisateur correspondant pour cette étape ; supprimer le champ rétablit la valeur héritée. Les budgets du workflow complet et son annulation restent actifs. Une étape de vérification qui pose une question bloquante attend votre réponse avant d’accepter un résultat réussi.
+
+Lorsqu’un ancien graphe enregistré est remplacé pour la première fois par des blocs Core, le graphe d’origine est conservé. La bibliothèque propose alors **Exporter le graphe d’origine**. L’export porte un nom distinct pour pouvoir être importé comme brouillon séparé sans remplacer le workflow actuel. La conversion et les modifications ultérieures ne publient jamais automatiquement une boucle.
+
+Utilisez **Définir les variables** pour conserver un état pendant une pause : définissez des valeurs JSON typées ou ajustez un compteur entier existant. Cette pièce ne fait aucun appel à l’IA. Toutes les modifications sont enregistrées ensemble ; un compteur invalide laisse toutes les variables inchangées. Les variables d’un composant mappé restent locales à ce composant.
+
+Pour un Decider, **Continuer tant que cette condition est remplie** protège les tâches obligatoires restantes. Par exemple, `$vars.failedPass == true` transforme une proposition d’arrêt en poursuite jusqu’à ce que le workflow efface cet indicateur. La décision est tout de même exécutée et les répétitions sans changement restent soumises à la limite de progression. Les questions humaines attendent toujours une réponse.
+
+Pour migrer une boucle enregistrée de l’ancien moteur, choisissez **Convertir vers Core** dans la bibliothèque. Sélectionnez le dépôt d’origine si une étape shell n’a pas de périmètre explicite. La conversion valide le graphe et enregistre un brouillon avec une copie exportable de l’original. Vérifiez les connexions puis publiez explicitement. Les boucles en cours ne peuvent pas être converties et les modifications concurrentes sont préservées. Les étapes d’écriture exigent de vraies commandes de vérification ; Quick SDD utilise OpenSpec inclus dans Core. Mettez Core à jour si la conversion est indisponible.

package/docs/guide/it/integrations/7-local-engines.md

@@ -15,7 +15,7 @@ Ogni connessione ha anche l'impostazione **Loop dell'agente**. **Compatto** (pre
 
 ## Cosa ottieni
 
-- Rails (implement, batch, freestyle, loop personalizzati), Explore e spec Quick, chat e missioni girano sul modello locale.
+- Rails (implement, freestyle, loop personalizzati), Explore e spec Quick, chat e missioni girano sul modello locale.
 - Le missioni mantengono i loro strumenti Specrails e i tuoi server MCP esterni.
 - Le sessioni riprendono tra un turno e l'altro; i job interattivi funzionano.
 - Il costo è onesto: i token vengono registrati, il costo resta *sconosciuto* a meno che tu non inserisca tariffe (allora è contrassegnato come *stimato*).

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

@@ -18,12 +18,12 @@ SpecsBoard (sinistra)       Rail (destra)
 
 Un rail è una **corsia di esecuzione**. Trascini una scheda spec dalla SpecsBoard su un rail e poi premi **▶ Play**. Nei repository git, il rail avvia la pipeline in un git worktree isolato, così l'IA può modificare file ed eseguire test senza toccare il tuo working tree attivo. Se il progetto non è ancora un repo git, Specrails degrada chiaramente all'esecuzione nella cartella condivisa e ti avvisa che non compariranno né branch né card PR.
 
-Puoi avere diversi rail per organizzare il lavoro in corsie con un nome (una per la feature su cui sei concentrato, un'altra in attesa dietro). I rail sono **dinamici**: il pulsante **+ Aggiungi** nell'header dei Rails crea una nuova corsia (fino a 12 per progetto) e le corsie vuote e inattive si possono eliminare. Ogni rail è ancorato al server, quindi il tuo set di corsie sopravvive ai ricaricamenti ed è visibile al companion mobile e all'agente integrato — l'agente può persino creare un rail da solo quando tutte le corsie sono occupate. Trovi più dettagli su multi-rail e batching in [Batch implement e multi-feature](batch-implement-and-multi-feature).
+Puoi avere diversi rail per organizzare il lavoro in corsie con un nome (una per la feature su cui sei concentrato, un'altra in attesa dietro). I rail sono **dinamici**: il pulsante **+ Aggiungi** nell'header dei Rails crea una nuova corsia (fino a 12 per progetto) e le corsie vuote e inattive si possono eliminare. Ogni rail è ancorato al server, quindi il tuo set di corsie sopravvive ai ricaricamenti ed è visibile al companion mobile e all'agente integrato — l'agente può persino creare un rail da solo quando tutte le corsie sono occupate.
 
 ## Avviare un rail su una spec
 
 1. **Trascina una scheda spec** dalla SpecsBoard su un rail. L'ID della spec compare nell'elenco di spec del rail. (Preferisci non trascinare? Usa il popover **Sposta su un rail** sulla scheda spec — mostra un pallino di stato per ogni rail, così non scarichi del lavoro su una corsia già occupata.)
-2. **Scegli un Loop** nell'intestazione del rail. Un rail esegue un **Loop** — è il lavoro che svolge. Quello predefinito è il Loop `Implement` integrato; puoi anche scegliere `Batch`, `Freestyle` o un loop personalizzato che hai costruito tu. Vedi [Il Loop Builder](the-loop-builder).
+2. **Scegli un Loop** nell'intestazione del rail. Un rail esegue un **Loop** — è il lavoro che svolge. Quello predefinito è il Loop `Implement` integrato; puoi anche scegliere `Freestyle` o un loop personalizzato che hai costruito tu. Vedi [Il Loop Builder](the-loop-builder).
 3. **Premi ▶ Play.**
 
 Tutto qui. Il rail avvia un processo CLI AI nel contesto di esecuzione corretto e dà il via alla pipeline.
@@ -34,25 +34,28 @@ Tutto qui. Il rail avvia un processo CLI AI nel contesto di esecuzione corretto
 |---------|--------------|
 | **Pillola di stato** | `idle`, `running` o `failed`. Non esiste uno stato "completed" separato — un rail torna a `idle` quando il suo job termina senza errori. |
 | **Elenco spec** | Gli ID assegnati a questo rail. Trascinane altri dentro, oppure fuori per staccarli. |
-| **Selettore Loop** | Il Loop che questo rail esegue — uno integrato (`Implement` / `Batch` / `Freestyle`) o un loop personalizzato. Vedi la tabella più sotto. Viene salvato per ogni rail. |
+| **Selettore Loop** | Il Loop che questo rail esegue — uno integrato (`Implement` / `Freestyle` / `SDD Quick (OpenSpec)`) o un loop personalizzato. Vedi la tabella più sotto. Viene salvato per ogni rail. |
 | **Selettore profilo** | Quale profilo del provider viene eseguito (rail Claude e Kimi). |
 | **Selettore engine** | Quale provider esegue il rail — Claude, Codex, Gemini o Kimi. |
 | **▶ Play / ■ Stop** | Avvia o annulla. |
 
 ### Cosa esegue un rail: i Loop
 
-Un rail esegue un **Loop** — la ricetta del lavoro. Tre loop sono **integrati** e coprono i casi più comuni:
+Un rail esegue un **Loop** — la ricetta del lavoro. Due loop sono **integrati** e coprono i casi più comuni:
 
 | Loop integrato | Comando | Cosa fa |
 |------|---------|--------------|
 | **Implement** | `/specrails:implement` | Un unico job che copre tutte le spec sul rail. Esegue l'intera pipeline Architect → Developer → Reviewer → Ship. L'impostazione predefinita di tutti i giorni. |
-| **Batch** | `/specrails:batch-implement` | Un unico job che lavora le spec del rail in sequenza, in ondate consapevoli delle dipendenze. Ideale per più spec correlate. |
 | **Freestyle** | Freestyle | Claude o Kimi implementa ogni spec in autonomia, **bypassando** la pipeline. |
 
+Per eseguire più spec, metti quelle correlate (fino a 3) su un unico rail — `Implement` le esegue come un solo job aggregato — oppure distribuisci le spec indipendenti su più rail: ogni rail con git gira in parallelo nel proprio worktree isolato.
+
 Freestyle usa strumenti e modelli nativi del provider. Claude ha un transport
 interattivo persistente; Kimi usa un processo agentic `kimi -p` senza stdin
 persistente.
 
+Anche i loop integrati sono modificabili: modificane uno nel Loop Builder e pubblicalo, e ogni rail che lo sceglie esegue la tua versione (usa **Ripristina originale** per tornare indietro).
+
 Oltre agli integrati, puoi **costruire i tuoi loop** — ripetere un ciclo verify → fix → verify finché un obiettivo non è raggiunto, concatenare comandi shell tra gli AI Step e altro ancora. Quei loop personalizzati compaiono nello stesso selettore Loop. È la prossima grande idea: [Il Loop Builder](the-loop-builder).
 
 ## La coda dei job
@@ -98,5 +101,4 @@ Se qualcosa sembra non andare:
 
 - [Il Loop Builder](the-loop-builder) — cosa esegue un rail e come costruire i tuoi loop.
 - [La vista Dettaglio job](the-job-detail-view) — fasi, metriche live, schede ticket.
-- [Batch implement e multi-feature](batch-implement-and-multi-feature) — esegui più spec insieme.
 - [Scegliere un engine per ogni rail](picking-an-engine-per-rail) — Claude, Codex, Gemini o Kimi.

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

@@ -22,7 +22,7 @@ Due pannelli stanno sopra il log completo in streaming; su un job Claude in esec
 
 ## Fasi della pipeline
 
-Per i job `Implement` e `Batch`, l'esecuzione attraversa le fasi definite dallo slash command — per impostazione predefinita:
+Per i job `Implement`, l'esecuzione attraversa le fasi definite dallo slash command — per impostazione predefinita:
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -113,5 +113,14 @@ Comodo per condividere un'esecuzione con un collega, o per inviare una segnalazi
 ## Dove andare ora
 
 - [Rail e job](rails-and-jobs) — avvio e accodamento.
-- [Batch implement e multi-feature](batch-implement-and-multi-feature) — molte spec, ondate di dipendenze.
 - [Tracciare i costi](../analytics/tracking-cost) — trasforma i costi per job in analytics di progetto.
+
+## Dopo il riavvio di un workflow
+
+Dopo un arresto improvviso, riprendi il workflow salvato con la configurazione e i repository originali. Una scrittura interrotta richiede di selezionare il tentativo esatto dopo aver esaminato il diff del worktree. I passaggi completati vengono conservati. Una chiamata al provider la cui risposta è andata persa resta conteggiata come interrotta, con consumo sconosciuto; non viene mai presentata come gratuita. Se i dati salvati non consentono di dimostrare la consegna originale, il recupero mostra un errore e conserva il worktree.
+
+Quando un passaggio decisionale si interrompe per una domanda, la ripresa riutilizza la decisione salvata e trasmette la risposta umana al passaggio successivo. Non richiama il modello per la stessa decisione. Un prompt in pausa può richiedere un altro turno del modello per applicare la risposta.
+
+## Conservazione della cronologia
+
+Le esecuzioni salvate sono conservate indefinitamente per impostazione predefinita. In **Esecuzioni salvate → Conservazione della cronologia**, un progetto può conservarle da 1 a 3650 giorni. Nulla viene eliminato in background: salva la regola, scegli **Anteprima pulizia** e controlla ogni esecuzione e il suo motivo prima di **Elimina cronologia scaduta**. Un’esecuzione resta protetta finché è attiva, attende una tua risposta o approvazione, ha una scrittura interrotta, una consegna aperta o un fork che ne dipende ancora. Viene rimossa solo la cronologia di esecuzione nello spazio Specrails del progetto; repository, worktree, log del job e costi restano. Un’esecuzione scaduta appare come **Scaduto** e non può più essere ripresa né forkata. Le versioni di Core ancora usate da un’esecuzione conservata non vengono mai rimosse.

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

@@ -21,14 +21,14 @@ L'engine selezionato esegue ogni fase della pipeline di quel rail. Se la CLI del
 
 ## In cosa è bravo ciascun engine
 
-Tutti e quattro eseguono **Implement** e **Batch**:
+Tutti e quattro eseguono **Implement**:
 
 | Engine | Scegli questo quando… | Note |
 |--------|--------------------|-------|
 | **Claude** | Servono costi nativi, interazione persistente o tool policy rigorose. | Profili, Freestyle e transform strutturati. |
 | **Codex** | Preferisci la CLI Codex di OpenAI o vuoi confrontare le implementazioni tra provider diversi. | `codex` ≥ 0.128.0. Nessuna reportistica nativa dei costi — l'app ricava il costo dalla sua tabella prezzi. I profili non si applicano. |
 | **Gemini** | Vuoi la CLI Gemini di Google, telemetria nativa o un'esecuzione più economica per le spec di routine. | `gemini` ≥ 0.11.0 (imposta `GEMINI_API_KEY`). Telemetria OTLP nativa. I profili non si applicano. |
-| **Kimi** | Vuoi Kimi agentic per Implement, Batch, Freestyle o loop senza Decider. | `kimi` ≥ 0.27.0 esterno; profili/ruoli, effort solo K3; token/costo non disponibili. |
+| **Kimi** | Vuoi Kimi agentic per Implement, Freestyle o loop senza Decider. | `kimi` ≥ 0.27.0 esterno; profili/ruoli, effort solo K3; token/costo non disponibili. |
 
 ### Differenze di capability
 

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

@@ -1,6 +1,16 @@
 # Il Loop Builder
 
-Un **rail esegue un Loop**. I loop integrati (`Implement`, `Batch`, `Freestyle`) coprono i casi di tutti i giorni, ma il **Loop Builder** ti permette di progettare i tuoi — un editor visuale in stile n8n per automazioni che si ripetono finché un obiettivo non è raggiunto. Questa pagina spiega cos'è un loop, come costruirne uno e come eseguirlo su un rail.
+## Workflow Core
+
+Con un motore Core compatibile, un nuovo canvas mostra i diciassette passaggi del catalogo installato. Fai clic o trascina un passaggio e compila il modulo. Provider e ruoli appartengono al progetto attivo. Collega ogni uscita denominata a un altro passaggio o a Fine; ciascuna uscita ammette una connessione.
+
+I moduli coprono campi facoltativi, oggetti, elenchi e dizionari per IA, condizioni, verifica, shell, OpenSpec, approvazioni, domande, pause, mappe, unioni, componenti e implementazione. Le opzioni includono limiti di token e transizioni e concorrenza. Anche i passaggi interni ai componenti contano nel limite.
+
+Crea un corpo riutilizzabile in **Componenti**, dichiara ingressi e uscite e selezionalo in un passaggio Componente o Mappa. La navigazione torna al canvas principale senza perdere le modifiche. Un Fine locale può scegliere un'uscita tramite `exit`.
+
+La pubblicazione invia la bozza a Core e mostra gli errori sui passaggi interessati. L'avvio convalida nuovamente la configurazione del progetto. Aggiorna Core se il motore non è disponibile. I loop precedenti conservano editor ed esecuzione; le sezioni seguenti li descrivono.
+
+Un **rail esegue un Loop**. I loop integrati (`Implement`, `Freestyle`, `SDD Quick (OpenSpec)`) coprono i casi di tutti i giorni, ma il **Loop Builder** ti permette di progettare i tuoi — un editor visuale in stile n8n per automazioni che si ripetono finché un obiettivo non è raggiunto. Questa pagina spiega cos'è un loop, come costruirne uno e come eseguirlo su un rail.
 
 ## Loop e rail — la relazione
 
@@ -10,9 +20,8 @@ Un **loop** è la *ricetta* del lavoro; un **rail** è la *corsia* che lo esegue
    Loop Builder (sidebar sinistra)         Rail (destra)
    ───────────────────────────             ─────────────
    Implement   (integrato)                 Rail 1
-   Batch       (integrato)     scegli su ►    Loop: Verify-until-green
-   Freestyle   (integrato)                    ▶ Play
-   Verify-until-green (tuo)
+   Freestyle   (integrato)     scegli su ►    Loop: Verify-until-green
+   Verify-until-green (tuo)                    ▶ Play
 ```
 
 - I loop vivono nella sezione **Loops** (sidebar sinistra, accanto ai tuoi progetti) — sono **globali**, condivisi tra tutti i progetti.
@@ -25,7 +34,7 @@ Quindi: costruisci un loop una volta, poi scegli quel loop su qualsiasi rail in
 
 Clicca **Loops** nella sidebar sinistra per vedere la libreria: i tre loop integrati più tutti i tuoi. Aprine uno per visualizzarlo, oppure clicca **New loop** per partire da una tela bianca.
 
-Non puoi modificare facilmente un integrato in modo diretto — invece fanne un **Fork**. Ti dà una copia modificabile di un grafo funzionante da cui partire, ed è il modo più semplice per imparare.
+I loop integrati sono loop veri e modificabili. Aprine uno con **Edit** e cambialo come qualsiasi altro loop: salvando torna in bozza, e **Publish** applica la tua versione a **ogni rail, avvio dalla chat dell'agente e avvio da Companion che usa quel loop integrato**. Finché la modifica è una bozza, i rail continuano a eseguire l'ultima versione pubblicata, quindi nulla si rompe a metà modifica. **Ripristina originale** (sulla card o nel builder) riporta un loop integrato alla versione predefinita; i loop integrati non si possono eliminare. Preferisci una copia separata? Usa **Duplicate**: crea un loop normale e lascia intatto quello integrato.
 
 ## Di cosa è fatto un loop
 
@@ -93,3 +102,13 @@ L'esecuzione scorre dal vivo nella vista **Jobs** con le stesse metriche e lo st
 - [Rail e job](rails-and-jobs) — avviare i rail e la coda dei job.
 - [La vista Dettaglio job](the-job-detail-view) — seguire un'esecuzione dal vivo.
 - [Scegliere un engine per rail](picking-an-engine-per-rail) — è il rail (non il loop) a scegliere il provider.
+
+Quando la versione di Core selezionata espone i limiti per invocazione, i blocchi prompt, ruolo e decider offrono `timeoutMs` e `idleTimeoutMs`. Imposta `0` per disattivare quel timer del passaggio oppure rimuovi il campo per ereditare il valore predefinito. I budget dell’intero workflow e l’annullamento restano attivi. Un passaggio di verifica che pone una domanda bloccante attende la tua risposta prima di accettare un risultato positivo.
+
+Quando un grafo precedente salvato viene sostituito per la prima volta con blocchi Core, il grafo originale viene conservato. La libreria offre quindi **Esporta il grafo originale**. L’esportazione ha un nome distinto, così puoi importarla come bozza separata senza sostituire il workflow attuale. La conversione e le modifiche successive non pubblicano mai automaticamente un loop.
+
+Usa **Imposta variabili** per conservare lo stato durante una pausa: imposta valori JSON tipizzati o modifica un contatore intero esistente. Questo blocco non chiama l’IA. Gli aggiornamenti vengono salvati insieme; un contatore non valido lascia tutte le variabili invariate. Le variabili di un componente mappato restano locali a quel componente.
+
+Nel Decider, **Continua finché questa condizione è vera** protegge il lavoro obbligatorio ancora aperto. Ad esempio, `$vars.failedPass == true` trasforma una proposta di arresto in continuazione finché il workflow non azzera il flag. La decisione viene comunque eseguita e le ripetizioni senza modifiche restano soggette al limite di mancato progresso. Le domande umane attendono sempre una risposta.
+
+Per migrare un loop salvato del motore precedente, scegli **Converti in Core** nella libreria. Seleziona il repository originale se un passo shell non ha un ambito esplicito. La conversione convalida il grafo e salva una bozza con una copia esportabile dell’originale. Controlla i collegamenti e pubblica esplicitamente. I loop in esecuzione non possono essere convertiti; le modifiche concorrenti vengono conservate. I passi di scrittura richiedono veri comandi di verifica e Quick SDD usa OpenSpec incluso in Core. Aggiorna Core se la conversione non è disponibile.

package/docs/guide/ja/integrations/7-local-engines.md

@@ -15,7 +15,7 @@
 
 ## できること
 
-- レール（implement、batch、freestyle、カスタムループ）、Explore と Quick スペック、チャット、ミッションがローカルモデルで動作します。
+- レール（implement、freestyle、カスタムループ）、Explore と Quick スペック、チャット、ミッションがローカルモデルで動作します。
 - ミッションは Specrails ツールと外部 MCP サーバーをそのまま使えます。
 - セッションはターンをまたいで再開でき、インタラクティブジョブも動作します。
 - コストは正直です。トークンは記録され、レートを入力しない限りコストは*不明*のまま（入力すると*推定*と表示）。

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

@@ -18,12 +18,12 @@ SpecsBoard（左）            レール（右）
 
 レールは**実行レーン**です。SpecsBoard からスペックカードをレールにドラッグし、**▶ Play** を押します。git リポジトリでは、レールは隔離された git worktree の中でパイプラインを起動するため、AI はあなたの現在のワークツリーに触れずにファイル編集やテスト実行を行えます。プロジェクトがまだ git リポジトリでない場合、Specrails は共有フォルダでの実行へ明確にフォールバックし、ブランチや PR カードが出ないことを知らせます。
 
-レールは複数持てるので、名前付きのレーンとして作業を整理できます（いま集中している機能用のレールと、その後ろに控えさせておくレールといった具合に）。レールは**動的**です。レールヘッダーの **+ 追加** ボタンで新しいレーンを作成でき（1 プロジェクトあたり最大 12 本）、空のアイドルなレーンは削除できます。すべてのレールはサーバーに裏付けられているので、レーンの構成はリロード後も保持され、モバイルコンパニオンやアプリ内エージェントからも見えます — レーンがすべて塞がっているときは、エージェントが自分でレールを作ることさえできます。複数レールやバッチ処理については [バッチ実装とマルチフィーチャー](batch-implement-and-multi-feature) で詳しく説明します。
+レールは複数持てるので、名前付きのレーンとして作業を整理できます（いま集中している機能用のレールと、その後ろに控えさせておくレールといった具合に）。レールは**動的**です。レールヘッダーの **+ 追加** ボタンで新しいレーンを作成でき（1 プロジェクトあたり最大 12 本）、空のアイドルなレーンは削除できます。すべてのレールはサーバーに裏付けられているので、レーンの構成はリロード後も保持され、モバイルコンパニオンやアプリ内エージェントからも見えます — レーンがすべて塞がっているときは、エージェントが自分でレールを作ることさえできます。
 
 ## スペックでレールを起動する
 
 1. **スペックカードをドラッグ**して、SpecsBoard からレールへ移します。スペックの ID がそのレールのスペック一覧に表示されます。（ドラッグが苦手ですか？ スペックカードの **レールに移動** ポップオーバーを使えば、レールごとにステータスのドットが表示されるので、ふさがっているレーンに作業を落としてしまう心配がありません。）
-2. レールヘッダーで **Loop を選びます**。レールは **Loop** を実行します — それがレールの行う作業そのものです。デフォルトは組み込みの `Implement` Loop ですが、`Batch`、`Freestyle`、あるいは自分で作ったカスタム Loop を選ぶこともできます。[Loop Builder](the-loop-builder) を参照してください。
+2. レールヘッダーで **Loop を選びます**。レールは **Loop** を実行します — それがレールの行う作業そのものです。デフォルトは組み込みの `Implement` Loop ですが、`Freestyle`、あるいは自分で作ったカスタム Loop を選ぶこともできます。[Loop Builder](the-loop-builder) を参照してください。
 3. **▶ Play を押します。**
 
 これだけです。レールが適切な実行コンテキストで AI CLI プロセスを立ち上げ、パイプラインを開始します。
@@ -34,25 +34,28 @@ SpecsBoard（左）            レール（右）
 |---------|--------------|
 | **ステータスピル** | `idle`、`running`、`failed` のいずれか。「completed」という別ステータスはありません — ジョブがきれいに完了すると、レールは `idle` に戻ります。 |
 | **スペック一覧** | このレールに割り当てられた ID。さらにドラッグして追加したり、ドラッグして外したりできます。 |
-| **Loop ピッカー** | このレールが実行する Loop — 組み込み（`Implement` / `Batch` / `Freestyle`）かカスタム Loop。下の表を参照してください。レールごとに保持されます。 |
+| **Loop ピッカー** | このレールが実行する Loop — 組み込み（`Implement` / `Freestyle` / `SDD Quick (OpenSpec)`）かカスタム Loop。下の表を参照してください。レールごとに保持されます。 |
 | **プロファイルピッカー** | 実行する provider profile（Claude/Kimi rail）。 |
 | **エンジンセレクター** | rail を実行する provider — Claude、Codex、Gemini、Kimi。 |
 | **▶ Play / ■ Stop** | 開始またはキャンセル。 |
 
 ### レールが実行するもの: Loop
 
-レールは **Loop** を実行します — それが作業のレシピです。3 つの Loop が **組み込み** で、よくあるケースをカバーします。
+レールは **Loop** を実行します — それが作業のレシピです。2 つの Loop が **組み込み** で、よくあるケースをカバーします。
 
 | 組み込み Loop | コマンド | 役割 |
 |------|---------|--------------|
 | **Implement** | `/specrails:implement` | レール上のすべてのスペックをまとめた 1 つのジョブ。Architect → Developer → Reviewer → Ship のフルパイプラインを実行します。日常的に使うデフォルトです。 |
-| **Batch** | `/specrails:batch-implement` | レール上のスペックを、依存関係を考慮したウェーブで順番に処理する 1 つのジョブ。関連する複数のスペックに最適です。 |
 | **Freestyle** | Freestyle | Claude または Kimi が pipeline を**バイパス**して自律的に実装します。 |
 
+複数のスペックを実行するには、関連するもの（最大 3 件）を 1 本のレールに載せる（`Implement` がまとめて 1 つのジョブとして実行します）か、独立したスペックを複数のレールに分けます。git 管理のレールはそれぞれ専用の分離された worktree で並行して動きます。
+
 Freestyle は provider の native tool/model を使います。Claude は
 persistent interactive transport、Kimi は persistent stdin のない agentic
 `kimi -p` process を使います。
 
+組み込み Loop も編集できます。Loop Builder で編集して公開すると、それを選んでいるすべてのレールがあなたのバージョンを実行します（戻すには **元に戻す** を使います）。
+
 組み込みのほかにも、**自分だけの Loop を作る** ことができます — verify → fix → verify のサイクルを目標が達成されるまで繰り返したり、AI ステップの間にシェルコマンドを連ねたり、さらにいろいろなことができます。そうしたカスタム Loop は同じ Loop ピッカーに表示されます。それが次の大きなアイデア、[Loop Builder](the-loop-builder) です。
 
 ## ジョブのキュー
@@ -98,5 +101,4 @@ git のないプロジェクトでは worktree 隔離も PR 継続も使えま
 
 - [Loop Builder](the-loop-builder) — レールが実行するもの、そして自分だけの Loop を作る方法。
 - [ジョブ詳細ビュー](the-job-detail-view) — フェーズ、ライブメトリクス、チケットカード。
-- [バッチ実装とマルチフィーチャー](batch-implement-and-multi-feature) — 複数のスペックをまとめて実行する。
 - [レールごとのエンジン選択](picking-an-engine-per-rail) — Claude / Codex / Gemini / Kimi。