specrails-desktop 2.57.0 → 2.58.0

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

@@ -22,7 +22,7 @@
 
 ## パイプラインのフェーズ
 
-`Implement` と `Batch` のジョブでは、スラッシュコマンドが定義するフェーズに沿って実行が進みます — デフォルトでは次のとおりです。
+`Implement` のジョブでは、スラッシュコマンドが定義するフェーズに沿って実行が進みます — デフォルトでは次のとおりです。
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -113,5 +113,14 @@ Architect ──► Developer ──► Reviewer ──► Ship
 ## 次に読むもの
 
 - [レールとジョブ](rails-and-jobs) — 起動とキューイング。
-- [バッチ実装とマルチフィーチャー](batch-implement-and-multi-feature) — 多数のスペックと依存ウェーブ。
 - [コストの追跡](../analytics/tracking-cost) — ジョブごとのコストをプロジェクト分析へ。
+
+## ワークフローの再起動後
+
+クラッシュ後は、元の設定とリポジトリを使って保存済みワークフローを再開します。書き込みが中断された場合は、ワークツリーの差分を確認してから、復旧する試行を正確に選択してください。完了したステップは保持されます。応答が失われたプロバイダー呼び出しも中断として集計され、使用量は不明のままです。無料として表示されることはありません。保存済みの記録で元の成果物の受け渡し関係を確認できない場合、復旧はエラーを表示し、ワークツリーを保持します。
+
+判断ステップが質問のために一時停止した場合、再開時には保存済みの判断を再利用し、人の回答を次のステップに渡します。同じ判断のためにモデルを再度呼び出すことはありません。一時停止したプロンプトでは、回答を反映するためにモデルの追加呼び出しが必要になることがあります。
+
+## 履歴の保持
+
+保存された実行は既定で無期限に保持されます。**保存された実行 → 履歴の保持** で、プロジェクトごとに 1〜3650 日の保持期間を設定できます。バックグラウンドで削除されることはありません。ポリシーを保存し、**削除対象を確認** で各実行と理由を確認してから **期限切れの履歴を削除** を選びます。実行中、回答や承認の待機中、中断された書き込みがある場合、未完了の配信やそれに依存するフォークがある場合、その実行は保護されます。削除されるのはプロジェクトの Specrails ストレージ内の実行履歴だけで、リポジトリ、worktree、ジョブログ、コスト記録は残ります。期限切れの実行は **期限切れ** と表示され、再開やフォークはできません。残っている実行が使う Core バージョンは常に保持されます。

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

@@ -22,14 +22,14 @@ install できます。
 
 ## それぞれのエンジンが得意なこと
 
-4 つすべてが **Implement** と **Batch** を実行します。
+4 つすべてが **Implement** を実行します。
 
 | エンジン | こんなときに | 補足 |
 |--------|--------------------|-------|
 | **Claude** | native cost、persistent interaction、strict tool policy が必要。 | Profile、Freestyle、structured transform。 |
 | **Codex** | OpenAI Codex CLI を好むとき、あるいはプロバイダー間で実装を比べたいとき。 | `codex` ≥ 0.128.0。ネイティブのコスト報告なし — アプリが料金表からコストを補います。プロファイルは適用されません。 |
 | **Gemini** | Google の Gemini CLI を使いたいとき、ネイティブのテレメトリがほしいとき、あるいは日常的なスペックを安く実行したいとき。 | `gemini` ≥ 0.11.0（`GEMINI_API_KEY` を設定）。ネイティブの OTLP テレメトリ。プロファイルは適用されません。 |
-| **Kimi** | Implement、Batch、Freestyle、Decider のない loop に agentic Kimi を使う。 | 外部 `kimi` ≥ 0.27.0。Profile/role、effort は K3 のみ。token/cost は unavailable。 |
+| **Kimi** | Implement、Freestyle、Decider のない loop に agentic Kimi を使う。 | 外部 `kimi` ≥ 0.27.0。Profile/role、effort は K3 のみ。token/cost は unavailable。 |
 
 ### Capability の違い
 

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

@@ -1,6 +1,16 @@
 # Loop Builder
 
-**レールは Loop を実行します。** 組み込みの Loop（`Implement`、`Batch`、`Freestyle`）は日常的なケースをカバーしますが、**Loop Builder** を使えば自分だけの Loop を設計できます — 目標が達成されるまで繰り返す自動化のための、n8n スタイルのビジュアルエディターです。このページでは、Loop とは何か、どう作るのか、そしてレールでどう実行するのかを説明します。
+## Core ワークフロー
+
+対応する Core エンジンでは、新しいキャンバスにインストール済みカタログの17種類のステップが表示されます。クリックまたはドラッグして追加し、フォームで設定します。プロバイダーとロールは現在のプロジェクトの設定を使用します。名前付きの出力を別のステップまたは終了に接続します。各出力に接続できる先は1つです。
+
+フォームは任意項目、オブジェクト、配列、辞書を編集でき、AI、条件、検証、シェル、OpenSpec、承認、質問、一時停止、各項目の実行、結合、コンポーネント、実装に対応します。設定ではトークン数、遷移数、並列数を制限できます。コンポーネント内部の実行も遷移数に含まれます。
+
+**コンポーネント**で再利用する処理を作成し、入力変数と出力名を宣言して、コンポーネントまたは各項目の実行ステップから選択します。ナビゲーションで編集内容を保持したままメインキャンバスに戻れます。内部の終了は `exit` で出力名を指定できます。
+
+公開時に Core が下書きを検証し、問題のあるステップにエラーを表示します。実行開始時にはプロジェクトの設定を再検証します。エンジンが利用できない場合は Core を更新してください。既存の Desktop ループは従来の編集・実行方式を維持し、以下の節で説明しています。
+
+**レールは Loop を実行します。** 組み込みの Loop（`Implement`、`Freestyle`、`SDD Quick (OpenSpec)`）は日常的なケースをカバーしますが、**Loop Builder** を使えば自分だけの Loop を設計できます — 目標が達成されるまで繰り返す自動化のための、n8n スタイルのビジュアルエディターです。このページでは、Loop とは何か、どう作るのか、そしてレールでどう実行するのかを説明します。
 
 ## Loop とレール — その関係
 
@@ -10,9 +20,8 @@
    Loop Builder（左サイドバー）             レール（右）
    ───────────────────────────             ─────────────
    Implement   （組み込み）                  レール 1
-   Batch       （組み込み）      ► で選ぶ      Loop: Verify-until-green
-   Freestyle   （組み込み）                    ▶ Play
-   Verify-until-green （あなたの作ったもの）
+   Freestyle   （組み込み）      ► で選ぶ      Loop: Verify-until-green
+   Verify-until-green （あなたの作ったもの）                    ▶ Play
 ```
 
 - Loop は **Loops** セクション（左サイドバー、プロジェクトの隣）にあります — これらは **グローバル** で、すべてのプロジェクトで共有されます。
@@ -25,7 +34,7 @@
 
 左サイドバーの **Loops** をクリックすると、ライブラリが表示されます。3 つの組み込み Loop に加えて、あなた自身の Loop が並びます。どれかを開いて中身を見るか、**New loop** をクリックして真っ白なキャンバスから始めます。
 
-組み込みの Loop を直接編集するのは簡単ではありません — 代わりに **Fork** します。そうすると、ちゃんと動くグラフの編集可能なコピーが手に入るので、そこから始められます。これが一番手っ取り早い学び方です。
+組み込み Loop は、実際に編集できる本物の Loop です。**Edit** で開いて、ほかの Loop と同じように変更できます。保存すると下書きになり、**Publish** すると、その組み込み Loop を使う**すべてのレール、エージェントチャットからの起動、Companion からの起動**にあなたのバージョンが適用されます。編集が下書きのあいだ、レールは最後に公開されたバージョンを実行し続けるので、編集途中で壊れることはありません。**元に戻す**（カードまたはビルダー）で組み込み Loop を既定に戻せます。組み込み Loop は削除できません。別のコピーがほしいときは **Duplicate** を使います。組み込み Loop はそのままで、通常の Loop が作成されます。
 
 ## Loop を構成するもの
 
@@ -93,3 +102,13 @@ Loop は最初は **Draft** です。グラフが有効になったら **Publish
 - [レールとジョブ](rails-and-jobs) — レールの起動とジョブのキュー。
 - [ジョブ詳細ビュー](the-job-detail-view) — 実行をライブで見守る。
 - [レールごとのエンジン選択](picking-an-engine-per-rail) — プロバイダーを選ぶのは（Loop ではなく）レール。
+
+選択した Core が呼び出しごとの制限に対応している場合、prompt、role、decider の各ピースで `timeoutMs` と `idleTimeoutMs` を設定できます。`0` を指定すると、そのステップの該当タイマーが無効になります。フィールドを削除すると、既定値を継承します。ワークフロー全体の予算とキャンセルは引き続き有効です。検証ステップが判断を必要とする質問をした場合、回答を待ってから成功結果を受け入れます。
+
+保存済みの従来のグラフを初めて Core のピースに置き換えると、元のグラフが保持されます。ライブラリには **元のグラフをエクスポート** が表示されます。エクスポートには別の名前が付くため、現在のワークフローを置き換えずに、独立した下書きとしてインポートできます。変換やその後の編集でループが自動公開されることはありません。
+
+**変数を設定**では、一時停止後も保持する状態を定義できます。型付きのJSON値を設定するか、既存の整数カウンターを増減します。このピースはAIを呼び出しません。更新はまとめて保存され、カウンターが無効な場合はすべての変数が変更されません。マップされたコンポーネントの変数は、そのコンポーネント内に限定されます。
+
+Deciderの**この条件が成立する間は続行**は、未完了の必須作業を保護します。例えば `$vars.failedPass == true` は、ワークフローがフラグを解除するまで停止提案を続行に変更します。判断処理は実行され、変更のない繰り返しには進捗なしの上限が適用されます。人への質問では引き続き回答を待ちます。
+
+以前のエンジンで保存したループを移行するには、ライブラリで **Core に変換**を選びます。シェルステップに明示的な対象がない場合は元のリポジトリを選択してください。変換はグラフを検証し、エクスポート可能な元のコピーとともに下書きを保存します。接続を確認して明示的に公開してください。実行中のループは変換できず、同時編集は保持されます。書き込みステップには実際の検証コマンドが必要です。Quick SDD は Core 同梱の OpenSpec を使用します。変換できない場合は Core を更新してください。

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

@@ -15,7 +15,7 @@ Cada conexão também tem a configuração **Loop do agente**. **Compacto** (pad
 
 ## O que você ganha
 
-- Rails (implement, batch, freestyle, loops personalizados), Explore e specs Quick, chat e missões rodam no modelo local.
+- Rails (implement, freestyle, loops personalizados), Explore e specs Quick, chat e missões rodam no modelo local.
 - As missões mantêm suas ferramentas Specrails e seus servidores MCP externos.
 - As sessões são retomadas entre turnos; jobs interativos funcionam.
 - O custo é honesto: os tokens são registrados, o custo fica *desconhecido* a menos que você informe tarifas (então é marcado como *estimado*).

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

@@ -18,12 +18,12 @@ SpecsBoard (esquerda)       Rails (direita)
 
 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).
+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.
 
 ## Lançando um rail sobre uma spec
 
 1. **Arraste um cartão de spec** do SpecsBoard para um rail. O ID da spec aparece na lista de specs do rail. (Prefere não arrastar? Use o popover **Mover para o rail** no cartão da spec — ele mostra um indicador de status por rail, para você não soltar trabalho numa pista ocupada.)
-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).
+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 `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 contexto de execução certo e começa o pipeline.
@@ -34,25 +34,28 @@ Você pode ter vários rails para organizar o trabalho em pistas nomeadas (uma p
 |---------|--------------|
 | **Pílula de status** | `idle`, `running` ou `failed`. Não há um "completed" separado — um rail volta para `idle` quando seu job termina sem erros. |
 | **Lista de specs** | Os IDs atribuídos a este rail. Arraste mais para dentro, arraste para fora para desanexar. |
-| **Seletor de Loop** | O Loop que este rail roda — um embutido (`Implement` / `Batch` / `Freestyle`) ou um loop personalizado. Veja a tabela abaixo. Persistido por rail. |
+| **Seletor de Loop** | O Loop que este rail roda — um embutido (`Implement` / `Freestyle` / `SDD Quick (OpenSpec)`) ou um loop personalizado. Veja a tabela abaixo. Persistido por rail. |
 | **Seletor de perfil** | Qual perfil do provider corre (rails Claude e Kimi). |
 | **Seletor de motor** | Qual provider corre o rail — Claude, Codex, Gemini ou Kimi. |
 | **▶ Play / ■ Stop** | Iniciar ou cancelar. |
 
 ### O que um rail roda: Loops
 
-Um rail roda um **Loop** — a receita do trabalho. Três loops são **embutidos** e cobrem os casos comuns:
+Um rail roda um **Loop** — a receita do trabalho. Dois loops são **embutidos** e cobrem os casos comuns:
 
 | Loop embutido | Comando | O que faz |
 |------|---------|--------------|
 | **Implement** | `/specrails:implement` | Um job cobrindo todas as specs do rail. Roda o pipeline completo Architect → Developer → Reviewer → Ship. O padrão do dia a dia. |
-| **Batch** | `/specrails:batch-implement` | Um job que percorre as specs do rail sequencialmente, em ondas que respeitam as dependências. Melhor para várias specs relacionadas. |
 | **Freestyle** | Freestyle | Claude ou Kimi implementa cada spec de forma autónoma, **ignorando** o pipeline. |
 
+Para rodar várias specs, coloque as relacionadas (até 3) num único rail — o `Implement` executa-as como um só job agregado — ou distribua specs independentes por vários rails: cada rail com git roda em paralelo na sua própria worktree isolada.
+
 Freestyle usa ferramentas e modelos nativos do provider. Claude tem transport
 interativo persistente; Kimi usa um processo agentic `kimi -p` sem stdin
 persistente.
 
+Os embutidos também são editáveis: edite um no Loop Builder e publique-o, e todos os rails que o escolhem rodam a sua versão (use **Restaurar original** para voltar atrás).
+
 Além dos embutidos, você pode **construir seus próprios loops** — repetir um ciclo verify → fix → verify até atingir uma meta, encadear comandos de shell entre AI Steps e muito mais. Esses loops personalizados aparecem no mesmo seletor de Loop. Essa é a próxima grande ideia: [O Loop Builder](the-loop-builder).
 
 ## A fila de jobs
@@ -98,5 +101,4 @@ Se algo parecer errado:
 
 - [O Loop Builder](the-loop-builder) — o que um rail roda, e como construir seus próprios loops.
 - [A vista de detalhe do job](the-job-detail-view) — fases, métricas ao vivo, cartões de ticket.
-- [Batch implement e multi-feature](batch-implement-and-multi-feature) — rode várias specs de uma vez.
 - [Escolhendo um motor por rail](picking-an-engine-per-rail) — Claude, Codex, Gemini ou Kimi.

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

@@ -22,7 +22,7 @@ Dois painéis ficam por cima do log completo em streaming; num job Claude em exe
 
 ## Fases do pipeline
 
-Para os jobs `Implement` e `Batch`, a execução percorre as fases definidas pelo slash command — por default:
+Para os jobs `Implement`, a execução percorre as fases definidas pelo slash command — por default:
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -112,5 +112,14 @@ Se a [telemetria](../settings/customizing) estava ativada para o job, aparece um
 ## Para onde ir a seguir
 
 - [Rails e jobs](rails-and-jobs) — lançar e enfileirar.
-- [Batch implement e multi-feature](batch-implement-and-multi-feature) — muitas specs, ondas de dependências.
 - [Acompanhar o custo](../analytics/tracking-cost) — transformar os custos por job em analytics do projeto.
+
+## Após reiniciar um workflow
+
+Após uma falha, retome o workflow salvo com a configuração e os repositórios originais. Uma escrita interrompida exige selecionar a tentativa exata depois de revisar o diff do worktree. As etapas concluídas são preservadas. Uma chamada ao provedor cuja resposta foi perdida continua contabilizada como interrompida, com consumo desconhecido; nunca é apresentada como gratuita. Se os registros salvos não comprovarem a entrega original, a recuperação mostra um erro e preserva o worktree.
+
+Quando uma etapa de decisão pausa para fazer uma pergunta, a retomada reutiliza a decisão salva e transmite a resposta humana à próxima etapa. O modelo não é chamado novamente para essa mesma decisão. Um prompt pausado pode precisar de outro turno do modelo para aplicar sua resposta.
+
+## Retenção do histórico
+
+As execuções guardadas são mantidas indefinidamente por omissão. Em **Execuções guardadas → Retenção do histórico**, um projeto pode mantê-las entre 1 e 3650 dias. Nada é eliminado em segundo plano: guarde a política, escolha **Pré-visualizar limpeza** e reveja cada execução e o seu motivo antes de **Eliminar histórico expirado**. Uma execução continua protegida enquanto está ativa, aguarda a sua resposta ou aprovação, tem uma escrita interrompida, uma entrega aberta ou um fork que ainda depende dela. Só é removido o histórico de execução no armazenamento Specrails do projeto; o repositório, os worktrees, o log do job e os registos de custo mantêm-se. Uma execução expirada aparece como **Expirado** e já não pode ser retomada nem bifurcada. As versões do Core ainda usadas por uma execução mantida são sempre preservadas.

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

@@ -22,14 +22,14 @@ O motor selecionado corre todas as fases do pipeline desse rail. Se a CLI do mot
 
 ## Em que cada motor é bom
 
-Os quatro correm os pipelines standard **Implement** e **Batch**:
+Os quatro correm o pipeline standard **Implement**:
 
 | Motor | Recorra a ele quando… | Notas |
 |--------|--------------------|-------|
 | **Claude** | Precisa de custo nativo, interação persistente ou tool policy rigorosa. | Perfis, Freestyle e transformações estruturadas. |
 | **Codex** | Prefere o Codex CLI da OpenAI ou quer comparar implementações entre fornecedores. | `codex` ≥ 0.128.0. Sem reporte de custo nativo — a app preenche o custo a partir da sua tabela de preços. Os perfis não se aplicam. |
 | **Gemini** | Quer o Gemini CLI da Google, telemetria nativa ou uma execução mais barata para specs de rotina. | `gemini` ≥ 0.11.0 (defina `GEMINI_API_KEY`). Telemetria OTLP nativa. Os perfis não se aplicam. |
-| **Kimi** | Quer Kimi agentic para Implement, Batch, Freestyle ou loops sem Decider. | `kimi` ≥ 0.27.0 externo; perfis/roles, effort só K3; tokens/custo indisponíveis. |
+| **Kimi** | Quer Kimi agentic para Implement, Freestyle ou loops sem Decider. | `kimi` ≥ 0.27.0 externo; perfis/roles, effort só K3; tokens/custo indisponíveis. |
 
 ### Diferenças de capability
 

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

@@ -1,6 +1,16 @@
 # O Loop Builder
 
-Um **rail roda um Loop**. Os loops embutidos (`Implement`, `Batch`, `Freestyle`) cobrem os casos do dia a dia, mas o **Loop Builder** deixa você desenhar os seus próprios — um editor visual, no estilo n8n, para automação que se repete até atingir uma meta. Esta página explica o que é um loop, como construir um e como rodá-lo em um rail.
+## Workflows Core
+
+Com um motor Core compatível, um novo canvas apresenta as dezassete etapas do catálogo instalado. Clique ou arraste uma etapa e preencha o formulário. Os fornecedores e papéis pertencem ao projeto ativo. Ligue cada saída identificada a outra etapa ou a Fim; cada saída permite uma ligação.
+
+Os formulários cobrem campos opcionais, objetos, listas e dicionários para IA, condições, verificação, shell, OpenSpec, aprovações, perguntas, pausas, mapas, uniões, componentes e implementação. As opções incluem limites de tokens e transições e concorrência. As visitas dentro de componentes também contam para o limite.
+
+Crie um corpo reutilizável em **Componentes**, declare entradas e saídas e selecione-o numa etapa Componente ou Mapear. A navegação regressa ao canvas principal sem perder alterações. Um Fim local pode selecionar uma saída através de `exit`.
+
+A publicação envia o rascunho ao Core e apresenta os erros nas etapas. O lançamento valida novamente a configuração do projeto. Atualize o Core se o motor estiver indisponível. Os loops antigos mantêm o editor e a execução anteriores; as secções seguintes descrevem-nos.
+
+Um **rail roda um Loop**. Os loops embutidos (`Implement`, `Freestyle`, `SDD Quick (OpenSpec)`) cobrem os casos do dia a dia, mas o **Loop Builder** deixa você desenhar os seus próprios — um editor visual, no estilo n8n, para automação que se repete até atingir uma meta. Esta página explica o que é um loop, como construir um e como rodá-lo em um rail.
 
 ## Loops e rails — a relação
 
@@ -10,9 +20,8 @@ Um **loop** é a *receita* do trabalho; um **rail** é a *pista* que o roda cont
    Loop Builder (barra lateral esq.)        Rails (direita)
    ───────────────────────────             ─────────────
    Implement   (embutido)                  Rail 1
-   Batch       (embutido)      escolha ►      Loop: Verify-until-green
-   Freestyle   (embutido)                     ▶ Play
-   Verify-until-green (seu)
+   Freestyle   (embutido)      escolha ►      Loop: Verify-until-green
+   Verify-until-green (seu)                     ▶ Play
 ```
 
 - Os loops vivem na seção **Loops** (barra lateral esquerda, ao lado dos seus projetos) — eles são **globais**, compartilhados por todos os projetos.
@@ -25,7 +34,7 @@ Ou seja: construa um loop uma vez e depois escolha-o em qualquer rail, em qualqu
 
 Clique em **Loops** na barra lateral esquerda para ver a biblioteca: os três loops embutidos mais os seus próprios. Abra um para vê-lo, ou clique em **New loop** para começar de uma tela em branco.
 
-Você não consegue editar um embutido diretamente com facilidade — em vez disso, faça **Fork** dele. Isso te dá uma cópia editável de um grafo que funciona como ponto de partida, que é a forma mais fácil de aprender.
+Os loops embutidos são loops reais e editáveis. Abra um com **Edit** e altere-o como qualquer outro loop: ao salvar ele vira rascunho, e **Publish** aplica a sua versão em **todos os rails, lançamentos pelo chat do agente e lançamentos pelo Companion que usam esse embutido**. Enquanto a sua edição for um rascunho, os rails continuam executando a última versão publicada, então nada quebra no meio da edição. **Restaurar original** (no cartão ou no builder) volta o embutido à versão padrão; embutidos não podem ser excluídos. Prefere uma cópia separada? Use **Duplicate** — isso cria um loop comum e deixa o embutido intacto.
 
 ## Do que um loop é feito
 
@@ -93,3 +102,13 @@ A execução transmite ao vivo na vista **Jobs** com as mesmas métricas e o mes
 - [Rails e jobs](rails-and-jobs) — lançando rails e a fila de jobs.
 - [A vista de detalhe do job](the-job-detail-view) — acompanhando uma execução ao vivo.
 - [Escolhendo um motor por rail](picking-an-engine-per-rail) — o rail (não o loop) escolhe o provedor.
+
+Quando a versão de Core selecionada disponibiliza limites por invocação, os blocos de prompt, função e decider oferecem `timeoutMs` e `idleTimeoutMs`. Use `0` para desativar esse temporizador da etapa ou remova o campo para herdar o valor padrão. Os orçamentos do workflow completo e o cancelamento continuam ativos. Uma etapa de verificação que faz uma pergunta bloqueante espera sua resposta antes de aceitar um resultado bem-sucedido.
+
+Quando um grafo antigo salvo é substituído pela primeira vez por blocos Core, o grafo original é preservado. A biblioteca passa a oferecer **Exportar grafo original**. A exportação tem um nome diferente para permitir a importação como rascunho separado, sem substituir o workflow atual. A conversão e as edições posteriores nunca publicam um loop automaticamente.
+
+Use **Definir variáveis** para preservar o estado durante uma pausa: defina valores JSON tipados ou ajuste um contador inteiro existente. Esta peça não faz chamadas à IA. Todas as alterações são guardadas em conjunto; um contador inválido deixa todas as variáveis intactas. As variáveis de um componente mapeado permanecem locais a esse componente.
+
+No Decider, **Continuar enquanto esta condição se verificar** protege o trabalho obrigatório pendente. Por exemplo, `$vars.failedPass == true` transforma uma proposta de paragem em continuação até o workflow limpar esse indicador. A decisão continua a ser executada e as repetições sem alterações continuam sujeitas ao limite de falta de progresso. As perguntas humanas continuam a aguardar uma resposta.
+
+Para migrar um loop guardado do motor anterior, escolha **Converter para Core** na biblioteca. Selecione o repositório original quando um passo shell não tiver um âmbito explícito. A conversão valida o grafo e guarda um rascunho com uma cópia exportável do original. Reveja as ligações e publique explicitamente. Loops em execução não podem ser convertidos; alterações concorrentes são preservadas. Os passos de escrita exigem comandos reais de verificação e Quick SDD utiliza o OpenSpec incluído no Core. Atualize o Core se a conversão não estiver disponível.

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

@@ -15,7 +15,7 @@
 
 ## 你将获得
 
-- Rails（implement、batch、freestyle、自定义 loop）、Explore 与 Quick spec、聊天和任务都在本地模型上运行。
+- Rails（implement、freestyle、自定义 loop）、Explore 与 Quick spec、聊天和任务都在本地模型上运行。
 - 任务保留 Specrails 工具和你的外部 MCP 服务器。
 - 会话可跨轮次恢复；交互式 job 可用。
 - 成本诚实：记录 token，除非你填写费率，否则成本显示为*未知*（填写后标记为*估算*）。

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

@@ -18,12 +18,12 @@ SpecsBoard (左)             Rails (右)
 
 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)。
+你可以同时拥有好几条 rail，把工作组织成一条条命名的通道（一条放你眼下专注的功能，另一条排在它后面候着）。rail 是**动态的**：Rails 头部的 **+ 添加** 按钮可以新建一条通道（每个项目最多 12 条），空闲且为空的通道可以删除。每条 rail 都由服务器托管，所以你的通道集合在刷新后依然保留，移动端 companion 和内置代理都能看到——当所有通道都在忙时，代理甚至能自己创建一条 rail。
 
 ## 在某个 spec 上启动一条 rail
 
 1. **把一张 spec 卡片拖**到某条 rail 上。该 spec 的 ID 会出现在这条 rail 的 spec 列表里。（不想拖？用 spec 卡片上的 **放入 Rail** 弹窗——它会为每条 rail 显示一个状态圆点，避免你把活儿丢进一条正忙的通道。）
-2. **在 rail 头部挑一个 Loop。** 一条 rail 运行的是一个 **Loop**——也就是它要做的活儿。默认是内置的 `Implement` loop；你也可以挑 `Batch`、`Freestyle`，或者你自己搭的某个自定义 loop。见 [Loop Builder](the-loop-builder)。
+2. **在 rail 头部挑一个 Loop。** 一条 rail 运行的是一个 **Loop**——也就是它要做的活儿。默认是内置的 `Implement` loop；你也可以挑 `Freestyle`，或者你自己搭的某个自定义 loop。见 [Loop Builder](the-loop-builder)。
 3. **按下 ▶ Play。**
 
 就这么简单。rail 会在正确的执行上下文里启动一个 AI CLI 进程，开始跑流水线。
@@ -34,25 +34,28 @@ rail 是一条**执行通道**。你从 SpecsBoard 上拖一张 spec 卡片放
 |---------|--------------|
 | **状态标签** | `idle`、`running` 或 `failed`。这里没有单独的"completed"——任务干净地跑完后，rail 会回到 `idle`。 |
 | **spec 列表** | 分配给这条 rail 的 ID。可以再拖进来，也可以拖出去解除关联。 |
-| **Loop 选择器** | 这条 rail 运行的 Loop——内置的（`Implement` / `Batch` / `Freestyle`）或某个自定义 loop。见下表。按 rail 单独记忆。 |
+| **Loop 选择器** | 这条 rail 运行的 Loop——内置的（`Implement` / `Freestyle` / `SDD Quick (OpenSpec)`）或某个自定义 loop。见下表。按 rail 单独记忆。 |
 | **Profile 选择器** | 使用哪个 provider profile（Claude/Kimi rail）。 |
 | **引擎选择器** | 哪个 provider 运行 rail——Claude、Codex、Gemini 或 Kimi。 |
 | **▶ Play / ■ Stop** | 启动或取消。 |
 
 ### rail 运行的是什么：Loop
 
-一条 rail 运行的是一个 **Loop**——干活的配方。有三个 loop 是**内置**的，覆盖了常见情况：
+一条 rail 运行的是一个 **Loop**——干活的配方。有两个 loop 是**内置**的，覆盖了常见情况：
 
 | 内置 loop | 命令 | 作用 |
 |------|---------|--------------|
 | **Implement** | `/specrails:implement` | 一个任务覆盖这条 rail 上的所有 spec。跑完整的 Architect → Developer → Reviewer → Ship 流水线。日常默认选项。 |
-| **Batch** | `/specrails:batch-implement` | 一个任务，按依赖感知的批次（wave）依次处理 rail 上的各个 spec。最适合一组相关的 spec。 |
 | **Freestyle** | Freestyle | Claude 或 Kimi 自主实现每个 spec，**绕过**流水线。 |
 
+要运行多个 spec，可以把相关的（最多 3 个）放到同一条 rail 上——`Implement` 会把它们作为一个整体任务运行——或者把彼此独立的 spec 分到多条 rail：每条基于 git 的 rail 都在自己隔离的 worktree 中并行运行。
+
 Freestyle 使用 provider 的 native tool/model。Claude 有 persistent
 interactive transport；Kimi 使用没有 persistent stdin 的 agentic
 `kimi -p` process。
 
+内置 loop 也可以编辑：在 Loop Builder 里编辑并发布后，所有选用它的 rail 都会运行你的版本（用 **恢复原始版本** 可以改回去）。
+
 除了这些内置 loop，你还可以**搭建自己的 loop**——重复一个 verify → fix → verify 的循环直到目标达成、在 AI 步骤之间串联 shell 命令，等等。这些自定义 loop 会出现在同一个 Loop 选择器里。这就是下一个大点子：[Loop Builder](the-loop-builder)。
 
 ## 任务队列
@@ -98,5 +101,4 @@ interactive transport；Kimi 使用没有 persistent stdin 的 agentic
 
 - [Loop Builder](the-loop-builder)——rail 运行的是什么，以及如何搭建你自己的 loop。
 - [任务详情视图](the-job-detail-view)——阶段、实时指标、工单卡片。
-- [批量实现与多功能](batch-implement-and-multi-feature)——一次跑多个 spec。
 - [为每条 rail 选择引擎](picking-an-engine-per-rail)——Claude、Codex、Gemini 或 Kimi。

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

@@ -22,7 +22,7 @@
 
 ## 流水线阶段
 
-对于 `Implement` 和 `Batch` 任务，整个运行会走过 slash 命令所定义的各个阶段——默认是：
+对于 `Implement` 任务，整个运行会走过 slash 命令所定义的各个阶段——默认是：
 
 ```
 Architect ──► Developer ──► Reviewer ──► Ship
@@ -112,5 +112,14 @@ Architect ──► Developer ──► Reviewer ──► Ship
 ## 接下来去哪儿
 
 - [Rail 与任务](rails-and-jobs)——启动与排队。
-- [批量实现与多功能](batch-implement-and-multi-feature)——多个 spec、依赖批次。
 - [追踪成本](../analytics/tracking-cost)——把单任务成本汇成项目级分析。
+
+## 工作流重启后
+
+发生崩溃后，请使用原始配置和仓库恢复已保存的工作流。对于中断的写入，先检查工作树差异，再选择要恢复的具体尝试。已完成的步骤会保留。响应丢失的提供商调用仍计为中断，用量保持未知，绝不会显示为免费。如果已保存的记录无法证明原始交付关系，恢复会显示错误并保留工作树。
+
+决策步骤因提问而暂停时，恢复执行会复用已保存的决策，并将人工回答传递给下一步骤，不会为同一次决策再次调用模型。暂停的提示步骤可能需要再次调用模型，才能根据你的回答继续处理。
+
+## 历史保留
+
+已保存的执行默认永久保留。在 **已保存的执行 → 历史保留** 中，项目可以改为保留 1 到 3650 天。后台不会自动删除任何内容：先保存策略，选择 **预览清理**，逐一查看每次执行及其原因，然后再选择 **删除过期历史**。只要执行仍在运行、正在等待你的回答或批准、有中断的写入、有未完成的交付或仍依赖它的分叉，它就会受到保护。只会删除项目 Specrails 存储中的运行历史；你的仓库、worktree、任务日志和成本记录都会保留。过期的执行显示为 **已过期**，不能再恢复或分叉。仍被保留执行使用的 Core 版本始终会保留。

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

@@ -21,14 +21,14 @@ Specrails desktop 把 **Claude Code**、**Codex CLI**、**Gemini CLI** 和
 
 ## 每个引擎擅长什么
 
-三者都能跑标准的 **Implement** 和 **Batch** 流水线。下面是一份实用的选择指南：
+三者都能跑标准的 **Implement** 流水线。下面是一份实用的选择指南：
 
 | 引擎 | 在什么情况下选它…… | 说明 |
 |--------|--------------------|-------|
 | **Claude** | 需要原生成本、持久交互或严格 tool policy。 | Profile、Freestyle 和 structured transform。 |
 | **Codex** | 你更喜欢 OpenAI Codex CLI，或想跨提供方对比实现。 | `codex` ≥ 0.128.0。无原生成本上报——应用会用自己的价格表来补上成本。Profile 不适用。 |
 | **Gemini** | 你想用 Google 的 Gemini CLI、原生遥测，或为常规 spec 跑得更省钱。 | `gemini` ≥ 0.11.0（需设置 `GEMINI_API_KEY`）。原生 OTLP 遥测。Profile 不适用。 |
-| **Kimi** | 用 agentic Kimi 跑 Implement、Batch、Freestyle 或无 Decider 的 loop。 | 外部 `kimi` ≥ 0.27.0；profile/role，effort 仅 K3；token/cost unavailable。 |
+| **Kimi** | 用 agentic Kimi 跑 Implement、Freestyle 或无 Decider 的 loop。 | 外部 `kimi` ≥ 0.27.0；profile/role，effort 仅 K3；token/cost unavailable。 |
 
 ### Capability 差异
 

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

@@ -1,6 +1,16 @@
 # Loop Builder
 
-**一条 rail 运行的是一个 Loop。** 内置的那些 loop（`Implement`、`Batch`、`Freestyle`）覆盖了日常场景，但 **Loop Builder** 让你能设计自己的——一个可视化的、n8n 风格的编辑器，用来做那种"重复执行直到目标达成"的自动化。本页会讲清楚什么是 loop、怎么搭一个，以及怎么在 rail 上运行它。
+## Core 工作流
+
+使用兼容的 Core 引擎时，新画布会显示已安装目录中的十七种步骤。单击或拖入步骤，再填写参数表单。提供商和角色来自当前项目。将每个命名输出连接到其他步骤或结束节点；每个输出只能有一条连接。
+
+表单支持可选字段、对象、列表和字典，覆盖 AI、条件、验证、Shell、OpenSpec、审批、提问、暂停、遍历、合并、组件及实现等步骤。工作流选项可设置 token、转换次数及并发限制。组件内部和分支中的执行也计入转换次数。
+
+在**组件**中创建可复用流程，声明输入变量和输出名称，再从组件或遍历步骤选择它。导航可以保留修改并返回主画布。组件内部的结束节点可通过 `exit` 指定输出名称。
+
+发布时，Core 会验证草稿并在相关步骤上显示错误。启动时会再次验证项目配置。引擎不可用时请更新 Core。现有 Desktop 循环保留原来的编辑器和执行方式，下面的章节介绍这些旧版流程。
+
+**一条 rail 运行的是一个 Loop。** 内置的那些 loop（`Implement`、`Freestyle`、`SDD Quick (OpenSpec)`）覆盖了日常场景，但 **Loop Builder** 让你能设计自己的——一个可视化的、n8n 风格的编辑器，用来做那种"重复执行直到目标达成"的自动化。本页会讲清楚什么是 loop、怎么搭一个，以及怎么在 rail 上运行它。
 
 ## Loop 与 rail——它们的关系
 
@@ -10,9 +20,8 @@
    Loop Builder (左侧栏)                   Rails (右)
    ───────────────────────────             ─────────────
    Implement   (内置)                       Rail 1
-   Batch       (内置)          在此挑选 ►       Loop: Verify-until-green
-   Freestyle   (内置)                          ▶ Play
-   Verify-until-green (你的)
+   Freestyle   (内置)          在此挑选 ►       Loop: Verify-until-green
+   Verify-until-green (你的)                          ▶ Play
 ```
 
 - loop 住在 **Loops** 区里（左侧栏，和你的项目并列）——它们是**全局**的，跨所有项目共享。
@@ -25,7 +34,7 @@
 
 点左侧栏的 **Loops**，就能看到这个库：三个内置 loop，再加上你自己的所有 loop。打开一个来查看，或者点 **New loop** 从一张空白画布开始。
 
-你没法轻易地直接编辑内置 loop——而是要 **Fork** 它。这会给你一份可编辑的副本，从一个能跑通的图出发，这也是最容易上手的学习方式。
+内置 loop 是真正可编辑的 loop。用 **Edit** 打开它，像编辑其他 loop 一样修改：保存后它会变成草稿，**Publish** 后你的版本会应用到**所有使用这个内置 loop 的轨道、代理聊天启动和 Companion 启动**。在你的修改还是草稿时，轨道会继续运行最后发布的版本，所以编辑中途不会出问题。**恢复原始版本**（在卡片上或构建器中）可以把内置 loop 重置为默认版本；内置 loop 不能删除。想要一份独立的副本？用 **Duplicate**——它会创建一个普通 loop，内置 loop 保持不变。
 
 ## 一个 loop 由什么组成
 
@@ -93,3 +102,13 @@ builder 会帮你在 loop 真正跑起来之前就把它弄对：
 - [Rail 与任务](rails-and-jobs)——启动 rail 以及任务队列。
 - [任务详情视图](the-job-detail-view)——实时观看一次运行。
 - [为每条 rail 选择引擎](picking-an-engine-per-rail)——是 rail（而不是 loop）来选提供方。
+
+如果所选 Core 支持单次调用限制，prompt、role 和 decider 节点会提供 `timeoutMs` 和 `idleTimeoutMs`。设为 `0` 可禁用该步骤的相应计时器；删除字段则继承默认值。整个工作流的预算和取消功能仍然有效。如果验证步骤提出需要人工决定的问题，它会等待你的回答，然后才能接受成功结果。
+
+首次将已保存的旧版图替换为 Core 节点时，系统会保留原始图。此后，库中会显示 **导出原始图**。导出文件使用不同的名称，方便你将其导入为独立草稿，而不替换当前工作流。转换和后续编辑都不会自动发布循环。
+
+使用**设置变量**保存暂停后仍需保留的状态：设置带类型的 JSON 值，或调整已有的整数计数器。此组件不会调用 AI。所有更新一起提交；计数器无效时，所有变量都保持不变。映射组件中的变量仅在该组件内部有效。
+
+Decider 的**满足此条件时继续**可保护尚未完成的必需工作。例如，`$vars.failedPass == true` 会将停止建议改为继续，直到工作流清除该标记。决策仍会执行，内容不变的重复运行仍受无进展次数上限约束。需要人工回答的问题仍会暂停执行。
+
+要迁移旧引擎中保存的循环，请在循环库中选择 **转换为 Core**。如果 Shell 步骤没有明确的作用范围，请选择原始仓库。转换会验证图并保存草稿，同时保留可导出的原始副本。请检查连接后明确发布。正在运行的循环不能转换；并发编辑会被保留。写入步骤需要实际的验证命令，Quick SDD 使用 Core 自带的 OpenSpec。如果转换不可用，请更新 Core。

package/docs/internals/api-reference.md

@@ -440,11 +440,11 @@ A non-developer-friendly file tree + Monaco viewer with plain-language AI summar
 | Method | Path | Notes |
 |--------|------|-------|
 | `GET` | `/` | List rails |
-| `PUT` | `/:railIndex/tickets` | Assign tickets to a rail. Body `{ ticketIds: number[] }` |
+| `PUT` | `/:railIndex/tickets` | Assign tickets to a rail. Body `{ ticketIds: number[], mode?, profileName?, aiEngine? }`. An omitted `mode` keeps the rail's stored mode; `mode` must be `implement` / `freestyle` / `loop` (400 otherwise), with `batch-implement` / `batch` normalized to `implement`. |
 | `PUT` | `/:railIndex/profile` | Set the rail's default profile |
 | `PUT` | `/:railIndex/engine` | Set the rail's AI engine override. Body `{ aiEngine }` (string — one of the project's providers — or `null` to clear) |
 | `PUT` | `/:railIndex/name` | Set the rail's display name. Body `{ name }` (string or `null` to clear back to the default label); 400 if longer than 60 characters |
-| `POST` | `/:railIndex/launch` | Launch the rail. Body `{ mode?, loopId?, profileName?, aiEngine?, model?, reasoning_effort?, originConversationId?, originSurface?, interactive? }`. `mode` is `implement` / `batch-implement` / `freestyle` / `loop`; a factory `loopId` maps to its canonical rail mode. `model` and `reasoning_effort` are validated against the effective adapter/model (Kimi effort is K3-only). Kimi + a loop containing a Decider returns a capability error before the first step. Claude alone advertises persistent in-job stdin; `interactive` remains wire-compatible. Returns `202 { jobId, railIndex, mode }`; a missing provider CLI fails before a job starts. |
+| `POST` | `/:railIndex/launch` | Launch the rail. Body `{ mode?, loopId?, profileName?, aiEngine?, model?, reasoning_effort?, originConversationId?, originSurface?, interactive? }`. `mode` is `implement` / `freestyle` / `loop` (the removed Batch mode's `batch-implement` / `batch` are accepted as input aliases and normalized to `implement`); a factory `loopId` maps to its canonical rail mode (`factory:batch` resolves to `factory:implement`). `model` and `reasoning_effort` are validated against the effective adapter/model (Kimi effort is K3-only). Kimi + a loop containing a Decider returns a capability error before the first step. Claude alone advertises persistent in-job stdin; `interactive` remains wire-compatible. Returns `202 { jobId, railIndex, mode }`; a missing provider CLI fails before a job starts. |
 | `POST` | `/:railIndex/stop` | Stop the rail's running job (cancels every job the rail registered) |
 
 ---

package/docs/internals/ci-performance.md

@@ -0,0 +1,71 @@
+# CI and release execution
+
+The required `test` check waits for quality, both complete coverage reports,
+workflow and secret checks, bundled Core, provider portability and native macOS
+fixtures. Failed, cancelled or skipped prerequisites cannot authorize a release.
+Main/branch push CI remains available for exact-source release admission; pull
+request checks do not substitute for trusted push evidence.
+
+## Coverage partitions
+
+Server coverage runs on three workers, each using one Vitest process as before.
+Client coverage runs on four workers. Every worker uses the locked Vitest version
+and its public `--shard` option; no test filters or coverage exclusions are added.
+`vitest.shard.config.ts` collects partial coverage without evaluating global
+thresholds. The mandatory merge jobs use the ordinary configuration and enforce
+all original thresholds on the combined coverage, including uncovered files.
+
+`scripts/coverage-shards.mjs` records the actually executed files, complete test
+inventory, commit, dependency/configuration digest, Vitest version and SHA-256 of
+each blob. Before merging, it rejects missing shards, overlapping or omitted
+files, unsuccessful reports, mixed identities and changed bytes. A real two-shard
+fixture proves complete coverage passes and an uncovered function fails the
+aggregate. A list-only command is not used to infer shard assignment: Vitest's
+file listing includes the complete corpus even when a shard is requested.
+
+To reproduce a server shard and merge downloaded artifacts:
+
+```sh
+node scripts/coverage-shards.mjs run server 1/3 /tmp/server-shard-1
+node scripts/coverage-shards.mjs merge server 3 /tmp/downloaded-server-shards
+```
+
+Merge input must contain all three `.manifest.json` and `.blob.json` pairs from
+one commit. Use `client 1/4` and `client 4` for the client. Normal local
+`test:coverage` commands retain their existing behavior.
+
+## Verified frontend reuse
+
+The quality job builds and package-checks the application, then uploads
+`verified-desktop-client`. It contains the platform-independent production
+frontend plus its commit, client lock digest and complete asset inventory with
+individual checksums. Production Vite URLs are relative and contain no runner or
+platform-specific endpoint.
+
+Release admission selects the latest successful trusted push CI attempt for the
+exact source SHA. A shared release job verifies and republishes that run's frontend.
+If the artifact expired or predates receipts, it rebuilds the exact admitted source
+once. API, identity and checksum failures remain failures; they never trigger a
+rebuild fallback. Each native job checks the shared bytes before restoring them,
+then builds its own platform-specific server, sidecars
+and Rust shell. The three native jobs reuse the same frontend; each still signs,
+notarizes where configured, and performs installed-application smoke checks.
+`build:desktop` continues to build from source for local development.
+
+## Measuring improvements
+
+The previous completed run `36228425753` took 15m50s including queue time; client
+coverage ran for 10m53s and server coverage for 7m07s. The final check waited almost
+five minutes for a runner. Compare critical-path execution and queue time
+separately; more partitions reduce work per runner but cannot eliminate host
+queueing. Blob manifests retain start/end and test counts for subsequent tuning.
+Updated run `36230773446` passed every check. Server shards took 2m12s–2m56s
+and client shards 2m52s–3m24s; each aggregate took 37s. Including queueing,
+the run took 22m52s, so this loaded-run comparison does not demonstrate a total
+wall-time reduction. Preserve both measures when adjusting worker counts.
+
+The subsequent exact-head run `36233342790` passed all 18 checks in **4m05s**
+including queueing (09:37:32–09:41:37 UTC). Server shards took 1m43s–2m42s,
+client shards 2m18s–3m10s, and aggregation took 35s/43s. This observed run is
+74% shorter than the 15m50s baseline; the preceding queued run demonstrates why
+this is an observed result, not a guaranteed hosted-runner latency.

package/docs/internals/companion-rails-as-loops-contract.md

@@ -45,9 +45,10 @@ The companion is a **light-control mirror**. It has no typed `Rail` model: rails
 
 ## 2. What rails-as-loops changed — the divergence list
 
-- **`loopId` is the new primary launch verb.** `POST /rails/:i/launch` now accepts `{mode='implement', profileName, aiEngine, model, interactive, loopId, reasoning_effort}` (`rails-router.ts:214-215`). `VALID_MODES` is now `{implement, batch-implement, freestyle, loop}` (`rails-router.ts:25`).
+- **`loopId` is the new primary launch verb.** `POST /rails/:i/launch` now accepts `{mode='implement', profileName, aiEngine, model, interactive, loopId, reasoning_effort}` (`rails-router.ts:214-215`). `VALID_MODES` is now `{implement, freestyle, loop}`; the removed Batch mode's `batch-implement` / `batch` are input aliases normalized to `implement` (`normalizeRailMode` in `rails-router.ts`).
 - **The mode segmented-control was removed** from the desktop UI and replaced by `RailLoopSelector` (`RailControls.tsx:51-53` comment; `RailRow.tsx:414-421, 597-604`). `RailMode` still exists but is now **derived** from the loop via `deriveRailMode()` (`rail-loops.ts:34-39`), not user-picked.
-- **Factory→mode mapping (the compat layer).** Client factory ids `factory:implement|factory:batch|factory:freestyle` (`rail-loops.ts:8-25`); server mirror `loop-factory.ts:33-55`. `factoryLoopMode()` maps `factory:implement→implement`, `factory:batch→batch-implement`, `factory:freestyle→freestyle` (`rails-router.ts:220-224`); any custom loop → `mode='loop'`.
+- **Factory→mode mapping (the compat layer).** Client factory ids `factory:implement|factory:freestyle` (`rail-loops.ts`); server mirror `loop-factory.ts`. `factoryLoopMode()` maps `factory:implement→implement`, `factory:freestyle→freestyle`, and the removed `factory:batch` alias → `implement` (`rails-router.ts:220-224`); any custom loop → `mode='loop'`.
+- **Built-ins are editable rows (editable-builtin-loops).** Desktop seeds one app-global `loops` row per built-in whose id IS the factory id (`factory:implement`, `factory:freestyle`, `factory:sdd-quick-openspec`; `builtinId` set). A launch with a factory id — from the dashboard, agent chat, MCP or the phone — resolves through `resolveBuiltinLoop` (`server/modules/loops/runtime/builtin-loops.ts`): an edited Published row runs its graph, an edited Draft runs its last Published snapshot, an unedited or missing row runs the code default. The ids, the factory→mode mapping and bare-`mode` launches are unchanged, so companion launches need no change. `GET /loops/factory` still lists the built-ins (now with the row's name/description, the graph a launch would run, and `editable`/`status`/`modified`); `POST /loops/factory/:id/fork` is kept as an alias of duplicate.
 - **Loop runs are NOT job-queue jobs.** When `isLoopsEnabled()` (default ON, `feature-flags.ts:51-52`, `!== 'false'`) AND a `loopId` is present (factory OR custom), the launch routes through **`LoopRunManager`**, not `QueueManager` (`rails-router.ts:301-381`). It returns `202 {loopRunIds, railIndex, mode}` with **no `jobId`** (`rails-router.ts:379`), and rows live in a **separate `loop_runs` table** (`loop-runs-store.ts:12-32`) keyed by `loopRunId`. QueueManager fallback freestyle/implement paths still return `{jobId, ...}` (`rails-router.ts:428, 453`).
 - **New WS lifecycle family.** `loop.run_started`/`loop.run_progress`/`loop.run_stopped`/`loop.run_completed` (`types.ts:756-790`), emitted by `LoopRunManager` (`loop-run-manager.ts:469`), NOT by the `project-registry.ts:543` `onJobFinished` path that emits `rail.job_completed`. Keying: `loop.run_started`/`loop.run_stopped`/`loop.run_completed` carry `railIndex` + `loopRunId`; **`loop.run_progress` carries only `loopRunId`/`iteration`/`activeNode`/`reasoning` — NO `railIndex`** (`types.ts:756-790`). `loop.run_completed.status ∈ {success, max-iterations, stopped, failed, blocked, stalled}` — `max-iterations` is a **successful** terminal state, not a failure; **`blocked`** (the Loop Decider flagged the run needs a human decision it can't make) and **`stalled`** (the non-convergence guard aborted after consecutive iterations left the working tree unchanged) are controlled HALTS: NOT in the success set, and the settle maps them to job status `canceled` (tickets revert to todo, no PR delivery). A naive `ok = status=='success'` already treats them as non-success — correct.
 - **`GET /rails` gained `activeLoopRuns`** → `{rails, activeJobs:{[idx]:{jobId,mode}}, activeLoopRuns:{[idx]:{loopRunId}}}` (`rails-router.ts:78-82`).
@@ -73,7 +74,7 @@ The list fetch never crashes (untyped maps, tolerant parsers). But a rail runnin
 Loop runs have a `loopRunId`, never a `jobId`, and are **not in the jobs/queue tables** (`loop-runs-store.ts:12-32`). The companion's "View running job log" routes by `jobId` (`rails_zone.dart:271-281`); `watch_job`/`log_batch`/`job_event` key on `jobId` (`mobile-ws.ts:196-243`). With no `jobId`, the job-tail surface never populates and the run is absent from Execution History (`JobHistoryScreen` reads queue jobs only). **Critically, a loop run produces NO tailable log at all** — its sole live heartbeat is `loop.run_progress` (`iteration`/`activeNode`), which is dropped at `topicFor()`. So even discounting the job-log routing, there is **no live-progress channel** for a running loop rail today: the running surface is a binary running/idle black box. For legacy non-loop launches the job-tail still WORKS.
 
 **(c) LAUNCH a rail — WORKS (factory/legacy only) / BROKEN (custom loops).**
-The companion sends bare `{mode}` (`rails_zone.dart:317` picker = `implement|batch-implement|freestyle`; `desktop_repository.dart:116-123`). This still validates server-side (`VALID_MODES` includes the three; default `mode='implement'` at `rails-router.ts:214`). Crucially, the gateway narrowing **strips `loopId`** (`mobile-router.ts:191-196`), so even a future companion that sent `loopId` would be silently ignored. Custom loops are unreachable (`mode='loop'` without `loopId` → 400, `rails-router.ts:385-386`). **Caveat:** the *running-state feedback* after launch is broken per (a)/(b) when the launch resolves to a `LoopRunManager` run (default-ON factory loops emit `loop.run_*`, no `rail.job_started`) — so the launch HTTP call succeeds (202) but the phone sees no live activity, no progress, and no completion notification.
+The companion sends bare `{mode}` (`rails_zone.dart:317` picker = `implement|batch-implement|freestyle`; `desktop_repository.dart:116-123`). This still validates server-side (`batch-implement` is normalized to `implement`; default `mode='implement'` at `rails-router.ts:214`). Crucially, the gateway narrowing **strips `loopId`** (`mobile-router.ts:191-196`), so even a future companion that sent `loopId` would be silently ignored. Custom loops are unreachable (`mode='loop'` without `loopId` → 400, `rails-router.ts:385-386`). **Caveat:** the *running-state feedback* after launch is broken per (a)/(b) when the launch resolves to a `LoopRunManager` run (default-ON factory loops emit `loop.run_*`, no `rail.job_started`) — so the launch HTTP call succeeds (202) but the phone sees no live activity, no progress, and no completion notification.
 
 **(d) Stop / assign tickets / engine — DEGRADED (stop) / WORKS (tickets) / WORKS-with-display-drift (engine).**
 - **Engine:** `PUT /rails/:i/engine {aiEngine}` WORKS end-to-end for *setting* the override (`desktop_repository.dart:127`; `mobile-router.ts:199-206`); `rail.updated` carries `aiEngine` (`types.ts:749`). The mutation needs no change. **But** the *displayed* engine drifts for loop-backed runs as noted in (a): the rail config `aiEngine` may be null while the actual run used the resolved provider/model from `loop_runs`, which is never forwarded.

package/docs/internals/configuration.md

@@ -114,14 +114,14 @@ specrails-desktop remove <project-id>    # Unregister a project by ID
 
 ```bash
 specrails-desktop implement "#42"                  # Queue /specrails:implement for spec #42
-specrails-desktop batch-implement "#40" "#41" "#43"  # Queue one batch job over several specs
+specrails-desktop implement "#40" "#41" "#43"        # One aggregate implement run over several specs
 specrails-desktop "any raw prompt"                 # Pass a raw prompt straight to the AI CLI
 specrails-desktop /specrails:health-check          # Pass any slash command directly
 ```
 
-> **Always quote issue refs.** An unquoted `#` starts a shell comment, so `batch-implement #40 #41` silently drops the refs. Quote each one: `"#40" "#41"`.
+> **Always quote issue refs.** An unquoted `#` starts a shell comment, so `implement #40 #41` silently drops the refs. Quote each one: `"#40" "#41"`.
 
-**Known verbs** (automatically prefixed with `/specrails:`): `implement`, `batch-implement`, `why`, `get-backlog-specs`, `auto-propose-backlog-specs`, `propose-spec`, `refactor-recommender`, `health-check`, `compat-check`, `enrich`. Any other first argument is passed as a raw prompt.
+**Known verbs** (automatically prefixed with `/specrails:`): `implement`, `why`, `get-backlog-specs`, `auto-propose-backlog-specs`, `propose-spec`, `refactor-recommender`, `health-check`, `compat-check`, `enrich`. The removed `batch-implement` verb is mapped to `implement`. Any other first argument is passed as a raw prompt.
 
 ### Port override example
 

package/docs/internals/core-runtime-updates.md

@@ -13,10 +13,11 @@ framework is rejected rather than silently replacing an update.
 
 ## Persistence and publication
 
-The release bundle pins Core 6.0.0 in `desktop-release.yml` and
+The release bundle pins Core 6.1.0 in `desktop-release.yml` and
 `scripts/assemble-bundled-core.lock.json`. Core 6 is the Desktop-only engine: it
 publishes integration contract 5.0 (no standalone `update`) and ships only the
-implement, batch-implement and retry workflows. Update both pins together and check compatibility against
+implement and retry workflows (Batch was folded into implement; Desktop no
+longer requires `batch-implement` but stays compatible with Cores that still ship it). Update both pins together and check compatibility against
 the staged published package; retained runs still use their original runtime.
 
 Desktop updates retain the complete npm installation, including dependencies,