specrails-desktop 2.20.1 → 2.22.0

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

@@ -40,17 +40,21 @@ Vague 3 :  #7 (docs sur l'ensemble) ← attend #4 et #5
 
 Au sein du job, les specs de chaque vague sont implémentées avant que la vague suivante ne commence. Vous ne configurez rien à la main — l'orchestrateur déduit les vagues à partir des specs elles-mêmes. Regardez-le se dérouler dans la [vue détaillée du job](the-job-detail-view) : le log en streaming raconte sur quelle spec le batch travaille, et l'en-tête de ticket affiche chaque spec touchée par le job.
 
-## Isolation par worktree
+## Isolation par worktree et livraison du travail
 
-Lorsque plusieurs specs sont implémentées en une seule exécution, le pipeline garde chaque unité de travail isolée pour que les changements concurrents ou séquentiels ne piétinent pas les fichiers des autres. L'orchestrateur de batch exécute l'implémentation de chaque spec dans son propre contexte de travail propre, puis intègre les résultats — ainsi une spec à moitié finie ne laisse jamais votre arbre dans un état intermédiaire cassé et visible par la suivante.
+Lorsque plusieurs specs sont implémentées en une seule exécution, le pipeline garde chaque unité de travail isolée pour que les changements concurrents ou séquentiels ne piétinent pas les fichiers des autres. L'implémentation de chaque spec s'exécute dans son propre **worktree git** propre — un checkout séparé qui partage l'historique de votre dépôt mais ne touche jamais votre arbre de travail pendant que l'IA travaille.
+
+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à.
 
 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.
-- Les relectures et les étapes de ship opèrent sur un instantané cohérent, pas sur une cible mouvante.
-- Un échec dans une vague est contenu — il ne corrompt pas silencieusement les specs déjà livrées.
+- Votre arbre de travail n'est jamais modifié pendant que l'exécution est en cours — rien n'est intégré tant que vous ne l'avez pas décidé.
+- Lorsque l'exécution est terminée, les specs affichent un badge **En relecture** et le rail vous pose la question : **Créer la PR** pour ouvrir la pull request en brouillon combinée, ou **Abandonner** pour nettoyer les branches et renvoyer les specs au backlog. Si vous avez lancé le rail depuis le chat de l'agent, la même question apparaît sous forme de carte dans cette conversation — répondez à l'un ou l'autre endroit, les deux restent synchronisés.
+- 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.
 
-L'application enregistre, par job, exactement quels fichiers ont été touchés et quel ticket les a touchés (vous verrez cela apparaître sous forme de puces de provenance dans la section **Code** et de liste « Fichiers touchés par ce ticket » dans la fenêtre de détail de chaque spec). Cette attribution est ce qui vous permet de faire confiance à une exécution multi-spec : vous pouvez toujours remonter d'une modification de fichier jusqu'à la spec qui l'a provoquée.
+> 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`.
 
 ## Multi-fonctionnalité entre projets
 

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

@@ -80,7 +80,7 @@ Pour exécuter un loop personnalisé :
 2. Dans l'en-tête du rail, ouvrez le **sélecteur de Loop** et choisissez votre loop publié.
 3. Appuyez sur **▶ Play**.
 
-L'exécution se diffuse en direct dans la vue **Jobs** exactement comme un job de rail intégré — mêmes logs, mêmes métriques, même suivi des coûts. Un loop qui s'arrête parce qu'il a atteint son plafond d'itérations ou de coût est rapporté avec ce résultat plutôt qu'un simple succès.
+L'exécution se diffuse en direct dans la vue **Jobs** avec les mêmes métriques et le même suivi des coûts que n'importe quel job de rail — et son log gagne un **explorateur d'étapes** dédié : une carte en direct de votre graphe avec une boîte repliable par étape, qui suit l'étape en cours à mesure que le loop avance (voir [La vue détaillée du job](the-job-detail-view)). Sur Claude, chaque **Étape IA** est aussi une session en direct : envoyez-lui des messages depuis le composeur de la vue détaillée du job pour la piloter en cours d'étape (entre les étapes, le composeur patiente brièvement, et **Régler cette étape** fait avancer le loop avec ce que l'étape a produit). Un loop qui s'arrête parce qu'il a atteint son plafond d'itérations ou de coût est rapporté avec ce résultat plutôt qu'un simple succès.
 
 > **À savoir pendant qu'un loop s'exécute.** Vous ne pouvez pas éditer ni supprimer un loop pendant qu'une de ses exécutions est en cours — arrêtez d'abord l'exécution.
 

package/docs/guide/fr/specs/1-specs-and-the-backlog.md

@@ -13,7 +13,7 @@ Le tableau propose deux modes d'affichage, basculables depuis un bouton de la ba
 - **Vue post-it** (par défaut) — des tuiles façon cartes avec de courts résumés.
 - **Vue liste** — des lignes compactes sur une seule ligne.
 
-Vous pouvez aussi filtrer par **statut** (Tous / À faire / Terminé) et par **label**, et trier par **Par défaut**, **Ticket #** ou **Priorité** (chacun avec un sens croissant/décroissant).
+Le **sélecteur de statuts** de la barre d'outils affiche chaque statut sous forme de puce avec un compteur en direct — plus deux groupes intelligents : **Actives** (le défaut — tout ce qui bouge encore : brouillons, à faire, en cours et en révision) et **Tous** (tout, avec Terminé épinglé en bas). Votre choix est mémorisé par projet et reflété dans l'URL : un rafraîchissement ou un lien partagé restaure la vue exacte. Sur les projets connectés à Jira, un menu déroulant **statut Jira** supplémentaire apparaît, listant les *vrais* statuts du workflow du board (leurs noms bruts, p. ex. « Code Review », chacun avec son compteur en direct) regroupés sous l'état auquel ils correspondent — il se combine avec les puces de statut. Vous pouvez aussi filtrer par **label**, et trier par **Par défaut**, **Ticket #** ou **Priorité** (chacun avec un sens croissant/décroissant).
 
 ## Les statuts
 
@@ -24,7 +24,8 @@ Une spec traverse un petit ensemble de statuts. Le tableau donne à chacun un re
 | **Brouillon** | Une idée en cours, enregistrée depuis une conversation Explore. Pas encore prête à être mise en œuvre — vous pouvez y revenir et continuer à la façonner. Affiche une pastille `Draft`. |
 | **À faire** | Prête à être prise en charge. C'est là qu'atterrit une spec finalisée lors de sa création. |
 | **En cours** | Le pipeline travaille actuellement dessus (un point bleu qui pulse). |
-| **Terminé** | Achevée par le pipeline (une coche verte). |
+| **En révision** | Implémentée — chaque exécution terminée gare ici ses specs pour votre approbation : fusionnez la PR en brouillon ou déplacez-les vous-même (une pastille ambre). |
+| **Terminé** | Approuvée — sa PR a été fusionnée, ou vous l'avez déplacée ici vous-même (une coche verte). |
 | **Annulé** | Abandonnée (une croix rouge). |
 
 Les brouillons vivent dans le même groupe actif que les specs À faire — il n'y a pas de colonne séparée pour eux — mais ils arborent une bordure subtilement teintée et une pastille `Draft` pour être facilement repérables. Voir [Les brouillons et le Contract Layer](drafts-and-contract-layer.md) pour tout savoir sur les brouillons.

package/docs/guide/it/insights/3-code-explorer.md

@@ -37,6 +37,12 @@ Un paio di garanzie tengono i costi ragionevoli: la generazione dei riepiloghi a
 
 Puoi anche scegliere la **lingua dei riepiloghi** (inglese o spagnolo) nelle impostazioni globali, nell'area *Code section*.
 
+## La storia di costruzione
+
+Sotto il visualizzatore di codice vive la **storia di costruzione**: una linea temporale cronologica di ogni spec e di ogni job che hanno costruito il file che stai guardando. Ogni capitolo è una scheda: quale spec è intervenuta (con il suo stato attuale), quando, se il file è stato creato, modificato o eliminato, e quanto è stato grande il cambiamento (righe aggiunte e rimosse). Fai clic su una scheda per aprire il dettaglio di quella spec. Anche i rail basati sui loop registrano i file che toccano, quindi il lavoro svolto in worktree isolati compare nella storia come i normali job della pipeline.
+
+Per qualsiasi capitolo puoi chiedere una spiegazione in linguaggio semplice: premi **Spiega questa modifica** e l'app scrive da una a tre frasi che descrivono cosa quel cambiamento specifico ha apportato al file — senza codice, senza gergo. Le spiegazioni condividono lo stesso budget mensile dei riepiloghi dei file e, finché non ne viene generata una, la scheda si affida ai fatti che conosce: il tipo di modifica, la spec e la data. Preferisci i dati grezzi? Un selettore **Storia / Registro** passa alla classica lista delle modifiche con diff su richiesta. Lo stesso pannello compare nella vista **Files** della modalità Agente.
+
 ## Collegare il codice alle spec
 
 Il legame di provenienza funziona in entrambe le direzioni. All'interno del Code explorer, cliccare il chip di un ticket su un file apre il dettaglio di quel ticket. E dall'altro lato, la vista di **dettaglio del ticket** ha una sezione *File toccati da questo ticket* — clicca un file lì e salti dritto nel Code explorer con quel file aperto. Chiude il cerchio tra "ecco la spec che abbiamo scritto" ed "ecco il codice che ne è uscito".

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

@@ -7,7 +7,7 @@ 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 (su **Fatto**, o di nuovo su **Da fare** se è fallito) e pubblica un commento di completamento con l'id del job, il costo e la 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 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).
 - 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.

package/docs/guide/it/integrations/6-agent-chat.md

@@ -53,9 +53,14 @@ Le risposte arrivano fluide e già formattate (titoli, tabelle, elenchi), ciascu
 
 ## Dettagli pratici
 
+- **Super spec da una conversazione.** Chiedi all’agente di *dare forma* a una spec insieme a te invece di generarla in un colpo solo: prima legge il codice reale, ti fa qualche domanda e mostra la bozza che evolve come una card dal vivo nella conversazione. Al tuo sì crea la spec e — per impostazione predefinita — la arricchisce in background con un **Contract Layer** (percorsi file esatti, forme dei dati, invarianti) perché gli agenti che implementano non improvvisino. Di’ "senza contract layer" per saltare l’arricchimento.
+- **Clicca ciò che menziona.** In una missione fissata a un progetto, i numeri di spec (`#12`) e gli id di job/run nelle risposte dell'agente sono chip cliccabili: una spec apre il modale di dettaglio della board, un id di job apre la vista del job dal vivo. Se il riferimento non esiste più, compare una discreta nota "non trovato".
+- **La scheda di implementazione resta in vista.** Quando l'agente implementa delle spec, una scheda dal vivo segue il lavoro — e finché ha bisogno di qualcosa da te (creare la PR, pubblicarla, riprovare, scartare) resta **fissata appena sopra la casella dei messaggi**, per quanto scorra la conversazione; al suo posto nella cronologia compare un discreto segnaposto «fissata sopra». Più schede attive si impilano come piccoli chip (cliccane uno per portarla in primo piano), e un chevron riduce la scheda a una barra sottile. Una volta pubblicata la PR — o quando il lavoro viene unito o scartato — la scheda torna al suo posto nella cronologia della conversazione.
 - **Cronologia dei prompt.** Con la casella vuota, premi **↑**/**↓** per scorrere ciò che hai chiesto prima (mostrato attenuato mentre scorri); inizia a scrivere per modificarlo, oppure premi Invio per inviarlo.
+- **Modifica la coda.** Hai inviato altro mentre l'agente era occupato? Finché ci sono messaggi in coda, **↑**/**↓** scorre *quelli*: la casella mostra il selezionato, lo modifichi sul posto e **Invio lo salva di nuovo in coda** (Esc annulla; la tua bozza non inviata torna com'era).
 - **Riduci a icona, senza perdere nulla.** Clicca la ✕ per rimettere il pannello nella bolla — la conversazione continua a girare. Riaprilo e atterri sull'ultimo messaggio; nulla viene riscritto.
 - **Nuova conversazione.** Il pulsante **+** avvia un thread pulito; la cronologia vive a livello di app, sopra qualunque singolo progetto.
+- **Cambia missione.** Il selettore di missioni accanto al selettore di progetto elenca le conversazioni dalla più recente alla più vecchia — un punto pulsante segnala quelle in cui l'agente sta ancora lavorando, e un piccolo badge conta i messaggi in coda. La ricerca compare quando la lista supera le otto voci, e l'icona del cestino su ogni riga elimina una missione dopo una rapida conferma in linea — anche una in corso (prima avvisa, poi ferma l'agente).
 
 ## Alcune cose da sapere
 

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

@@ -18,7 +18,7 @@ SpecsBoard (sinistra)       Rail (destra)
 
 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.
 
-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). Trovi più dettagli su multi-rail e batching in [Batch implement e multi-feature](batch-implement-and-multi-feature).
+Puoi avere diversi rail per organizzare il lavoro in corsie con un nome (una per la feature su cui sei concentrato, un'altra in attesa dietro). I rail sono **dinamici**: il pulsante **+ Aggiungi** nell'header dei Rails crea una nuova corsia (fino a 12 per progetto) e le corsie vuote e inattive si possono eliminare. Ogni rail è ancorato al server, quindi il tuo set di corsie sopravvive ai ricaricamenti ed è visibile al companion mobile e all'agente integrato — l'agente può persino creare un rail da solo quando tutte le corsie sono occupate. Trovi più dettagli su multi-rail e batching in [Batch implement e multi-feature](batch-implement-and-multi-feature).
 
 ## Avviare un rail su una spec
 
@@ -49,7 +49,7 @@ Un rail esegue un **Loop** — la ricetta del lavoro. Tre loop sono **integrati*
 | **Batch** | `/specrails:batch-implement` | Un unico job che lavora le spec del rail in sequenza, in ondate consapevoli delle dipendenze. Ideale per più spec correlate. |
 | **Freestyle** | Freestyle | Claude implementa ogni spec in autonomia, **bypassando** la pipeline. Un job indipendente per ogni spec. Solo Claude. |
 
-Freestyle è il caso a sé stante: salta la catena di agenti e affida a Claude la spec grezza, lasciandolo lavorare con i suoi strumenti nativi. È a finalità aperta, quindi premendo Play si apre prima una conferma, e un selettore di modello per rail ti permette di scegliere tra Haiku / Sonnet / Opus. Compare solo quando l'engine del rail è Claude.
+Freestyle è il caso a sé stante: salta la catena di agenti e affida a Claude la spec grezza, lasciandolo lavorare con i suoi strumenti nativi. È a finalità aperta, quindi premendo Play si apre prima una conferma, e un selettore di modello per rail ti permette di scegliere tra Haiku / Sonnet / Opus. Compare solo quando l'engine del rail è Claude. Un'esecuzione Freestyle è anche l'unico job che **resta aperto ad aspettarti**: chatta con lui dal composer del Dettaglio job e clicca **Finalize** quando sei soddisfatto (tutti gli altri job si concludono da soli).
 
 Oltre agli integrati, puoi **costruire i tuoi loop** — ripetere un ciclo verify → fix → verify finché un obiettivo non è raggiunto, concatenare comandi shell tra gli AI Step e altro ancora. Quei loop personalizzati compaiono nello stesso selettore Loop. È la prossima grande idea: [Il Loop Builder](the-loop-builder).
 
@@ -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:
 
-> **Un job alla volta, per progetto.** Ogni progetto ha un'unica coda. All'interno di un progetto viene eseguito un solo job di rail alla volta — gli altri si mettono in coda dietro e partono automaticamente man mano che si liberano gli slot.
+> **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.
 
-Questo sorprende chi aggiunge tre rail aspettandosi che vadano in parallelo. Non succede — non all'interno dello stesso progetto. Aggiungere rail *organizza* il tuo lavoro in corsie; non fa sì che quelle corsie vadano in contemporanea.
+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.
 
-**Il vero parallelismo è tra progetti diversi.** Ogni progetto ha la sua coda indipendente, quindi un rail nel Progetto A e un rail nel Progetto B vengono eseguiti nello stesso momento senza contendersi le risorse. Vuoi più throughput? Apri più progetti.
+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.
 
 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.
 
@@ -73,7 +73,7 @@ Trovi ogni job in **Job**, nella barra laterale destra del progetto — un elenc
 - **Filtro per intervallo di date** — restringi a una finestra temporale.
 - **Confronta** — scegli due job e visualizzali fianco a fianco.
 
-Clicca su una scheda qualsiasi per aprire la **vista Dettaglio job**, dove vivono il log in streaming in tempo reale e le metriche live. È la pagina successiva: [La vista Dettaglio job](the-job-detail-view).
+Clicca su una scheda qualsiasi per aprire la **vista Dettaglio job**, dove vivono il log in streaming in tempo reale e le metriche live — e dove, sui job Claude, un composer di chat ti permette di **fare domande all'agente in esecuzione o orientarlo a metà corsa** senza fermare nulla. È la pagina successiva: [La vista Dettaglio job](the-job-detail-view).
 
 ## Annullare un job
 

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

@@ -1,10 +1,10 @@
 # La vista Dettaglio job
 
-Clicca su una qualsiasi scheda job nella pagina **Job** e arrivi qui: la cabina di pilotaggio di una singola esecuzione di rail. È costruita attorno a una promessa — **i numeri live che vedi sono reali, mai ipotesi.** Questa pagina ti accompagna tra le fasi, le metriche live e le schede ticket.
+Clicca su una qualsiasi scheda job nella pagina **Job** e arrivi qui: la cabina di pilotaggio di una singola esecuzione di rail. È costruita attorno a una promessa — **i numeri live che vedi sono reali, mai ipotesi.** Questa pagina ti accompagna tra le fasi, le metriche live, le schede ticket — e il composer che ti permette di **parlare con il job in esecuzione**.
 
 ## Il layout
 
-Due pannelli stanno sopra il log completo in streaming:
+Due pannelli stanno sopra il log completo in streaming; su un job Claude in esecuzione, un composer di chat sta sotto:
 
 ```
 ┌─────────────────────────────────────────────┐
@@ -15,6 +15,8 @@ Due pannelli stanno sopra il log completo in streaming:
 │                                             │
 │  Log in streaming (auto-scroll · ricerca · …) │
 │                                             │
+├─────────────────────────────────────────────┤
+│  Composer (invia un messaggio al job · …)   │
 └─────────────────────────────────────────────┘
 ```
 
@@ -71,6 +73,29 @@ Sotto i pannelli c'è il log completo dell'esecuzione, trasmesso in tempo reale
 
 Questa è la verità grezza di ciò che l'AI sta facendo — ogni chiamata a uno strumento, ogni modifica a un file, ogni test eseguito.
 
+## Esecuzioni di loop: l'esploratore di passi
+
+Quando il job è un'**esecuzione di loop** (vedi [Il Loop Builder](the-loop-builder)), il log piatto lascia il posto a un **esploratore di passi** che rispecchia la forma reale del loop:
+
+- **La striscia di panoramica** in alto è la mappa live del loop — un chip per nodo (Passo AI, Shell, Decisore del loop…), nell'ordine in cui scorre il grafo. I chip si accendono man mano che l'esecuzione avanza: attenuati in attesa, pulsanti durante l'esecuzione, poi una spunta o una croce. Il chip di un Decisore mostra anche il verdetto con cui ha instradato — tornare indietro o proseguire — e un contatore di iterazioni (`Iterazione 3/10`) tiene il conto a destra. Clicca un chip qualsiasi per saltare dritto all'ultimo passo di quel nodo.
+- **Una scatola richiudibile per passo.** Ogni passaggio su un nodo diventa una sezione a sé, con il numero del passo, il nome, un badge di iterazione, la durata una volta concluso — e il proprio pulsante di copia, per portarti via esattamente l'output di un passo. (La copia nella barra degli strumenti prende sempre il log intero.) Tutto ciò che viene stampato prima del primo passo — il banner di avvio, l'avviso del worktree — finisce in una sezione **Preparazione**.
+- **La modalità segui** è attiva per default: il passo in esecuzione resta aperto e scorre da solo mentre i precedenti si ripiegano. Nel momento in cui scorri verso l'alto o apri un passo più vecchio, il seguito si mette in pausa per lasciarti leggere — una pillola flottante **Riprendi a seguire** ti riporta al live. **Espandi tutto / Comprimi tutto** vivono nella barra degli strumenti, e la ricerca cerca in tutti i passi contemporaneamente.
+- **Anche i passi interrotti sono onesti.** Un passo che non è mai riuscito a riportare il suo esito — l'esecuzione è stata annullata o l'app si è chiusa a metà passo — viene marcato **Interrotto** con un bordo tratteggiato, invece di fingere di aver finito.
+
+Tutto il resto di questa pagina funziona esattamente allo stesso modo per le esecuzioni di loop — le metriche live, le schede ticket, il composer. I job che non sono loop mantengono il classico log in streaming qui sopra.
+
+## Parla con il job in esecuzione
+
+Ogni job Claude gira di default come una **sessione live**, quindi un composer di chat sta in fondo a questa pagina — e alla modale del job in modalità missione. Usalo per fare una domanda all'agente in esecuzione («perché quel test è fallito?») o per orientarlo a metà esecuzione («salta il refactoring, concentrati sul fix»).
+
+Alcune cose che vale la pena sapere:
+
+- **I messaggi si accodano, non interrompono.** Invia mentre l'agente sta trasmettendo e il tuo messaggio aspetta il suo turno — viene eseguito come prompt successivo, e il job continua a seguire il suo piano. Un piccolo contatore mostra quanti messaggi sono in coda.
+- **La riga dei totali è reale.** Il composer mostra un riepilogo live `N turni · $X`, sommato dall'uso reale di ogni turno completato — coerente con la promessa di questa pagina di non tirare mai a indovinare.
+- **Due modi in cui una sessione finisce.** La maggior parte dei job **si conclude da sola**: nel momento in cui un turno termina senza messaggi in coda, la sessione si assesta e il job si completa — i tuoi messaggi sono guida opzionale, mai un obbligo. Un'azione discreta **Concludi ora** la chiude prima, con tutto ciò che è stato prodotto fin lì. I job **Freestyle** sono l'eccezione: restano in attesa tra un turno e l'altro finché non clicchi **Finalize** — è il loro design, una sessione botta e risposta che chiudi quando hai finito.
+- **Nelle esecuzioni di loop i messaggi vanno al passo attivo.** Su un loop integrato o personalizzato, il tuo messaggio raggiunge il **passo AI in esecuzione in quel momento**. Tra un passo e l'altro (mentre il Loop Decider riflette, o gira un comando shell) il composer mostra un breve stato *«In attesa del prossimo passo…»* — il testo in bozza viene conservato, e l'invio si riattiva quando parte il prossimo passo AI. **Assesta questo passo** termina il passo corrente in anticipo e lascia che il loop avanzi con ciò che ha prodotto.
+- **Solo Claude, per ora.** I job Codex e Gemini girano one-shot esattamente come prima — non compare alcun composer. (Gli operatori del server possono spegnere l'intera funzionalità con `SPECRAILS_INTERACTIVE_JOBS=false`.)
+
 ## Esportazione diagnostica
 
 Se la [telemetria](../settings/customizing) era abilitata per il job, nell'intestazione compare un pulsante **Esporta diagnostica**. Scarica uno ZIP che contiene:

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

@@ -40,17 +40,21 @@ Ondata 3:  #7 (docs su tutto)       ← attende #4 e #5
 
 All'interno del job, le spec di ogni ondata vengono implementate prima che inizi l'ondata successiva. Non lo configuri a mano — l'orchestratore ricava le ondate dalle spec stesse. Guarda tutto svolgersi nella [vista Dettaglio job](the-job-detail-view): il log in streaming racconta su quale spec sta lavorando il batch, e l'intestazione ticket mostra ogni spec toccata dal job.
 
-## Isolamento worktree
+## Isolamento worktree e come viene consegnato il lavoro
 
-Quando più spec vengono implementate in un'unica esecuzione, la pipeline mantiene isolata ogni unità di lavoro, così che le modifiche concorrenti o sequenziali non si calpestino i file a vicenda. L'orchestratore del batch esegue l'implementazione di ogni spec nel suo contesto di lavoro pulito, poi integra i risultati — così una spec lasciata a metà non lascia mai il tuo tree in uno stato intermedio rotto visibile alla successiva.
+Quando più spec vengono implementate in un'unica esecuzione, la pipeline mantiene isolata ogni unità di lavoro, così che le modifiche concorrenti o sequenziali non si calpestino i file a vicenda. L'implementazione di ogni spec viene eseguita nel suo **git worktree** pulito e dedicato — un checkout separato che condivide la cronologia del tuo repository ma non tocca mai il tuo working tree mentre l'IA lavora.
+
+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.
 
 In pratica questo significa:
 
-- Ogni spec parte da una tabula rasa su cui implementare, invece di ereditare le modifiche ancora in corso della spec precedente.
-- Le revisioni e i passi di ship operano su uno snapshot coerente, non su un bersaglio in movimento.
-- Un fallimento in un'ondata viene contenuto — non corrompe in silenzio le spec già consegnate.
+- Ogni spec ottiene una tabula rasa su cui implementare, invece di ereditare a metà corsa le modifiche ancora in corso della spec precedente.
+- Il tuo working tree non viene mai modificato mentre l'esecuzione è in corso — nulla viene applicato finché non sei tu a dirlo.
+- Quando l'esecuzione è terminata le spec mostrano un badge **In revisione** e il rail ti pone la domanda: **Crea PR** per aprire la pull request in bozza combinata, oppure **Scarta** per ripulire i branch e riportare le spec nel backlog. Se hai lanciato il rail dalla chat dell'agente, la stessa domanda compare come card in quella conversazione — rispondi in uno qualsiasi dei due posti, restano sincronizzati.
+- 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.
 
-L'app registra, per ogni job, esattamente quali file sono stati toccati e quale ticket li ha toccati (lo vedrai comparire come chip di provenance nella sezione **Code** e come elenco "File toccati da questo ticket" nella modale di dettaglio di ogni spec). È proprio questa attribuzione a renderti possibile fidarti di un'esecuzione multi-spec: puoi sempre risalire da una modifica a un file alla spec che l'ha causata.
+> 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`.
 
 ## Multi-feature tra progetti
 

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

@@ -80,7 +80,7 @@ Per eseguire un loop personalizzato:
 2. Nell'header del rail, apri il **selettore Loop** e scegli il tuo loop pubblicato.
 3. Premi **▶ Play**.
 
-L'esecuzione scorre dal vivo nella vista **Jobs** esattamente come un job di rail integrato — stessi log, stesse metriche, stesso tracciamento del costo. Un loop che si ferma perché ha raggiunto il suo tetto di iterazioni o di costo viene riportato con quell'esito anziché con un semplice successo.
+L'esecuzione scorre dal vivo nella vista **Jobs** con le stesse metriche e lo stesso tracciamento del costo di qualsiasi job di rail — e il suo log guadagna un **esploratore di passi** dedicato: una mappa live del tuo grafo con una scatola richiudibile per passo, che segue il passo in esecuzione man mano che il loop avanza (vedi [La vista Dettaglio job](the-job-detail-view)). Su Claude, ogni **Passo AI** è anche una sessione live: mandagli messaggi dal composer del Dettaglio job per orientarlo a metà passo (tra un passo e l'altro il composer attende brevemente, e **Assesta questo passo** fa avanzare il loop con ciò che il passo ha prodotto). Un loop che si ferma perché ha raggiunto il suo tetto di iterazioni o di costo viene riportato con quell'esito anziché con un semplice successo.
 
 > **Attenzione mentre un loop gira.** Non puoi modificare o eliminare un loop mentre una delle sue esecuzioni è in corso — ferma prima l'esecuzione.
 

package/docs/guide/it/specs/1-specs-and-the-backlog.md

@@ -13,7 +13,7 @@ La board ha due modalità di visualizzazione, che si alternano con un toggle nel
 - **Vista post-it** (quella predefinita) — riquadri in stile card con brevi riepiloghi.
 - **Vista elenco** — righe compatte su una sola riga.
 
-Puoi anche filtrare per **stato** (Tutti / Da fare / Completati) e per **etichetta**, oltre a ordinare per **Predefinito**, **Ticket #** o **Priorità** (ciascuno con un toggle crescente/decrescente).
+Il **selettore di stati** della toolbar mostra ogni stato come chip dedicato con un conteggio in tempo reale — più due gruppi intelligenti: **Attive** (il predefinito — tutto ciò che è ancora in movimento: bozze, da fare, in corso e in revisione) e **Tutti** (tutto, con Completato fissato in fondo). La scelta viene ricordata per progetto e riflessa nell'URL, così un refresh o un link condiviso ripristina esattamente la stessa vista. Nei progetti collegati a Jira compare in più un menu a tendina **stato Jira**, che elenca gli stati *reali* del workflow della board (i nomi grezzi, es. "Code Review", ciascuno con il proprio conteggio in tempo reale) raggruppati sotto lo stato a cui mappano — si combina con i chip di stato. Puoi anche filtrare per **etichetta**, oltre a ordinare per **Predefinito**, **Ticket #** o **Priorità** (ciascuno con un toggle crescente/decrescente).
 
 ## Stati
 
@@ -24,7 +24,8 @@ Una spec attraversa un piccolo insieme di stati. La board associa a ciascuno un
 | **Bozza** | Un'idea in corso salvata da una conversazione in modalità Explore. Non ancora pronta da realizzare — puoi tornarci e continuare a darle forma. Mostra un badge `Draft`. |
 | **Da fare** | Pronta per essere presa in carico. È qui che atterra una spec finita quando la crei. |
 | **In corso** | La pipeline ci sta lavorando in questo momento (un punto blu pulsante). |
-| **Completato** | Portata a termine dalla pipeline (un segno di spunta verde). |
+| **In revisione** | Implementata — ogni esecuzione conclusa parcheggia qui le sue spec per la tua approvazione: fai il merge della PR in bozza o spostale tu stesso (un badge ambra). |
+| **Completato** | Approvata — la sua PR è stata unita, o l'hai spostata qui tu stesso (un segno di spunta verde). |
 | **Annullato** | Abbandonata (una X rossa). |
 
 Le bozze vivono nello stesso gruppo attivo delle spec Da fare — non c'è una colonna separata per loro — ma hanno un bordo dalla tinta sottile e un badge `Draft` che le rende facili da individuare. Consulta [Le bozze e il Contract Layer](drafts-and-contract-layer.md) per tutta la storia sulle bozze.

package/docs/guide/ja/insights/3-code-explorer.md

@@ -37,6 +37,12 @@
 
 また、グローバル設定の*Code section*の領域で、**要約の言語**（英語またはスペイン語）を選べます。
 
+## 構築ストーリー
+
+コードビューアの下には**構築ストーリー**があります。いま見ているファイルを築き上げた、すべてのスペックとジョブを時系列に並べたタイムラインです。各章はカードになっており、どのスペックが介入したか（現在のステータス付き）、いつ、ファイルが作成・変更・削除されたのか、そして変更の規模（追加・削除された行数）が分かります。カードをクリックすると、そのスペックの詳細が開きます。ループベースのレールもファイルへの変更を記録するので、分離されたワークツリーで行われた作業も通常のパイプラインジョブと同じようにストーリーに現れます。
+
+どの章でも、分かりやすい言葉での説明を求められます。**この変更を説明**を押すと、その具体的な変更がこのファイルに何をもたらしたのかを、アプリが 1〜3 文で書いてくれます。コードも専門用語もありません。説明はファイル要約と同じ月間予算を共有し、まだ生成されていない間は、カードは把握している事実 — 変更の種類、スペック、日付 — に正直にとどまります。生データが好みなら、**ストーリー / ログ**の切り替えで、オンデマンドの diff 付きのクラシックな変更履歴リストに切り替えられます。同じパネルはエージェントモードの **Files** ペインにも表示されます。
+
 ## コードをスペックへ結びつける
 
 来歴のリンクは双方向に機能します。Code エクスプローラーの中で、ファイル上のチケットチップをクリックすると、そのチケットの詳細が開きます。逆方向では、**チケット詳細**ビューに*このチケットが変更したファイル*セクションがあり — そこでファイルをクリックすると、そのファイルが開いた状態の Code エクスプローラーへ直接ジャンプします。「これが私たちの書いたスペック」と「これがそこから生まれたコード」の間のループを、きちんと閉じてくれます。

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

@@ -7,7 +7,7 @@
 Specrails は、Jira とプロジェクトのあいだの**同期レイヤー**として動きます。大きな考え方はこうです。パイプラインが読み込む正本はあくまでローカルのスペックストアであり、それと Jira を一致させ続ける責任を Specrails が担います。
 
 - レールを起動すると、Specrails はリンクされた Jira の課題を **In Progress** に移動します。
-- ジョブが終わると、Specrails は課題を遷移させ（**Done** へ、失敗した場合は **To Do** へ戻す）、ジョブ ID・コスト・所要時間を含む完了コメントを投稿します。
+- ジョブが終わると、Specrails は課題を遷移させます。成功した場合はマッピングされた**レビュー**ステータスへ移り、作業を承認して初めて **Done** に到達します（ドラフト PR をマージすると「PR merged」コメントが投稿されます）。失敗した場合は **To Do** へ戻り、ジョブ ID・コスト・所要時間を含む完了コメントが投稿されます。
 - Specrails は定期的に Jira を**ポーリング**し、ボード上で誰かが行った変更を取り込んで、スペックに反映します。
 
 すべての書き戻しは、耐久性があってクラッシュに強いアウトボックスを通ります。そのため、一時的な Jira の不調がジョブを壊すことはなく、更新は再試行されるだけです。

package/docs/guide/ja/integrations/6-agent-chat.md

@@ -53,9 +53,14 @@ Agent Chat は組み込みの **Specrails MCP サーバー**を通じてアプ
 
 ## 気の利いた工夫
 
+- **会話からスーパースペックを。** 一発生成ではなく、エージェントと一緒にスペックを*磨き上げて*みてください。まず実際のコードを読み、手短に質問し、進化していく下書きを会話内のライブカードとして表示します。あなたが承認するとスペックを作成し、デフォルトでバックグラウンドの **Contract Layer**（正確なファイルパス、データ形状、不変条件）で充実させるため、実装エージェントが即興に頼ることがなくなります。「contract layer なし」と言えば省略できます。
+- **言及されたものをクリック。** プロジェクトに固定されたミッションでは、エージェントの返信内のスペック番号（`#12`）やジョブ／実行の id はクリック可能なチップです——スペックはボードの詳細モーダルを、ジョブ id はライブのジョブビューを開きます。参照がもう存在しない場合は、控えめな「見つかりません」の通知が表示されます。
+- **実装カードは常に見える位置に。** エージェントがスペックを実装すると、ライブカードが作業を追跡します——あなたの判断（PR の作成、公開、再試行、破棄）を待っている間、カードは会話がどれだけスクロールしても**メッセージ欄のすぐ上にピン留め**されたままです。履歴上の元の位置には「上部にピン留め中」の控えめなマーカーが表示されます。複数のカードがアクティブな場合は小さなチップとして積み重なり（クリックで前面に表示）、シェブロンでカードを細いバーに最小化できます。PR が公開されるか、作業がマージまたは破棄されると、カードは会話履歴の元の位置に戻ります。
 - **プロンプト履歴。** 入力欄が空のとき、**↑**/**↓** を押すと以前に頼んだ内容をたどれます（スクロール中は薄く表示されます）。入力を始めれば編集でき、Enter で送信できます。
+- **キューを編集。** エージェントが作業中にさらに送信しましたか？メッセージがキューにある間、**↑**/**↓** は*それら*の間を移動します——入力欄に選択したメッセージが表示され、その場で編集でき、**Enter でキューへ保存し直せます**（Esc でキャンセル。未送信の下書きはそのまま戻ってきます）。
 - **最小化しても失わない。** ✕ をクリックするとパネルはバブルへ戻ります——会話はそのまま動き続けます。開き直すと最新のメッセージに着地します。何も打ち直す必要はありません。
 - **新しい会話。** **+** ボタンでまっさらなスレッドを始めます。履歴はアプリ全体にわたって存在し、個々のプロジェクトの上位にあります。
+- **ミッションの切り替え。** プロジェクトセレクターの隣にあるミッションセレクターは、会話を新しい順に一覧表示します — 点滅するドットはエージェントがまだ作業中の会話を示し、小さなバッジはキュー内のメッセージ数を表します。リストが 8 件を超えると検索欄が現れます。各行のゴミ箱アイコンは、行内のクイック確認のあとにミッションを削除します — 実行中のものでも可能です（先に警告し、その後エージェントを停止します）。
 
 ## 知っておくとよいこと
 

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

@@ -18,7 +18,7 @@ SpecsBoard（左）            レール（右）
 
 レールは**実行レーン**です。SpecsBoard からスペックカードをレールにドラッグし、**▶ Play** を押します。するとレールがパイプラインを起動し、あなたのプロジェクトの作業ディレクトリの中で、ファイルの編集やテストの実行まで含めて、スペックを最初から最後までやり遂げます。
 
-レールは複数持てるので、名前付きのレーンとして作業を整理できます（いま集中している機能用のレールと、その後ろに控えさせておくレールといった具合に）。複数レールやバッチ処理については [バッチ実装とマルチフィーチャー](batch-implement-and-multi-feature) で詳しく説明します。
+レールは複数持てるので、名前付きのレーンとして作業を整理できます（いま集中している機能用のレールと、その後ろに控えさせておくレールといった具合に）。レールは**動的**です。レールヘッダーの **+ 追加** ボタンで新しいレーンを作成でき（1 プロジェクトあたり最大 12 本）、空のアイドルなレーンは削除できます。すべてのレールはサーバーに裏付けられているので、レーンの構成はリロード後も保持され、モバイルコンパニオンやアプリ内エージェントからも見えます — レーンがすべて塞がっているときは、エージェントが自分でレールを作ることさえできます。複数レールやバッチ処理については [バッチ実装とマルチフィーチャー](batch-implement-and-multi-feature) で詳しく説明します。
 
 ## スペックでレールを起動する
 
@@ -49,7 +49,7 @@ SpecsBoard（左）            レール（右）
 | **Batch** | `/specrails:batch-implement` | レール上のスペックを、依存関係を考慮したウェーブで順番に処理する 1 つのジョブ。関連する複数のスペックに最適です。 |
 | **Freestyle** | Freestyle | Claude が各スペックをパイプラインを**バイパス**して自律的に実装します。スペックごとに独立したジョブが 1 つずつ作られます。Claude 専用。 |
 
-Freestyle は少し毛色が違います。エージェントチェーンを飛ばし、生のスペックを Claude に渡してネイティブツールで作業させます。自由度が高いぶん、Play を押すとまず確認ダイアログが開き、レールごとのモデルピッカーで Haiku / Sonnet / Opus を選べます。Freestyle はレールのエンジンが Claude のときだけ表示されます。
+Freestyle は少し毛色が違います。エージェントチェーンを飛ばし、生のスペックを Claude に渡してネイティブツールで作業させます。自由度が高いぶん、Play を押すとまず確認ダイアログが開き、レールごとのモデルピッカーで Haiku / Sonnet / Opus を選べます。Freestyle はレールのエンジンが Claude のときだけ表示されます。さらに Freestyle の実行は、**あなたを待って開き続ける**唯一のジョブでもあります。ジョブ詳細のコンポーザーから会話し、満足したら **Finalize** をクリックしてください（それ以外のジョブはすべて自分で締めくくります）。
 
 組み込みのほかにも、**自分だけの Loop を作る** ことができます — verify → fix → verify のサイクルを目標が達成されるまで繰り返したり、AI ステップの間にシェルコマンドを連ねたり、さらにいろいろなことができます。そうしたカスタム Loop は同じ Loop ピッカーに表示されます。それが次の大きなアイデア、[Loop Builder](the-loop-builder) です。
 
@@ -57,11 +57,11 @@ Freestyle は少し毛色が違います。エージェントチェーンを飛
 
 Play を押すたびに、そのレールの実行は **ジョブ** になります。ぜひ頭に入れておいてほしい一番大事なルールがこれです。
 
-> **1 プロジェクトにつき、同時に動くジョブは 1 つだけ。** 各プロジェクトはキューを 1 つ持っています。1 つのプロジェクト内では、レールのジョブは一度に 1 つしか実行されません — 残りはその後ろで待機し、スロットが空くと自動的に開始されます。
+> **レールは並列に実行されます。** すべての起動は作業をスペックごとの git worktree に隔離するので、同じプロジェクト内でも複数のレールを同時に走らせて衝突することはありません — 各実行の変更は、完了時にマージまたはドラフト PR として戻ってきます。
 
-レールを 3 つ追加すれば並列で動くと思っていた人は、たいてい驚きます。同じプロジェクト内では並列にはなりません。レールを追加するのは作業をレーンに**整理する**ためで、それらのレーンを同時に走らせるためのものではありません。
+すべてを一斉に動かしたいときは、レールヘッダーの **すべて起動** ボタンが準備完了のレーンをまとめて起動します。確認は 1 回だけで、そこで総コスト（レール数 × AI 支出）が提示されます。空のレール、実行中のレール、PR の判断待ちのレールはスキップされ、コンパクトなサマリートーストで報告されます。アプリ内エージェントも `specrails_rails(launch_all)` で同じことができ、空きレーンがなければ自分で新しいレールを作ります。
 
-**本当の並列処理はプロジェクトをまたいで行われます。** 各プロジェクトは独立したキューを持つので、プロジェクト A のレールとプロジェクト B のレールは、互いに競合することなく同時に動きます。もっとスループットがほしいですか？ プロジェクトをもっと開きましょう。
+旧来の 1 プロジェクト 1 ジョブのキューに戻るのは、レガシー経路（Loops 機能を無効化した場合）だけです。その場合、追加のレールは実行中のレールの後ろで待機します。プロジェクトをまたぐ並列性は従来どおりで、各プロジェクトは完全に独立しています。
 
 調整できるグローバルな同時実行のつまみはありません。唯一の自動スロットルは予算ベースのものです。1 日の予算（プロジェクト単位またはアプリ全体）を設定していれば、その日の支出が上限に達した時点でキューが自動的に一時停止します。
 
@@ -73,7 +73,7 @@ Play を押すたびに、そのレールの実行は **ジョブ** になりま
 - **日付範囲フィルター** — 期間で絞り込みます。
 - **比較** — 2 つのジョブを選んで並べて表示します。
 
-どれかのカードをクリックすると **ジョブ詳細ビュー** が開きます。ここにライブのストリーミングログとライブのメトリクスがあります。それが次のページ、[ジョブ詳細ビュー](the-job-detail-view) です。
+どれかのカードをクリックすると **ジョブ詳細ビュー** が開きます。ここにライブのストリーミングログとライブのメトリクスがあり、Claude のジョブならチャットコンポーザーから、何も止めずに**実行中のエージェントへ質問したり、途中で舵取りしたり**できます。それが次のページ、[ジョブ詳細ビュー](the-job-detail-view) です。
 
 ## ジョブをキャンセルする
 

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

@@ -1,10 +1,10 @@
 # ジョブ詳細ビュー
 
-**ジョブ** ページでどれかのジョブカードをクリックすると、ここにたどり着きます。1 回のレール実行のためのコックピットです。このビューはたった 1 つの約束を軸に作られています — **あなたが目にするライブの数値は本物であり、決して推測ではありません。** このページでは、フェーズ、ライブメトリクス、チケットカードをひととおり見ていきます。
+**ジョブ** ページでどれかのジョブカードをクリックすると、ここにたどり着きます。1 回のレール実行のためのコックピットです。このビューはたった 1 つの約束を軸に作られています — **あなたが目にするライブの数値は本物であり、決して推測ではありません。** このページでは、フェーズ、ライブメトリクス、チケットカード、そして**実行中のジョブと会話できる**コンポーザーをひととおり見ていきます。
 
 ## レイアウト
 
-ストリーミングログ全体の上に、2 つのパネルが並びます。
+ストリーミングログ全体の上に 2 つのパネルが並び、実行中の Claude ジョブではその下にチャットコンポーザーが表示されます。
 
 ```
 ┌─────────────────────────────────────────────┐
@@ -15,6 +15,8 @@
 │                                             │
 │  ストリーミングログ  (自動スクロール · 検索 · …)  │
 │                                             │
+├─────────────────────────────────────────────┤
+│  コンポーザー  (ジョブにメッセージを送る · …)   │
 └─────────────────────────────────────────────┘
 ```
 
@@ -71,6 +73,29 @@ Architect ──► Developer ──► Reviewer ──► Ship
 
 これは AI が何をしているかの生の真実です — すべてのツール呼び出し、すべてのファイル編集、すべてのテスト実行が映ります。
 
+## Loop の実行: ステップエクスプローラー
+
+ジョブが **Loop の実行**（[Loop Builder](the-loop-builder) を参照）の場合、フラットなログの代わりに、Loop の実際の形をなぞる**ステップエクスプローラー**が表示されます。
+
+- 上部の**オーバービューストリップ**は Loop のライブマップです — ノードごとにひとつのチップ（AI ステップ、シェル、ループ判定…）が、グラフの流れる順に並びます。チップは実行の進行に合わせて灯っていきます: 待機中は薄く、実行中は脈動し、終わればチェックかバツが付きます。判定ノードのチップには実際に採った裁定 — ループに戻るか、先へ進むか — も表示され、右側の反復カウンター（`反復 3/10`）が回数を刻みます。チップをクリックすると、そのノードの最新のステップへ直接ジャンプします。
+- **ステップごとに折りたたみ可能なボックス。** ノードを通るたびにそれぞれ独立したセクションになり、ステップ番号、名前、反復バッジ、完了後の所要時間 — さらに専用のコピーボタンが付くので、ひとつのステップの出力だけを正確に持ち出せます。（ツールバーのコピーは従来どおりログ全体を対象にします。）最初のステップより前に出力されたもの — 実行バナーや worktree の通知 — は**セットアップ**セクションにまとめられます。
+- **追従モード**はデフォルトでオンです: 実行中のステップは開いたまま自動スクロールし、前のステップは折りたたまれて道を空けます。上へスクロールしたり古いステップを開いたりした瞬間、読めるように追従は一時停止します — フローティングの**追従を再開**ピルでライブに戻れます。**すべて展開 / すべて折りたたむ**はツールバーにあり、検索ボックスに入力するとすべてのステップを横断して検索します。
+- **中断されたステップも誠実です。** 結果を報告できないまま終わったステップ — 実行がキャンセルされた、あるいはステップの途中でアプリが落ちた — は、終わったふりをせず、破線の枠で**中断**と印付けされます。
+
+このページのそれ以外はすべて、Loop の実行でもまったく同じに動きます — ライブメトリクス、チケットカード、コンポーザー。Loop ではないジョブは、上の従来のストリーミングログのままです。
+
+## 実行中のジョブと会話する
+
+すべての Claude ジョブはデフォルトで**ライブセッション**として実行されるため、このページの下部 — そしてミッションモードのジョブモーダルの下部 — にチャットコンポーザーが表示されます。実行中のエージェントに質問したり（「あのテストはなぜ失敗した？」）、実行の途中で方向を示したり（「リファクタは飛ばして、修正に集中して」）するのに使えます。
+
+知っておくと便利なポイント:
+
+- **メッセージはキューに入り、割り込みません。** エージェントがストリーミング中に送信しても、メッセージは順番を待ちます — 次のプロンプトとして実行され、ジョブは自分の計画を進め続けます。小さなカウンターが、待機中のメッセージ数を表示します。
+- **合計の行は本物です。** コンポーザーはライブの `N ターン · $X` サマリーを表示します。完了した各ターンの実際の使用量を合算したもので、このページの「推測しない」という約束と一貫しています。
+- **セッションの終わり方は 2 通り。** ほとんどのジョブは**自分で締めくくります**。キューにメッセージが残っていない状態でターンが終わった瞬間、セッションは自ら落ち着き、ジョブは完了します — あなたのメッセージは任意の舵取りであって、義務ではありません。控えめな**今すぐ締めくくる**アクションで、それまでの成果を保ったまま早めに終わらせることもできます。**Freestyle** ジョブだけは例外です。ターンの合間で待機し、あなたが **Finalize** をクリックするまで開き続けます — あなたが閉じる往復のセッション、それが Freestyle の設計です。
+- **Loop 実行では、メッセージはアクティブなステップに届きます。** 組み込みでもカスタムでも、Loop 上ではメッセージは**いままさに実行中の AI ステップ**に届きます。ステップの合間（Loop Decider が考えている間や、シェルコマンドの実行中）には、コンポーザーは*「次のステップを待っています…」*という短い待機状態を表示します — 下書きのテキストは保持され、次の AI ステップが始まると送信が再び有効になります。**このステップを確定**すると現在のステップを早めに終わらせ、その成果とともに Loop を先へ進められます。
+- **今のところ Claude のみ。** Codex と Gemini のジョブは従来どおりワンショットで実行されます — コンポーザーは表示されません。（サーバー運用者は `SPECRAILS_INTERACTIVE_JOBS=false` で機能全体を無効化できます。）
+
 ## 診断のエクスポート
 
 そのジョブで [テレメトリ](../settings/customizing) が有効になっていた場合、ヘッダーに **診断をエクスポート** ボタンが表示されます。クリックすると次のものを含む ZIP がダウンロードされます。

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

@@ -40,17 +40,21 @@
 
 ジョブ内では、各ウェーブのスペックが実装されてから次のウェーブが始まります。これを手で設定する必要はありません — オーケストレーターがスペックそのものからウェーブを導き出します。その様子は [ジョブ詳細ビュー](the-job-detail-view) で見られます。ストリーミングログがバッチがいまどのスペックに取り組んでいるかを語り、チケットヘッダーがジョブの触れたすべてのスペックを表示します。
 
-## ワークツリーの隔離
+## ワークツリーの隔離と成果物の届け方
 
-複数のスペックが 1 回の実行で実装されるとき、パイプラインは各作業単位を隔離し、同時または逐次の変更が互いのファイルを踏み荒らさないようにします。バッチオーケストレーターは各スペックの実装を、それ専用のクリーンな作業コンテキストで走らせ、その結果を統合します — だから、途中までしかできていないスペックが、次のスペックから見える壊れた中間状態をツリーに残すことはありません。
+複数のスペックを 1 回の実行で実装するとき、パイプラインは各作業単位を隔離し、同時または逐次の変更が互いのファイルを踏み荒らさないようにします。各スペックの実装は、それ専用のクリーンな **git ワークツリー** の中で走ります — これはリポジトリの履歴を共有しつつも、AI が作業している間はあなたのワークツリーには一切触れない、独立したチェックアウトです。
+
+実行が終わっても、**何もプッシュされず、プルリクエストもまだ開かれません**。成果は隔離された各ブランチに安全にコミットされたまま残り、スペックは新しい **レビュー中（On review）** ステータスへ移り、specrails が **まずあなたに尋ねます**。レール上に常設の決定バーが現れ、**PR を作成** — プロジェクトで指定した統合ブランチ（**設定 → 統合ブランチ** で指定します。既定ではリポジトリのデフォルトブランチになります）を起点に、レール上のすべてのスペックをまとめた 1 つのドラフトのプルリクエストを開く — と **破棄** の選択肢を提示します。specrails が **マージすることはなく、統合ブランチへ直接コミットすることもありません** — そもそも PR を作るかどうかを決めるのはあなたであり、マージの責任は人間が持ちます。これは安全な引き渡しです。specrails はあなたが承認したときにだけプルリクエストを用意し、あなたのエンジニアがふだんどおり GitHub でレビューしてマージします。
 
 実際のところ、これは次を意味します。
 
 - 各スペックは、前のスペックの進行中の編集を途中から引き継ぐのではなく、まっさらな状態から実装に取りかかれます。
-- レビューと ship ステップは、動く標的ではなく、一貫したスナップショットに対して動作します。
-- あるウェーブでの失敗は封じ込められます — すでに ship 済みのスペックを密かに壊すことはありません。
+- 実行中にあなたのワークツリーが変更されることはありません — あなたが承認するまで、何も反映されません。
+- 実行が終わると、スペックに **レビュー中** のバッジが付き、レールがあなたに問いかけます。**PR を作成** でまとめられたドラフトのプルリクエストを開くか、**破棄** でブランチを片付けてスペックをバックログへ戻します。レールをエージェントチャットから起動していた場合は、同じ質問がその会話の中にカードとして現れます — どちらで答えても、両者は同期し続けます。
+- 作成後は、**PR を開く** で内容を確認し、**公開** でチームのレビューに公開してふだんどおりの GitHub レビューへ引き渡し、**マージを確認** で、チームがマージを終えた時点でスペックが完了（Done）へ切り替わります。
+- PR の作成時に隔離されたブランチをきれいに統合できない場合、specrails は安全に停止し、ブランチを人間のために残します — 壊れたマージをベースへ無理やり押し込むことは決してありません。同じバーから再試行も破棄もできます。
 
-アプリはジョブごとに、どのファイルが触れられ、どのチケットがそれに触れたかを正確に記録します（これは **コード** セクションでは provenance チップとして、各スペックの詳細モーダルでは「このチケットが触れたファイル」リストとして表面化します）。この帰属づけこそが、複数スペックの実行を信頼できるものにしています — ファイルの変更を、それを引き起こしたスペックまでいつでもたどれるのです。
+> PR を作成するには、認証済みの GitHub CLI（`gh`）とリモートの設定が必要です。それらがなくても、成果はあなた自身がプルリクエストを開けるブランチへコミットされたまま残ります — 何も失われませんし、決定バーから再試行できます。以前の挙動（尋ねずにローカルで統合する）に戻すには、`SPECRAILS_RAIL_DELIVER_PR=0` を設定してください。
 
 ## プロジェクトをまたいだマルチフィーチャー
 

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

@@ -80,7 +80,7 @@ Loop は最初は **Draft** です。グラフが有効になったら **Publish
 2. レールヘッダーで **Loop ピッカー** を開き、公開したあなたの Loop を選びます。
 3. **▶ Play** を押します。
 
-実行は **ジョブ** ビューで、組み込みのレールジョブとまったく同じようにライブでストリーミングされます — 同じログ、同じメトリクス、同じコストトラッキングです。反復回数やコストの上限に達して停止した Loop は、ただの成功ではなく、その結果とともに報告されます。
+実行は **ジョブ** ビューで、他のレールジョブと同じメトリクスとコストトラッキングとともにライブでストリーミングされます — さらにそのログには専用の**ステップエクスプローラー**が付きます。グラフのライブマップの下にステップごとの折りたたみボックスが並び、Loop が進むにつれて実行中のステップを追従します（[ジョブ詳細ビュー](the-job-detail-view) を参照）。Claude では各 **AI ステップ**もライブセッションです。ジョブ詳細のコンポーザーからメッセージを送ってステップの途中で舵取りできます（ステップの合間はコンポーザーが少し待機し、**このステップを確定**すればその成果とともに Loop が先へ進みます）。反復回数やコストの上限に達して停止した Loop は、ただの成功ではなく、その結果とともに報告されます。
 
 > **Loop の実行中の注意点。** いずれかの実行が動いている間は、その Loop を編集したり削除したりできません — 先に実行を止めてください。
 

package/docs/guide/ja/specs/1-specs-and-the-backlog.md

@@ -13,7 +13,7 @@
 - **付箋表示**（デフォルト）— 短い概要が添えられたカード形式のタイル。
 - **リスト表示** — 1 行ずつのコンパクトな表示。
 
-さらに**ステータス**（すべて / ToDo / 完了）や**ラベル**で絞り込んだり、**デフォルト**・**チケット #**・**優先度**で並べ替えたり（それぞれ昇順／降順を切り替え可能）できます。
+ツールバーの**ステータスセレクター**は、各ステータスをライブカウント付きの独立したチップとして表示します。さらに 2 つのスマートグループがあります：**アクティブ**（デフォルト — まだ動いているものすべて：下書き、Todo、進行中、レビュー中）と**すべて**（全部を表示し、完了は一番下に固定）。選択はプロジェクトごとに記憶され URL にも反映されるため、リロードや共有リンクでもまったく同じビューが復元されます。Jira に接続したプロジェクトでは、さらに **Jira ステータス**のドロップダウンが現れ、ボードの*実際の*ワークフローステータス（生の名前、例：「Code Review」、それぞれライブカウント付き）を、対応する状態ごとにグループ化して一覧します — ステータスチップと組み合わせて使えます。さらに**ラベル**で絞り込んだり、**デフォルト**・**チケット #**・**優先度**で並べ替えたり（それぞれ昇順／降順を切り替え可能）できます。
 
 ## ステータス
 
@@ -24,7 +24,8 @@
 | **下書き** | Explore の会話から保存した、作りかけのアイデア。まだ実装の準備はできていません。あとから戻ってきて、引き続き形にしていけます。`Draft` のピルが表示されます。 |
 | **Todo** | これから着手できる状態。スペックを作り終えると、ここに着地します。 |
 | **進行中** | パイプラインが現在作業中です（青い点が点滅します）。 |
-| **完了** | パイプラインによって完了しました（緑のチェックマーク）。 |
+| **レビュー中** | 実装済み — 実行が終わるとスペックはここで承認待ちになります。ドラフト PR をマージするか、自分で先へ移動してください（琥珀色のピル）。 |
+| **完了** | 承認済み — PR がマージされたか、自分でここへ移動しました（緑のチェックマーク）。 |
 | **キャンセル** | 取りやめになりました（赤い X）。 |
 
 下書きは Todo のスペックと同じアクティブな枠に並びます（専用の列はありません）が、ほんのり色づいたボーダーと `Draft` ピルが付いているので、すぐに見分けられます。下書きについての詳しい話は[下書きと Contract Layer](drafts-and-contract-layer.md)をご覧ください。

package/docs/guide/pt/insights/3-code-explorer.md

@@ -37,6 +37,12 @@ Algumas salvaguardas mantêm os custos sob controlo: a geração de resumos corr
 
 Pode também escolher o **idioma do resumo** (inglês ou espanhol) nas definições globais, na área da *secção Code*.
 
+## A história de construção
+
+Por baixo do visualizador de código vive a **história de construção** — uma linha do tempo cronológica de cada spec e cada job que construíram o ficheiro que estás a ver. Cada capítulo é um cartão: que spec interveio (com o seu estado atual), quando, se o ficheiro foi criado, modificado ou eliminado, e o tamanho da mudança (linhas adicionadas e removidas). Clica num cartão para abrir o detalhe dessa spec. Os rails baseados em loops também registam os ficheiros que tocam, por isso o trabalho feito em worktrees isolados aparece na história tal como os jobs normais do pipeline.
+
+Para qualquer capítulo podes pedir uma explicação em linguagem simples: carrega em **Explicar esta alteração** e a app escreve uma a três frases a descrever o que essa mudança concreta contribuiu para o ficheiro — sem código, sem jargão. As explicações partilham o mesmo orçamento mensal dos resumos de ficheiros e, enquanto nenhuma for gerada, o cartão recorre aos factos que conhece: o tipo de mudança, a spec e a data. Preferes os dados em bruto? Um seletor **História / Registro** muda para a lista clássica de alterações com diffs a pedido. O mesmo painel aparece na vista **Files** do modo Agente.
+
 ## Ligar o código de volta às specs
 
 A ligação de proveniência funciona nos dois sentidos. Dentro do Code explorer, clicar na etiqueta de um ticket num ficheiro abre o detalhe desse ticket. E no sentido inverso, a vista de **detalhe do ticket** tem uma secção *Ficheiros alterados por este ticket* — clique aí num ficheiro e salta diretamente para o Code explorer com ele aberto. Fecha o ciclo entre "aqui está a spec que escrevemos" e "aqui está o código que daí saiu".

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

@@ -7,7 +7,7 @@ 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 (para **Concluído**, ou de volta para **A fazer** se falhar) e publica um comentário de conclusão com o id do trabalho, o custo e a 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 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).
 - 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.

package/docs/guide/pt/integrations/6-agent-chat.md

@@ -53,9 +53,14 @@ As respostas chegam de forma fluida e já formatadas (títulos, tabelas, listas)
 
 ## Detalhes práticos
 
+- **Super specs a partir de uma conversa.** Peça ao agente para *moldar* uma spec com você em vez de gerá-la de uma vez: ele lê primeiro o código real, faz algumas perguntas e mostra o rascunho em evolução como um cartão ao vivo dentro da conversa. Quando você diz sim, ele cria a spec e — por padrão — a enriquece em segundo plano com uma **Contract Layer** (caminhos de arquivo exatos, formas de dados, invariantes) para que os agentes que implementam não improvisem. Diga "sem contract layer" para pular o enriquecimento.
+- **Clique no que ele menciona.** Em uma missão fixada a um projeto, os números de spec (`#12`) e os ids de job/execução nas respostas do agente são chips clicáveis: uma spec abre o modal de detalhe do quadro e um id de job abre a visão do job ao vivo. Se a referência não existir mais, você verá um aviso discreto de "não encontrado".
+- **O cartão de implementação, sempre à vista.** Quando o agente implementa specs, um cartão ao vivo acompanha o trabalho — e enquanto ele precisar de algo de você (criar a PR, publicá-la, tentar de novo, descartar) fica **fixado logo acima da caixa de mensagem**, por mais que a conversa role; no lugar dele no histórico aparece um marcador discreto de "fixado acima". Vários cartões ativos se empilham como pequenos chips (clique em um para trazê-lo à frente), e um chevron minimiza o cartão para uma barra fina. Quando a PR é publicada — ou o trabalho é mesclado ou descartado — o cartão volta ao seu lugar no histórico da conversa.
 - **Histórico de prompts.** Com a caixa vazia, pressione **↑**/**↓** para percorrer o que você perguntou antes (mostrado esmaecido enquanto rola); comece a digitar para editar, ou pressione Enter para enviar.
+- **Edite a fila.** Enviou mais enquanto o agente estava ocupado? Enquanto houver mensagens na fila, **↑**/**↓** percorre *essas* mensagens: a caixa mostra a selecionada, você a edita ali mesmo e **Enter a salva de volta na fila** (Esc cancela; seu rascunho não enviado volta intacto).
 - **Minimize sem perder nada.** Clique no ✕ para devolver o painel à bolha — a conversa continua rodando. Reabra e você chega na mensagem mais recente; nada é redigitado.
 - **Nova conversa.** O botão **+** inicia um fio limpo; o histórico vive no nível da aplicação, acima de qualquer projeto individual.
+- **Troque de missão.** O seletor de missões ao lado do seletor de projeto lista suas conversas da mais recente para a mais antiga — um ponto pulsante marca aquelas em que o agente ainda está trabalhando, e um pequeno selo conta as mensagens na fila. A busca aparece quando a lista passa de oito, e o ícone de lixeira de cada linha exclui uma missão após uma confirmação rápida em linha — mesmo uma em andamento (ele avisa primeiro e depois para o agente).
 
 ## Algumas coisas para saber