specrails-desktop 2.24.0 → 2.24.2

package/README.md

@@ -25,7 +25,7 @@
 **Specrails Desktop** (`specrails-desktop`) turns *"I'll just let the AI do it"* into a workflow you can **see, steer, and trust**. It's the desktop app for specrails — a local-first dashboard and CLI that sits on top of [**specrails-core**](https://github.com/fjpulidop/specrails-core) and gives you **one window for all your projects**:
 
 - 💬 Shape a spec in conversation with an AI, or generate one in a single shot.
-- 🛤️ Drag specs onto **execution rails**, pick a **Loop** to run (built-in or your own), and ship — one job at a time per project, in parallel across projects.
+- 🛤️ Drag specs onto **execution rails**, pick a **Loop** to run (built-in or your own), and ship — rails run in parallel inside a git-backed project, each isolated in its own worktree.
 - 🤖 Watch the **Architect → Developer → Reviewer → Ship** pipeline stream live — and **talk to the running job**: ask questions or steer it mid-run from the built-in composer.
 - 💰 See exactly **what each agent cost you** this week, per provider, per ticket.
 
@@ -51,10 +51,10 @@
 
 | | |
 |---|---|
-| 🛤️ **Execution rails** | Each rail is an independent lane. Drag specs in, **pick a Loop**, and press Play. Within a project, jobs run **one at a time** (rails let you queue and organise the work); true parallelism is **across projects**. Each rail carries its own **agent profile** and provider. |
+| 🛤️ **Execution rails** | Each rail is an independent lane. Drag specs in, **pick a Loop**, and press Play. In git-backed projects, rails run in parallel inside isolated per-spec worktrees, so several lanes can build at once without touching your active working tree. Each rail carries its own **agent profile** and provider. |
 | 🔁 **Loops** | A global, visual **Loop Builder** (n8n-style). The built-in loops — **Implement**, **Batch**, **Freestyle** — are what a rail runs by default, or build your own: chain AI steps, shell commands and a **Loop Decider** that repeats until a goal is met (e.g. *verify → fix → verify until green*). Publish a loop and pick it on any rail. See [Running pipelines](docs/running-pipelines.md). |
 | 🧩 **Agent profiles** | A per-project, declarative catalog that tells the implement pipeline which agents to run and at what model — snapshotted per job so concurrent rails stay isolated. |
-| 🔀 **Safe PR delivery (ask-first)** | Each rail runs in an isolated **git worktree** off your designated integration branch (set it in *Settings → Integration branch*). When it finishes, nothing is pushed and no PR exists yet — the specs move to **On Review** and the app **asks you first**: **Create PR** (one combined draft PR across all the specs on the rail) or **Discard** (clean up, specs back to the backlog). After creating it you can **Publish** (open the draft for your team's review) and **Check merge** — once your team merges it in GitHub, the specs flip to Done. specrails **never merges and never touches your working tree**. Set `SPECRAILS_RAIL_DELIVER_PR=0` to fall back to local integration. |
+| 🔀 **Safe PR delivery (ask-first)** | Fresh work runs in an isolated **git worktree** off your designated integration branch (set it in *Settings → Integration branch*). When it finishes, nothing is pushed and no PR exists yet — the specs move to **On Review** and the app **asks you first**: **Create PR** (one combined draft PR across all the specs on the rail) or **Discard** (clean up, specs back to the backlog). If you relaunch a spec that is already in review with an open PR, specrails detects that active PR and continues its head branch instead of starting from the integration branch again. After a PR exists you can **Publish** (open the draft for your team's review) and **Check merge** — once your team merges it in GitHub, the specs flip to Done. specrails **never merges and never touches your working tree**. Projects without git degrade to shared-folder execution with no branch or PR card. Set `SPECRAILS_RAIL_DELIVER_PR=0` to fall back to local integration. |
 | 📡 **Live job detail** | A premium ticket-identity header, live duration ticker, incremental turns/tokens, and authoritative cost on exit. Every Claude job is a **live session**: a chat composer on the job view lets you ask the running agent questions or steer it mid-run — messages queue while it streams, and the job still finishes its plan (Freestyle waits for your explicit **Finalize**; everything else wraps up on its own). |
 | 🔌 **Plugins** | A per-project marketplace of MCP-based integrations (**Serena** semantic code-nav bundled today). Additive by design — installing plugin N+1 never disturbs plugin N. |
 
@@ -159,7 +159,8 @@ When the app is running, the CLI talks to it over HTTP + WebSocket; when it isn'
   - **[Claude Code](https://claude.com/claude-code)** — the `claude` binary, signed in (via Claude subscription login or an `ANTHROPIC_API_KEY`). No minimum version pinned.
   - **[Codex CLI](https://developers.openai.com/codex)** ≥ 0.128.0 — the `codex` binary. Run `codex login` or set `OPENAI_API_KEY`.
   - **[Gemini CLI](https://github.com/google-gemini/gemini-cli)** ≥ 0.11.0 — the `gemini` binary, authenticated (set `GEMINI_API_KEY`).
-- 🌿 **git**
+- 🌿 **git** — required for isolated worktrees, branch-based resume, and PR delivery. Non-git projects still run in shared-folder mode, but no branch or PR card is created.
+- 🔀 *(optional but recommended)* **GitHub CLI (`gh`)** authenticated — required when you want Specrails to create, publish, check, or continue GitHub pull requests for rail deliveries.
 - 🧪 *(optional)* **`uv`** — only if you want the Serena plugin
 - 📦 **specrails-core** ≥ 4.8.0 in the project *(the wizard installs it)* — a single shared floor for all providers; 4.8.0 is the release that ships the Gemini target. Agent profiles need core ≥ 4.1.0 in the project.
 

package/docs/guide/de/integrations/3-jira-integration.md

@@ -7,7 +7,8 @@ Du möchtest, dass deine Specs auf einem echten **Jira-Board** leben statt in Sp
 Specrails agiert als **Sync-Schicht** zwischen Jira und deinem Projekt. Die Grundidee: Dein lokaler Spec-Speicher bleibt das Maßgebliche, das die Pipeline liest, und Specrails ist dafür verantwortlich, ihn und Jira in Übereinstimmung zu halten.
 
 - Wenn du eine Rail startest, verschiebt Specrails den verknüpften Jira-Vorgang nach **In Arbeit**.
-- Wenn ein Job abschließt, überführt Specrails den Vorgang: bei Erfolg in deinen gemappten **Prüf**-Status — **Fertig** wird er erst, wenn du die Arbeit freigibst (das Mergen der Entwurfs-PR postet einen „PR merged"-Kommentar); bei Fehlschlag zurück nach **To Do** mit einem Abschlusskommentar (Job-ID, Kosten, Dauer).
+- Wenn ein Job abschließt, überführt Specrails den Vorgang: bei Erfolg in deinen gemappten **Prüf**-Status — **Fertig** wird er erst, wenn die Liefer-PR gemerged oder das lokale Ergebnis akzeptiert wurde; bei Fehlschlag zurück nach **To Do** mit einem Abschlusskommentar, der Ergebnis, Run-ID, Kosten, Dauer und die Jira-Statusänderung enthält.
+- Wenn du Follow-up-Änderungen anfragst, während der Jira-Vorgang bereits in Prüfung ist, versucht Specrails, die bestehende offene PR-Branch für dieses Ticket fortzusetzen, statt eine neue Branch zu erstellen. Falls dein Jira-Prüfstatus nicht explizit gemappt ist und lokal noch als **In Arbeit** erscheint, kann Specrails die PR trotzdem fortsetzen, wenn der Jira-Schlüssel zum offenen Pull-Request passt.
 - In regelmäßigen Abständen **pollt** Specrails Jira nach Änderungen, die jemand auf dem Board vorgenommen hat, und spiegelt sie zurück in deine Specs.
 
 Alle Rückschreibungen laufen über eine dauerhafte, absturzsichere Outbox, sodass ein kurzzeitiger Jira-Aussetzer niemals einen Job kaputtmacht — das Update wird einfach erneut versucht.
@@ -32,7 +33,7 @@ Dein Token wird **verschlüsselt auf deinem eigenen Rechner** gespeichert und ve
 
 ## Statuszuordnung
 
-Der kniffligste Teil jeder Jira-Synchronisierung ist es, *deinen* Workflow auf die einfachen Zustände von Specrails abzubilden (To Do / In Arbeit / Fertig, plus Abbruch-/Ship-Varianten). Specrails löst das in zwei Stufen:
+Der kniffligste Teil jeder Jira-Synchronisierung ist es, *deinen* Workflow auf die einfachen Zustände von Specrails abzubilden (To Do / In Arbeit / In Prüfung / Fertig, plus Abbruch-Varianten). Specrails löst das in zwei Stufen:
 
 1. **Deine explizite Statuszuordnung**, falls du im Assistenten eine festgelegt hast — sie gewinnt immer.
 2. **Automatische Erkennung** anhand der Kategorie jedes Status (new / in-progress / done) plus intelligentem Abgleich für Abbruch- und Ship-artige Status.

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

@@ -1,6 +1,6 @@
 # Rails & Jobs
 
-Du hast Specs auf dem Board. Hier werden sie zu Code. Eine **Rail** ist die Spur, die eine Spec durch die komplette Pipeline schiebt — Architect → Developer → Reviewer → Ship — und dabei echte KI-Agents direkt in deinem Projektverzeichnis laufen lässt. Diese Seite zeigt dir, wie du eine Rail startest, wie die Job-Queue funktioniert und wie du der Arbeit live zusiehst.
+Du hast Specs auf dem Board. Hier werden sie zu Code. Eine **Rail** ist die Spur, die eine Spec durch die komplette Pipeline schiebt — Architect → Developer → Reviewer → Ship — und dabei echte KI-Agents für dein Projekt laufen lässt. Diese Seite zeigt dir, wie du eine Rail startest, wie parallele Ausführung funktioniert und wie du der Arbeit live zusiehst.
 
 ## Was eine Rail ist
 
@@ -16,7 +16,7 @@ SpecsBoard (links)          Rails (rechts)
                     └────────────►   Rail 2   ▶ Play
 ```
 
-Eine Rail ist eine **Ausführungsspur**. Du ziehst eine Spec-Karte vom SpecsBoard auf eine Rail und drückst dann **▶ Play**. Die Rail startet die Pipeline und arbeitet die Spec von vorne bis hinten ab — direkt im Arbeitsverzeichnis deines Projekts: Dateien werden bearbeitet, Tests laufen, alles inklusive.
+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).
 
@@ -26,7 +26,7 @@ Du kannst mehrere rails anlegen, um deine Arbeit in benannten Spuren zu organisi
 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).
 3. **Drück ▶ Play.**
 
-Das war's. Die rail startet einen KI-CLI-Prozess in deinem Projekt und legt mit der Pipeline los.
+Das war's. Die rail startet einen KI-CLI-Prozess im richtigen Ausführungskontext und legt mit der Pipeline los.
 
 ### Was im rail-Header steckt
 
@@ -57,11 +57,11 @@ Freestyle ist der Sonderfall: Es überspringt die Agent-Kette und übergibt Clau
 
 Jedes Mal, wenn du Play drückst, wird der rail-Lauf zu einem **Job**. Die wichtigste Regel, die du verinnerlichen solltest:
 
-> **Rails laufen parallel.** Jeder Start isoliert seine Arbeit in einem Git-Worktree pro Spec — mehrere rails können also gleichzeitig im selben Projekt laufen, ohne sich in die Quere zu kommen. Die Änderungen jedes Laufs kommen als Merge oder als Draft-PR zurück, sobald er abgeschlossen ist.
+> **Rails laufen parallel.** Jeder Git-gestützte Start isoliert seine Arbeit in einem Git-Worktree pro Spec — mehrere rails können also gleichzeitig im selben Projekt laufen, ohne sich in die Quere zu kommen. Neue Arbeit endet in einer **In Prüfung**-Entscheidungskarte, über die du eine Draft-PR erstellen oder verwerfen kannst; Follow-up-Arbeit für eine Spec mit bereits offener PR setzt diese PR-Branch fort, statt erneut vom Integrations-Branch zu starten.
 
 Du willst alles auf einmal starten? Der Button **Alle starten** im Rails-Header startet jede startbereite Spur in einem Rutsch — nach einer einzigen Bestätigung, die die Gesamtkosten einordnet (N rails × KI-Ausgaben). Leere, bereits laufende oder auf eine PR-Entscheidung wartende rails werden übersprungen und in einem kompakten Zusammenfassungs-Toast gemeldet. Der eingebaute Agent hat dieselbe Fähigkeit über `specrails_rails(launch_all)` — und legt eine frische rail an, wenn keine freie Spur existiert.
 
-Nur der Legacy-Pfad (Loops-Feature deaktiviert) fällt auf die alte Ein-Job-pro-Projekt-Queue zurück, in der sich zusätzliche rails hinter der laufenden anstellen. Die Parallelität zwischen Projekten bleibt unverändert: Jedes Projekt ist weiterhin völlig unabhängig.
+Projekte ohne Git haben keine Worktree-Isolation und keine PR-Fortsetzung. Sie können trotzdem laufen, aber die Rail schreibt direkt in den gemeinsamen Projektordner und das Ergebnis wird manuell über das Spec-Board akzeptiert oder zurückgenommen.
 
 Es gibt keinen globalen Regler für die Parallelität. Die einzige automatische Bremse ist budgetbasiert: Wenn du ein Tagesbudget gesetzt hast (pro Projekt oder app-weit), pausiert die Queue von selbst, sobald die Ausgaben des Tages das Limit erreichen.
 

package/docs/guide/de/pipeline/3-batch-implement-and-multi-feature.md

@@ -12,7 +12,7 @@ Der einfachste Weg, einen ganzen Stapel Specs aus einer Rail laufen zu lassen, i
 
 Die Rail startet **einen** `/specrails:batch-implement`-Job, der jede zugewiesene Spec abarbeitet. Beobachte ihn wie jeden anderen Job auf der Jobs-Seite — es ist ein einzelner Job für das gesamte Set, nicht ein Job pro Spec.
 
-Das ist wichtig wegen der **Ein-Job-pro-Projekt-Queue**. Da ein Projekt immer nur einen Rail-Job auf einmal ausführt, ist der Batch-Modus auch der sauberste Weg, eine Liste von Specs zu *verketten*, ohne mit mehreren Rails zu jonglieren und auf das Leeren jeder einzelnen zu warten.
+Der Batch-Modus bleibt der sauberste Weg, zusammenhängende Specs zu *sequenzieren*, weil ihre Abhängigkeitsreihenfolge in einer einzigen Rail bleibt. Wenn die Specs unabhängig sind, kannst du sie auch auf mehrere Rails verteilen: Git-gestützte Rails laufen parallel und jede bekommt ihren eigenen isolierten Worktree.
 
 ### Implement vs. Batch — welcher Modus?
 
@@ -46,6 +46,8 @@ Wenn in einem Lauf mehrere Specs implementiert werden, hält die Pipeline jede A
 
 Wenn der Lauf fertig ist, **wird nichts gepusht und noch kein Pull-Request geöffnet**. Die Arbeit bleibt sicher auf ihren isolierten Branches committet, die Specs wechseln in einen neuen Status **In Prüfung**, und specrails **fragt dich zuerst**: Auf dem Rail erscheint eine persistente Entscheidungsleiste mit **PR erstellen** — ein einziger Entwurfs-Pull-Request von dem für dein Projekt festgelegten Integrations-Branch (lege ihn unter **Einstellungen → Integrations-Branch** fest; standardmäßig ist es der Default-Branch deines Repositories), kombiniert über alle Specs des Rails — und **Verwerfen**. specrails **merged niemals und committet niemals direkt auf deinen Integrations-Branch** — du entscheidest, ob überhaupt ein PR entsteht, und ein Mensch verantwortet den Merge. Das ist die sichere Übergabe: specrails erstellt den Pull-Request erst, wenn du es sagst, und deine Entwickler prüfen ihn und mergen ihn in GitHub genau so, wie sie es ohnehin schon tun.
 
+Wenn du eine Spec erneut startest, die bereits in Prüfung ist und einen offenen Pull-Request hat, behandelt Specrails das als Follow-up-Arbeit. Es erkennt die aktive PR über seinen eigenen Lieferdatensatz oder über GitHub-/Jira-Referenzen, checkt die Head-Branch dieser PR aus, committet die neuen Änderungen dort und zeigt dieselbe PR-Karte wieder an. Neue Arbeit startet weiterhin vom Integrations-Branch.
+
 In der Praxis heißt das:
 
 - Jede Spec bekommt zum Implementieren eine saubere Ausgangslage, statt die noch laufenden Änderungen der vorherigen Spec mitten im Fluss zu erben.
@@ -54,11 +56,11 @@ In der Praxis heißt das:
 - Nach dem Erstellen kannst du mit **PR öffnen** hineinsehen, mit **Veröffentlichen** ihn für das Review deines Teams öffnen und an das normale GitHub-Review übergeben, und **Merge prüfen** setzt die Specs auf Fertig, sobald dein Team ihn gemerged hat.
 - Falls die isolierten Branches beim Erstellen des PR nicht sauber kombiniert werden können, stoppt specrails auf sichere Weise und überlässt die Branches einem Menschen — es erzwingt niemals einen kaputten Merge auf deinen Basis-Branch. Von derselben Leiste aus kannst du es erneut versuchen oder verwerfen.
 
-> Für das Erstellen des PR müssen die GitHub-CLI (`gh`) authentifiziert und ein Remote konfiguriert sein. Ohne sie bleibt die Arbeit trotzdem auf einem Branch committet, von dem aus du selbst einen Pull-Request öffnen kannst — es geht nichts verloren, und die Entscheidungsleiste erlaubt einen erneuten Versuch. Um auf das ältere Verhalten zurückzufallen (lokal integrieren, statt zu fragen), setze `SPECRAILS_RAIL_DELIVER_PR=0`.
+> Für das Erstellen oder Fortsetzen einer PR brauchst du ein Git-Repository, eine authentifizierte GitHub-CLI (`gh`) und ein konfiguriertes Remote. Ohne `gh` oder Remote bleibt die Arbeit trotzdem auf einem Branch committet, von dem aus du selbst einen Pull-Request öffnen kannst — es geht nichts verloren, und die Entscheidungsleiste erlaubt einen erneuten Versuch. Ganz ohne Git gibt es keinen Branch-Graphen, den Specrails fortsetzen könnte: Die Rail läuft im gemeinsamen Ordner und es erscheint keine PR-Karte. Um auf das ältere Verhalten zurückzufallen (lokal integrieren, statt zu fragen), setze `SPECRAILS_RAIL_DELIVER_PR=0`.
 
 ## Multi-Feature über Projekte hinweg
 
-Wenn du echte Parallelität willst — zwei große Features, die gleichzeitig gebaut werden — teile sie **über Projekte** auf, nicht über Rails in einem Projekt. Jedes Projekt hat seine eigene unabhängige Queue, also:
+Wenn du echte Parallelität willst, nutze mehrere Rails für unabhängige Specs im selben Git-gestützten Projekt oder teile die Arbeit über Projekte auf. Jede aktive Rail bekommt ihren eigenen isolierten Worktree, also:
 
 ```
 Projekt A   ▶ Rail baut Feature X   ┐
@@ -66,7 +68,7 @@ Projekt A   ▶ Rail baut Feature X   ┐
 Projekt B   ▶ Rail baut Feature Y   ┘
 ```
 
-Es gibt kein globales Parallelitäts-Limit und keinen Wettstreit zwischen Projekten. Öffne beide, starte in jedem eine Rail, und sie kommen zusammen voran. Die einzige geteilte Bremse ist dein Budget-Limit, das die Queues pro Projekt oder app-weit pausiert, sobald die Ausgaben des Tages das Limit erreichen.
+Es gibt kein globales Parallelitäts-Limit, das du einstellen musst. Öffne die Projekte oder Rails, die du brauchst, starte sie, und sie kommen zusammen voran. Die einzige geteilte Bremse ist dein Budget-Limit, das die Queues pro Projekt oder app-weit pausiert, sobald die Ausgaben des Tages das Limit erreichen.
 
 ## Tipps für große Batches
 

package/docs/guide/en/integrations/3-jira-integration.md

@@ -7,7 +7,8 @@ Want your specs to live on a real **Jira board** instead of inside Specrails? Th
 Specrails acts as a **sync layer** between Jira and your project. The big idea: your local spec store stays the canonical thing the pipeline reads, and Specrails is responsible for keeping it and Jira in agreement.
 
 - When you launch a rail, Specrails moves the linked Jira issue to **In Progress**.
-- When a job finishes, Specrails transitions the issue: on success it moves to your mapped **review** status and only reaches **Done** once you approve the work (merging the draft PR posts a "PR merged" comment); on failure it goes back to **To Do** with a completion comment (job id, cost, duration).
+- When a job finishes, Specrails transitions the issue: on success it moves to your mapped **review** status and only reaches **Done** once the delivery PR is merged or you accept the local result; on failure it goes back to **To Do** with a completion comment that includes the result, run id, cost, duration, and the Jira status change.
+- If you ask for follow-up changes while the Jira issue is already in review, Specrails tries to continue the existing open PR branch for that ticket instead of creating a fresh branch. If your Jira review status is not explicitly mapped and still appears locally as **In Progress**, Specrails can still continue the PR when the Jira key matches the open pull request.
 - Periodically Specrails **polls** Jira for changes anyone made on the board and reflects them back into your specs.
 
 All write-backs go through a durable, crash-safe outbox, so a momentary Jira hiccup never breaks a job — the update just retries.
@@ -32,7 +33,7 @@ Your token is stored **encrypted on your own machine** and never leaves it. The
 
 ## Status mapping
 
-The trickiest part of any Jira sync is matching *your* workflow to Specrails' simple states (To Do / In Progress / Done, plus cancel/ship variants). Specrails resolves this in two tiers:
+The trickiest part of any Jira sync is matching *your* workflow to Specrails' simple states (To Do / In Progress / On Review / Done, plus cancel variants). Specrails resolves this in two tiers:
 
 1. **Your explicit status map**, if you set one in the wizard — always wins.
 2. **Automatic detection** from each status's category (new / in-progress / done) plus smart matching for cancel and ship-style statuses.
@@ -68,4 +69,4 @@ Specs backed by Jira show a **Jira key badge** (like `PROJ-123`) on their card,
 
 ## Turning it off
 
-If you ever want to fully back out, just **Disconnect** from Settings. Your specs return to local-only behavior, and the Jira metadata simply sits unused — nothing is destroyed.
+If you ever want to fully back out, just **Disconnect** from Settings. Your specs return to local-only behavior, and the Jira metadata simply sits unused — nothing is destroyed.

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

@@ -1,6 +1,6 @@
 # Rails & jobs
 
-You've got specs on the board. This is where they turn into code. A **rail** is the lane that drives a spec through the full pipeline — Architect → Developer → Reviewer → Ship — running real AI agents inside your project directory. This page covers launching a rail, the job queue, and watching the work happen live.
+You've got specs on the board. This is where they turn into code. A **rail** is the lane that drives a spec through the full pipeline — Architect → Developer → Reviewer → Ship — running real AI agents for your project. This page covers launching a rail, parallel execution, and watching the work happen live.
 
 ## What a rail is
 
@@ -16,7 +16,7 @@ SpecsBoard (left)            Rails (right)
                     └────────────►   Rail 2   ▶ Play
 ```
 
-A rail is an **execution lane**. You drag a spec card from the SpecsBoard onto a rail, then press **▶ Play**. The rail launches the pipeline and works the spec end to end, right in your project's working directory — editing files, running tests, the works.
+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).
 
@@ -26,7 +26,7 @@ You can have several rails to organise work into named lanes (one for the featur
 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).
 3. **Press ▶ Play.**
 
-That's it. The rail spins up an AI CLI process in your project and starts the pipeline.
+That's it. The rail spins up an AI CLI process in the right execution context and starts the pipeline.
 
 ### What's in a rail header
 
@@ -57,11 +57,11 @@ Beyond the built-ins, you can **build your own loops** — repeat a verify → f
 
 Every time you press Play, the rail run becomes a **job**. The most important rule to internalise:
 
-> **Rails run in parallel.** Every launch isolates its work in a per-spec git worktree, so several rails can run at the same time inside the same project without stepping on each other — each run's changes come back as a merge or a draft PR when it settles.
+> **Rails run in parallel.** Every git-backed launch isolates its work in a per-spec git worktree, so several rails can run at the same time inside the same project without stepping on each other. Fresh work settles into an **On Review** decision card where you can create a draft PR or discard it; follow-up work for a spec that already has an open PR continues that PR branch instead of starting over from the integration branch.
 
 Want everything moving at once? The **Launch all** button in the Rails header starts every ready lane in one go, after a single confirmation that frames the total cost (N rails × AI spend). Rails that are empty, already running, or awaiting a PR decision are skipped and reported in a compact summary toast. The in-app agent has the same power through `specrails_rails(launch_all)` — and it will create a fresh rail when no free lane exists.
 
-Only the legacy path (the Loops feature disabled) falls back to the old one-job-at-a-time project queue, where extra rails queue behind the running one. Cross-project parallelism is unchanged: each project remains fully independent.
+Projects without git do not get worktree isolation or PR continuation. They still run, but the rail writes directly into the shared project folder and the result is accepted or reverted manually from the spec board.
 
 There's no global concurrency knob to tune. The only automatic throttle is budget-based: if you've set a daily budget (project or app-wide), the queue auto-pauses once that day's spend hits the cap.
 

package/docs/guide/en/pipeline/3-batch-implement-and-multi-feature.md

@@ -12,7 +12,7 @@ The simplest way to run a pile of specs from one rail is **Batch** mode:
 
 The rail launches **one** `/specrails:batch-implement` job that works through every assigned spec. Monitor it like any other job on the Jobs page — it's a single job covering the whole set, not one job per spec.
 
-This matters because of the **one-job-per-project queue**. Since a project runs only one rail job at a time, Batch mode is also the cleanest way to *chain* a list of specs without juggling multiple rails and waiting for each to drain.
+Batch mode is still the cleanest way to *sequence* related specs because it keeps their dependency order inside one rail. If the specs are independent, you can also spread them across several rails: git-backed rails run in parallel and each one gets its own isolated worktree.
 
 ### Implement vs Batch — which mode?
 
@@ -46,6 +46,8 @@ When several specs are implemented in one run, the pipeline keeps each unit of w
 
 When the run finishes, **nothing is pushed and no pull request is opened yet**. The work stays safely committed on its isolated branches, the specs move to a new **On Review** status, and specrails **asks you first**: a persistent decision bar appears on the rail with **Create PR** — one draft pull request off your project's designated integration branch (set it in **Settings → Integration branch**; it defaults to your repository's default branch), combined across every spec on the rail — and **Discard**. specrails **never merges, and never commits to your integration branch directly** — you decide whether a PR exists at all, and a human owns the merge. It's the safe hand-off: specrails produces the pull request only when you say so, and your engineers review and merge it in GitHub the way they already do.
 
+If you relaunch a spec that is already in review and has an open pull request, Specrails treats that as follow-up work. It detects the active PR from its own delivery record or from GitHub/Jira references, checks out the PR's head branch, commits the new changes there, and brings the same PR card back. New work still starts from the integration branch.
+
 In practice this means:
 
 - Each spec gets a clean slate to implement against, rather than inheriting the in-flight edits of the previous spec mid-stream.
@@ -54,13 +56,13 @@ In practice this means:
 - After creating it, **Open PR** views the draft, **Publish** opens it for review and hands it to your team's normal GitHub review, and **Check merge** flips the specs to Done once your team has merged it.
 - If the isolated branches can't be combined cleanly when you create the PR, specrails stops safely and leaves the branches for a human — it never forces a broken merge onto your base. You can retry or discard from the same bar.
 
-> Creating the PR needs the GitHub CLI (`gh`) authenticated and a remote configured. Without them, specrails still keeps the work committed on a branch you can open a pull request from yourself — nothing is lost, and the decision bar lets you retry. To fall back to the older behaviour (integrate locally instead of asking), set `SPECRAILS_RAIL_DELIVER_PR=0`.
+> Creating or continuing a PR needs a git repository, the GitHub CLI (`gh`) authenticated, and a remote configured. Without `gh` or a remote, specrails still keeps the work committed on a branch you can open a pull request from yourself — nothing is lost, and the decision bar lets you retry. Without git at all, there is no branch graph to continue: the rail runs in the shared folder and no PR card appears. To fall back to the older behaviour (integrate locally instead of asking), set `SPECRAILS_RAIL_DELIVER_PR=0`.
 
 The app records, per job, exactly which files were touched and which ticket touched them (you'll see this surface as provenance chips in the **Code** section and as a "Files touched by this ticket" list on each spec's detail modal). That attribution is what lets you trust a multi-spec run: you can always trace a file change back to the spec that caused it.
 
 ## Multi-feature across projects
 
-If you want genuine parallelism — two big features building at the same time — split them **across projects**, not across rails in one project. Each project has its own independent queue, so:
+If you want genuine parallelism, use multiple rails for independent specs in the same git-backed project, or split work across projects. Each active rail gets its own isolated worktree, so:
 
 ```
 Project A   ▶ Rail running feature X   ┐
@@ -68,7 +70,7 @@ Project A   ▶ Rail running feature X   ┐
 Project B   ▶ Rail running feature Y   ┘
 ```
 
-There's no global concurrency limit and no contention between projects. Open both, launch a rail in each, and they progress together. The only shared throttle is your budget cap, which pauses queues per-project or app-wide once the day's spend hits the limit.
+There's no global concurrency limit to tune. Open the projects or rails you need, launch them, and they progress together. The only shared throttle is your budget cap, which pauses queues per-project or app-wide once the day's spend hits the limit.
 
 ## Tips for big batches
 

package/docs/guide/es/integrations/3-jira-integration.md

@@ -7,7 +7,8 @@
 Specrails actúa como **capa de sincronización** entre Jira y tu proyecto. La idea central: tu almacén local de specs sigue siendo lo canónico que lee el pipeline, y Specrails se encarga de mantenerlo de acuerdo con Jira.
 
 - Cuando lanzas un rail, Specrails mueve el issue de Jira vinculado a **En progreso**.
-- Cuando un trabajo termina, Specrails transiciona el issue: si tuvo éxito, lo mueve a tu estado de **revisión** mapeado y solo llega a **Hecho** cuando apruebas el trabajo (fusionar la PR en borrador publica un comentario "PR merged"); si falló, vuelve a **Por hacer** con un comentario de finalización (id del trabajo, coste y duración).
+- Cuando un trabajo termina, Specrails transiciona el issue: si tuvo éxito, lo mueve a tu estado de **revisión** mapeado y solo llega a **Hecho** cuando se mergea la PR de entrega o aceptas el resultado local; si falló, vuelve a **Por hacer** con un comentario de finalización que incluye resultado, id de ejecución, coste, duración y el cambio de estado en Jira.
+- Si pides cambios de seguimiento cuando el issue de Jira ya está en revisión, Specrails intenta continuar la rama de la PR abierta existente para ese ticket en lugar de crear una rama nueva. Si tu estado de revisión de Jira no está mapeado explícitamente y todavía aparece localmente como **En progreso**, Specrails puede continuar igualmente la PR cuando la clave de Jira coincide con la pull request abierta.
 - Periódicamente, Specrails **sondea** Jira en busca de cambios que cualquiera haya hecho en el tablero y los refleja de vuelta en tus specs.
 
 Todas las escrituras pasan por un outbox duradero y a prueba de fallos, así que un tropiezo puntual de Jira nunca rompe un trabajo: la actualización simplemente se reintenta.
@@ -32,7 +33,7 @@ Tu token se guarda **cifrado en tu propia máquina** y nunca sale de ella. La ap
 
 ## Mapeo de estados
 
-La parte más delicada de cualquier sincronización con Jira es hacer coincidir *tu* flujo de trabajo con los estados sencillos de Specrails (Por hacer / En progreso / Hecho, más las variantes de cancelar/entregar). Specrails lo resuelve en dos niveles:
+La parte más delicada de cualquier sincronización con Jira es hacer coincidir *tu* flujo de trabajo con los estados sencillos de Specrails (Por hacer / En progreso / En revisión / Hecho, más las variantes de cancelar). Specrails lo resuelve en dos niveles:
 
 1. **Tu mapa de estados explícito**, si configuras uno en el asistente: siempre gana.
 2. **Detección automática** a partir de la categoría de cada estado (nuevo / en progreso / hecho) más una coincidencia inteligente para los estados de tipo cancelar y entregar.

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

@@ -1,6 +1,6 @@
 # Rails y jobs
 
-Ya tienes specs en el tablero. Aquí es donde se convierten en código. Un **rail** es el carril que lleva una spec a través de todo el pipeline — Architect → Developer → Reviewer → Ship — ejecutando agentes de IA reales dentro del directorio de tu proyecto. En esta página verás cómo lanzar un rail, la cola de jobs y cómo seguir el trabajo en vivo.
+Ya tienes specs en el tablero. Aquí es donde se convierten en código. Un **rail** es el carril que lleva una spec a través de todo el pipeline — Architect → Developer → Reviewer → Ship — ejecutando agentes de IA reales para tu proyecto. En esta página verás cómo lanzar un rail, la ejecución en paralelo y cómo seguir el trabajo en vivo.
 
 ## Qué es un rail
 
@@ -16,7 +16,7 @@ SpecsBoard (izquierda)      Rails (derecha)
                     └────────────►   Rail 2   ▶ Play
 ```
 
-Un rail es un **carril de ejecución**. Arrastras una tarjeta de spec desde el SpecsBoard hasta un rail y luego pulsas **▶ Play**. El rail lanza el pipeline y trabaja la spec de principio a fin, directamente en el directorio de trabajo de tu proyecto — editando archivos, ejecutando tests, todo lo necesario.
+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).
 
@@ -26,7 +26,7 @@ Puedes tener varios rails para organizar el trabajo en carriles con nombre (uno
 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).
 3. **Pulsa ▶ Play.**
 
-Eso es todo. El rail arranca un proceso de la CLI de IA en tu proyecto y empieza el pipeline.
+Eso es todo. El rail arranca un proceso de la CLI de IA en el contexto de ejecución correcto y empieza el pipeline.
 
 ### Qué hay en la cabecera de un rail
 
@@ -57,11 +57,11 @@ Más allá de los integrados, puedes **construir tus propios loops** — repetir
 
 Cada vez que pulsas Play, la ejecución del rail se convierte en un **job**. La regla más importante que debes interiorizar:
 
-> **Los rails se ejecutan en paralelo.** Cada lanzamiento aísla su trabajo en un worktree de git por spec, así que varios rails pueden ejecutarse a la vez dentro del mismo proyecto sin pisarse — los cambios de cada ejecución vuelven como merge o como draft PR cuando termina.
+> **Los rails se ejecutan en paralelo.** Cada lanzamiento respaldado por git aísla su trabajo en un worktree de git por spec, así que varios rails pueden ejecutarse a la vez dentro del mismo proyecto sin pisarse. El trabajo nuevo termina en una tarjeta de decisión **En revisión**, donde puedes crear una draft PR o descartarlo; el trabajo de seguimiento para una spec que ya tiene una PR abierta continúa esa rama de PR en lugar de empezar otra vez desde la rama de integración.
 
 ¿Quieres que todo arranque a la vez? El botón **Lanzar todos** de la cabecera de Rails inicia todos los carriles listos de una tacada, tras una única confirmación que enmarca el coste total (N rails × gasto de IA). Los rails vacíos, ya en ejecución o a la espera de una decisión de PR se omiten y se informan en un toast resumen compacto. El agente integrado tiene el mismo poder mediante `specrails_rails(launch_all)` — y creará un rail nuevo cuando no quede ningún carril libre.
 
-Solo la ruta legacy (con la funcionalidad de Loops desactivada) recurre a la antigua cola de un-job-a-la-vez por proyecto, donde los rails adicionales esperan detrás del que está en marcha. El paralelismo entre proyectos no cambia: cada proyecto sigue siendo totalmente independiente.
+Los proyectos sin git no tienen aislamiento por worktree ni continuación de PR. Siguen pudiendo ejecutarse, pero el rail escribe directamente en la carpeta compartida del proyecto y el resultado se acepta o se revierte manualmente desde el tablero de specs.
 
 No hay ninguna palanca global de concurrencia que ajustar. El único freno automático se basa en el presupuesto: si has fijado un presupuesto diario (de proyecto o de toda la app), la cola se pausa sola en cuanto el gasto de ese día llega al tope.
 

package/docs/guide/es/pipeline/3-batch-implement-and-multi-feature.md

@@ -12,7 +12,7 @@ La forma más sencilla de ejecutar un montón de specs desde un mismo rail es el
 
 El rail lanza **un** job `/specrails:batch-implement` que recorre todas las specs asignadas. Monitorízalo como cualquier otro job en la página Jobs — es un único job que cubre el conjunto entero, no un job por spec.
 
-Esto importa por la **cola de un job por proyecto**. Como un proyecto solo ejecuta un job de rail a la vez, el modo Batch es también la forma más limpia de *encadenar* una lista de specs sin tener que hacer malabares con varios rails y esperar a que cada uno se vacíe.
+El modo Batch sigue siendo la forma más limpia de *secuenciar* specs relacionadas porque mantiene su orden de dependencias dentro de un solo rail. Si las specs son independientes, también puedes repartirlas entre varios rails: los rails respaldados por git se ejecutan en paralelo y cada uno recibe su propio worktree aislado.
 
 ### Implement vs Batch — ¿qué modo?
 
@@ -46,6 +46,8 @@ Cuando se implementan varias specs en una misma ejecución, el pipeline mantiene
 
 Cuando la ejecución termina, **no se sube nada y todavía no se abre ninguna pull request**. El trabajo queda commiteado a salvo en sus ramas aisladas, las specs pasan a un nuevo estado **En revisión**, y specrails **te pregunta primero**: en el rail aparece una barra de decisión persistente con **Crear PR** — una única pull request en borrador partiendo de la rama de integración que hayas designado para tu proyecto (configúrala en **Ajustes → Rama de integración**; por defecto es la rama por defecto de tu repositorio), combinada a través de todas las specs del rail — y **Descartar**. specrails **nunca hace merge ni commitea directamente sobre tu rama de integración** — tú decides si siquiera existe una PR, y el merge lo decide una persona. Es el traspaso seguro: specrails produce la pull request solo cuando tú lo dices, y tus ingenieros la revisan y la mergean en GitHub como ya lo hacen.
 
+Si relanzas una spec que ya está en revisión y tiene una pull request abierta, Specrails lo trata como trabajo de seguimiento. Detecta la PR activa desde su propio registro de entrega o desde referencias de GitHub/Jira, hace checkout de la rama head de esa PR, commitea ahí los nuevos cambios y vuelve a mostrar la misma tarjeta de PR. El trabajo nuevo sigue empezando desde la rama de integración.
+
 En la práctica esto significa:
 
 - Cada spec recibe un lienzo en blanco contra el que implementar, en vez de heredar a mitad de camino las ediciones en vuelo de la spec anterior.
@@ -54,11 +56,11 @@ En la práctica esto significa:
 - Una vez creada, **Abrir PR** la muestra, **Publicar** la abre a revisión y la entrega a la revisión habitual de GitHub de tu equipo, y **Comprobar merge** pasa las specs a Hecho en cuanto tu equipo la haya mergeado.
 - Si las ramas aisladas no se pueden combinar limpiamente al crear la PR, specrails se detiene de forma segura y deja las ramas para una persona — nunca fuerza un merge roto sobre tu base. Puedes reintentar o descartar desde la misma barra.
 
-> Crear la PR requiere que la CLI de GitHub (`gh`) esté autenticada y un remoto configurado. Sin ellos, specrails igualmente mantiene el trabajo commiteado en una rama desde la que puedes abrir tú mismo una pull request — no se pierde nada, y la barra de decisión te permite reintentar. Para volver al comportamiento anterior (integrar en local en vez de preguntar), define `SPECRAILS_RAIL_DELIVER_PR=0`.
+> Crear o continuar una PR requiere un repositorio git, la CLI de GitHub (`gh`) autenticada y un remoto configurado. Sin `gh` o sin remoto, specrails igualmente mantiene el trabajo commiteado en una rama desde la que puedes abrir tú mismo una pull request — no se pierde nada, y la barra de decisión te permite reintentar. Sin git en absoluto, no hay grafo de ramas que continuar: el rail se ejecuta en la carpeta compartida y no aparece ninguna tarjeta de PR. Para volver al comportamiento anterior (integrar en local en vez de preguntar), define `SPECRAILS_RAIL_DELIVER_PR=0`.
 
 ## Multifuncionalidad entre proyectos
 
-Si quieres paralelismo de verdad — dos funcionalidades grandes construyéndose al mismo tiempo — repártelas **entre proyectos**, no entre rails de un mismo proyecto. Cada proyecto tiene su propia cola independiente, así que:
+Si quieres paralelismo de verdad, usa varios rails para specs independientes dentro del mismo proyecto respaldado por git, o reparte el trabajo entre proyectos. Cada rail activo recibe su propio worktree aislado, así que:
 
 ```
 Proyecto A   ▶ Rail ejecutando la funcionalidad X   ┐
@@ -66,7 +68,7 @@ Proyecto A   ▶ Rail ejecutando la funcionalidad X   ┐
 Proyecto B   ▶ Rail ejecutando la funcionalidad Y   ┘
 ```
 
-No hay límite global de concurrencia ni contención entre proyectos. Abre los dos, lanza un rail en cada uno y avanzarán juntos. El único freno compartido es tu tope de presupuesto, que pausa las colas por proyecto o de toda la app en cuanto el gasto del día llega al límite.
+No hay límite global de concurrencia que ajustar. Abre los proyectos o rails que necesites, lánzalos y avanzarán juntos. El único freno compartido es tu tope de presupuesto, que pausa las colas por proyecto o de toda la app en cuanto el gasto del día llega al límite.
 
 ## Consejos para batches grandes
 

package/docs/guide/fr/integrations/3-jira-integration.md

@@ -7,7 +7,8 @@ Vous voulez que vos specs vivent sur un véritable **tableau Jira** plutôt qu'
 Specrails agit comme une **couche de synchronisation** entre Jira et votre projet. L'idée maîtresse : votre magasin de specs local reste la référence que lit le pipeline, et Specrails se charge de le maintenir en accord avec Jira.
 
 - Lorsque vous lancez un rail, Specrails fait passer le ticket Jira lié à **En cours**.
-- Lorsqu'un job se termine, Specrails fait transitionner le ticket : en cas de succès, il passe à votre statut de **révision** mappé et n'atteint **Terminé** qu'une fois le travail approuvé (la fusion de la PR en brouillon publie un commentaire « PR merged ») ; en cas d'échec, il revient à **À faire** avec un commentaire de clôture (identifiant du job, coût, durée).
+- Lorsqu'un job se termine, Specrails fait transitionner le ticket : en cas de succès, il passe à votre statut de **révision** mappé et n'atteint **Terminé** qu'une fois la PR de livraison fusionnée ou le résultat local accepté ; en cas d'échec, il revient à **À faire** avec un commentaire de clôture qui indique le résultat, l'id d'exécution, le coût, la durée et le changement de statut Jira.
+- Si vous demandez des changements de suivi alors que le ticket Jira est déjà en révision, Specrails essaie de continuer la branche de la PR ouverte existante pour ce ticket au lieu de créer une nouvelle branche. Si votre statut de révision Jira n'est pas explicitement mappé et apparaît encore localement comme **En cours**, Specrails peut tout de même continuer la PR lorsque la clé Jira correspond à la pull request ouverte.
 - Périodiquement, Specrails **interroge** Jira pour récupérer les changements effectués par quiconque sur le tableau et les répercute dans vos specs.
 
 Toutes les écritures vers Jira passent par une file d'attente durable et résistante aux pannes : un incident Jira passager ne casse donc jamais un job — la mise à jour est simplement retentée.
@@ -32,7 +33,7 @@ Votre jeton est stocké **chiffré sur votre propre machine** et n'en sort jamai
 
 ## Association des statuts
 
-La partie la plus délicate de toute synchronisation Jira, c'est de faire correspondre *votre* workflow aux états simples de Specrails (À faire / En cours / Terminé, plus les variantes annulé/livré). Specrails résout cela en deux niveaux :
+La partie la plus délicate de toute synchronisation Jira, c'est de faire correspondre *votre* workflow aux états simples de Specrails (À faire / En cours / En relecture / Terminé, plus les variantes d'annulation). Specrails résout cela en deux niveaux :
 
 1. **Votre association de statuts explicite**, si vous en définissez une dans l'assistant — toujours prioritaire.
 2. **La détection automatique** à partir de la catégorie de chaque statut (new / in-progress / done) plus une correspondance intelligente pour les statuts de type annulation et livraison.

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

@@ -1,6 +1,6 @@
 # Rails et jobs
 
-Vous avez des specs sur le tableau. C'est ici qu'ils se transforment en code. Un **rail** est la voie qui conduit un spec à travers tout le pipeline — Architect → Developer → Reviewer → Ship — en exécutant de vrais agents IA à l'intérieur du répertoire de votre projet. Cette page couvre le lancement d'un rail, la file d'attente des jobs et le suivi du travail en direct.
+Vous avez des specs sur le tableau. C'est ici qu'ils se transforment en code. Un **rail** est la voie qui conduit un spec à travers tout le pipeline — Architect → Developer → Reviewer → Ship — en exécutant de vrais agents IA pour votre projet. Cette page couvre le lancement d'un rail, l'exécution en parallèle et le suivi du travail en direct.
 
 ## Ce qu'est un rail
 
@@ -16,7 +16,7 @@ SpecsBoard (gauche)         Rails (droite)
                     └────────────►   Rail 2   ▶ Play
 ```
 
-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**. Le rail lance le pipeline et travaille le spec de bout en bout, directement dans le répertoire de travail de votre projet — en éditant des fichiers, en lançant des tests, tout y passe.
+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).
 
@@ -26,7 +26,7 @@ Vous pouvez avoir plusieurs rails pour organiser le travail en voies nommées (u
 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).
 3. **Appuyez sur ▶ Play.**
 
-Voilà. Le rail démarre un processus AI CLI dans votre projet et lance le pipeline.
+Voilà. Le rail démarre un processus AI CLI dans le bon contexte d'exécution et lance le pipeline.
 
 ### Ce que contient l'en-tête d'un rail
 
@@ -57,11 +57,11 @@ Au-delà des intégrés, vous pouvez **construire vos propres loops** — répé
 
 Chaque fois que vous appuyez sur Play, l'exécution du rail devient un **job**. La règle la plus importante à intégrer :
 
-> **Les rails s'exécutent en parallèle.** Chaque lancement isole son travail dans un worktree git par spec, donc plusieurs rails peuvent tourner en même temps dans le même projet sans se marcher dessus — les changements de chaque exécution reviennent en merge ou en draft PR quand elle se termine.
+> **Les rails s'exécutent en parallèle.** Chaque lancement adossé à git isole son travail dans un worktree git par spec, donc plusieurs rails peuvent tourner en même temps dans le même projet sans se marcher dessus. Le nouveau travail se termine sur une carte de décision **En relecture**, où vous pouvez créer une draft PR ou l'abandonner ; le travail de suivi pour une spec qui possède déjà une PR ouverte continue la branche de cette PR au lieu de repartir de la branche d'intégration.
 
 Vous voulez tout lancer d'un coup ? Le bouton **Tout lancer** de l'en-tête Rails démarre toutes les voies prêtes en une fois, après une seule confirmation qui cadre le coût total (N rails × dépense IA). Les rails vides, déjà en cours ou en attente d'une décision de PR sont ignorés et signalés dans un toast récapitulatif compact. L'agent intégré a le même pouvoir via `specrails_rails(launch_all)` — et il créera un nouveau rail quand aucune voie libre n'existe.
 
-Seul le chemin legacy (fonctionnalité Loops désactivée) retombe sur l'ancienne file un-job-à-la-fois par projet, où les rails supplémentaires attendent derrière celui qui tourne. Le parallélisme entre projets ne change pas : chaque projet reste totalement indépendant.
+Les projets sans git n'ont ni isolation par worktree ni continuation de PR. Ils peuvent tout de même s'exécuter, mais le rail écrit directement dans le dossier partagé du projet et le résultat s'accepte ou se rétablit manuellement depuis le tableau des specs.
 
 Il n'y a pas de réglage de concurrence global à ajuster. Le seul frein automatique est basé sur le budget : si vous avez défini un budget quotidien (par projet ou pour toute l'app), la file s'auto-suspend dès que la dépense du jour atteint le plafond.
 

package/docs/guide/fr/pipeline/3-batch-implement-and-multi-feature.md

@@ -12,7 +12,7 @@ La façon la plus simple de lancer une pile de specs depuis un seul rail, c'est
 
 Le rail lance **un** job `/specrails:batch-implement` qui traite chaque spec assignée. Suivez-le comme n'importe quel autre job sur la page Jobs — c'est un seul job couvrant tout l'ensemble, pas un job par spec.
 
-C'est important à cause de la **file d'attente d'un job par projet**. Puisqu'un projet n'exécute qu'un job de rail à la fois, le mode Batch est aussi le moyen le plus propre d'*enchaîner* une liste de specs sans jongler avec plusieurs rails ni attendre que chacun se vide.
+Le mode Batch reste le moyen le plus propre de *séquencer* des specs liées, car il garde leur ordre de dépendances dans un seul rail. Si les specs sont indépendantes, vous pouvez aussi les répartir sur plusieurs rails : les rails adossés à git s'exécutent en parallèle et chacun reçoit son propre worktree isolé.
 
 ### Implement vs Batch — quel mode ?
 
@@ -46,6 +46,8 @@ Lorsque plusieurs specs sont implémentées en une seule exécution, le pipeline
 
 Lorsque l'exécution se termine, **rien n'est poussé et aucune pull request n'est encore ouverte**. Le travail reste commité en sécurité sur ses branches isolées, les specs passent à un nouveau statut **En relecture**, et specrails **vous demande d'abord** : une barre de décision persistante apparaît sur le rail avec **Créer la PR** — une seule pull request en brouillon à partir de la branche d'intégration désignée de votre projet (définissez-la dans **Réglages → Branche d'intégration** ; par défaut, c'est la branche par défaut de votre dépôt), combinée à travers toutes les specs du rail — et **Abandonner**. specrails **ne fusionne jamais, et ne commite jamais directement sur votre branche d'intégration** — c'est vous qui décidez si une PR existe tout court, et c'est un humain qui décide de la fusion. C'est le passage de relais sûr : specrails produit la pull request seulement quand vous le décidez, et vos ingénieurs la relisent et la fusionnent dans GitHub comme ils le font déjà.
 
+Si vous relancez une spec déjà en relecture avec une pull request ouverte, Specrails traite cela comme un travail de suivi. Il détecte la PR active depuis son propre registre de livraison ou depuis les références GitHub/Jira, checkout la branche head de cette PR, y commite les nouveaux changements et réaffiche la même carte de PR. Le nouveau travail continue de partir de la branche d'intégration.
+
 En pratique, cela signifie :
 
 - Chaque spec part d'une page blanche pour son implémentation, plutôt que d'hériter des modifications en cours de la spec précédente.
@@ -54,11 +56,11 @@ En pratique, cela signifie :
 - Une fois créée, **Ouvrir la PR** permet de la consulter, **Publier** l'ouvre à la relecture et la confie au processus de relecture GitHub habituel de votre équipe, et **Vérifier le merge** fait passer les specs à Terminé dès que votre équipe l'a fusionnée.
 - Si les branches isolées ne peuvent pas être combinées proprement au moment de créer la PR, specrails s'arrête en toute sécurité et laisse les branches à un humain — il ne force jamais une fusion cassée sur votre branche de base. Vous pouvez réessayer ou abandonner depuis la même barre.
 
-> Créer la PR nécessite le CLI GitHub (`gh`) authentifié et un dépôt distant configuré. Sans eux, specrails garde quand même le travail commité sur une branche à partir de laquelle vous pouvez ouvrir une pull request vous-même — rien n'est perdu, et la barre de décision vous permet de réessayer. Pour revenir à l'ancien comportement (intégrer en local au lieu de demander), définissez `SPECRAILS_RAIL_DELIVER_PR=0`.
+> Créer ou continuer une PR nécessite un dépôt git, le CLI GitHub (`gh`) authentifié et un dépôt distant configuré. Sans `gh` ou sans remote, specrails garde quand même le travail commité sur une branche à partir de laquelle vous pouvez ouvrir une pull request vous-même — rien n'est perdu, et la barre de décision vous permet de réessayer. Sans git du tout, il n'existe pas de graphe de branches à continuer : le rail s'exécute dans le dossier partagé et aucune carte de PR n'apparaît. Pour revenir à l'ancien comportement (intégrer en local au lieu de demander), définissez `SPECRAILS_RAIL_DELIVER_PR=0`.
 
 ## Multi-fonctionnalité entre projets
 
-Si vous voulez un vrai parallélisme — deux grosses fonctionnalités qui se construisent en même temps — répartissez-les **entre projets**, pas entre rails d'un même projet. Chaque projet possède sa propre file d'attente indépendante, donc :
+Si vous voulez un vrai parallélisme, utilisez plusieurs rails pour des specs indépendantes dans le même projet adossé à git, ou répartissez le travail entre projets. Chaque rail actif reçoit son propre worktree isolé, donc :
 
 ```
 Projet A   ▶ Rail exécutant la fonctionnalité X   ┐
@@ -66,7 +68,7 @@ Projet A   ▶ Rail exécutant la fonctionnalité X   ┐
 Projet B   ▶ Rail exécutant la fonctionnalité Y   ┘
 ```
 
-Il n'y a aucune limite globale de concurrence et aucune contention entre projets. Ouvrez les deux, lancez un rail dans chacun, et ils progressent ensemble. Le seul régulateur partagé est votre plafond de budget, qui met les files en pause par projet ou pour toute l'application dès que la dépense du jour atteint la limite.
+Il n'y a aucune limite globale de concurrence à régler. Ouvrez les projets ou rails dont vous avez besoin, lancez-les, et ils progressent ensemble. Le seul régulateur partagé est votre plafond de budget, qui met les files en pause par projet ou pour toute l'application dès que la dépense du jour atteint la limite.
 
 ## Conseils pour les gros batchs
 

package/docs/guide/it/integrations/3-jira-integration.md

@@ -7,7 +7,8 @@ Vuoi che le tue spec vivano su una vera **board Jira** invece che dentro Specrai
 Specrails funge da **livello di sincronizzazione** tra Jira e il tuo progetto. L'idea di fondo: il tuo archivio locale delle spec resta l'elemento canonico che la pipeline legge, e Specrails è responsabile di mantenerlo allineato con Jira.
 
 - Quando avvii un rail, Specrails sposta il ticket Jira collegato su **In corso**.
-- Quando un job termina, Specrails fa transitare il ticket: in caso di successo passa al tuo stato di **revisione** mappato e arriva su **Fatto** solo quando approvi il lavoro (il merge della PR in bozza pubblica un commento "PR merged"); in caso di fallimento torna su **Da fare** con un commento di completamento (id del job, costo e durata).
+- Quando un job termina, Specrails fa transitare il ticket: in caso di successo passa al tuo stato di **revisione** mappato e arriva su **Fatto** solo quando la PR di consegna viene fusa o accetti il risultato locale; in caso di fallimento torna su **Da fare** con un commento di completamento che include risultato, id dell'esecuzione, costo, durata e cambio di stato Jira.
+- Se chiedi modifiche di follow-up mentre il ticket Jira è già in revisione, Specrails prova a continuare il branch della PR aperta esistente per quel ticket invece di creare un branch nuovo. Se il tuo stato di revisione Jira non è mappato esplicitamente e localmente appare ancora come **In corso**, Specrails può comunque continuare la PR quando la chiave Jira corrisponde alla pull request aperta.
 - Periodicamente Specrails interroga (**polling**) Jira per le modifiche apportate da chiunque sulla board e le riporta nelle tue spec.
 
 Tutti i riscritti verso Jira passano attraverso un outbox durevole e resistente ai crash, così un'interruzione momentanea di Jira non blocca mai un job — l'aggiornamento viene semplicemente ritentato.
@@ -32,7 +33,7 @@ Il tuo token viene memorizzato **cifrato sulla tua macchina** e non la lascia ma
 
 ## Mappatura degli stati
 
-La parte più delicata di qualsiasi sincronizzazione con Jira è far corrispondere il *tuo* workflow agli stati semplici di Specrails (Da fare / In corso / Fatto, più le varianti di annullamento e di rilascio). Specrails risolve la cosa su due livelli:
+La parte più delicata di qualsiasi sincronizzazione con Jira è far corrispondere il *tuo* workflow agli stati semplici di Specrails (Da fare / In corso / In revisione / Fatto, più le varianti di annullamento). Specrails risolve la cosa su due livelli:
 
 1. **La tua mappa degli stati esplicita**, se ne hai impostata una nella procedura guidata — vince sempre.
 2. **Il rilevamento automatico** dalla categoria di ciascuno stato (nuovo / in corso / fatto) più un'associazione intelligente per gli stati di tipo annullamento e rilascio.