specrails-desktop 2.64.2 → 2.65.1

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

@@ -1,4 +1,4 @@
-# Specs & das Backlog
+# Specs & das Backlog {#specs-backlog}
 
 Eine **Spec** ist die Arbeitseinheit, die die KI-Pipeline umsetzt. Stell sie dir wie ein Ticket vor: ein Titel, eine Beschreibung dessen, was du erledigt haben möchtest, eine Priorität und optionale Labels. Wenn du die Pipeline startest, lesen die KI-Agenten die Spec und handeln danach – eine klare Spec ist also der mit Abstand wichtigste Input für ein gutes Ergebnis.
 
@@ -13,7 +13,27 @@ Das Board hat zwei Ansichtsmodi, die du über einen Umschalter in der Toolbar we
 - **Post-it-Ansicht** (Standard) – kartenartige Kacheln mit kurzen Zusammenfassungen.
 - **Listenansicht** – kompakte, einzeilige Zeilen.
 
-Der **Status-Selektor** in der Werkzeugleiste zeigt jeden Status als eigenen Chip mit Live-Zähler — plus zwei smarte Gruppen: **Aktiv** (der Standard — alles, was noch in Bewegung ist: Entwürfe, To-dos, in Arbeit und in Prüfung) und **Alle** (alles, mit Fertig unten angeheftet). Deine Auswahl wird pro Projekt gemerkt und in die URL gespiegelt, sodass ein Neuladen oder ein geteilter Link exakt dieselbe Ansicht wiederherstellt. Bei Jira-verbundenen Projekten erscheint zusätzlich ein **Jira-Status**-Dropdown mit den *echten* Workflow-Status des Boards (ihre Rohnamen, z. B. „Code Review", jeweils mit Live-Zähler), gruppiert unter dem Zustand, auf den sie abbilden — es kombiniert sich mit den Status-Chips. Du kannst außerdem nach **Label** filtern sowie nach **Standard**, **Ticket #** oder **Priorität** sortieren (jeweils mit Umschalter für auf- und absteigend).
+Die Specs-Werkzeugleiste hat zwei Zeilen. Die erste enthält ein **Suchfeld** (mit `/` springst du hinein; es findet Titel, `#Nummer`, Label oder Jira-Schlüssel), eine einzige **Filter**-Schaltfläche, die Sortier- und Ansichtssteuerung sowie **Neue Spec**. Die zweite Zeile ist der **Status-Selektor**: jeder Status als eigenes Segment mit Live-Zähler, dazu zwei smarte Gruppen, **Aktiv** (der Standard: alles, was noch in Bewegung ist, also Entwürfe, To-dos, in Arbeit und in Prüfung) und **Alle** (alles, mit Fertig unten angeheftet). Ist die Spalte schmal, wandern die seltener genutzten Status in ein **Mehr**-Menü, und der gewählte Status bleibt immer sichtbar. Deine Auswahl wird pro Projekt gemerkt und in die URL gespiegelt, sodass ein Neuladen oder ein geteilter Link exakt dieselbe Ansicht wiederherstellt. **Filter** öffnet ein Panel mit einem Abschnitt pro Dimension: **Labels** (Mehrfachauswahl) und bei Jira-verbundenen Projekten **Epic**, **Sprint** und **Jira-Status** (die *echten* Workflow-Status des Boards, z. B. „Code Review“, gruppiert unter dem Zustand, auf den sie abbilden, kombiniert mit dem Status-Selektor). Solange eine Suche oder ein Filter das Board eingrenzt, zeigt eine dritte Zeile jeden davon als entfernbaren Chip, nennt „x von y“ Specs und bietet **Alle zurücksetzen** (dein gewählter Status bleibt erhalten). Sortiere nach **Standard**, **Ticket #** oder **Priorität**, jeweils mit Umschalter für auf- und absteigend.
+
+### Mehrere Specs auswählen
+
+Sortieren Sie gesammelt statt Spec für Spec. Drücken Sie `x` auf einer fokussierten Karte, klicken Sie mit `Strg`/`⌘` auf eine Karte oder mit `Umschalt` für einen Bereich (ein Bereich bleibt in einer Spalte: die aktiven Specs oder der Bereich „Erledigt“). `Strg`/`⌘`+`A` wählt die ganze Spalte, in der Sie sind, `Esc` hebt die Auswahl auf. Jede Karte zeigt beim Darüberfahren oder Fokussieren ein Kontrollkästchen, ausgewählte Karten haben einen hervorgehobenen Rahmen. Keine dieser Tasten wirkt, solange Sie im Suchfeld tippen.
+
+Sobald eine Spec ausgewählt ist, erscheint unten im Board eine schwebende Leiste mit der Anzahl und den Aktionen:
+
+- **Verschieben nach** ändert den Status. Lokale Specs erhalten die lokalen Status; Specs aus Jira erhalten die echten Workflow-Status des Jira-Boards und laufen über dieselbe Jira-Warteschlange wie eine einzelne Verschiebung.
+- **Label** fügt der Auswahl ein Label hinzu oder entfernt eines, das die Specs tragen.
+- **Priorität** setzt für alle dieselbe Priorität.
+- **Zu Rail hinzufügen** legt die Auswahl auf einen Rail.
+- **Alle starten** gibt jeder ausgewählten Spec einen eigenen freien Rail und startet sie parallel, nach derselben Bestätigung und Prüfung des Tagesbudgets wie *Alle starten* bei den Rails. Specs, die noch nicht starten können (etwa im Review ohne offenen PR) oder keinen freien Rail finden, werden übersprungen und in der Zusammenfassung gezählt.
+- **Löschen** verschiebt sie nach *Zuletzt gelöscht*.
+- **Aufheben** (oder `Esc`) verwirft die Auswahl.
+
+Löschen sowie Änderungen von Status, Labels und Priorität lassen sich in einem Schritt rückgängig machen: eine einzige *Rückgängig*-Meldung (oder `⌘Z`) stellt jede geänderte Spec wieder her. Schlagen einzelne fehl, nennt eine Meldung, wie viele geklappt haben und wie viele nicht. Die Auswahl enthält nur Specs, die Sie sehen: Ein Filter, der eine ausgewählte Spec ausblendet, nimmt sie aus der Auswahl.
+
+### Gespeicherte Ansichten
+
+Die Schaltfläche **Ansichten** neben **Filter** speichert das Board so, wie es gerade ist: die Statusauswahl, die Filter, die Sortierung und die Dichte (nicht den Suchtext). Wählen Sie **Aktuelle Ansicht speichern…**, geben Sie ihr einen Namen („Startbereit“, „Sprint 42“, „Diese Woche fehlgeschlagen“) und wählen Sie sie später im selben Menü. **Ansichten verwalten…** benennt eine Ansicht um, aktualisiert sie mit dem aktuellen Board, kopiert ihren Link oder löscht sie. Ansichten gehören zum Projekt. Ein kopierter Link (`?view=…`) wendet die Ansicht an, wenn er in dieser App geöffnet wird, und die Befehlspalette (`⌘K`) kann die aktuelle Ansicht speichern oder zu einer anderen wechseln.
 
 ## Status
 
@@ -38,7 +58,7 @@ Entwürfe sind die einzige Ausnahme: Ein Entwurf darf *gar keine* Priorität hab
 
 ## Eine Spec erstellen
 
-Um eine Spec zu erstellen, klicke auf **Hinzufügen** (die Plus-Schaltfläche in der SpecsBoard-Toolbar). Der Dialog **Spec hinzufügen** öffnet sich mit mehreren Arbeitsweisen:
+Um eine Spec zu erstellen, klicke auf **Neue Spec** (die Plus-Schaltfläche in der SpecsBoard-Toolbar). Der Dialog **Spec hinzufügen** öffnet sich mit mehreren Arbeitsweisen:
 
 - **Quick-Modus** – du beschreibst, was du möchtest, und die KI schreibt die vollständige Spec in einem Rutsch. Siehe [Spec hinzufügen – Quick-Modus](add-spec-quick-mode.md).
 - **Explore-Modus** – du unterhältst dich mit der KI, und sie hilft dir, die Spec Zug um Zug zu formen. Siehe [Spec hinzufügen – Explore-Modus](add-spec-explore-mode.md).
@@ -50,6 +70,24 @@ Welchen du wählst, hängt davon ab, wie klar die Idee schon ist. Du weißt gena
 
 Wenn hinter einer Spec bereits Arbeit steckt – ein PR im Review, ein gemergtes Feature – und du *mehr* willst, schreibe ihre Beschreibung nicht um: Das verfälscht die Spec (und synchronisiert die Abweichung nach Jira) und zwingt den nächsten Lauf, alles neu zu planen. Öffne die Spec und füge stattdessen ein **Addendum** hinzu: eine kurze Notiz mit einer Art (Änderungswunsch, Review-Feedback, Klarstellung, Einschränkung) und deinen Worten. Offene Addenda reisen automatisch mit dem nächsten Start dieser Spec auf jedem Loop mit – Implement, SDD Quick, Freestyle –, sodass der Lauf nur ändert, was du verlangt hast, und das Review-Paket jedes als angewendet, teilweise angewendet oder blockiert meldet. Schlägt der Lauf fehl oder verwirfst du die Lieferung, kehren sie von selbst zu **Offen** zurück. Der Missions-Agent kann sie für dich anlegen, wenn du ihn bittest, etwas an einer bestehenden Spec zu ändern.
 
+## Eine Lieferung prüfen – worauf zuerst achten
+
+Wenn ein Lauf endet, beginnt sein Review-Paket mit **Worauf achten**: den kurzen Hinweisen des KI-Reviewers, die die riskantesten Stellen zuerst nennen (hoch, dann mittel, dann niedrig, jeweils mit Datei und Zeile), das Verhalten, das sich ändert, die Regeln, auf die sich die Änderung stützt, die Codepfade, die kein Test ausführt, und die Prüfungen, die nur ein Mensch machen kann. Dieselben Risiken, ungetesteten Pfade und Prüfungen stehen in einem kurzen Block oben im Pull Request, und die Missionskarte zeigt das größte Risiko in einer Zeile. Die Hinweise unterstützen Ihr Review, sie sind kein Prüfergebnis und blockieren Annehmen nie. Läufe mit einem älteren Specrails Core haben keine Hinweise; ihr Paket sieht aus wie bisher.
+
+## Rückgängig und Zuletzt gelöscht {#recently-deleted}
+
+Eine Spec löschen, ihren Status ändern, ihre Labels ändern oder sie von einer Rail nehmen geschieht sofort — ohne vorherige Rückfrage. Stattdessen bietet ein Hinweis etwa acht Sekunden lang **Rückgängig** an, und **⌘Z** (**Strg+Z** unter Windows und Linux) tut dasselbe, solange du nicht in einem Feld tippst. Rückgängig gilt pro Projekt: Ein Projektwechsel beendet das Zeitfenster.
+
+Eine gelöschte Spec (und eine gelöschte Mission) ist nicht weg. Sie landet unter **Einstellungen → Zuletzt gelöscht** in den Projekteinstellungen, wo du sie 30 Tage lang **Wiederherstellen** oder **Endgültig löschen** kannst — Letzteres fragt nach. Nach 30 Tagen wird sie endgültig entfernt. Nicht gepushte Arbeit verwerfen, einen Pull Request erzwungen schließen und ein Projekt entfernen fragen weiterhin nach, weil sie sich nicht rückgängig machen lassen. Eine Jira-gestützte Spec wird weiterhin mit **Verschieben nach** statt durch Löschen bearbeitet.
+
+## Der Spec-Verlauf und die Übergabe {#spec-timeline}
+
+Öffne eine Spec und wechsle zum Tab **Verlauf**, um ihre ganze Geschichte an einem Ort zu lesen: die Änderungen und Nachträge, die Missionen, die sie berührt haben, jeden Lauf mit seinen Phasen und Agent-Aktionen, die Pull-Request-Ereignisse und das Urteil des Reviewers samt Befunden. Die Einträge sind nach Tag gruppiert, die Chips filtern nach Art, und jeder Eintrag verlinkt auf die Mission, den Lauf oder das Review, aus dem er stammt. Lange Gruppen (Phasen, Agent-Aktionen, Missions-Turns) sind mit einer Zahl eingeklappt und klappen an Ort und Stelle auf.
+
+Die Kosten stehen neben dem Eintrag, der sie verursacht hat, und die beiden Arten bleiben getrennt: ein vom Anbieter gemeldeter Betrag und ein aus der lokalen Preistabelle geschätzter (mit „gesch.“ markiert). Wird ein Anbieter über ein Abo abgerechnet, zeigen Verlauf und Exporte Turns, nie Dollar; ein Lauf ohne gemeldete Kosten zeigt schlicht keine.
+
+**Übergabe exportieren** (das Menü neben den Tabs oder ⌘K → *Übergabe für #N exportieren*) schreibt eine Markdown-Datei oder eine eigenständige HTML-Seite mit der Zusammenfassung, den Entscheidungen (Nachträge, Klärungen, Urteile des Reviewers), den Diff-Statistiken, den Kosten und dem, was noch offen ist (offene Nachträge und ungelöste Review-Befunde). **Als PR-Beschreibung kopieren** (auch in ⌘K) legt eine kürzere Markdown-Fassung in die Zwischenablage. Die Überschriften folgen der Sprache der App. Alles läuft durch dieselbe Geheimnis-Schwärzung wie das Audit der Agent-Aktionen, und die Meldung sagt dir, wenn etwas entfernt wurde.
+
 ## Wie es weitergeht
 
 - [Spec hinzufügen – Quick-Modus](add-spec-quick-mode.md) – der schnellste Weg, eine Idee in eine Spec zu verwandeln.

package/docs/guide/de/specs/2-add-spec-quick-mode.md

@@ -6,7 +6,7 @@ Der Quick-Modus ist für die Momente gedacht, in denen du bereits weißt, was du
 
 So erstellst du schnell eine Spec:
 
-1. Klicke auf dem Dashboard auf **Hinzufügen** (die Plus-Schaltfläche in der SpecsBoard-Toolbar).
+1. Klicke auf dem Dashboard auf **Neue Spec** (die Plus-Schaltfläche in der SpecsBoard-Toolbar).
 2. Wähle den Modus **Quick**.
 3. Tippe deine Idee ins Textfeld – ein Satz oder ein Absatz, was immer sie auf den Punkt bringt.
 4. Klicke auf Generieren.

package/docs/guide/de/specs/3-add-spec-explore-mode.md

@@ -22,7 +22,7 @@ Während du dich unterhältst, zeigt ein Entwurfsbereich die Spec in ihrem aktue
 
 Das ist das Herzstück des Explore-Modus: Du starrst nie auf ein leeres Formular. Du blickst immer auf eine echte, sich entwickelnde Spec.
 
-## Wie viel die KI sieht: der Kontext-Schieberegler
+## Wie viel die KI sieht: der Kontext-Schieberegler {#context-scope}
 
 Bevor die KI antwortet, entscheidest du, wie viel von deinem Projekt sie sehen darf. Ein Schieberegler mit Kontext-Presets lässt dich Geschwindigkeit gegen Tiefe abwägen:
 

package/docs/guide/en/agents/1-meet-the-agents.md

@@ -1,4 +1,4 @@
-# Meet the agents
+# Meet the agents {#agents}
 
 When you launch an **Implement** rail, Specrails doesn't hand your spec to a single AI and hope for the best. It runs a small team of specialised *agents*, each with one job, in a deliberate order. This page introduces who's on that team and what each one does.
 

package/docs/guide/en/getting-started/1-what-is-specrails.md

@@ -8,7 +8,7 @@ Instead of copy-pasting prompts back and forth, you describe what you want as a
 
 The heart of specrails is a simple idea: **the best way to get good code out of AI is to start from a clear spec.**
 
-A *spec* is a short, structured description of one piece of work — a feature, a fix, a refactor. You can write one in seconds, or shape one through a guided chat that asks the right questions and drafts it for you. Each spec becomes a **ticket** on your project board, just like a task in any issue tracker.
+A *spec* is a short, structured description of one piece of work — a feature, a fix, a refactor. You can write one in seconds, or shape one through a guided chat that asks the right questions and drafts it for you. Each spec becomes a **spec** on your project board, just like a task in any issue tracker.
 
 From there, you hand the spec to the pipeline and let the AI do the heavy lifting.
 

package/docs/guide/en/getting-started/2-installing-and-first-run.md

@@ -39,3 +39,5 @@ You'll see:
 That's the whole onboarding — no account to create, no sign-up. Specrails works entirely on your machine.
 
 Click **Add your first project** and continue to [Adding your first project](adding-your-first-project).
+
+Or start with the [sample project](try-the-sample-project): a tiny game and three ready-made specs, with the cost stated upfront.

package/docs/guide/en/getting-started/3-try-the-sample-project.md

@@ -0,0 +1,35 @@
+# Try the sample project
+
+Want to see a spec become a reviewed change before you point specrails at your own code? The **sample project** is a tiny tic-tac-toe web game with three ready-made specs. It takes a few minutes and ends at a real **Review packet**.
+
+## Start it
+
+On the welcome screen, click **Try it on a sample project** (next to **Add your first project**). The dialog tells you, before anything happens:
+
+- **What is created**: a small web game in its own git repository, with three specs already on your board.
+- **Where**: by default `~/Specrails Samples/tic-tac-toe` inside your home folder. You can change the folder; an existing folder is never overwritten.
+- **What a run would cost**: an estimate such as "≈ $0.30–$1 · about 3–5 min". It is only shown as dollars when your provider bills per use. On a subscription plan it says there is no extra charge, and on a local engine there is no API cost.
+
+Creating the sample costs nothing and runs nothing. Click **Create sample project** and you land on the Board.
+
+## The three steps
+
+A small guide card points at the real Board, one step at a time. You can dismiss it at any moment; it collapses to a **Sample project** pill where **Show guide** brings it back.
+
+1. **The spec.** The three specs are written for you. Each says what to build and how to know it is done.
+2. **The rail.** Click **Run the first spec**. The sample is set up to be cheap and bounded: Quick mode, the cheapest available model, and a per-run soft cap (the run pauses and asks before passing $1). If you have a local engine configured you can choose it instead, with no API cost.
+3. **The review.** Nothing is merged on its own. When the run ends, a **Review packet** shows what changed and lets you accept or discard it.
+
+## No AI provider ready?
+
+Before offering the run, specrails checks that a provider is installed and signed in. If none is ready you get **Watch a recorded run** instead: a replay of a finished run that ends at a Review packet. It is clearly labelled a recording; nothing runs and nothing is charged. Install or sign in to a provider, then choose **Check again** to switch to a real run.
+
+## Then, your own project
+
+The guide ends with **Now add your own project**. When you are done with the sample, **Remove sample** unregisters it with one click. The folder stays on disk unless you tick **Also delete the sample folder**, which cannot be undone.
+
+## Replay the platform tour
+
+The tour is no longer on the welcome screen. Open **Docs** and choose **Replay tour**, or press the command palette key and type "Replay tour". It is also in **Settings ▸ Appearance**.
+
+Next: [Adding your first project](adding-your-first-project).

package/docs/guide/en/getting-started/5-the-dashboard-tour.md

@@ -0,0 +1,52 @@
+# The dashboard tour
+
+With a project added, you're looking at your **project dashboard** — your home base for turning specs into shipped code. Here's how to find your way around.
+
+## The big picture
+
+The window has three zones:
+
+- **Left sidebar** — your list of projects. Click any project to switch to it instantly; everything else in the window updates to match. The **Add project** button lives here too.
+- **Main area** — the dashboard for the active project: your specs and the pipeline that runs them.
+- **Right sidebar** — navigation between the sections of the current project.
+
+## The main dashboard
+
+This is where the work happens. The dashboard shows:
+
+- **Your specs** — the specs you've created, organized by status (Backlog/To-Do through Done). You can view them as a list, a grid, or sticky-note cards, whichever you prefer.
+- **A way to add a spec** — start a new piece of work. You can write a quick spec directly, or open a guided **Explore** chat that helps you shape it through conversation and drafts the spec for you.
+- **Rails** — these are the lanes where specs get built. Drop a spec onto a rail and launch it to send it through the Architect → Developer → Reviewer → Ship pipeline. Multiple rails can run at once, so you can work on several things in parallel.
+
+When a spec is running, you'll see its pipeline progress and live logs — the AI's real-time output as it designs, codes, and reviews your change.
+
+## The right sidebar: project sections
+
+The right sidebar is your switchboard for the current project. Hover it to expand, or pin it open. The sections you'll see:
+
+- **Dashboard** — the specs board and rails (where you just were).
+- **Jobs** — every pipeline run for this project, past and present, with status, duration, and the ability to dig into any run's detail and logs.
+- **Integrations** — optional add-ons, like connecting your specs to a **Jira** board or enabling extra tooling for the AI.
+- **Settings** — per-project options (telemetry, budgets, provider configuration, and more).
+
+## The status bar
+
+A thin strip runs along the very bottom of the window. It's small but handy:
+
+- **Connection indicator** (left) — a coloured dot and label showing the app is live: green for *connected*, amber while *reconnecting*, blue while *syncing* just after a reconnect. You'll rarely need it, but it's reassuring when you do.
+- **Total spend** (right) — a running total of what you've spent, so cost is always one glance away.
+- **Terminal toggle** (far right) — open the built-in terminal panel. Press **Cmd+J** (macOS) or **Ctrl+J** (Windows/Linux) to toggle it any time. It's a full shell, opened right in your project folder.
+
+## A few handy shortcuts {#shortcuts}
+
+- **Cmd/Ctrl+B** — pin or collapse the left sidebar; **Option+Cmd+B** (**Ctrl+Alt+B**) does the same for the right sidebar.
+- **Cmd/Ctrl+J** — toggle the terminal panel.
+- **Cmd/Ctrl+K** — the command palette: search missions, projects and jobs, and **run actions**. Type a verb ("new", "launch", "move", "switch") or start with **>** to list actions: New spec (also in Explore), Launch or Move a spec, Open its review, Hand off or Pause a Flow, New mission, Switch theme, Switch between Mission and Board mode, Open app or project settings on a section, Run a loop, toggle the sidebars, Go back or forward, Undo the last change, and Recently deleted. Actions that need a choice (a rail, a status, a theme, a section) open a second page; **Backspace** on an empty search returns. Each action shows its keyboard shortcut, so the palette teaches the keys. It only offers what works where you are, and it respects the same rules as the buttons (a spec that cannot launch is not offered). With an empty search it lists your **Recent actions** and **Recent places**.
+- **Cmd+[ / Cmd+]** (**Alt+← / Alt+→** on Windows/Linux) or the **←  →** buttons in the title bar, or your mouse's back/forward buttons — go back or forward through the places you have been: specs, missions, jobs, projects and full-page panels. Right-click (or long-press) a button to see the last few places.
+- **Cmd+Shift+I** (**Ctrl+Alt+I** on Windows and Linux) or the **Inbox** button in the title bar — the **Needs you** inbox: everything across all your projects that waits for you, in one list grouped by project. It collects reviews ready to decide, questions an agent is waiting on, runs that failed or got blocked, runs paused at the daily budget and Jira updates that could not sync. Each row has its main action right there (**Open review**, **Answer**, **Resume**, **Retry**) plus **Snooze** (1 hour or until tomorrow) and **Done**. A snoozed or done item comes back by itself if its state changes. The button shows how many items wait, and a provider-limit notification opens the inbox. The inbox is also a link (`?inbox=1`) and an action in the command palette.
+- **M** — with a spec card focused on the board, opens a picker to move it to a status or a rail, the keyboard equivalent of drag and drop. It works on a multi-selection too, and the palette offers it as **Move focused spec…**.
+- **?** — the shortcuts cheatsheet. Type in its search box to filter the shortcuts and to find matching pages and sections of this guide, which open in the guide without leaving your screen. The small **ⓘ** icons and **Learn more** links next to settings, rails, Flow, the context slider and budgets open the guide at the matching section the same way.
+
+## Where to go next
+
+That's the lay of the land. From here, the natural first move is to **add a spec** and launch it on a rail — watch the pipeline run end to end, then check **Analytics** to see what it cost. Welcome aboard.

package/docs/guide/en/getting-started/6-universal-search.md

@@ -0,0 +1,34 @@
+# Universal search (⌘K)
+
+Press **⌘K** (**Ctrl+K** on Windows and Linux) to search almost everything in Specrails from one place: missions, specs, job logs, files, settings and this guide. Type a plain query to search missions, projects, specs and recent jobs as before, or start with a **prefix** to search one source only.
+
+## Prefixes
+
+| Type | Searches | Enter opens |
+| --- | --- | --- |
+| `#` | Specs: title, summary, description, labels, out-of-scope notes, addenda and comments. `#12` finds spec 12. | The spec |
+| `@` | Missions: title and conversation content. | The mission |
+| `/` | Settings (Desktop and project) by name or by what you would call them. | The settings window at that block, scrolled into view and focused |
+| `f:` | Files of the project, by name or path. | The file in the Code explorer |
+| `log:` | Job logs: commands, loop names, phase titles and failure diagnoses. | The job |
+| `?` | This guide: page titles and headings. | The guide at that heading |
+
+When you type a prefix it becomes a **chip** in the search box and the box keeps only your query. Press **Backspace** on an empty box (or click the chip's ×) to drop the scope. With an empty box, the palette lists the prefixes under the box; click one to start. `>` still lists actions, as before.
+
+## Highlights
+
+Results show a short snippet around the first match, with the matching text highlighted. Matching ignores case and accents, so `revision` finds "Revisión".
+
+## Settings
+
+`/` knows the main settings blocks, in your language: theme, language, editor, budgets, notifications, webhooks, updates, branch, environment, telemetry, rules and more. Project settings are offered when a project is open. Pick one and the right window opens at that block. Without a prefix, a strong match (three or more characters) adds up to three settings to the normal results. `/budget` also finds the Budget panel (caps, projection, what-if), where the weekly and monthly caps live. A slash command such as `/implement` is listed under the settings, in its own group, so the `/` prefix never hides it.
+
+## Job logs
+
+`log:` searches a compact index, not the raw output of a run: the command, the loop name, the phase titles and the short diagnosis of a failed, blocked or stalled run. It never stores token streams or tool output, so it stays small and fast. It is kept per project and holds the latest runs.
+
+## Good to know
+
+- `#`, `f:` and `log:` search the active project; open a project first.
+- The files scope respects the Code explorer's ignore rules.
+- Each group shows only its best few results; refine the query to narrow it down.

package/docs/guide/en/insights/1-analytics-and-cost-tracking.md

@@ -6,15 +6,17 @@ Open it from the right sidebar (it's labelled **Analytics**). Everything you see
 
 ## What counts as spend
 
-Specrails tracks five kinds of AI activity, called *surfaces*. Each one is colour-coded consistently across every chart so you can spot it at a glance:
+Specrails tags every AI run with a *surface*: the part of the app that spent it. The main surfaces each get a consistent colour and a filter chip, so you can spot them at a glance:
 
-- **Job** — a pipeline rail running Architect → Developer → Reviewer → Ship.
+- **Job** — a queued pipeline job (Architect → Developer → Reviewer → Ship), including Freestyle runs.
+- **Loop** — each AI step of a loop run. Rails run as loops by default, so most rail spend lands here.
 - **Quick spec** — a spec generated through the fast Add Spec path.
 - **Explore spec** — an Explore conversation where you shape a spec by chatting.
 - **AI edit** — an AI-assisted refine on an agent or file.
-- **File summary** — the plain-language summaries that power the Code explorer.
+- **SMASH** — splitting an epic spec into smaller specs.
+- **File summary** — the plain-language summaries and file stories that power the Code explorer.
 
-A couple of things are deliberately *not* tracked: the chat sidebar and the setup wizard both spawn AI CLIs, but they never show up in your spend. So the dashboard reflects real, repeatable work rather than incidental chatter.
+Smaller surfaces are tracked as well, without a chip of their own: the chat sidebar, the OpenSpec spec launcher, spec proposals, Agent Studio and the legacy setup chat. Missions pinned to the project count toward its spend too. Nothing that runs an AI CLI is left out, so the totals reflect all of the project's AI activity.
 
 ## Reading the dashboard
 
@@ -40,9 +42,9 @@ Your top models by spend (up to ten). Click any model to filter the whole dashbo
 
 Each point is one invocation, plotting cost against the number of turns. Outliers — the expensive, many-turn runs — jump right out. (The scatter shows your most recent 500 points to stay responsive.)
 
-### Top tickets
+### Top specs
 
-Your ten most expensive tickets across *all* surfaces combined, so a ticket that cost a little in Explore and a lot in a job shows its true total. Deleted tickets and unattributed runs get their own buckets so nothing silently vanishes from the totals.
+Your ten most expensive specs across *all* surfaces combined, so a spec that cost a little in Explore and a lot in a job shows its true total. Deleted specs and unattributed runs get their own buckets so nothing silently vanishes from the totals.
 
 ### Raw invocations table
 
@@ -54,19 +56,19 @@ The sticky header at the top carries the two primary filters — **period** and
 
 A note on accuracy: failed and aborted runs are kept out of *cost averages* (they'd skew the per-run numbers) but they still count toward your total run count and failure rate. So the averages stay clean while the reliability picture stays complete.
 
-## Per-ticket cost
+## Per-spec cost
 
-You don't have to come to the Analytics page to see what a spec cost. Open any ticket and, if it has any spend attached, you'll see a one-line summary right under the title:
+You don't have to come to the Analytics page to see what a spec cost. Open any spec and, if it has any spend attached, you'll see a one-line summary right under the title:
 
 > $0.42 · 6 turns · 1m 12s active · breakdown
 
-Click it and you land on the Analytics page already filtered to that ticket. It's the quickest path from "what did this feature cost me?" to the full breakdown.
+Click it and you land on the Analytics page already filtered to that spec. It's the quickest path from "what did this feature cost me?" to the full breakdown.
 
 ## Exporting your data
 
 When you need the numbers outside the app — a spreadsheet, a finance report, your own analysis — use the **Export** dropdown. It offers four formats:
 
-- **Summary CSV** — a multi-section file with totals, the daily timeline, by-surface, by-model, and top tickets.
+- **Summary CSV** — a multi-section file with totals, the daily timeline, by-surface, by-model, and top specs.
 - **Summary JSON** — the same summary, structured.
 - **Raw CSV** — every invocation row (up to 10,000; it notes if it had to truncate).
 - **Raw JSON** — the same raw rows, structured.
@@ -76,3 +78,15 @@ Exports respect whatever period and surface filters you currently have applied,
 ## Staying live
 
 You don't need to refresh. When a new invocation is recorded anywhere in the project, the open dashboard quietly refetches itself a moment later, so the burn meter keeps pace with work as it finishes.
+
+## Daily limits {#daily-budget}
+
+Set a daily limit to cap what a day can cost. Every cap, daily, weekly, monthly and per-run, is edited in one place: **Analytics → Spend limits**. **Settings → Advanced** and **Project settings → Spend limits** only show the current daily cap, with an **Open Spend limits** button that takes you there.
+
+When the day's recorded spend reaches a limit, the queue pauses itself, rails and loop runs refuse to launch with *Daily limit reached*, and a loop run already in progress parks between steps, paused at the limit. Raise or clear the limit, or wait for the daily reset, and then resume.
+
+The project limit counts your local day; the app-wide limit counts the UTC day. The per-job cost alert is a separate setting.
+
+**Weekly, monthly and per-run caps.** Longer caps work the same way. Open **Analytics → Spend limits** to set a **weekly** and a **monthly** cap, per project and for the whole app, and a **per-run soft cap** (*pause and ask at $X*). Weeks start on Monday and months on the 1st, in your local time. A weekly or monthly cap pauses queues, refuses launches and parks running loops exactly like the daily limit; raise or clear it there, or wait for the reset. When a run's own reported cost reaches the per-run cap it pauses, and **Resume** asks whether to continue without the cap or raise it. Reaching any cap also adds a **Raise cap** item to the inbox.
+
+The Spend limits panel shows today, this week and this month against each cap. Its month-end **projection** is an estimate (the average of the last 14 completed days times the days left, plus what you have spent), never added to billed spend. **What-if** re-prices the last 30 days of recorded token usage on another model with the app's price list, and says *No pricing* for a model it has no price for. On a subscription plan there is no dollar cost per use, so the panel shows turns and plan limits instead of dollars.

package/docs/guide/en/insights/2-the-integrated-terminal.md

@@ -1,4 +1,4 @@
-# The integrated terminal
+# The integrated terminal {#integrated-terminal}
 
 Specrails has a real terminal built right in — the panel that slides up from the bottom of the window, just like the one in VS Code or Cursor. It runs your actual shell, in your actual project directory, so you can run `git`, `npm`, tests, or anything else without leaving the app.
 

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

@@ -1,4 +1,4 @@
-# Code explorer
+# Code explorer {#code-explorer}
 
 The **Code** section gives you a friendly, read-only window into your repository — designed especially for people who want to understand what the AI has been building without living in an editor. You get a file tree on the left, a code viewer on the right, and, above the code, a plain-language summary of what each file actually does.
 
@@ -10,7 +10,7 @@ Open it from the right sidebar (**Code**), and like everything else it's scoped
 
 The left pane is a virtualised tree of your project's files — fast even on large repos. It respects your `.gitignore` and a built-in deny-list, so you see the files that matter, not a sea of build artifacts and `node_modules`.
 
-Next to files you'll notice **provenance chips** — little markers that tell you a file was *touched by AI*. This is the heart of the Code explorer: Specrails records which files each pipeline job created or modified, and ties them back to the ticket that prompted the work. So you can answer, at a glance, "did the AI write this, or did I?"
+Next to files you'll notice **provenance chips** — little markers that tell you a file was *touched by AI*. This is the heart of the Code explorer: Specrails records which files each pipeline job created or modified, and ties them back to the spec that prompted the work. So you can answer, at a glance, "did the AI write this, or did I?"
 
 At the top of the tree there's a filter:
 
@@ -39,17 +39,17 @@ You can also choose the **summary language** (English or Spanish) in the global
 
 ## The construction story
 
-Beneath the code viewer lives the **construction story** — a chronological timeline of every spec and job that built the file you're looking at. Each chapter is a card: which spec intervened (with its live status), when, whether the file was created, modified or deleted, and how big the change was (lines added and removed). Click a spec card to open that ticket's detail. Loop-based rails record their file touches too, so work done in isolated worktrees shows up in the story just like regular pipeline jobs.
+Beneath the code viewer lives the **construction story** — a chronological timeline of every spec and job that built the file you're looking at. Each chapter is a card: which spec intervened (with its live status), when, whether the file was created, modified or deleted, and how big the change was (lines added and removed). Click a spec card to open that spec's detail. Loop-based rails record their file touches too, so work done in isolated worktrees shows up in the story just like regular pipeline jobs.
 
 For any chapter you can ask for a plain-language explanation: press **Explain this change** and the app writes one to three sentences describing what that specific change contributed to the file — no code, no jargon. Explanations share the same monthly budget as file summaries, and until one is generated the card falls back to the honest facts it knows: the kind of change, the spec, and the date. Prefer the raw data? A **Story / Log** toggle switches to the classic touch-history list with on-demand diffs. The same story panel appears in Agent Mode's **Files** pane.
 
 ## Connecting code back to specs
 
-The provenance link runs both ways. Inside the Code explorer, clicking a ticket chip on a file opens that ticket's detail. And from the other direction, the **ticket detail** view has a *Files touched by this ticket* section — click a file there and you jump straight into the Code explorer with it open. It closes the loop between "here's the spec we wrote" and "here's the code that came out of it."
+The provenance link runs both ways. Inside the Code explorer, clicking a spec chip on a file opens that spec's detail. And from the other direction, the **spec detail** view has a *Files touched by this spec* section — click a file there and you jump straight into the Code explorer with it open. It closes the loop between "here's the spec we wrote" and "here's the code that came out of it."
 
 ## What it doesn't do (yet)
 
-To set expectations clearly, this first version intentionally leaves a few things out: in-app editing, per-symbol or directory-level summaries, a narrative diff view, and conversational "ask the AI about this file." Provenance attributes a file to its primary ticket only. These are the kinds of things that may grow over time.
+To set expectations clearly, this first version intentionally leaves a few things out: in-app editing, per-symbol or directory-level summaries, a narrative diff view, and conversational "ask the AI about this file." Provenance attributes a file to its primary spec only. These are the kinds of things that may grow over time.
 
 ## Turning it off
 

package/docs/guide/en/integrations/1-ai-providers.md

@@ -1,6 +1,6 @@
 <!-- guide-revision: mission-first-v1 -->
 
-# Connect an AI provider
+# Connect an AI provider {#ai-providers}
 
 Specrails coordinates your authenticated Claude or Codex CLI. Provider installation, account access and model billing remain separate from the application.
 

package/docs/guide/en/integrations/2-plugins.md

@@ -1,4 +1,4 @@
-# Plugins (Integrations)
+# Plugins (Integrations) {#plugins}
 
 The **Integrations** section is a per-project marketplace of optional add-ons that extend what the AI can do. Each project decides independently which plugins it wants — installing a plugin in one project never touches another.
 

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

@@ -8,14 +8,14 @@ Specrails acts as a **sync layer** between Jira and your project. The big idea:
 
 - When you launch a rail, Specrails moves the linked Jira issue to **In Progress**.
 - When a job finishes, Specrails transitions the issue: on success it moves to your mapped **review** status and only reaches **Done** once the delivery PR is merged or you accept the local result; on failure it goes back to **To Do** with a completion comment that includes the result, run id, cost, duration, and the Jira status change.
-- If you ask for follow-up changes while the Jira issue is already in review, Specrails tries to continue the existing open PR branch for that ticket instead of creating a fresh branch. If your Jira review status is not explicitly mapped and still appears locally as **In Progress**, Specrails can still continue the PR when the Jira key matches the open pull request.
+- If you ask for follow-up changes while the Jira issue is already in review, Specrails tries to continue the existing open PR branch for that spec instead of creating a fresh branch. If your Jira review status is not explicitly mapped and still appears locally as **In Progress**, Specrails can still continue the PR when the Jira key matches the open pull request.
 - Periodically Specrails **polls** Jira for changes anyone made on the board and reflects them back into your specs.
 
 All write-backs go through a durable, crash-safe outbox, so a momentary Jira hiccup never breaks a job — the update just retries.
 
 ## Connecting a board
 
-You connect from a project's **Settings** page (there's also an optional "Configure Jira" step at the end of the Add-Project wizard). The connect wizard walks you through:
+You connect from the **Plugins** page in the left sidebar: click **Install** on the Jira card and choose the project. The connect wizard walks you through:
 
 1. **Test** — enter your Jira URL and credentials, and Specrails verifies the connection.
 2. **Pick a project** — choose which Jira project to sync with.
@@ -52,7 +52,7 @@ So you can experiment freely — flip it on, run a few rails, flip it off — wi
 
 ## Day-to-day
 
-Once connected, the project's Settings page shows a **connected card** where you can:
+Once connected, the Jira card on the **Plugins** page switches to **Manage**. Choose the project there to open its **connected card**, where you can:
 
 - **Sync now** — force an immediate poll instead of waiting for the timer.
 - **Retry dead-letters** — re-run any write-backs that got stuck.
@@ -69,4 +69,4 @@ Specs backed by Jira show a **Jira key badge** (like `PROJ-123`) on their card,
 
 ## Turning it off
 
-If you ever want to fully back out, just **Disconnect** from Settings. Your specs return to local-only behavior, and the Jira metadata simply sits unused — nothing is destroyed.
+If you ever want to fully back out, just **Disconnect** from the connected card. Your specs return to local-only behavior, and the Jira metadata simply sits unused — nothing is destroyed.

package/docs/guide/en/integrations/4-mobile-companion.md

@@ -1,4 +1,4 @@
-# The mobile companion
+# The mobile companion {#mobile-companion}
 
 Specrails has a companion phone app so you can keep an eye on your rails while you're away from your desk — watch jobs run, see them finish, and stay in the loop without sitting in front of the dashboard.
 

package/docs/guide/en/integrations/5-mcp-server.md

@@ -1,4 +1,4 @@
-# Control Specrails from any AI (MCP server)
+# Control Specrails from any AI (MCP server) {#mcp-server}
 
 Specrails can expose **itself** to any AI assistant that speaks the [Model Context Protocol](https://modelcontextprotocol.io) — Claude Desktop, Claude Code, Cursor, Cline, or your own agent. Turn it on, point your assistant at Specrails, and you can drive the whole app by chatting: *"list my projects", "create a spec for social login in the API project", "launch rail 0 and tell me when it's done", "how much did I spend this week?"*. Your assistant calls Specrails' tools under the hood instead of you clicking around.
 
@@ -47,16 +47,16 @@ Untick **Destructive** and it can build all night without ever deleting anything
 > *"Check all my projects. Tell me which have specs in the backlog and no rail running, and start the highest-priority one in each."*
 
 **Hands-free while you code.** Drive Specrails from your editor or by voice, without switching windows:
-> *"Launch rail 0 in Freestyle mode with Opus for ticket #42 and tell me when it's done."*
+> *"Launch rail 0 in Freestyle mode with Opus for spec #42 and tell me when it's done."*
 
 **Ask about cost and history.** Your analytics, in plain language:
-> *"Where did I spend the most on AI this week, by project and by model? Show me the five most expensive tickets."*
+> *"Where did I spend the most on AI this week, by project and by model? Show me the five most expensive specs."*
 
 **Your daily standup.**
 > *"Write my standup: which rails ran yesterday, what completed, what failed, total cost — as bullets ready to paste into Slack."*
 
 **Understand the code.** No editor needed:
-> *"Which files did ticket #38 touch? Summarise in one line what changed in each."*
+> *"Which files did spec #38 touch? Summarise in one line what changed in each."*
 
 Because your assistant reads the built-in guide first, you rarely need to name tools or specs — describe the outcome and it works out the calls.
 

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

@@ -1,6 +1,6 @@
 # Operate Specrails by chatting (Agent Chat)
 
-The **Agent Chat** is a copilot that lives *inside* Specrails and can drive the whole app for you. Instead of clicking through projects, specs, rails and analytics, you just ask: *"how many jobs succeeded this week?"*, *"create a spec for social login in the API project"*, *"launch the three highest-priority tickets and tell me when they finish"*. It carries out the work by calling Specrails' own tools — the same ones the [MCP server](./5-mcp-server.md) exposes — while you watch the dashboard update live behind it.
+The **Agent Chat** is a copilot that lives *inside* Specrails and can drive the whole app for you. Instead of clicking through projects, specs, rails and analytics, you just ask: *"how many jobs succeeded this week?"*, *"create a spec for social login in the API project"*, *"launch the three highest-priority specs and tell me when they finish"*. It carries out the work by calling Specrails' own tools — the same ones the [MCP server](./5-mcp-server.md) exposes — while you watch the dashboard update live behind it.
 
 > **Not to be confused with the pipeline agents.** The *Agents* section (Architect → Developer → Reviewer) is about *how a rail implements a spec*. The **Agent Chat** is a single assistant that *operates the app itself*. Different thing, same word.
 
@@ -33,6 +33,8 @@ The agent can touch the whole app, so you decide how much freedom it has with a
 
 Start on **Observe** and raise the level only when you want the agent to act. If it tries something above the current level it stops and tells you exactly which level to switch on — it never works around the limit. This is separate from the Settings ▸ MCP tiers, which govern *external* assistants; the level here is just for this in-app agent.
 
+Raising the level **to Autonomous** never happens on a keystroke alone: Shift+Tab from Operate shows a notice with **Switch to Autonomous**, and pressing Shift+Tab again instead skips back to Observe. Lowering the level is always immediate.
+
 ## A few things you can ask
 
 Once you're on **Operate**, try:
@@ -47,15 +49,20 @@ Once you're on **Operate**, try:
 
 Replies stream in smoothly and land formatted (headings, tables, lists), each with a small **copy** button. A status chip at the bottom shows what the agent is doing right now — *Thinking…*, *MCP · jobs*, *Terminal* — so you always know its state.
 
+Code blocks show their language and have their own **copy** button. If you scroll up while the agent is still writing, a **New messages** pill appears above the box — click it to jump back to the latest reply.
+
 ## Handy touches
 
 - **Click what it mentions.** In a project-pinned mission, spec numbers (`#12`) and job/run ids in the agent's replies are clickable chips — a spec opens the board's detail modal, a job id opens the live job view. If the reference no longer exists you get a quiet "not found" note.
-- **The implementation card stays in sight.** When the agent implements specs, a live card tracks the work — and while it needs something from you (create the PR, publish it, retry, discard) it stays **pinned just above the message box**, however far the conversation scrolls; its place in the history shows a slim "pinned above" marker instead. Several active cards stack as small chips (click one to bring it forward), and a chevron minimizes the card to a slim bar. Once the PR is published — or the work is merged or discarded — the card settles back into the conversation history.
+- **One strip for your runs.** When the agent launches work, a single strip just above the message box follows it: what the run is doing in plain words ("Writing the spec from your changes"), how many runs finished, the time and the real cost so far (`—` until the provider bills it). When a run needs you — create the PR, retry, go back to Flow — the strip says so with an icon and words and offers that one action; click the strip to open the run's full card just above it (Esc closes it). With several runs, the strip shows the one that needs you first and a small switcher ("Rail 1 · Rail 2 · +1"). The conversation keeps only what happened — "Launched on Rail 1", "Rail 1 failed: …", "Delivered: PR #812" — and each line opens its run. Missions waiting for your decision show a dot in the mission list. Actions that start a new paid run (**Relaunch**, **Recover & retry**) or that other people see (Create PR, Publish) never fire from the strip: it opens the card with the focus on that button, so you confirm there.
+- **The strip from the keyboard.** **⌥R** (**Alt+R** on Windows/Linux) jumps from the message box to the strip of the mission you are in; press it again to show or hide the run's details, and **Esc** takes you back to where you were. Outside a text field, **⌥[** and **⌥]** switch between runs. While the strip has focus, **P** pauses or resumes a Flow and **H** hands it off; these letters never act from anywhere else. Press **?** for the full list.
 - **Prompt history.** With the box empty, press **↑**/**↓** to browse what you asked before (shown dimmed while you scroll); start typing to edit it, or hit Enter to send.
 - **Edit the queue.** Sent more while the agent was busy? While messages are queued, **↑**/**↓** moves through *them* instead — the box shows the selected one, you edit it in place, and **Enter saves it back to the queue** (Esc cancels; your unsent draft comes right back).
+- **Answer with a key.** When the agent offers choices, each chip carries a number: press **⌥1**…**⌥9** (**Alt+1**…**Alt+9** on Windows/Linux) with the box empty to pick one.
+- **Undo a deleted queued message.** Deleting a queued message shows **Undo** for a few seconds; it puts the message back in the queue.
 - **Minimize, don't lose.** Click the ✕ to drop the panel back to the bubble — the conversation keeps running. Reopen and you land at the latest message; nothing is re-typed.
 - **New conversation.** The **+** button starts a clean thread; the history lives app-wide, above any single project.
-- **Switch missions.** The mission selector next to the project picker lists your conversations newest-first — a pulsing dot marks the ones where the agent is still working, and a small badge counts queued messages. Search appears when the list grows past eight, and the trash icon on each row deletes a mission after a quick inline confirm — even a running one (it warns first, then stops the agent).
+- **Switch missions.** The mission selector next to the project picker lists your conversations newest-first — a pulsing dot marks the ones where the agent is still working, and a small badge counts queued messages. Search appears when the list grows past eight, and the trash icon on each row deletes a mission at once and shows **Undo** (or press **⌘Z**) for a few seconds; the mission then waits in **Recently deleted** in the project settings for 30 days. A mission where the agent is still working asks first, because stopping the agent can't be undone.
 - **Find a mission from anywhere.** Press **⌘K** (or the sidebar **Search** button in Agent Mode) and type any fragment you remember — a word from the title *or* from what was said inside. Missions match instantly by title from memory, and a heartbeat later the matches by content arrive with the matching passage highlighted, plus the pinned project and when it was last active. In Agent Mode missions are the first group; on the board they sit right after Projects. Enter opens the mission.
 
 ## Rail launch cards and run cards
@@ -68,9 +75,9 @@ Replies stream in smoothly and land formatted (headings, tables, lists), each wi
 
 ## Sub-agents
 
-Some providers can hand parts of a task to **sub-agents** — helpers that work in parallel and keep going after the agent replies. Sub-agents are **off by default**: they multiply what one request costs.
+Some providers can hand parts of a task to **sub-agents** — helpers that work in parallel and keep going after the agent replies. Sub-agents are **on by default**; turn them off per project if you want to keep each request's cost down, since they multiply what one request costs.
 
-- **Turn them on per project.** Open the project's **Settings → Sub-agents** and switch on **Allow sub-agents in this project**. It covers that project's missions, explore and refinements; Implement pipelines are never affected. Missions without a project follow **App settings → AI providers → Allow sub-agents in missions without a project**.
+- **Turn them off per project.** Open the project's **Settings → Sub-agents** and switch off **Allow sub-agents in this project**. It covers that project's missions, explore and refinements; Implement pipelines are never affected. Missions without a project follow **App settings → AI providers → Allow sub-agents in missions without a project**.
 - **Choose who runs them.** Under **Run sub-agents with**, the default **Same as the mission agent** lets the mission's own CLI launch them natively: fastest, and they share its prompt cache. Pick a provider, model and effort instead to mix providers — for example a Codex mission with Claude sub-agents. Missions already on that provider stay native with that model; on another provider Specrails launches each sub-agent itself, which starts colder and can cost more, but gives you more control and shows each one's real cost. Specrails asks you to confirm before switching, and those sub-agents carry a provider badge in the mission.
 - **Watch them work.** The agents a reply launched appear as one compact line under that reply. It stays open while they work, and once they all finish it folds into a summary with the total time and tokens. Expand a row to read its result and what it cost, or to follow its activity live. Each launch stays at its point in the conversation, so later launches never mix with earlier ones. Stop a running agent from its row, or stop them all from the line.
 - **The agent follows up on its own.** When background agents finish, the agent continues and posts what they found, marked *Continued after background agents*.