specrails-desktop 2.57.0 → 2.58.0

package/client/dist/index.html

@@ -204,7 +204,7 @@
         .specrails-splash__mark .pill { opacity: 1; }
       }
     </style>
-    <script type="module" crossorigin src="/assets/index-Cxb288Rj.js"></script>
+    <script type="module" crossorigin src="/assets/index-C4Mv6tV6.js"></script>
     <link rel="modulepreload" crossorigin href="/assets/rolldown-runtime-CNC7AqOf.js">
     <link rel="modulepreload" crossorigin href="/assets/jsx-runtime-zu2_FqZY.js">
     <link rel="modulepreload" crossorigin href="/assets/react-dom-DiWzBDP9.js">
@@ -213,43 +213,43 @@
     <link rel="modulepreload" crossorigin href="/assets/activity-DiyjsgQV.js">
     <link rel="modulepreload" crossorigin href="/assets/addspec-BOvgmcgk.js">
     <link rel="modulepreload" crossorigin href="/assets/agent-aiVhqFW1.js">
-    <link rel="modulepreload" crossorigin href="/assets/agentRuntime-bAAjw1vw.js">
+    <link rel="modulepreload" crossorigin href="/assets/agentRuntime-BeUb3g9g.js">
     <link rel="modulepreload" crossorigin href="/assets/agents-CTwbx-fb.js">
-    <link rel="modulepreload" crossorigin href="/assets/agentstudio-CN2pokQu.js">
+    <link rel="modulepreload" crossorigin href="/assets/agentstudio-BWAKeGgB.js">
     <link rel="modulepreload" crossorigin href="/assets/aiedit-iIjz2_Qk.js">
-    <link rel="modulepreload" crossorigin href="/assets/analytics-BlypLLR6.js">
+    <link rel="modulepreload" crossorigin href="/assets/analytics-BWynXPEm.js">
     <link rel="modulepreload" crossorigin href="/assets/attachments-B53PG733.js">
     <link rel="modulepreload" crossorigin href="/assets/browser-CG0PE1j_.js">
-    <link rel="modulepreload" crossorigin href="/assets/builder-BTiGnPT0.js">
+    <link rel="modulepreload" crossorigin href="/assets/builder-CzW5ovyI.js">
     <link rel="modulepreload" crossorigin href="/assets/chat-BGD7MXAy.js">
     <link rel="modulepreload" crossorigin href="/assets/code-DaZ-ZwCT.js">
     <link rel="modulepreload" crossorigin href="/assets/commands-BAWSYHjQ.js">
-    <link rel="modulepreload" crossorigin href="/assets/common-BrlwEnL7.js">
-    <link rel="modulepreload" crossorigin href="/assets/dashboard-BV4vOZkR.js">
+    <link rel="modulepreload" crossorigin href="/assets/common-DmsclwjP.js">
+    <link rel="modulepreload" crossorigin href="/assets/dashboard-XGdQ5mjw.js">
     <link rel="modulepreload" crossorigin href="/assets/explore-DgBACn39.js">
     <link rel="modulepreload" crossorigin href="/assets/integrations-mB-7zoyT.js">
     <link rel="modulepreload" crossorigin href="/assets/jira-CKJg3HZd.js">
-    <link rel="modulepreload" crossorigin href="/assets/jobs-C9j2PuwW.js">
-    <link rel="modulepreload" crossorigin href="/assets/loops-B7YpGizO.js">
+    <link rel="modulepreload" crossorigin href="/assets/jobs-KG4Sn12X.js">
+    <link rel="modulepreload" crossorigin href="/assets/loops-B4_D-nbg.js">
     <link rel="modulepreload" crossorigin href="/assets/mcp-CUAN6ORK.js">
     <link rel="modulepreload" crossorigin href="/assets/narration-n3hOA7LY.js">
     <link rel="modulepreload" crossorigin href="/assets/nav-DhPb-Isc.js">
     <link rel="modulepreload" crossorigin href="/assets/packet-B0H15elv.js">
-    <link rel="modulepreload" crossorigin href="/assets/settings-HZSu-K4l.js">
-    <link rel="modulepreload" crossorigin href="/assets/setup-DpqzaEEA.js">
+    <link rel="modulepreload" crossorigin href="/assets/settings-tfLhQZRN.js">
+    <link rel="modulepreload" crossorigin href="/assets/setup-CRKLp_ke.js">
     <link rel="modulepreload" crossorigin href="/assets/specs-DfIdoU5L.js">
     <link rel="modulepreload" crossorigin href="/assets/terminal-BAzpHtpY.js">
     <link rel="modulepreload" crossorigin href="/assets/tickets-D41ZMQpf.js">
     <link rel="modulepreload" crossorigin href="/assets/createLucideIcon-Bjbbp_KS.js">
-    <link rel="modulepreload" crossorigin href="/assets/useSharedWebSocket-Dz-HI6De.js">
-    <link rel="modulepreload" crossorigin href="/assets/Trans-DEbgkuAY.js">
-    <link rel="modulepreload" crossorigin href="/assets/useDesktop-QogiN0zR.js">
+    <link rel="modulepreload" crossorigin href="/assets/useSharedWebSocket-BZMrX4jr.js">
+    <link rel="modulepreload" crossorigin href="/assets/Trans-D3AfDylf.js">
+    <link rel="modulepreload" crossorigin href="/assets/useDesktop-0unHDBJJ.js">
     <link rel="modulepreload" crossorigin href="/assets/provider-capabilities-Vi1ZGvAK.js">
     <link rel="modulepreload" crossorigin href="/assets/save-B6wGWwBR.js">
-    <link rel="modulepreload" crossorigin href="/assets/spending-T5GM7wpn.js">
+    <link rel="modulepreload" crossorigin href="/assets/spending-HBSk-6jv.js">
     <link rel="modulepreload" crossorigin href="/assets/sparkles-DrY8hb0X.js">
     <link rel="modulepreload" crossorigin href="/assets/x-CBMI9ejn.js">
-    <link rel="modulepreload" crossorigin href="/assets/MinimizedChatsContext-D3QzgV0B.js">
+    <link rel="modulepreload" crossorigin href="/assets/MinimizedChatsContext-CNx_0bZu.js">
     <link rel="modulepreload" crossorigin href="/assets/zap-CUOlvtT1.js">
     <link rel="modulepreload" crossorigin href="/assets/circle-x-CMYsN4ZH.js">
     <link rel="modulepreload" crossorigin href="/assets/download-CFHyyHcw.js">
@@ -269,18 +269,18 @@
     <link rel="modulepreload" crossorigin href="/assets/utils-BC4DHlz2.js">
     <link rel="modulepreload" crossorigin href="/assets/dialog-xXB2q5HJ.js">
     <link rel="modulepreload" crossorigin href="/assets/lib-CGdyxIWg.js">
-    <link rel="modulepreload" crossorigin href="/assets/getTimezoneOffsetInMilliseconds-BHm2U-w1.js">
-    <link rel="modulepreload" crossorigin href="/assets/formatDistanceToNow-Cc2u5FwQ.js">
+    <link rel="modulepreload" crossorigin href="/assets/getTimezoneOffsetInMilliseconds-DOGj1Mfz.js">
+    <link rel="modulepreload" crossorigin href="/assets/formatDistanceToNow-aBss1Nai.js">
     <link rel="modulepreload" crossorigin href="/assets/button-Ccc9Dc-D.js">
-    <link rel="modulepreload" crossorigin href="/assets/jira-api-DrGxiD9p.js">
-    <link rel="modulepreload" crossorigin href="/assets/project-repositories-9Wzs0coQ.js">
-    <link rel="modulepreload" crossorigin href="/assets/RepositoryScopeSelector-hPGZNRBm.js">
-    <link rel="modulepreload" crossorigin href="/assets/TicketDetailModalContext-DAK-NoK6.js">
+    <link rel="modulepreload" crossorigin href="/assets/jira-api-BYbEPlkr.js">
+    <link rel="modulepreload" crossorigin href="/assets/project-repositories-CSnfzUpg.js">
+    <link rel="modulepreload" crossorigin href="/assets/RepositoryScopeSelector-C2mvWBQ6.js">
+    <link rel="modulepreload" crossorigin href="/assets/TicketDetailModalContext-B-DySpKL.js">
     <link rel="modulepreload" crossorigin href="/assets/core-B3mKBIh5.js">
-    <link rel="modulepreload" crossorigin href="/assets/RepositoryDeliveries-Du2UCf1a.js">
-    <link rel="modulepreload" crossorigin href="/assets/useRuntimeRuns-Dqmz9fS9.js">
+    <link rel="modulepreload" crossorigin href="/assets/RepositoryDeliveries-BiwJuS8r.js">
+    <link rel="modulepreload" crossorigin href="/assets/useRuntimeRuns-BN1rhyEm.js">
     <link rel="modulepreload" crossorigin href="/assets/event-Bt7f3wXe.js">
-    <link rel="stylesheet" crossorigin href="/assets/index-C51x61Bz.css">
+    <link rel="stylesheet" crossorigin href="/assets/index-BS7KCWkV.css">
   </head>
   <body>
     <div id="specrails-splash" aria-hidden="false" role="status" aria-label="Loading Specrails">

package/docs/agent-live-steering.md

@@ -55,3 +55,19 @@ Cada invocación, incluido un reintento por sesión caducada, recibe una capabil
 - [Codex app-server](https://learn.chatgpt.com/docs/app-server), contrastado con el esquema generado por Codex 0.153.4.
 - [Gemini model steering](https://geminicli.com/docs/cli/model-steering/) y ACP instalado 0.49.0: la capacidad interactiva no equivale a entrada sin interrupción en su transporte ACP.
 - [Kimi Server API](https://www.kimi.com/code/docs/en/kimi-code-cli/reference/server-api.html): transporte distinto del modo print utilizado actualmente.
+
+## Definition engine runs
+
+For engine v2, POST `/api/projects/:projectId/agent-runtime/runs/:runId/steer` with `{text, requestId}`. Use a stable request id for transport retries; changing its text is a conflict. Text must contain 1–20,000 characters. Desktop sends it over stdin to the run's retained Core package and original frozen context. The endpoint returns HTTP 202 with `{id, acceptedAt}` after Core commits its inbox transaction.
+
+Acceptance does not mean the agent has read the instruction. The next eligible AI attempt consumes it. Runtime status exposes bounded steering receipts with pending/consumed status, consuming attempt and timestamp. The counts cover the whole inbox; at most 512 receipts and 240-character previews are returned. Older retained runtimes may lack this reporting and cannot confirm consumption. Terminal runs reject new controls.
+
+The MCP `specrails_jobs` action `runtime_steer` takes `jobId`, `steeringText` and `requestId`; it is a write operation. Inspect `runtime_runs` for consumption. Steering does not replace frozen requirements or grant broader repository permissions.
+
+Job details and Settings → Saved executions expose the same instruction inbox.
+The composer preserves its request identity after a failed or lost response;
+editing the text starts a new message. An acceptance receipt remains labelled
+pending until Core reports the consuming attempt. Project switches discard the
+draft and ignore late responses from the previous project. Questions and
+approvals keep their separate explicit actions. All eight interface locales
+include the inbox labels.

package/docs/cli.md

@@ -98,13 +98,14 @@ specrails-desktop implement "#42"
 
 This is shorthand for `specrails-desktop /specrails:implement "#42"` — the app queues a rail job that you can monitor in the Dashboard. Token usage and cost are tracked in Analytics.
 
-### Implement a batch
+### Implement several specs
 
 ```bash
-specrails-desktop batch-implement "#40" "#41" "#43"
+specrails-desktop implement "#40" "#41" "#43"
 ```
 
-Shorthand for `/specrails:batch-implement` — runs the listed specs in one dependency-aware job.
+`implement` accepts several specs and runs them in one aggregate job. The old
+`batch-implement` verb was removed; typing it still works and runs `implement`.
 
 ### Health check
 
@@ -128,8 +129,7 @@ These are all shorthand for `/specrails:<verb>` — the app auto-prefixes:
 
 | Verb | What it does |
 |------|--------------|
-| `implement` | Queue a rail job for one spec |
-| `batch-implement` | Queue one job that implements many specs |
+| `implement` | Queue a rail job for one or more specs (one aggregate run) |
 | `why` | Explain why a chunk of code looks the way it does |
 | `propose-spec` | Explore an idea and produce a structured spec proposal |
 | `get-backlog-specs` | View the prioritised spec backlog |
@@ -155,7 +155,7 @@ The app still tracks cost in Analytics under `surface=job`.
 
 ```bash
 specrails-desktop --project my-app implement "#42"
-specrails-desktop --project ~/repos/api-srv batch-implement "#5" "#6"
+specrails-desktop --project ~/repos/api-srv implement "#5" "#6"
 ```
 
 `--project` accepts a project **name** or a **path** (absolute, or relative starting with `.` / `..`). Use it when you want to launch work in a project from outside its directory (e.g. from a CI runner or your home directory). Both `--project` and `--port` may appear **anywhere** in the command, not just at the front.
@@ -197,7 +197,7 @@ specrails-desktop /opsx:archive      # archive to openspec/changes/archive/
 
 ## When the app isn't running
 
-If you invoke a command that routes work (`implement`, `batch-implement`, a raw prompt, …) while the app is not running, the CLI falls back to spawning the **`claude`** binary directly in the current directory. You'll see:
+If you invoke a command that routes work (`implement`, a raw prompt, …) while the app is not running, the CLI falls back to spawning the **`claude`** binary directly in the current directory. You'll see:
 
 ```
 [specrails-desktop] manager not running — invoking claude directly

package/docs/codex.md

@@ -54,7 +54,7 @@ binary isn't on `PATH`; it shows install commands if you click "More info".
    - `.codex/config.toml` — model, reasoning effort, sandbox mode, and
      approval policy (all top-level keys per the codex 0.128.0+ schema).
    - `.codex/skills/sr-*/SKILL.md` — general specrails skills
-     (implement, batch-implement, why, compat-check, …).
+     (implement, why, compat-check, …).
    - `.codex/skills/rails/sr-*/SKILL.md` — the pipeline rails.
    - `AGENTS.md` — top-level instructions file with a sentinel-protected
      managed block. Anything outside the sentinels is preserved on
@@ -126,7 +126,7 @@ The table below includes all four registered providers. See the
 | **Reasoning efforts** | `low`–`xhigh` | model-dependent | none | `low`/`high`/`max`, K3 only |
 | **Agent format** | `.claude/agents/<id>.md` | `.codex/skills/<id>/SKILL.md` | `.gemini/` target | `.kimi-code/skills/<id>/SKILL.md` |
 | **Agent profiles** | ✅ | legacy | legacy | ✅ provider-scoped |
-| **Implement / Batch** | ✅ | ✅ | ✅ | ✅ |
+| **Implement** | ✅ | ✅ | ✅ | ✅ |
 | **Freestyle** | ✅ | ❌ | ❌ | ✅ |
 | **Pure-output transforms** | capability-dependent | capability-dependent | capability-dependent | ❌ fail closed |
 | **MCP registration** | `.mcp.json` | isolated `CODEX_HOME` | `.gemini/settings.json` | `.kimi-code/mcp.json` |

package/docs/customizing.md

@@ -63,7 +63,7 @@ The daily counter is the sum of completed-job cost since midnight, so it resets
 
 ### Rail pre-prompt
 
-A custom instruction appended to every **Implement** and **Batch-implement** rail job, after the ticket context and before execution. Use it for stable project guidance that should accompany every rail run (e.g. "keep migrations backward compatible, add tests for every change"). Leave it blank for none.
+A custom instruction appended to every **Implement** rail job, after the ticket context and before execution. Use it for stable project guidance that should accompany every rail run (e.g. "keep migrations backward compatible, add tests for every change"). Leave it blank for none.
 
 ### Freestyle pre-prompt
 

package/docs/gemini.md

@@ -15,7 +15,7 @@ Specrails supports **four AI providers**: Anthropic's
 
 **What works with Gemini:** Explore Spec, Quick spec, AI Edit, the terminal
 "Open AI CLI" launcher, cost analytics, **and the full rails pipeline**
-(`/specrails:implement`, `batch-implement`). Gemini does not advertise
+(`/specrails:implement`). Gemini does not advertise
 **Freestyle rails**; choose Claude or Kimi for that autonomous rail mode.
 
 ## Prerequisites

package/docs/getting-started.md

@@ -103,7 +103,7 @@ The committed spec lands on your board with status `todo`.
 The right pane of the Dashboard is your **Rails** — execution lanes:
 
 1. Drag a spec card from the left pane onto a Rail.
-2. Pick a **Loop** in the rail header — start with the built-in **Implement** (the full pipeline). You can also pick **Batch**, **Freestyle**, or a custom loop you built in the **Loops** section. See [Running pipelines → Loops](running-pipelines.md#loops).
+2. Pick a **Loop** in the rail header — start with the built-in **Implement** (the full pipeline). You can also pick **Freestyle**, **SDD Quick (OpenSpec)**, or a custom loop you built in the **Loops** section. See [Running pipelines → Loops](running-pipelines.md#loops).
 3. (Optional) pick an **agent profile** from the rail header. This picker only appears once the project has profiles (create them on the **Agents** page); otherwise the rail runs in legacy mode (single orchestrator, no per-agent overrides).
 4. Press **▶ Play** on the rail.
 

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

@@ -15,7 +15,7 @@ Jede Verbindung hat außerdem die Einstellung **Agenten-Schleife**. **Kompakt**
 
 ## Was du bekommst
 
-- Rails (implement, batch, freestyle, eigene Loops), Explore und Quick-Specs, Chat und Missionen laufen auf dem lokalen Modell.
+- Rails (implement, freestyle, eigene Loops), Explore und Quick-Specs, Chat und Missionen laufen auf dem lokalen Modell.
 - Missionen behalten ihre Specrails-Tools und deine externen MCP-Server.
 - Sitzungen werden über Turns hinweg fortgesetzt; interaktive Jobs funktionieren.
 - Kosten sind ehrlich: Tokens werden erfasst, die Kosten bleiben *unbekannt*, sofern du keine Tarife einträgst (dann als *geschätzt* markiert).

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

@@ -18,12 +18,12 @@ SpecsBoard (links)          Rails (rechts)
 
 Eine Rail ist eine **Ausführungsspur**. Du ziehst eine Spec-Karte vom SpecsBoard auf eine Rail und drückst dann **▶ Play**. In Git-Repositories startet die Rail die Pipeline in einem isolierten Git-Worktree, damit die KI Dateien bearbeiten und Tests ausführen kann, ohne deinen aktiven Arbeitsbaum zu berühren. Ist das Projekt noch kein Git-Repo, degradiert Specrails klar sichtbar zur Ausführung im gemeinsamen Ordner und sagt dir, dass keine Branch- oder PR-Karte erscheinen wird.
 
-Du kannst mehrere rails anlegen, um deine Arbeit in benannten Spuren zu organisieren (eine für das Feature, an dem du gerade dran bist, eine weitere, die dahinter wartet). Rails sind **dynamisch**: Der **+ Hinzufügen**-Button im Rails-Header erstellt eine neue Spur (bis zu 12 pro Projekt), und leere, inaktive Spuren lassen sich löschen. Jede rail ist server-gestützt — dein Spuren-Set übersteht Reloads und ist für den mobilen Companion und den eingebauten Agenten sichtbar; der Agent kann sogar selbst eine rail anlegen, wenn alle Spuren belegt sind. Mehr zu mehreren rails und zum Stapelbetrieb findest du unter [Batch implement & Multi-Feature](batch-implement-and-multi-feature).
+Du kannst mehrere rails anlegen, um deine Arbeit in benannten Spuren zu organisieren (eine für das Feature, an dem du gerade dran bist, eine weitere, die dahinter wartet). Rails sind **dynamisch**: Der **+ Hinzufügen**-Button im Rails-Header erstellt eine neue Spur (bis zu 12 pro Projekt), und leere, inaktive Spuren lassen sich löschen. Jede rail ist server-gestützt — dein Spuren-Set übersteht Reloads und ist für den mobilen Companion und den eingebauten Agenten sichtbar; der Agent kann sogar selbst eine rail anlegen, wenn alle Spuren belegt sind.
 
 ## Eine Rail auf einer Spec starten
 
 1. **Zieh eine Spec-Karte** vom SpecsBoard auf eine rail. Die ID der Spec taucht in der Spec-Liste der rail auf. (Du ziehst lieber nicht? Nutze das **Move to rail**-Popover auf der Spec-Karte — es zeigt pro rail einen Status-Punkt, damit du keine Arbeit auf eine belegte Spur ablegst.)
-2. **Wähle einen Loop** im rail-Header. Eine rail führt einen **Loop** aus — das ist die Arbeit, die sie erledigt. Standard ist der eingebaute `Implement`-Loop; du kannst auch `Batch`, `Freestyle` oder einen selbst gebauten Loop wählen. Siehe [Der Loop Builder](the-loop-builder).
+2. **Wähle einen Loop** im rail-Header. Eine rail führt einen **Loop** aus — das ist die Arbeit, die sie erledigt. Standard ist der eingebaute `Implement`-Loop; du kannst auch `Freestyle` oder einen selbst gebauten Loop wählen. Siehe [Der Loop Builder](the-loop-builder).
 3. **Drück ▶ Play.**
 
 Das war's. Die rail startet einen KI-CLI-Prozess im richtigen Ausführungskontext und legt mit der Pipeline los.
@@ -34,25 +34,28 @@ Das war's. Die rail startet einen KI-CLI-Prozess im richtigen Ausführungskontex
 |---------|--------------|
 | **Status-Pill** | `idle`, `running` oder `failed`. Es gibt kein eigenes „completed“ — eine rail kehrt auf `idle` zurück, wenn ihr Job sauber durchläuft. |
 | **Spec-Liste** | Die IDs, die dieser rail zugewiesen sind. Zieh weitere hinein oder heraus, um sie wieder zu lösen. |
-| **Loop-Auswahl** | Der Loop, den diese rail ausführt — ein eingebauter (`Implement` / `Batch` / `Freestyle`) oder ein eigener Loop. Siehe Tabelle unten. Pro rail gespeichert. |
+| **Loop-Auswahl** | Der Loop, den diese rail ausführt — ein eingebauter (`Implement` / `Freestyle` / `SDD Quick (OpenSpec)`) oder ein eigener Loop. Siehe Tabelle unten. Pro rail gespeichert. |
 | **Profil-Auswahl** | Welches Provider-Profil läuft (Claude- und Kimi-Rails). |
 | **Engine-Auswahl** | Welcher Provider die Rail ausführt — Claude, Codex, Gemini oder Kimi. |
 | **▶ Play / ■ Stop** | Starten oder abbrechen. |
 
 ### Was eine rail ausführt: Loops
 
-Eine rail führt einen **Loop** aus — das Rezept für die Arbeit. Drei Loops sind **eingebaut** und decken die gängigen Fälle ab:
+Eine rail führt einen **Loop** aus — das Rezept für die Arbeit. Zwei Loops sind **eingebaut** und decken die gängigen Fälle ab:
 
 | Eingebauter Loop | Befehl | Was er macht |
 |------|---------|--------------|
 | **Implement** | `/specrails:implement` | Ein Job für alle Specs auf der rail. Durchläuft die komplette Pipeline Architect → Developer → Reviewer → Ship. Der Alltagsstandard. |
-| **Batch** | `/specrails:batch-implement` | Ein Job, der die Specs der rail nacheinander abarbeitet — in abhängigkeitsbewussten Wellen. Ideal für mehrere zusammenhängende Specs. |
 | **Freestyle** | Freestyle | Claude oder Kimi implementiert jede Spec eigenständig und **umgeht** dabei die Pipeline. |
 
+Für mehrere Specs legst du zusammengehörige (bis zu 3) auf eine rail — `Implement` führt sie als einen gemeinsamen Job aus — oder verteilst unabhängige Specs auf mehrere rails: Jede git-gestützte rail läuft parallel in ihrem eigenen isolierten Worktree.
+
 Freestyle nutzt native Tools und Modelle des Providers. Claude hat persistenten
 interaktiven Transport; Kimi nutzt einen agentischen `kimi -p`-Prozess ohne
 persistentes stdin.
 
+Auch die eingebauten Loops sind bearbeitbar: Bearbeite einen im Loop Builder und veröffentliche ihn, dann führt jede rail, die ihn wählt, deine Version aus (mit **Original wiederherstellen** gehst du zurück).
+
 Über die eingebauten Loops hinaus kannst du **deine eigenen Loops bauen** — einen verify → fix → verify-Zyklus wiederholen, bis ein Ziel erreicht ist, Shell-Befehle zwischen KI-Schritten verketten und mehr. Diese eigenen Loops erscheinen in derselben Loop-Auswahl. Das ist die nächste große Idee: [Der Loop Builder](the-loop-builder).
 
 ## Die Job-Queue
@@ -98,5 +101,4 @@ Wenn etwas nicht stimmt:
 
 - [Der Loop Builder](the-loop-builder) — was eine rail ausführt und wie du deine eigenen Loops baust.
 - [Die Job-Detail-Ansicht](the-job-detail-view) — Phasen, Live-Metriken, Ticket-Karten.
-- [Batch implement & Multi-Feature](batch-implement-and-multi-feature) — mehrere Specs auf einmal ausführen.
 - [Engine pro Rail wählen](picking-an-engine-per-rail) — Claude, Codex, Gemini oder Kimi.

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

@@ -22,7 +22,7 @@ Klick auf eine beliebige Job-Karte auf der **Jobs**-Seite, und du landest hier:
 
 ## Pipeline-Phasen
 
-Bei `Implement`- und `Batch`-Jobs durchläuft der Lauf die Phasen, die der Slash-Befehl definiert — standardmäßig:
+Bei `Implement`-Jobs durchläuft der Lauf die Phasen, die der Slash-Befehl definiert — standardmäßig:
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -113,5 +113,14 @@ Praktisch, um einen Lauf mit einem Teammitglied zu teilen oder einen präzisen F
 ## Wie es weitergeht
 
 - [Rails & Jobs](rails-and-jobs) — Starten und Einreihen in die Queue.
-- [Batch implement & Multi-Feature](batch-implement-and-multi-feature) — viele Specs, abhängigkeitsbewusste Wellen.
 - [Kosten verfolgen](../analytics/tracking-cost) — aus Kosten pro Job Projekt-Analysen machen.
+
+## Nach einem Workflow-Neustart
+
+Setze nach einem Absturz den gespeicherten Workflow mit seiner ursprünglichen Konfiguration und seinen ursprünglichen Repositorys fort. Prüfe bei einem unterbrochenen Schreibvorgang zuerst den Worktree-Diff und wähle dann den genauen Versuch aus. Abgeschlossene Schritte bleiben erhalten. Ein Anbieteraufruf mit verlorener Antwort wird weiterhin als unterbrochen mit unbekanntem Verbrauch gezählt, niemals als kostenlos. Lässt sich die ursprüngliche Auslieferung anhand der gespeicherten Daten nicht belegen, zeigt die Wiederherstellung einen Fehler und erhält den Worktree.
+
+Wenn ein Entscheidungsschritt wegen einer Frage pausiert, verwendet die Fortsetzung die gespeicherte Entscheidung und gibt die menschliche Antwort an den nächsten Schritt weiter. Das Modell wird für dieselbe Entscheidung nicht erneut aufgerufen. Ein pausierter Prompt kann einen weiteren Modellaufruf benötigen, um Ihre Antwort umzusetzen.
+
+## Aufbewahrung des Verlaufs
+
+Gespeicherte Ausführungen werden standardmäßig unbegrenzt aufbewahrt. Unter **Gespeicherte Ausführungen → Aufbewahrung des Verlaufs** kann ein Projekt sie stattdessen 1 bis 3650 Tage aufbewahren. Im Hintergrund wird nichts gelöscht: Speichere die Richtlinie, wähle **Bereinigung prüfen** und prüfe jede Ausführung samt Grund, bevor du **Abgelaufenen Verlauf löschen** wählst. Eine Ausführung bleibt geschützt, solange sie aktiv ist, auf deine Antwort oder Freigabe wartet, einen unterbrochenen Schreibvorgang, eine offene Auslieferung oder einen davon abhängigen Fork hat. Entfernt wird nur der Laufzeitverlauf im Specrails-Speicher des Projekts; Repository, Worktrees, Job-Log und Kostendaten bleiben erhalten. Eine abgelaufene Ausführung wird als **Abgelaufen** angezeigt und kann nicht mehr fortgesetzt oder geforkt werden. Core-Versionen, die eine verbleibende Ausführung noch nutzt, bleiben immer erhalten.

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

@@ -21,14 +21,14 @@ Die ausgewählte Engine führt jede Phase der Pipeline dieser Rail aus. Ist die
 
 ## Wofür jede Engine gut ist
 
-Alle vier führen **Implement** und **Batch** aus:
+Alle vier führen **Implement** aus:
 
 | Engine | Greif dazu, wenn… | Hinweise |
 |--------|--------------------|-------|
 | **Claude** | Du native Kosten, persistente Interaktion oder strikte Tool-Policies brauchst. | Profile, Freestyle und strukturierte Transforms. |
 | **Codex** | Du die OpenAI Codex CLI bevorzugst oder Implementierungen über verschiedene Provider hinweg vergleichen willst. | `codex` ≥ 0.128.0. Keine native Kostenmeldung — die App ergänzt die Kosten aus ihrer Preistabelle. Profile gelten nicht. |
 | **Gemini** | Du Googles Gemini CLI, native Telemetrie oder einen günstigeren Lauf für Routine-Specs willst. | `gemini` ≥ 0.11.0 (setze `GEMINI_API_KEY`). Native OTLP-Telemetrie. Profile gelten nicht. |
-| **Kimi** | Du agentisches Kimi für Implement, Batch, Freestyle oder Loops ohne Decider willst. | Externes `kimi` ≥ 0.27.0; Profile/Rollen, Effort nur K3; Tokens/Kosten nicht verfügbar. |
+| **Kimi** | Du agentisches Kimi für Implement, Freestyle oder Loops ohne Decider willst. | Externes `kimi` ≥ 0.27.0; Profile/Rollen, Effort nur K3; Tokens/Kosten nicht verfügbar. |
 
 ### Fähigkeitsunterschiede
 

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

@@ -1,6 +1,16 @@
 # Der Loop Builder
 
-Eine **rail führt einen Loop aus**. Die eingebauten Loops (`Implement`, `Batch`, `Freestyle`) decken die Alltagsfälle ab, aber der **Loop Builder** lässt dich deine eigenen entwerfen — ein visueller Editor im n8n-Stil für Automatisierung, die sich wiederholt, bis ein Ziel erreicht ist. Diese Seite erklärt, was ein Loop ist, wie du einen baust und wie du ihn auf einer rail ausführst.
+## Core-Workflows
+
+Mit einer kompatiblen Core-Engine zeigt ein neuer Canvas die siebzehn Schritte des installierten Katalogs. Klicke auf einen Schritt oder ziehe ihn auf den Canvas und fülle das Formular aus. Anbieter und Rollen stammen aus dem aktiven Projekt. Verbinde jeden benannten Ausgang mit einem weiteren Schritt oder Ende. Jeder Ausgang erlaubt eine Verbindung.
+
+Die Formulare unterstützen optionale Felder, Objekte, Listen und Wörterbücher für alle Schritte: KI, Bedingungen, Prüfung, Shell, OpenSpec, Freigaben, Fragen, Pausen, Zuordnung, Zusammenführung, Komponenten und Implementierung. Workflow-Optionen enthalten Token- und Übergangslimits sowie Parallelität. Das Übergangslimit zählt auch Besuche in Komponenten und Zweigen.
+
+Erstelle unter **Komponenten** einen wiederverwendbaren Ablauf, deklariere Eingaben und Ausgaben und wähle ihn in Komponente oder Zuordnen. Die Navigation kehrt ohne Datenverlust zum Hauptworkflow zurück. Ein lokales Ende wählt seine Komponentenausgabe optional über `exit`.
+
+Beim Veröffentlichen validiert Core den Entwurf und markiert fehlerhafte Schritte. Beim Start wird die Projektkonfiguration erneut geprüft. Aktualisiere Core, wenn die Engine fehlt. Bestehende Desktop-Loops behalten ihren bisherigen Editor und Ablauf; die folgenden Abschnitte beschreiben diese.
+
+Eine **rail führt einen Loop aus**. Die eingebauten Loops (`Implement`, `Freestyle`, `SDD Quick (OpenSpec)`) decken die Alltagsfälle ab, aber der **Loop Builder** lässt dich deine eigenen entwerfen — ein visueller Editor im n8n-Stil für Automatisierung, die sich wiederholt, bis ein Ziel erreicht ist. Diese Seite erklärt, was ein Loop ist, wie du einen baust und wie du ihn auf einer rail ausführst.
 
 ## Loops und rails — die Beziehung
 
@@ -10,9 +20,8 @@ Ein **Loop** ist das *Rezept* für die Arbeit; eine **rail** ist die *Spur*, die
    Loop Builder (linke Seitenleiste)        Rails (rechts)
    ───────────────────────────             ─────────────
    Implement   (eingebaut)                  Rail 1
-   Batch       (eingebaut)     wählen auf ►    Loop: Verify-until-green
-   Freestyle   (eingebaut)                     ▶ Play
-   Verify-until-green (deiner)
+   Freestyle   (eingebaut)     wählen auf ►    Loop: Verify-until-green
+   Verify-until-green (deiner)                     ▶ Play
 ```
 
 - Loops leben im **Loops**-Bereich (linke Seitenleiste, neben deinen Projekten) — sie sind **global**, projektübergreifend geteilt.
@@ -25,7 +34,7 @@ Also: Bau einen Loop einmal, dann wähl ihn auf jeder rail in jedem Projekt.
 
 Klick **Loops** in der linken Seitenleiste, um die Bibliothek zu sehen: die drei eingebauten Loops plus alle deine eigenen. Öffne einen, um ihn anzusehen, oder klick **New loop**, um mit einer leeren Leinwand zu starten.
 
-Einen eingebauten Loop kannst du nicht ohne Weiteres direkt bearbeiten — stattdessen **Fork** ihn. Das gibt dir eine bearbeitbare Kopie eines funktionierenden Graphen als Ausgangspunkt, was der einfachste Weg zum Lernen ist.
+Eingebaute Loops sind echte, bearbeitbare Loops. Öffne einen mit **Edit** und ändere ihn wie jeden anderen Loop: Beim Speichern wird er zum Entwurf, und **Publish** wendet deine Version auf **jede Rail, jeden Start aus dem Agenten-Chat und jeden Companion-Start an, der diesen eingebauten Loop verwendet**. Solange deine Änderung ein Entwurf ist, führen Rails weiter die zuletzt veröffentlichte Version aus – mitten im Bearbeiten geht also nichts kaputt. **Original wiederherstellen** (auf der Karte oder im Builder) setzt einen eingebauten Loop auf die Standardversion zurück; eingebaute Loops lassen sich nicht löschen. Lieber eine separate Kopie? Nutze **Duplicate** – das erzeugt einen normalen Loop und lässt den eingebauten unverändert.
 
 ## Woraus ein Loop besteht
 
@@ -93,3 +102,13 @@ Der Lauf streamt live in der **Jobs**-Ansicht, mit denselben Metriken und dersel
 - [Rails & Jobs](rails-and-jobs) — rails starten und die Job-Queue.
 - [Die Job-Detail-Ansicht](the-job-detail-view) — einem Lauf live zusehen.
 - [Eine Engine pro Rail wählen](picking-an-engine-per-rail) — die rail (nicht der Loop) wählt den Provider.
+
+Wenn die ausgewählte Core-Version Aufruflimits bereitstellt, bieten Prompt-, Rollen- und Decider-Bausteine `timeoutMs` und `idleTimeoutMs` an. Mit `0` deaktivierst du den jeweiligen Timer des Schritts; entfernst du das Feld, wird der Standardwert übernommen. Budgets des gesamten Workflows und der Abbruch bleiben wirksam. Stellt ein Verifizierungsschritt eine blockierende Frage, wartet er auf deine Antwort, bevor er ein erfolgreiches Ergebnis akzeptiert.
+
+Wenn ein gespeicherter älterer Graph erstmals durch Core-Bausteine ersetzt wird, bleibt sein ursprünglicher Graph erhalten. Die Bibliothek bietet dann **Ursprünglichen Graphen exportieren** an. Der Export erhält einen eigenen Namen, damit du ihn als separaten Entwurf importieren kannst, ohne den aktuellen Workflow zu ersetzen. Konvertierungen und spätere Änderungen veröffentlichen einen Loop niemals automatisch.
+
+Mit **Variablen setzen** bleibt Zustand über eine Pause hinweg erhalten: Setzen Sie typisierte JSON-Werte oder ändern Sie einen bestehenden ganzzahligen Zähler. Dieser Baustein ruft keine KI auf. Alle Änderungen werden gemeinsam gespeichert; ein ungültiger Zähler lässt sämtliche Variablen unverändert. Variablen einer zugeordneten Komponente bleiben auf diese Komponente beschränkt.
+
+Beim Decider schützt **Fortsetzen, solange diese Bedingung erfüllt ist** noch offene Pflichtaufgaben. Beispielsweise wandelt `$vars.failedPass == true` einen Stoppvorschlag in eine Fortsetzung um, bis der Workflow das Kennzeichen löscht. Die Entscheidung wird weiterhin ausgeführt; unveränderte Wiederholungen unterliegen weiterhin der Fortschrittsgrenze. Rückfragen pausieren weiterhin bis zur Antwort.
+
+Wähle in der Loop-Bibliothek **In Core umwandeln**, um einen gespeicherten Loop der bisherigen Engine zu migrieren. Wähle das ursprüngliche Repository, wenn ein Shell-Schritt keinen expliziten Bereich hat. Die Konvertierung validiert den Graphen und speichert einen Entwurf samt exportierbarer Originalkopie. Prüfe die Verbindungen und veröffentliche ausdrücklich. Laufende Loops können nicht konvertiert werden; gleichzeitige Änderungen bleiben erhalten. Schreibende Schritte benötigen echte Prüfkommandos. Quick SDD nutzt das in Core enthaltene OpenSpec. Aktualisiere Core, falls die Konvertierung nicht verfügbar ist.

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

@@ -15,7 +15,7 @@ Each connection also has an **Agent loop** setting. **Compact** (default) drives
 
 ## What you get
 
-- Rails (implement, batch, freestyle, custom loops), Explore and Quick specs, chat and missions all run on the local model.
+- Rails (implement, freestyle, custom loops), Explore and Quick specs, chat and missions all run on the local model.
 - Missions keep their Specrails tools and your external MCP servers.
 - Sessions resume across turns; interactive jobs work.
 - Cost is honest: tokens are recorded, cost stays *unknown* unless you enter rates (then it is marked *estimated*).

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

@@ -18,12 +18,12 @@ SpecsBoard (left)            Rails (right)
 
 A rail is an **execution lane**. You drag a spec card from the SpecsBoard onto a rail, then press **▶ Play**. For git repositories, the rail launches the pipeline in an isolated git worktree so the AI can edit files and run tests without touching your active working tree. If the project is not a git repo yet, Specrails clearly degrades to shared-folder execution and tells you that no branch or PR card will appear.
 
-You can have several rails to organise work into named lanes (one for the feature you're focused on, another queued behind it). Rails are **dynamic**: the **+ Add** button in the Rails header creates a new lane (up to 12 per project) and idle empty lanes can be deleted. Every rail is server-backed, so your set of lanes survives reloads and is visible to the mobile companion and the in-app agent — the agent can even create a rail itself when all lanes are busy. More on multi-rail and batching in [Batch implement & multi-feature](batch-implement-and-multi-feature).
+You can have several rails to organise work into named lanes (one for the feature you're focused on, another queued behind it). Rails are **dynamic**: the **+ Add** button in the Rails header creates a new lane (up to 12 per project) and idle empty lanes can be deleted. Every rail is server-backed, so your set of lanes survives reloads and is visible to the mobile companion and the in-app agent — the agent can even create a rail itself when all lanes are busy.
 
 ## Launching a rail on a spec
 
 1. **Drag a spec card** from the SpecsBoard onto a rail. The spec's ID shows up in the rail's spec list. (Prefer not to drag? Use the **Move to rail** popover on the spec card — it shows a status dot per rail so you don't drop work onto a busy lane.)
-2. **Pick a Loop** in the rail header. A rail runs a **Loop** — that's the work it performs. The default is the built-in `Implement` loop; you can also pick `Batch`, `Freestyle`, or a custom loop you built yourself. See [The Loop Builder](the-loop-builder).
+2. **Pick a Loop** in the rail header. A rail runs a **Loop** — that's the work it performs. The default is the built-in `Implement` loop; you can also pick `Freestyle`, or a custom loop you built yourself. See [The Loop Builder](the-loop-builder).
 3. **Press ▶ Play.**
 
 That's it. The rail spins up an AI CLI process in the right execution context and starts the pipeline.
@@ -34,27 +34,30 @@ That's it. The rail spins up an AI CLI process in the right execution context an
 |---------|--------------|
 | **Status pill** | `idle`, `running`, or `failed`. There's no separate "completed" — a rail returns to `idle` when its job finishes cleanly. |
 | **Spec list** | The IDs assigned to this rail. Drag more in, drag them out to detach. |
-| **Loop picker** | The Loop this rail runs — a built-in (`Implement` / `Batch` / `Freestyle`) or a custom loop. See the table below. Persisted per rail. |
+| **Loop picker** | The Loop this rail runs — a built-in (`Implement` / `Freestyle` / `SDD Quick (OpenSpec)`) or a custom loop. See the table below. Persisted per rail. |
 | **Profile picker** | Which provider-scoped agent profile runs (Claude and Kimi rails). Only appears once the effective provider has at least one profile. |
 | **Engine selector** | Which installed provider runs this rail — Claude, Codex, Gemini, or Kimi. Only renders when the project has more than one provider. See [Picking an engine per rail](picking-an-engine-per-rail). |
 | **▶ Play / ■ Stop** | Start or cancel. |
 
 ### What a rail runs: Loops
 
-A rail runs a **Loop** — the recipe for the work. Three loops are **built in** and cover the common cases:
+A rail runs a **Loop** — the recipe for the work. Two loops are **built in** and cover the common cases:
 
 | Built-in loop | Command | What it does |
 |------|---------|--------------|
 | **Implement** | `/specrails:implement` | One job covering all specs on the rail. Runs the full Architect → Developer → Reviewer → Ship pipeline. The everyday default. |
-| **Batch** | `/specrails:batch-implement` | One job that works through the rail's specs sequentially, in dependency-aware waves. Best for several related specs. |
 | **Freestyle** | Freestyle | A capable provider implements each spec autonomously, **bypassing** the pipeline. One independent job per spec. Claude and Kimi support it. |
 
+To run several specs, put related ones (up to 3) on one rail — `Implement` runs them as one aggregate job — or spread independent specs across several rails: each git-backed rail runs in parallel in its own isolated worktree.
+
 Freestyle is the odd one out: it skips the agent chain and hands the capable
 provider the raw spec to work on with native tools. It's open-ended, so
 pressing Play opens a confirmation first, and its model picker follows that
 provider's catalog. Claude uses its persistent live-session flow; Kimi uses an
 owned agentic `kimi -p` process and has no persistent stdin.
 
+The built-ins are editable, too: edit one in the Loop Builder and publish it, and every rail that picks it runs your version (use **Restore original** to go back).
+
 Beyond the built-ins, you can **build your own loops** — repeat a verify → fix
 → verify cycle until a goal is met, chain shell commands between AI steps, and
 more. Kimi runs loops without a Loop Decider; its `-p` transport cannot enforce
@@ -107,5 +110,4 @@ If something looks wrong:
 
 - [The Loop Builder](the-loop-builder) — what a rail runs, and how to build your own loops.
 - [The Job Detail view](the-job-detail-view) — phases, live metrics, ticket cards.
-- [Batch implement & multi-feature](batch-implement-and-multi-feature) — run several specs at once.
 - [Picking an engine per rail](picking-an-engine-per-rail) — Claude vs Codex vs Gemini vs Kimi.

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

@@ -22,7 +22,7 @@ Two panels sit above the full streaming log; on a running Claude job, a chat com
 
 ## Pipeline phases
 
-For `Implement` and `Batch` jobs, the run moves through the phases defined by the slash command — by default:
+For `Implement` jobs, the run moves through the phases defined by the slash command — by default:
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -113,5 +113,14 @@ Handy for sharing a run with a teammate, or filing a precise bug report.
 ## Where to go next
 
 - [Rails & jobs](rails-and-jobs) — launching and queueing.
-- [Batch implement & multi-feature](batch-implement-and-multi-feature) — many specs, dependency waves.
 - [Tracking cost](../analytics/tracking-cost) — turn per-job costs into project analytics.
+
+## After a workflow restart
+
+After a crash, resume the saved workflow with its original configuration and repositories. An interrupted write requires selecting the exact attempt after inspecting the worktree diff. Completed steps are reused. A provider call whose response was lost remains counted as interrupted with unknown usage; it is never reported as free. If the original delivery cannot be proven from saved records, recovery shows an error and preserves the worktree.
+
+When a decision step pauses for a question, resuming reuses its saved decision and sends the human answer to the following step. It does not call the model again for that same decision. A paused prompt can need another model turn to act on your answer.
+
+## History retention
+
+Saved executions are kept indefinitely by default. In **Saved executions → History retention**, a project can keep them for 1 to 3650 days instead. Nothing is deleted in the background: save the policy, choose **Preview cleanup** and review each run and its reason before **Delete expired history**. A run stays protected while it is active, waiting for your answer or approval, has an interrupted write, has an open delivery or a fork that still depends on it. Only runtime history under the project's Specrails storage is removed; your repository, worktrees, job log and cost records remain. An expired run shows as **Expired** and can no longer be resumed or forked. Core versions still used by a surviving run are always kept.

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

@@ -23,14 +23,14 @@ The selected engine runs every phase of that rail's pipeline. If the chosen engi
 
 ## What each engine is good at
 
-All four run the standard **Implement** and **Batch** pipelines. Here's a practical guide to choosing:
+All four run the standard **Implement** pipeline. Here's a practical guide to choosing:
 
 | Engine | Reach for it when… | Notes |
 |--------|--------------------|-------|
 | **Claude** | You want native billed cost, persistent job interaction, and the richest hard tool-policy controls. | Supports profiles, Freestyle, and structured transforms such as Contract Layer/SMASH. |
 | **Codex** | You prefer the OpenAI Codex CLI or want to compare implementations across providers. | `codex` ≥ 0.128.0. No native cost reporting — the app fills in cost from its rate card. Profiles don't apply. |
 | **Gemini** | You want Google's Gemini CLI, native telemetry, or a cheaper run for routine specs. | `gemini` ≥ 0.11.0 (set `GEMINI_API_KEY`). Native OTLP telemetry. Profiles don't apply. |
-| **Kimi** | You want Kimi Code's autonomous agentic CLI for implementation, Batch, Freestyle, or loops without a Decider. | External `kimi` ≥ 0.27.0. Profiles/manual roles and K3 low/high/max effort are supported; tokens and USD cost are unavailable. |
+| **Kimi** | You want Kimi Code's autonomous agentic CLI for implementation, Freestyle, or loops without a Decider. | External `kimi` ≥ 0.27.0. Profiles/manual roles and K3 low/high/max effort are supported; tokens and USD cost are unavailable. |
 
 ### Capability differences
 

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

@@ -1,6 +1,18 @@
 # The Loop Builder
 
-A **rail runs a Loop**. The built-in loops (`Implement`, `Batch`, `Freestyle`) cover the everyday cases, but the **Loop Builder** lets you design your own — a visual, n8n-style editor for automation that repeats until a goal is met. This page explains what a loop is, how to build one, and how to run it on a rail.
+## Core workflows
+
+With a compatible Core engine, a new canvas shows the installed catalog of seventeen pieces. Click or drag a piece onto the canvas, select it, and complete its parameter form. Provider and role choices come from the active project. A piece's named output handles show the outcomes it can produce; connect each outcome to another piece or an End. A source outcome can have one connection.
+
+The catalog includes prompts, role turns, decisions, conditions, verification, shell, OpenSpec validation and archival, approvals, questions, gates, maps, joins, reusable components, implementation and End. Optional fields, nested objects, arrays and dictionary values are editable through the form. **Workflow options** also exposes token and transition limits and concurrency policies. An explicit transition limit counts all visits inside components and map branches.
+
+Create a reusable body under **Components**, declare its input variables and output labels, then select it from a Component or Map piece. The breadcrumb returns to the root canvas without losing edits. A component End has a business outcome and an optional `exit` matching one of the component's output labels.
+
+**Publish** sends the draft to Core for validation. Errors appear in the problems panel and highlight the affected nodes. Launch validates the selected project's effective configuration again. The installed Core owns the execution format and its hash. If it is unavailable, update Core to author or publish these workflows; existing Desktop loops keep their original editor and execution behavior.
+
+The remaining sections describe the existing Desktop loop nodes and rail behavior.
+
+A **rail runs a Loop**. The built-in loops (`Implement`, `Freestyle`, `SDD Quick (OpenSpec)`) cover the everyday cases, but the **Loop Builder** lets you design your own — a visual, n8n-style editor for automation that repeats until a goal is met. This page explains what a loop is, how to build one, and how to run it on a rail.
 
 ## Loops and rails — the relationship
 
@@ -10,9 +22,8 @@ A **loop** is the *recipe* for the work; a **rail** is the *lane* that runs it a
    Loop Builder (left sidebar)             Rails (right)
    ───────────────────────────             ─────────────
    Implement   (built-in)                  Rail 1
-   Batch       (built-in)      pick on ►      Loop: Verify-until-green
-   Freestyle   (built-in)                     ▶ Play
-   Verify-until-green (yours)
+   Freestyle   (built-in)      pick on ►      Loop: Verify-until-green
+   Verify-until-green (yours)                     ▶ Play
 ```
 
 - Loops live in the **Loops** section (left sidebar, alongside your projects) — they are **global**, shared across every project.
@@ -25,7 +36,7 @@ So: build a loop once, then pick it on any rail in any project.
 
 Click **Loops** in the left sidebar to see the library: the three built-in loops plus any of your own. Open one to view it, or click **New loop** to start from a blank canvas.
 
-You can't easily edit a built-in directly — instead **Fork** it. That gives you an editable copy of a working graph to start from, which is the easiest way to learn.
+Built-in loops are real, editable loops. Open one with **Edit** and change it like any other loop: saving turns it into a Draft, and **Publish** applies your version to **every rail, agent-chat launch and Companion launch that uses that built-in**. While your edit is a Draft, rails keep running the last published version, so nothing breaks mid-edit. **Restore original** (on the card or in the builder) resets a built-in to its default; built-ins cannot be deleted. Prefer a separate copy? Use **Duplicate** — it creates an ordinary loop that leaves the built-in untouched.
 
 ## What a loop is made of
 
@@ -94,3 +105,21 @@ The run streams live in the **Jobs** view with the same metrics and cost trackin
 - [Rails & jobs](rails-and-jobs) — launching rails and the job queue.
 - [The Job Detail view](the-job-detail-view) — watching a run live.
 - [Picking an engine per rail](picking-an-engine-per-rail) — the rail (not the loop) picks the provider.
+
+When the selected Core exposes invocation limits, prompt, role and decider
+pieces offer `timeoutMs` and `idleTimeoutMs`. Set a limit to `0` to disable that
+step timer, or remove the field to inherit the default. Whole-workflow budgets
+and cancellation still apply. A verification step that asks a blocking question
+waits for your answer before accepting a success result.
+
+When a saved legacy graph is first replaced with Core pieces, its original graph is preserved. The library then offers **Export original graph**. The export has a distinct name so you can import it as a separate draft without replacing the current workflow. Conversion and later edits never publish a loop automatically.
+
+Use **Set variables** for state that must survive a pause: set typed JSON values or adjust an existing integer counter. This piece makes no AI call. All updates commit together; an invalid counter leaves every variable unchanged. Variables in a mapped component remain local to that component.
+
+For a Decider, **Continue while this condition holds** can protect unfinished required work. For example, `$vars.failedPass == true` converts a stop proposal into continue until the workflow clears that flag. The decision still runs, and repeated unchanged work remains subject to the no-progress limit. Human questions still pause for an answer.
+
+To migrate a saved legacy loop, choose **Convert to Core** in the loop library. Select the original repository when a shell step has no explicit scope. Conversion validates the graph and saves a draft with an exportable copy of the original. Review the connected steps and publish explicitly. Running loops cannot be converted; conflicting edits are preserved. Converted writers require real verification commands, and Quick SDD uses the OpenSpec version included in Core. Update Core if conversion is unavailable.
+
+To see which saved loops still need attention, open **Core migration check** in the loop library and choose **Check**. It lists loops the installed Core rejects, loops ready to convert and loops that need a repository or other fix. It never converts or publishes anything on its own.
+
+A future Core that runs only Core workflows refuses to launch an unconverted loop on a rail. Desktop shows a message that points you to **Convert to Core** instead of starting a run that would fail midway. Runs that already started keep the Core version that created them.

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

@@ -52,4 +52,4 @@ Loop history stores a terminal result independently of optional provider telemet
 It separates process execution from Core acceptance and delivery, and distinguishes
 steps, decider evaluations and agent turns. Phase durations and attempts come from
 Core's journal; no per-phase cost is inferred from the total. Older runtimes keep
-acceptance evidence unavailable. See the implementation result in the batch guide.
+acceptance evidence unavailable.

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

@@ -15,7 +15,7 @@ Cada conexión tiene además un ajuste **Bucle del agente**. **Compacto** (por d
 
 ## Qué obtienes
 
-- Rails (implement, batch, freestyle, loops personalizados), Explore y specs Quick, chat y misiones se ejecutan con el modelo local.
+- Rails (implement, freestyle, loops personalizados), Explore y specs Quick, chat y misiones se ejecutan con el modelo local.
 - Las misiones conservan sus herramientas Specrails y tus servidores MCP externos.
 - Las sesiones se reanudan entre turnos; los jobs interactivos funcionan.
 - El coste es honesto: se registran los tokens, el coste queda *desconocido* salvo que indiques tarifas (entonces se marca *estimado*).