specrails-desktop 2.24.0 → 2.24.2

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

@@ -1,6 +1,6 @@
 # Rail e job
 
-Hai le tue spec sulla board. È qui che si trasformano in codice. Un **rail** è la corsia che porta una spec attraverso l'intera pipeline — Architect → Developer → Reviewer → Ship — eseguendo veri agenti AI dentro la cartella del tuo progetto. Questa pagina spiega come avviare un rail, come funziona la coda dei job e come seguire il lavoro dal vivo mentre accade.
+Hai le tue spec sulla board. È qui che si trasformano in codice. Un **rail** è la corsia che porta una spec attraverso l'intera pipeline — Architect → Developer → Reviewer → Ship — eseguendo veri agenti AI per il tuo progetto. Questa pagina spiega come avviare un rail, l'esecuzione in parallelo e come seguire il lavoro dal vivo mentre accade.
 
 ## Cos'è un rail
 
@@ -16,7 +16,7 @@ SpecsBoard (sinistra)       Rail (destra)
                     └────────────►   Rail 2   ▶ Play
 ```
 
-Un rail è una **corsia di esecuzione**. Trascini una scheda spec dalla SpecsBoard su un rail e poi premi **▶ Play**. Il rail avvia la pipeline e lavora la spec dall'inizio alla fine, direttamente nella cartella di lavoro del tuo progetto — modificando file, eseguendo test, tutto quanto.
+Un rail è una **corsia di esecuzione**. Trascini una scheda spec dalla SpecsBoard su un rail e poi premi **▶ Play**. Nei repository git, il rail avvia la pipeline in un git worktree isolato, così l'IA può modificare file ed eseguire test senza toccare il tuo working tree attivo. Se il progetto non è ancora un repo git, Specrails degrada chiaramente all'esecuzione nella cartella condivisa e ti avvisa che non compariranno né branch né card PR.
 
 Puoi avere diversi rail per organizzare il lavoro in corsie con un nome (una per la feature su cui sei concentrato, un'altra in attesa dietro). I rail sono **dinamici**: il pulsante **+ Aggiungi** nell'header dei Rails crea una nuova corsia (fino a 12 per progetto) e le corsie vuote e inattive si possono eliminare. Ogni rail è ancorato al server, quindi il tuo set di corsie sopravvive ai ricaricamenti ed è visibile al companion mobile e all'agente integrato — l'agente può persino creare un rail da solo quando tutte le corsie sono occupate. Trovi più dettagli su multi-rail e batching in [Batch implement e multi-feature](batch-implement-and-multi-feature).
 
@@ -26,7 +26,7 @@ Puoi avere diversi rail per organizzare il lavoro in corsie con un nome (una per
 2. **Scegli un Loop** nell'intestazione del rail. Un rail esegue un **Loop** — è il lavoro che svolge. Quello predefinito è il Loop `Implement` integrato; puoi anche scegliere `Batch`, `Freestyle` o un loop personalizzato che hai costruito tu. Vedi [Il Loop Builder](the-loop-builder).
 3. **Premi ▶ Play.**
 
-Tutto qui. Il rail avvia un processo CLI AI nel tuo progetto e dà il via alla pipeline.
+Tutto qui. Il rail avvia un processo CLI AI nel contesto di esecuzione corretto e dà il via alla pipeline.
 
 ### Cosa c'è nell'intestazione di un rail
 
@@ -57,11 +57,11 @@ Oltre agli integrati, puoi **costruire i tuoi loop** — ripetere un ciclo verif
 
 Ogni volta che premi Play, l'esecuzione del rail diventa un **job**. La regola più importante da fare propria:
 
-> **I rail girano in parallelo.** Ogni lancio isola il proprio lavoro in un worktree git per spec, quindi più rail possono girare contemporaneamente nello stesso progetto senza pestarsi i piedi — le modifiche di ogni esecuzione tornano come merge o come draft PR quando si conclude.
+> **I rail girano in parallelo.** Ogni lancio supportato da git isola il proprio lavoro in un worktree git per spec, quindi più rail possono girare contemporaneamente nello stesso progetto senza pestarsi i piedi. Il lavoro nuovo termina in una card di decisione **In revisione**, dove puoi creare una draft PR o scartarlo; il lavoro di follow-up per una spec che ha già una PR aperta continua il branch di quella PR invece di ripartire dal ramo di integrazione.
 
 Vuoi far partire tutto insieme? Il pulsante **Lancia tutti** nell'header dei Rails avvia in un colpo solo tutte le corsie pronte, dopo un'unica conferma che inquadra il costo totale (N rail × spesa IA). I rail vuoti, già in esecuzione o in attesa di una decisione PR vengono saltati e riportati in un toast di riepilogo compatto. L'agente integrato ha lo stesso potere tramite `specrails_rails(launch_all)` — e crea un rail nuovo quando non esiste una corsia libera.
 
-Solo il percorso legacy (feature Loops disattivata) ricade sulla vecchia coda un-job-alla-volta per progetto, dove i rail extra aspettano dietro quello in esecuzione. Il parallelismo tra progetti non cambia: ogni progetto resta del tutto indipendente.
+I progetti senza git non hanno isolamento worktree né continuazione di PR. Possono comunque essere eseguiti, ma il rail scrive direttamente nella cartella condivisa del progetto e il risultato si accetta o si ripristina manualmente dalla board delle spec.
 
 Non c'è una manopola globale di concorrenza da regolare. L'unico freno automatico è basato sul budget: se hai impostato un budget giornaliero (di progetto o per tutta l'app), la coda si mette automaticamente in pausa quando la spesa della giornata raggiunge il limite.
 

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

@@ -12,7 +12,7 @@ Il modo più semplice per eseguire un mucchio di spec da un unico rail è la mod
 
 Il rail avvia **un solo** job `/specrails:batch-implement` che lavora ogni spec assegnata. Monitoralo come qualsiasi altro job nella pagina Job — è un unico job che copre l'intero gruppo, non un job per ogni spec.
 
-Questo è importante per via della **coda a un job per progetto**. Dato che un progetto esegue un solo job di rail alla volta, la modalità Batch è anche il modo più pulito per *concatenare* un elenco di spec senza dover gestire più rail e aspettare che ciascuno si svuoti.
+La modalità Batch resta il modo più pulito per *mettere in sequenza* spec correlate, perché mantiene il loro ordine di dipendenza dentro un solo rail. Se le spec sono indipendenti, puoi anche distribuirle su più rail: i rail supportati da git girano in parallelo e ciascuno riceve il proprio worktree isolato.
 
 ### Implement vs Batch — quale modalità?
 
@@ -46,6 +46,8 @@ Quando più spec vengono implementate in un'unica esecuzione, la pipeline mantie
 
 Quando l'esecuzione termina, **non viene fatto alcun push e nessuna pull request viene ancora aperta**. Il lavoro resta committato al sicuro sui suoi branch isolati, le spec passano a un nuovo stato **In revisione**, e specrails **ti chiede prima**: sul rail compare una barra di decisione persistente con **Crea PR** — un'unica pull request in bozza a partire dal ramo di integrazione designato del tuo progetto (impostalo in **Impostazioni → Ramo di integrazione**; per impostazione predefinita corrisponde al ramo predefinito del tuo repository), combinata attraverso tutte le spec del rail — e **Scarta**. specrails **non esegue mai il merge e non committa mai direttamente sul tuo ramo di integrazione** — sei tu a decidere se una PR debba esistere, e il merge resta in mano a una persona. È la consegna sicura: specrails produce la pull request solo quando lo decidi tu, e i tuoi sviluppatori la revisionano e la fondono su GitHub come già fanno.
 
+Se rilanci una spec che è già in revisione e ha una pull request aperta, Specrails lo tratta come lavoro di follow-up. Rileva la PR attiva dal proprio registro di consegna o da riferimenti GitHub/Jira, fa checkout del branch head di quella PR, committa lì le nuove modifiche e mostra di nuovo la stessa card PR. Il lavoro nuovo continua a partire dal ramo di integrazione.
+
 In pratica questo significa:
 
 - Ogni spec ottiene una tabula rasa su cui implementare, invece di ereditare a metà corsa le modifiche ancora in corso della spec precedente.
@@ -54,11 +56,11 @@ In pratica questo significa:
 - Una volta creata, **Apri PR** la visualizza, **Pubblica** la apre alla revisione e la affida alla normale revisione GitHub del tuo team, e **Verifica merge** porta le spec a Fatto non appena il tuo team l'ha fusa.
 - Se i branch isolati non possono essere combinati in modo pulito quando crei la PR, specrails si ferma in sicurezza e lascia i branch a una persona — non forza mai un merge rotto sul tuo ramo base. Dalla stessa barra puoi riprovare o scartare.
 
-> Creare la PR richiede la GitHub CLI (`gh`) autenticata e un remote configurato. Senza di essi, specrails mantiene comunque il lavoro committato su un branch da cui puoi aprire tu stesso una pull request — non si perde nulla, e la barra di decisione ti permette di riprovare. Per tornare al comportamento precedente (integrazione in locale invece di chiedere), imposta `SPECRAILS_RAIL_DELIVER_PR=0`.
+> Creare o continuare una PR richiede un repository git, la GitHub CLI (`gh`) autenticata e un remote configurato. Senza `gh` o senza remote, specrails mantiene comunque il lavoro committato su un branch da cui puoi aprire tu stesso una pull request — non si perde nulla, e la barra di decisione ti permette di riprovare. Senza git non esiste un grafo di branch da continuare: il rail gira nella cartella condivisa e non compare alcuna card PR. Per tornare al comportamento precedente (integrazione in locale invece di chiedere), imposta `SPECRAILS_RAIL_DELIVER_PR=0`.
 
 ## Multi-feature tra progetti
 
-Se vuoi un vero parallelismo — due grandi feature che vengono costruite nello stesso momento — dividile **tra progetti diversi**, non tra rail nello stesso progetto. Ogni progetto ha la sua coda indipendente, quindi:
+Se vuoi un vero parallelismo, usa più rail per spec indipendenti nello stesso progetto supportato da git, oppure dividi il lavoro tra progetti. Ogni rail attivo riceve il proprio worktree isolato, quindi:
 
 ```
 Progetto A   ▶ Rail che esegue la feature X   ┐
@@ -66,7 +68,7 @@ Progetto A   ▶ Rail che esegue la feature X   ┐
 Progetto B   ▶ Rail che esegue la feature Y   ┘
 ```
 
-Non c'è alcun limite globale di concorrenza né contesa tra progetti. Apri entrambi, avvia un rail in ciascuno e procedono insieme. L'unico freno condiviso è il tuo limite di budget, che mette in pausa le code per progetto o per tutta l'app quando la spesa della giornata raggiunge il limite.
+Non c'è alcun limite globale di concorrenza da regolare. Apri i progetti o i rail che ti servono, avviali e procedono insieme. L'unico freno condiviso è il tuo limite di budget, che mette in pausa le code per progetto o per tutta l'app quando la spesa della giornata raggiunge il limite.
 
 ## Consigli per i batch grandi
 

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

@@ -7,7 +7,8 @@
 Specrails は、Jira とプロジェクトのあいだの**同期レイヤー**として動きます。大きな考え方はこうです。パイプラインが読み込む正本はあくまでローカルのスペックストアであり、それと Jira を一致させ続ける責任を Specrails が担います。
 
 - レールを起動すると、Specrails はリンクされた Jira の課題を **In Progress** に移動します。
-- ジョブが終わると、Specrails は課題を遷移させます。成功した場合はマッピングされた**レビュー**ステータスへ移り、作業を承認して初めて **Done** に到達します（ドラフト PR をマージすると「PR merged」コメントが投稿されます）。失敗した場合は **To Do** へ戻り、ジョブ ID・コスト・所要時間を含む完了コメントが投稿されます。
+- ジョブが終わると、Specrails は課題を遷移させます。成功した場合はマッピングされた**レビュー**ステータスへ移り、delivery PR がマージされるかローカル結果を受け入れて初めて **Done** に到達します。失敗した場合は **To Do** へ戻り、結果、実行 ID、コスト、所要時間、Jira ステータス変更を含む完了コメントが投稿されます。
+- Jira の課題がすでにレビュー中のときに追加入力を依頼すると、Specrails は新しいブランチを作る代わりに、その ticket の既存の開いている PR ブランチを続行しようとします。Jira のレビューステータスが明示的にマッピングされておらず、ローカルではまだ **In Progress** として見える場合でも、Jira key が開いている pull request と一致すれば、その PR を続行できます。
 - Specrails は定期的に Jira を**ポーリング**し、ボード上で誰かが行った変更を取り込んで、スペックに反映します。
 
 すべての書き戻しは、耐久性があってクラッシュに強いアウトボックスを通ります。そのため、一時的な Jira の不調がジョブを壊すことはなく、更新は再試行されるだけです。
@@ -32,7 +33,7 @@ Specrails は、Jira とプロジェクトのあいだの**同期レイヤー**
 
 ## ステータスのマッピング
 
-どんな Jira 同期でも一番やっかいなのは、*あなたの*ワークフローを Specrails のシンプルな状態（To Do / In Progress / Done に加え、cancel / ship のバリエーション）に対応付けることです。Specrails はこれを 2 段階で解決します。
+どんな Jira 同期でも一番やっかいなのは、*あなたの*ワークフローを Specrails のシンプルな状態（To Do / In Progress / On Review / Done に加え、cancel のバリエーション）に対応付けることです。Specrails はこれを 2 段階で解決します。
 
 1. **明示的なステータスマップ** — ウィザードで設定した場合は、常にこれが優先されます。
 2. **自動検出** — 各ステータスのカテゴリ（new / in-progress / done）に基づき、加えて cancel や ship 系のステータスのスマートなマッチングも行います。

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

@@ -1,6 +1,6 @@
 # レールとジョブ
 
-ボードにスペックがそろいました。ここからが、それを実際のコードに変えていく場所です。**レール**は、スペックをパイプライン全体（Architect → Developer → Reviewer → Ship）に通していくためのレーンで、本物の AI エージェントをあなたのプロジェクトディレクトリの中で動かします。このページでは、レールの起動、ジョブのキュー、そして作業がライブで進んでいく様子の見方を紹介します。
+ボードにスペックがそろいました。ここからが、それを実際のコードに変えていく場所です。**レール**は、スペックをパイプライン全体（Architect → Developer → Reviewer → Ship）に通していくためのレーンで、本物の AI エージェントをあなたのプロジェクトのために動かします。このページでは、レールの起動、並列実行、そして作業がライブで進んでいく様子の見方を紹介します。
 
 ## レールとは
 
@@ -16,7 +16,7 @@ SpecsBoard（左）            レール（右）
                     └────────────►   レール 2   ▶ Play
 ```
 
-レールは**実行レーン**です。SpecsBoard からスペックカードをレールにドラッグし、**▶ Play** を押します。するとレールがパイプラインを起動し、あなたのプロジェクトの作業ディレクトリの中で、ファイルの編集やテストの実行まで含めて、スペックを最初から最後までやり遂げます。
+レールは**実行レーン**です。SpecsBoard からスペックカードをレールにドラッグし、**▶ Play** を押します。git リポジトリでは、レールは隔離された git worktree の中でパイプラインを起動するため、AI はあなたの現在のワークツリーに触れずにファイル編集やテスト実行を行えます。プロジェクトがまだ git リポジトリでない場合、Specrails は共有フォルダでの実行へ明確にフォールバックし、ブランチや PR カードが出ないことを知らせます。
 
 レールは複数持てるので、名前付きのレーンとして作業を整理できます（いま集中している機能用のレールと、その後ろに控えさせておくレールといった具合に）。レールは**動的**です。レールヘッダーの **+ 追加** ボタンで新しいレーンを作成でき（1 プロジェクトあたり最大 12 本）、空のアイドルなレーンは削除できます。すべてのレールはサーバーに裏付けられているので、レーンの構成はリロード後も保持され、モバイルコンパニオンやアプリ内エージェントからも見えます — レーンがすべて塞がっているときは、エージェントが自分でレールを作ることさえできます。複数レールやバッチ処理については [バッチ実装とマルチフィーチャー](batch-implement-and-multi-feature) で詳しく説明します。
 
@@ -26,7 +26,7 @@ SpecsBoard（左）            レール（右）
 2. レールヘッダーで **Loop を選びます**。レールは **Loop** を実行します — それがレールの行う作業そのものです。デフォルトは組み込みの `Implement` Loop ですが、`Batch`、`Freestyle`、あるいは自分で作ったカスタム Loop を選ぶこともできます。[Loop Builder](the-loop-builder) を参照してください。
 3. **▶ Play を押します。**
 
-これだけです。レールがあなたのプロジェクト内で AI CLI プロセスを立ち上げ、パイプラインを開始します。
+これだけです。レールが適切な実行コンテキストで AI CLI プロセスを立ち上げ、パイプラインを開始します。
 
 ### レールヘッダーにあるもの
 
@@ -57,11 +57,11 @@ Freestyle は少し毛色が違います。エージェントチェーンを飛
 
 Play を押すたびに、そのレールの実行は **ジョブ** になります。ぜひ頭に入れておいてほしい一番大事なルールがこれです。
 
-> **レールは並列に実行されます。** すべての起動は作業をスペックごとの git worktree に隔離するので、同じプロジェクト内でも複数のレールを同時に走らせて衝突することはありません — 各実行の変更は、完了時にマージまたはドラフト PR として戻ってきます。
+> **レールは並列に実行されます。** git に裏付けられた起動は作業をスペックごとの git worktree に隔離するので、同じプロジェクト内でも複数のレールを同時に走らせて衝突することはありません。新しい作業は **レビュー中** の決定カードに着地し、そこから draft PR を作成するか破棄できます。すでに開いている PR を持つスペックの追加入力は、その PR のブランチを続行し、統合ブランチからやり直すことはありません。
 
 すべてを一斉に動かしたいときは、レールヘッダーの **すべて起動** ボタンが準備完了のレーンをまとめて起動します。確認は 1 回だけで、そこで総コスト（レール数 × AI 支出）が提示されます。空のレール、実行中のレール、PR の判断待ちのレールはスキップされ、コンパクトなサマリートーストで報告されます。アプリ内エージェントも `specrails_rails(launch_all)` で同じことができ、空きレーンがなければ自分で新しいレールを作ります。
 
-旧来の 1 プロジェクト 1 ジョブのキューに戻るのは、レガシー経路（Loops 機能を無効化した場合）だけです。その場合、追加のレールは実行中のレールの後ろで待機します。プロジェクトをまたぐ並列性は従来どおりで、各プロジェクトは完全に独立しています。
+git のないプロジェクトでは worktree 隔離も PR 継続も使えません。それでも実行はできますが、レールは共有プロジェクトフォルダへ直接書き込み、結果はスペックボードから手動で受け入れるか戻す形になります。
 
 調整できるグローバルな同時実行のつまみはありません。唯一の自動スロットルは予算ベースのものです。1 日の予算（プロジェクト単位またはアプリ全体）を設定していれば、その日の支出が上限に達した時点でキューが自動的に一時停止します。
 

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

@@ -12,7 +12,7 @@
 
 レールは **1 つ** の `/specrails:batch-implement` ジョブを起動し、割り当てられたすべてのスペックを順に処理します。他のジョブと同じようにジョブページで監視できます — スペックごとに別ジョブが立つのではなく、セット全体をカバーする 1 つのジョブです。
 
-これが効いてくるのは、**1 プロジェクトにつきジョブは 1 つ** というキューがあるからです。プロジェクトは一度に 1 つのレールジョブしか実行しないので、バッチモードは複数のレールを抱え込んで一つひとつ空くのを待たずに、スペックのリストを*連鎖的に*処理する一番すっきりした方法でもあります。
+Batch モードは、関連するスペックを*順番に処理する*一番すっきりした方法であり続けます。依存順序を 1 本のレールの中に保てるからです。スペック同士が独立しているなら、複数のレールに分けることもできます。git に裏付けられたレールは並列に走り、それぞれ専用の隔離 worktree を持ちます。
 
 ### Implement と Batch — どちらのモード？
 
@@ -46,6 +46,8 @@
 
 実行が終わっても、**何もプッシュされず、プルリクエストもまだ開かれません**。成果は隔離された各ブランチに安全にコミットされたまま残り、スペックは新しい **レビュー中（On review）** ステータスへ移り、specrails が **まずあなたに尋ねます**。レール上に常設の決定バーが現れ、**PR を作成** — プロジェクトで指定した統合ブランチ（**設定 → 統合ブランチ** で指定します。既定ではリポジトリのデフォルトブランチになります）を起点に、レール上のすべてのスペックをまとめた 1 つのドラフトのプルリクエストを開く — と **破棄** の選択肢を提示します。specrails が **マージすることはなく、統合ブランチへ直接コミットすることもありません** — そもそも PR を作るかどうかを決めるのはあなたであり、マージの責任は人間が持ちます。これは安全な引き渡しです。specrails はあなたが承認したときにだけプルリクエストを用意し、あなたのエンジニアがふだんどおり GitHub でレビューしてマージします。
 
+すでにレビュー中で、開いている pull request を持つスペックを再度起動した場合、Specrails はそれを追加入力として扱います。自分の delivery 記録、または GitHub/Jira の参照からアクティブな PR を検出し、その PR の head ブランチをチェックアウトし、新しい変更をそこへコミットして、同じ PR カードを再表示します。新しい作業はこれまでどおり統合ブランチから始まります。
+
 実際のところ、これは次を意味します。
 
 - 各スペックは、前のスペックの進行中の編集を途中から引き継ぐのではなく、まっさらな状態から実装に取りかかれます。
@@ -54,11 +56,11 @@
 - 作成後は、**PR を開く** で内容を確認し、**公開** でチームのレビューに公開してふだんどおりの GitHub レビューへ引き渡し、**マージを確認** で、チームがマージを終えた時点でスペックが完了（Done）へ切り替わります。
 - PR の作成時に隔離されたブランチをきれいに統合できない場合、specrails は安全に停止し、ブランチを人間のために残します — 壊れたマージをベースへ無理やり押し込むことは決してありません。同じバーから再試行も破棄もできます。
 
-> PR を作成するには、認証済みの GitHub CLI（`gh`）とリモートの設定が必要です。それらがなくても、成果はあなた自身がプルリクエストを開けるブランチへコミットされたまま残ります — 何も失われませんし、決定バーから再試行できます。以前の挙動（尋ねずにローカルで統合する）に戻すには、`SPECRAILS_RAIL_DELIVER_PR=0` を設定してください。
+> PR を作成または継続するには、git リポジトリ、認証済みの GitHub CLI（`gh`）、そしてリモートの設定が必要です。`gh` やリモートがなくても、成果はあなた自身が pull request を開けるブランチへコミットされたまま残ります — 何も失われませんし、決定バーから再試行できます。git がまったくない場合、継続できるブランチグラフはありません。レールは共有フォルダで実行され、PR カードは表示されません。以前の挙動（尋ねずにローカルで統合する）に戻すには、`SPECRAILS_RAIL_DELIVER_PR=0` を設定してください。
 
 ## プロジェクトをまたいだマルチフィーチャー
 
-本物の並列処理がほしいなら — 大きな機能を 2 つ同時にビルドしたいなら — 1 つのプロジェクト内のレールにまたがせるのではなく、**プロジェクトをまたいで** 分けてください。各プロジェクトは独立したキューを持つので、
+本物の並列処理がほしいなら、同じ git 対応プロジェクト内で独立したスペックを複数のレールに分けてもよいですし、プロジェクトをまたいで分けてもかまいません。各アクティブなレールは専用の隔離 worktree を持つので、
 
 ```
 プロジェクト A   ▶ 機能 X を実行中のレール   ┐
@@ -66,7 +68,7 @@
 プロジェクト B   ▶ 機能 Y を実行中のレール   ┘
 ```
 
-グローバルな同時実行の上限はなく、プロジェクト間の競合もありません。両方を開き、それぞれでレールを起動すれば、いっしょに進みます。共有されるスロットルは予算上限だけで、その日の支出が上限に達するとプロジェクト単位またはアプリ全体でキューを一時停止します。
+調整すべきグローバルな同時実行上限はありません。必要なプロジェクトやレールを開いて起動すれば、いっしょに進みます。共有されるスロットルは予算上限だけで、その日の支出が上限に達するとプロジェクト単位またはアプリ全体でキューを一時停止します。
 
 ## 大きなバッチのためのヒント
 

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

@@ -7,7 +7,8 @@ Quer que as suas specs vivam num **quadro Jira** real em vez de dentro do Specra
 O Specrails atua como uma **camada de sincronização** entre o Jira e o seu projeto. A ideia central: o seu repositório local de specs continua a ser a fonte canónica que o pipeline lê, e o Specrails é responsável por mantê-lo de acordo com o Jira.
 
 - Quando lança um rail, o Specrails move a issue Jira associada para **Em curso**.
-- Quando um trabalho termina, o Specrails transita a issue: em caso de sucesso, move-a para o seu estado de **revisão** mapeado e só chega a **Concluído** quando aprova o trabalho (o merge da PR em rascunho publica um comentário "PR merged"); em caso de falha, volta a **A fazer** com um comentário de conclusão (id do trabalho, custo e duração).
+- Quando um trabalho termina, o Specrails transita a issue: em caso de sucesso, move-a para o seu estado de **revisão** mapeado e só chega a **Concluído** quando a PR de entrega é mergeada ou aceita o resultado local; em caso de falha, volta a **A fazer** com um comentário de conclusão que inclui resultado, id da execução, custo, duração e a alteração de estado no Jira.
+- Se pedir alterações de seguimento quando a issue Jira já está em revisão, o Specrails tenta continuar a branch da PR aberta existente para esse ticket em vez de criar uma nova branch. Se o seu estado de revisão do Jira não estiver explicitamente mapeado e ainda aparecer localmente como **Em curso**, o Specrails ainda pode continuar a PR quando a chave Jira corresponde ao pull request aberto.
 - Periodicamente, o Specrails faz **polling** ao Jira em busca de alterações que alguém tenha feito no quadro e reflete-as de volta nas suas specs.
 
 Todas as escritas de retorno passam por uma fila de saída (outbox) durável e resistente a falhas, por isso um soluço momentâneo do Jira nunca quebra um trabalho — a atualização simplesmente volta a tentar.
@@ -32,7 +33,7 @@ O seu token é armazenado **cifrado na sua própria máquina** e nunca a abandon
 
 ## Mapeamento de estados
 
-A parte mais complicada de qualquer sincronização com o Jira é fazer corresponder *o seu* fluxo de trabalho aos estados simples do Specrails (A fazer / Em curso / Concluído, mais as variantes de cancelar/concluir). O Specrails resolve isto em dois níveis:
+A parte mais complicada de qualquer sincronização com o Jira é fazer corresponder *o seu* fluxo de trabalho aos estados simples do Specrails (A fazer / Em curso / Em revisão / Concluído, mais as variantes de cancelar). O Specrails resolve isto em dois níveis:
 
 1. **O seu mapa de estados explícito**, se definir um no assistente — ganha sempre.
 2. **Deteção automática** a partir da categoria de cada estado (novo / em curso / concluído) mais uma correspondência inteligente para estados do tipo cancelar e concluir.

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

@@ -1,6 +1,6 @@
 # Rails e jobs
 
-Você já tem specs no quadro. É aqui que elas viram código. Um **rail** é a pista que conduz uma spec por todo o pipeline — Architect → Developer → Reviewer → Ship — executando agentes de IA reais dentro do diretório do seu projeto. Esta página cobre como lançar um rail, a fila de jobs e como acompanhar o trabalho acontecendo ao vivo.
+Você já tem specs no quadro. É aqui que elas viram código. Um **rail** é a pista que conduz uma spec por todo o pipeline — Architect → Developer → Reviewer → Ship — executando agentes de IA reais para o seu projeto. Esta página cobre como lançar um rail, a execução em paralelo e como acompanhar o trabalho acontecendo ao vivo.
 
 ## O que é um rail
 
@@ -16,7 +16,7 @@ SpecsBoard (esquerda)       Rails (direita)
                     └────────────►   Rail 2   ▶ Play
 ```
 
-Um rail é uma **pista de execução**. Você arrasta um cartão de spec do SpecsBoard para um rail e depois aperta **▶ Play**. O rail dispara o pipeline e trabalha a spec de ponta a ponta, bem no diretório de trabalho do seu projeto — editando arquivos, rodando testes, tudo.
+Um rail é uma **pista de execução**. Você arrasta um cartão de spec do SpecsBoard para um rail e depois aperta **▶ Play**. Em repositórios git, o rail dispara o pipeline num git worktree isolado para que a IA possa editar arquivos e rodar testes sem tocar na sua árvore de trabalho ativa. Se o projeto ainda não é um repo git, o Specrails degrada claramente para execução na pasta compartilhada e avisa que não haverá branch nem cartão de PR.
 
 Você pode ter vários rails para organizar o trabalho em pistas nomeadas (uma para a feature em que está focado, outra na fila atrás dela). Os rails são **dinâmicos**: o botão **+ Adicionar** no cabeçalho de Rails cria uma nova pista (até 12 por projeto) e pistas vazias e ociosas podem ser removidas. Cada rail é respaldado pelo servidor, então seu conjunto de pistas sobrevive a recargas e fica visível para o companion móvel e para o agente integrado — o agente pode até criar um rail sozinho quando todas as pistas estão ocupadas. Mais sobre multi-rail e batching em [Batch implement e multi-feature](batch-implement-and-multi-feature).
 
@@ -26,7 +26,7 @@ Você pode ter vários rails para organizar o trabalho em pistas nomeadas (uma p
 2. **Escolha um Loop** no cabeçalho do rail. Um rail roda um **Loop** — é o trabalho que ele realiza. O padrão é o Loop `Implement` embutido; você também pode escolher `Batch`, `Freestyle` ou um loop personalizado que você mesmo construiu. Veja [O Loop Builder](the-loop-builder).
 3. **Aperte ▶ Play.**
 
-É isso. O rail sobe um processo de CLI de IA no seu projeto e começa o pipeline.
+É isso. O rail sobe um processo de CLI de IA no contexto de execução certo e começa o pipeline.
 
 ### O que tem no cabeçalho de um rail
 
@@ -57,11 +57,11 @@ Além dos embutidos, você pode **construir seus próprios loops** — repetir u
 
 Toda vez que você aperta Play, a execução do rail vira um **job**. A regra mais importante para internalizar:
 
-> **Os rails rodam em paralelo.** Cada lançamento isola seu trabalho em um worktree do git por spec, então vários rails podem rodar ao mesmo tempo dentro do mesmo projeto sem se atropelar — as mudanças de cada execução voltam como merge ou como draft PR quando ela termina.
+> **Os rails rodam em paralelo.** Cada lançamento apoiado por git isola seu trabalho em um worktree do git por spec, então vários rails podem rodar ao mesmo tempo dentro do mesmo projeto sem se atropelar. Trabalho novo termina num cartão de decisão **Em revisão**, onde você pode criar uma draft PR ou descartar; trabalho de seguimento para uma spec que já tem PR aberta continua a branch dessa PR em vez de recomeçar a partir da branch de integração.
 
 Quer tudo andando de uma vez? O botão **Lançar todos** no cabeçalho de Rails inicia todas as pistas prontas de uma só vez, após uma única confirmação que enquadra o custo total (N rails × gasto de IA). Rails vazios, já em execução ou aguardando uma decisão de PR são pulados e reportados em um toast de resumo compacto. O agente integrado tem o mesmo poder via `specrails_rails(launch_all)` — e cria um rail novo quando não existe pista livre.
 
-Só o caminho legado (feature de Loops desativada) volta à antiga fila de um-job-por-vez por projeto, em que rails extras esperam atrás do que está rodando. O paralelismo entre projetos não muda: cada projeto continua totalmente independente.
+Projetos sem git não têm isolamento por worktree nem continuação de PR. Eles ainda podem rodar, mas o rail escreve diretamente na pasta compartilhada do projeto e o resultado é aceito ou revertido manualmente a partir do quadro de specs.
 
 Não há um botão global de concorrência para ajustar. O único limite automático é baseado em orçamento: se você definiu um orçamento diário (do projeto ou da app), a fila se autopausa assim que o gasto do dia atinge o teto.
 

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

@@ -12,7 +12,7 @@ A forma mais simples de correr um monte de specs a partir de um rail é o modo *
 
 O rail lança **um** job `/specrails:batch-implement` que trabalha cada spec atribuída. Monitorize-o como qualquer outro job na página Jobs — é um único job que cobre todo o conjunto, não um job por spec.
 
-Isto importa por causa da **fila de um job por projeto**. Como um projeto só corre um job de rail de cada vez, o modo Batch é também a forma mais limpa de *encadear* uma lista de specs sem andar a fazer malabarismo com vários rails e à espera que cada um esvazie.
+O modo Batch continua a ser a forma mais limpa de *sequenciar* specs relacionadas, porque mantém a ordem das dependências dentro de um só rail. Se as specs forem independentes, também pode distribuí-las por vários rails: rails apoiados por git correm em paralelo e cada um recebe o seu próprio worktree isolado.
 
 ### Implement vs Batch — que modo?
 
@@ -46,6 +46,8 @@ Quando várias specs são implementadas numa só execução, o pipeline mantém
 
 Quando a execução termina, **nada é enviado e ainda não é aberto nenhum pull request**. O trabalho fica commitado em segurança nos seus branches isolados, as specs passam a um novo estado **Em revisão**, e o specrails **pergunta-lhe primeiro**: no rail aparece uma barra de decisão persistente com **Criar PR** — um pull request em rascunho a partir do branch de integração designado do seu projeto (defina-o em **Settings → Integration branch**; por omissão é o branch por defeito do seu repositório), combinado através de todas as specs do rail — e **Descartar**. O specrails **nunca faz merge, e nunca faz commit diretamente no seu branch de integração** — é você quem decide se sequer existe um PR, e um humano é responsável pelo merge. É a passagem de testemunho segura: o specrails produz o pull request apenas quando você o autoriza, e os seus engenheiros revêem-no e fazem merge no GitHub da forma como já o fazem.
 
+Se relançar uma spec que já está em revisão e tem um pull request aberto, o Specrails trata isso como trabalho de seguimento. Deteta a PR ativa a partir do seu próprio registo de entrega ou de referências GitHub/Jira, faz checkout da branch head dessa PR, commita aí as novas alterações e volta a mostrar o mesmo cartão de PR. Trabalho novo continua a começar a partir da branch de integração.
+
 Na prática isto significa:
 
 - Cada spec recebe um ponto de partida limpo para implementar, em vez de herdar as edições em curso da spec anterior a meio do processo.
@@ -54,11 +56,11 @@ Na prática isto significa:
 - Depois de criado, **Abrir PR** mostra o rascunho, **Publicar** abre-o à revisão e entrega-o à revisão normal da sua equipa no GitHub, e **Verificar merge** passa as specs a Concluído assim que a sua equipa o tiver mergeado.
 - Se os branches isolados não puderem ser combinados de forma limpa ao criar o PR, o specrails para em segurança e deixa os branches para um humano — nunca força um merge partido sobre a sua base. Pode tentar de novo ou descartar a partir da mesma barra.
 
-> Criar o PR precisa do GitHub CLI (`gh`) autenticado e de um remote configurado. Sem eles, o specrails mantém na mesma o trabalho commitado num branch a partir do qual pode abrir um pull request por si mesmo — nada se perde, e a barra de decisão permite tentar de novo. Para voltar ao comportamento anterior (integrar localmente em vez de perguntar), defina `SPECRAILS_RAIL_DELIVER_PR=0`.
+> Criar ou continuar uma PR precisa de um repositório git, do GitHub CLI (`gh`) autenticado e de um remote configurado. Sem `gh` ou sem remote, o specrails mantém na mesma o trabalho commitado num branch a partir do qual pode abrir um pull request por si mesmo — nada se perde, e a barra de decisão permite tentar de novo. Sem git, não há grafo de branches a continuar: o rail corre na pasta compartilhada e não aparece nenhum cartão de PR. Para voltar ao comportamento anterior (integrar localmente em vez de perguntar), defina `SPECRAILS_RAIL_DELIVER_PR=0`.
 
 ## Multi-feature entre projetos
 
-Se quiser paralelismo genuíno — duas grandes features a construir ao mesmo tempo — divida-as **entre projetos**, não entre rails de um mesmo projeto. Cada projeto tem a sua fila independente, por isso:
+Se quiser paralelismo genuíno, use vários rails para specs independentes no mesmo projeto apoiado por git, ou divida o trabalho entre projetos. Cada rail ativo recebe o seu próprio worktree isolado, por isso:
 
 ```
 Projeto A   ▶ Rail a correr a feature X   ┐
@@ -66,7 +68,7 @@ Projeto A   ▶ Rail a correr a feature X   ┐
 Projeto B   ▶ Rail a correr a feature Y   ┘
 ```
 
-Não há limite global de concorrência nem disputa entre projetos. Abra os dois, lance um rail em cada e progridem juntos. O único limitador partilhado é o seu limite de orçamento, que pausa as filas por projeto ou da app inteira assim que o gasto do dia atinge o limite.
+Não há limite global de concorrência para ajustar. Abra os projetos ou rails de que precisa, lance-os e progridem juntos. O único limitador partilhado é o seu limite de orçamento, que pausa as filas por projeto ou da app inteira assim que o gasto do dia atinge o limite.
 
 ## Dicas para batches grandes
 

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

@@ -7,7 +7,8 @@
 Specrails 充当 Jira 和你项目之间的**同步层**。核心思路是：你本地的规格存储仍然是流水线读取的那个权威来源，而 Specrails 负责让它和 Jira 保持一致。
 
 - 当你启动一条 rail 时，Specrails 会把关联的 Jira 事务移动到 **In Progress**。
-- 当一个任务结束时，Specrails 会转移该事务的状态：成功时移到你映射的**评审**状态，只有当你确认这份工作后才会到达 **Done**（合并草稿 PR 会发布一条 "PR merged" 评论）；失败时退回 **To Do**，并附上包含任务 id、成本和时长的完成评论。
+- 当一个任务结束时，Specrails 会转移该事务的状态：成功时移到你映射的**评审**状态，只有当交付 PR 被合并或你接受本地结果后才会到达 **Done**；失败时退回 **To Do**，并附上包含结果、运行 id、成本、时长以及 Jira 状态变化的完成评论。
+- 如果你在 Jira 事务已经处于评审状态时请求后续修改，Specrails 会尝试继续该 ticket 已有的打开 PR 分支，而不是创建新分支。如果你的 Jira 评审状态没有显式映射、在本地仍显示为 **In Progress**，只要 Jira key 与打开的 pull request 匹配，Specrails 仍然可以继续那条 PR。
 - Specrails 会定期**轮询** Jira，把任何人在看板上做的改动取回来，反映到你的规格里。
 
 所有的回写都会经过一个持久化、防崩溃的发件箱（outbox），所以 Jira 一时的小故障绝不会让任务出错——那次更新只是会重试而已。
@@ -32,7 +33,7 @@ Specrails 充当 Jira 和你项目之间的**同步层**。核心思路是：你
 
 ## 状态映射
 
-任何 Jira 同步里最棘手的部分，就是把*你的*工作流对应到 Specrails 那套简单的状态上（To Do / In Progress / Done，外加取消 / 上线的变体）。Specrails 分两层来解决：
+任何 Jira 同步里最棘手的部分，就是把*你的*工作流对应到 Specrails 那套简单的状态上（To Do / In Progress / On Review / Done，外加取消变体）。Specrails 分两层来解决：
 
 1. **你显式设置的状态映射**——如果你在向导里设了一个，它永远优先。
 2. **自动检测**——依据每个状态的类别（new / in-progress / done），再加上针对取消和上线类状态的智能匹配。

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

@@ -1,6 +1,6 @@
 # Rail 与任务
 
-你已经在看板上准备好了一堆 spec，现在就到了把它们变成真实代码的环节。一条 **rail** 就是一条"通道"，负责把一个 spec 推过完整的流水线——Architect → Developer → Reviewer → Ship——并在你的项目目录里运行真实的 AI Agent。本页会讲清楚如何启动一条 rail、任务队列是怎么回事，以及如何实时观看整个过程。
+你已经在看板上准备好了一堆 spec，现在就到了把它们变成真实代码的环节。一条 **rail** 就是一条"通道"，负责把一个 spec 推过完整的流水线——Architect → Developer → Reviewer → Ship——并为你的项目运行真实的 AI Agent。本页会讲清楚如何启动一条 rail、并行执行是怎么回事，以及如何实时观看整个过程。
 
 ## 什么是 rail
 
@@ -16,7 +16,7 @@ SpecsBoard (左)             Rails (右)
                     └────────────►   Rail 2   ▶ Play
 ```
 
-rail 是一条**执行通道**。你从 SpecsBoard 上拖一张 spec 卡片放到某条 rail 上，然后按下 **▶ Play**。这条 rail 就会启动流水线，从头到尾把这个 spec 做完——就在你项目的工作目录里，改文件、跑测试，样样都来。
+rail 是一条**执行通道**。你从 SpecsBoard 上拖一张 spec 卡片放到某条 rail 上，然后按下 **▶ Play**。对于 git 仓库，这条 rail 会在隔离的 git worktree 中启动流水线，让 AI 可以改文件、跑测试，而不会碰你当前活跃的工作树。如果项目还不是 git 仓库，Specrails 会明确降级到共享文件夹执行，并告诉你不会出现分支或 PR 卡片。
 
 你可以同时拥有好几条 rail，把工作组织成一条条命名的通道（一条放你眼下专注的功能，另一条排在它后面候着）。rail 是**动态的**：Rails 头部的 **+ 添加** 按钮可以新建一条通道（每个项目最多 12 条），空闲且为空的通道可以删除。每条 rail 都由服务器托管，所以你的通道集合在刷新后依然保留，移动端 companion 和内置代理都能看到——当所有通道都在忙时，代理甚至能自己创建一条 rail。关于多 rail 和批量运行的更多内容，请看 [批量实现与多功能](batch-implement-and-multi-feature)。
 
@@ -26,7 +26,7 @@ rail 是一条**执行通道**。你从 SpecsBoard 上拖一张 spec 卡片放
 2. **在 rail 头部挑一个 Loop。** 一条 rail 运行的是一个 **Loop**——也就是它要做的活儿。默认是内置的 `Implement` loop；你也可以挑 `Batch`、`Freestyle`，或者你自己搭的某个自定义 loop。见 [Loop Builder](the-loop-builder)。
 3. **按下 ▶ Play。**
 
-就这么简单。rail 会在你的项目里启动一个 AI CLI 进程，开始跑流水线。
+就这么简单。rail 会在正确的执行上下文里启动一个 AI CLI 进程，开始跑流水线。
 
 ### rail 头部里有什么
 
@@ -57,11 +57,11 @@ Freestyle 是个特例：它跳过 Agent 链条，把原始 spec 直接交给 Cl
 
 每次你按下 Play，这次 rail 的运行就成了一个**任务**。最该记牢的一条规则是：
 
-> **rail 是并行运行的。** 每次启动都会把工作隔离到每个 spec 独立的 git worktree 中，所以同一个项目里的多条 rail 可以同时运行、互不干扰——每次运行结束后，改动会以 merge 或 draft PR 的形式回归。
+> **rail 是并行运行的。** 每次有 git 支撑的启动都会把工作隔离到每个 spec 独立的 git worktree 中，所以同一个项目里的多条 rail 可以同时运行、互不干扰。新的工作会落到一个 **On review** 决策卡片里，你可以创建 draft PR 或丢弃；如果某个 spec 已经有打开的 PR，后续修改会继续使用那条 PR 的分支，而不是重新从集成分支开始。
 
 想让所有工作一起开跑？Rails 头部的 **全部启动** 按钮会一次性启动所有就绪的通道，只需一次确认，确认框会说明总成本（N 条 rail × AI 花费）。空的、已在运行的或等待 PR 决定的 rail 会被跳过，并在一个紧凑的汇总 toast 中报告。内置代理通过 `specrails_rails(launch_all)` 拥有同样的能力——而且当没有空闲通道时，它会自己创建一条新 rail。
 
-只有传统路径（关闭 Loops 功能时）才会退回到旧的"每个项目一次一个任务"队列，此时多余的 rail 会排在正在运行的那条后面。跨项目的并行不变：每个项目仍然完全独立。
+没有 git 的项目不会有 worktree 隔离，也不会有 PR 续接。它们仍然可以运行，但 rail 会直接写入项目的共享文件夹，结果需要你在 spec 看板上手动接受或还原。
 
 没有什么全局并发旋钮可调。唯一的自动节流是基于预算的：如果你设了每日预算（项目级或应用级），当当天的花费触到上限时，队列会自动暂停。
 

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

@@ -12,7 +12,7 @@
 
 这条 rail 会启动**一个** `/specrails:batch-implement` 任务，逐一处理每个分配进来的 spec。像监控其他任务一样在 Jobs 页面上盯着它就行——它是覆盖整组 spec 的单个任务，而不是每个 spec 一个任务。
 
-这一点之所以重要，是因为有那条**每个项目一个任务的队列**规则。既然一个项目同一时间只跑一个 rail 任务，Batch 模式也就成了把一串 spec*串起来*的最干净方式，免得你去摆弄多条 rail、还要等每条逐个排空。
+Batch 模式仍然是把相关 spec *按顺序处理*的最干净方式，因为它把依赖顺序保留在同一条 rail 内。如果这些 spec 彼此独立，也可以把它们分散到多条 rail 上：有 git 支撑的 rail 会并行运行，并且每条都有自己的隔离 worktree。
 
 ### Implement 还是 Batch——选哪个？
 
@@ -46,6 +46,8 @@ Wave 3:  #7 (docs across all)   ← waits for #4 and #5
 
 当运行结束时，**什么都不会被推送，也还没有任何 pull request 被创建**。工作安全地留在它们各自的隔离分支上，spec 进入一个新的 **On review（审查中）** 状态，然后 specrails **先来问你**：轨道上会出现一条常驻的决策栏，提供 **Create PR**——从你为项目指定的集成分支（在 **Settings → Integration branch** 里设置它；它默认取你仓库的默认分支）发起一个 draft pull request，把轨道上所有 spec 的工作合并在一起——以及 **Discard**。specrails **绝不合并，也绝不直接向你的集成分支提交**——PR 要不要存在由你决定，而合并这一步由人来掌控。这是一次安全的交接：只有你点头，specrails 才产出 pull request，你的工程师则像他们一贯做的那样，在 GitHub 里审查并合并它。
 
+如果你重新启动一个已经在审查中并且有打开 PR 的 spec，Specrails 会把它当作后续修改处理。它会从自己的交付记录或 GitHub/Jira 引用中识别活跃 PR，检出该 PR 的 head 分支，把新改动提交到那里，并重新显示同一张 PR 卡片。新的工作仍然从集成分支开始。
+
 落到实处就是：
 
 - 每个 spec 都得到一块干净的画布去实现，而不是半路接手上一个 spec 尚在进行中的编辑。
@@ -54,11 +56,11 @@ Wave 3:  #7 (docs across all)   ← waits for #4 and #5
 - 创建之后，**Open PR** 查看这个草稿，**发布** 把它开放给团队评审、交给你团队日常的 GitHub 审查流程，**Check merge** 则在你的团队完成合并后，把 spec 翻转为 Done。
 - 如果在创建 PR 时这些隔离的分支没法干净地合并到一起，specrails 会安全地停下来，把这些分支留给人来处理——它绝不会把一次破碎的合并硬塞到你的基线上。你可以在同一条决策栏上重试或丢弃。
 
-> 创建 PR 需要 GitHub CLI（`gh`）已完成认证，并配置好远端。若没有这些，specrails 依然会把工作保留在一个已提交的分支上，你可以自己从它发起 pull request——不会丢失任何东西，而且决策栏允许你重试。若要回退到旧行为（在本地整合而不是先询问），设置 `SPECRAILS_RAIL_DELIVER_PR=0`。
+> 创建或继续 PR 需要一个 git 仓库、已认证的 GitHub CLI（`gh`）以及配置好的远端。若没有 `gh` 或远端，specrails 依然会把工作保留在一个已提交的分支上，你可以自己从它发起 pull request——不会丢失任何东西，而且决策栏允许你重试。若完全没有 git，就没有可继续的分支图：rail 会在共享文件夹中运行，也不会出现 PR 卡片。若要回退到旧行为（在本地整合而不是先询问），设置 `SPECRAILS_RAIL_DELIVER_PR=0`。
 
 ## 跨项目的多功能
 
-如果你想要真正的并行——两个大功能同时在做——那就把它们**跨项目**拆开，而不是塞进同一个项目里的多条 rail。每个项目都有自己独立的队列，所以：
+如果你想要真正的并行，可以在同一个有 git 支撑的项目里用多条 rail 处理彼此独立的 spec，也可以把工作拆到多个项目中。每条活跃 rail 都有自己的隔离 worktree，所以：
 
 ```
 Project A   ▶ Rail running feature X   ┐
@@ -66,7 +68,7 @@ Project A   ▶ Rail running feature X   ┐
 Project B   ▶ Rail running feature Y   ┘
 ```
 
-没有全局并发上限，项目之间也没有争抢。两个都开着，各启动一条 rail，它们就会一起推进。唯一共享的节流是你的预算上限，它会在当天花费触到上限时，按项目或按应用级暂停队列。
+没有需要调节的全局并发上限。打开你需要的项目或 rail，启动它们，它们就会一起推进。唯一共享的节流是你的预算上限，它会在当天花费触到上限时，按项目或按应用级暂停队列。
 
 ## 大批量的小贴士
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specrails-desktop",
-  "version": "2.24.0",
+  "version": "2.24.2",
   "license": "MIT",
   "repository": {
     "type": "git",