specrails-desktop 2.59.3 → 2.61.0

package/client/dist/index.html

@@ -204,7 +204,7 @@
         .specrails-splash__mark .pill { opacity: 1; }
       }
     </style>
-    <script type="module" crossorigin src="/assets/index-DVkWHOR3.js"></script>
+    <script type="module" crossorigin src="/assets/index-lTGJJTuk.js"></script>
     <link rel="modulepreload" crossorigin href="/assets/rolldown-runtime-CNC7AqOf.js">
     <link rel="modulepreload" crossorigin href="/assets/jsx-runtime-zu2_FqZY.js">
     <link rel="modulepreload" crossorigin href="/assets/react-dom-DiWzBDP9.js">
@@ -214,9 +214,9 @@
     <link rel="modulepreload" crossorigin href="/assets/activity-DiyjsgQV.js">
     <link rel="modulepreload" crossorigin href="/assets/addspec-BOvgmcgk.js">
     <link rel="modulepreload" crossorigin href="/assets/agent-Z5s_GTP0.js">
-    <link rel="modulepreload" crossorigin href="/assets/agentRuntime-Bpx3yWHK.js">
-    <link rel="modulepreload" crossorigin href="/assets/agents-CTwbx-fb.js">
-    <link rel="modulepreload" crossorigin href="/assets/agentstudio-BWAKeGgB.js">
+    <link rel="modulepreload" crossorigin href="/assets/agentRuntime-C_yLPKDy.js">
+    <link rel="modulepreload" crossorigin href="/assets/agents-Doe1sHY5.js">
+    <link rel="modulepreload" crossorigin href="/assets/agentstudio-BzugqB_N.js">
     <link rel="modulepreload" crossorigin href="/assets/aiedit-iIjz2_Qk.js">
     <link rel="modulepreload" crossorigin href="/assets/analytics-BWynXPEm.js">
     <link rel="modulepreload" crossorigin href="/assets/attachments-B53PG733.js">
@@ -231,9 +231,9 @@
     <link rel="modulepreload" crossorigin href="/assets/integrations-Dwl9KQp0.js">
     <link rel="modulepreload" crossorigin href="/assets/jira-FXr7u2lh.js">
     <link rel="modulepreload" crossorigin href="/assets/jobs-De3EqaO0.js">
-    <link rel="modulepreload" crossorigin href="/assets/loops--KWr0X-w.js">
+    <link rel="modulepreload" crossorigin href="/assets/loops-WyWDkhok.js">
     <link rel="modulepreload" crossorigin href="/assets/mcp-CUAN6ORK.js">
-    <link rel="modulepreload" crossorigin href="/assets/narration-n3hOA7LY.js">
+    <link rel="modulepreload" crossorigin href="/assets/narration-DbHnz0qV.js">
     <link rel="modulepreload" crossorigin href="/assets/nav--u7iPYlS.js">
     <link rel="modulepreload" crossorigin href="/assets/packet-B0H15elv.js">
     <link rel="modulepreload" crossorigin href="/assets/settings-Dbyd6gmj.js">
@@ -243,15 +243,15 @@
     <link rel="modulepreload" crossorigin href="/assets/terminal-BAzpHtpY.js">
     <link rel="modulepreload" crossorigin href="/assets/tickets-D41ZMQpf.js">
     <link rel="modulepreload" crossorigin href="/assets/createLucideIcon-Bjbbp_KS.js">
-    <link rel="modulepreload" crossorigin href="/assets/useSharedWebSocket-g0nTHfTT.js">
-    <link rel="modulepreload" crossorigin href="/assets/Trans-Br_OIUKP.js">
-    <link rel="modulepreload" crossorigin href="/assets/useDesktop-ChSmmJfc.js">
+    <link rel="modulepreload" crossorigin href="/assets/useSharedWebSocket-DaWuiO0S.js">
+    <link rel="modulepreload" crossorigin href="/assets/Trans-D5eOjfvG.js">
+    <link rel="modulepreload" crossorigin href="/assets/useDesktop-DKNbOF0u.js">
     <link rel="modulepreload" crossorigin href="/assets/provider-capabilities-lePfeT_Y.js">
     <link rel="modulepreload" crossorigin href="/assets/save-OsUqVn99.js">
-    <link rel="modulepreload" crossorigin href="/assets/spending-EXaboRU0.js">
+    <link rel="modulepreload" crossorigin href="/assets/spending-DQDNtM8q.js">
     <link rel="modulepreload" crossorigin href="/assets/sparkles-DrY8hb0X.js">
     <link rel="modulepreload" crossorigin href="/assets/x-CBMI9ejn.js">
-    <link rel="modulepreload" crossorigin href="/assets/MinimizedChatsContext-Bc9xHByW.js">
+    <link rel="modulepreload" crossorigin href="/assets/MinimizedChatsContext-CroAs6Kh.js">
     <link rel="modulepreload" crossorigin href="/assets/zap-CUOlvtT1.js">
     <link rel="modulepreload" crossorigin href="/assets/file-text-BcLCfcWZ.js">
     <link rel="modulepreload" crossorigin href="/assets/circle-x-CMYsN4ZH.js">
@@ -266,20 +266,20 @@
     <link rel="modulepreload" crossorigin href="/assets/search-Cq_gE3Ik.js">
     <link rel="modulepreload" crossorigin href="/assets/trash-2-BOU3WdZZ.js">
     <link rel="modulepreload" crossorigin href="/assets/triangle-alert-H9T4jAmh.js">
-    <link rel="modulepreload" crossorigin href="/assets/jira-api-C2Tzc362.js">
+    <link rel="modulepreload" crossorigin href="/assets/jira-api-Bp0zXwjg.js">
     <link rel="modulepreload" crossorigin href="/assets/clsx-CjueKrWZ.js">
     <link rel="modulepreload" crossorigin href="/assets/utils-BC4DHlz2.js">
     <link rel="modulepreload" crossorigin href="/assets/dialog-CMgps2MY.js">
     <link rel="modulepreload" crossorigin href="/assets/lib-CGdyxIWg.js">
-    <link rel="modulepreload" crossorigin href="/assets/getTimezoneOffsetInMilliseconds-Bq0CXBaJ.js">
-    <link rel="modulepreload" crossorigin href="/assets/formatDistanceToNow-Q7QPRFV4.js">
+    <link rel="modulepreload" crossorigin href="/assets/getTimezoneOffsetInMilliseconds-9JiGlFrx.js">
+    <link rel="modulepreload" crossorigin href="/assets/formatDistanceToNow-DZ3VWsHq.js">
     <link rel="modulepreload" crossorigin href="/assets/button-D1xExSTF.js">
-    <link rel="modulepreload" crossorigin href="/assets/project-repositories-DZKmieH3.js">
-    <link rel="modulepreload" crossorigin href="/assets/RepositoryScopeSelector-D3PlHIM-.js">
-    <link rel="modulepreload" crossorigin href="/assets/TicketDetailModalContext-gGUv7gsQ.js">
+    <link rel="modulepreload" crossorigin href="/assets/project-repositories-CadLZOnr.js">
+    <link rel="modulepreload" crossorigin href="/assets/RepositoryScopeSelector-CeCr6Jz-.js">
+    <link rel="modulepreload" crossorigin href="/assets/TicketDetailModalContext-YBJX3RmP.js">
     <link rel="modulepreload" crossorigin href="/assets/core-B3mKBIh5.js">
-    <link rel="modulepreload" crossorigin href="/assets/RepositoryDeliveries-DIWDFLRM.js">
-    <link rel="modulepreload" crossorigin href="/assets/useRuntimeRuns-w9-5OzZl.js">
+    <link rel="modulepreload" crossorigin href="/assets/RepositoryDeliveries-DJCm1pZr.js">
+    <link rel="modulepreload" crossorigin href="/assets/useRuntimeRuns-D3YMw9qx.js">
     <link rel="modulepreload" crossorigin href="/assets/event-Bt7f3wXe.js">
     <link rel="stylesheet" crossorigin href="/assets/index-Bfunvi6w.css">
   </head>

package/docs/getting-started.md

@@ -51,9 +51,9 @@ specrails-desktop list   # verify
 
 The setup wizard runs automatically. Three steps:
 
-1. **Configure** — choose which agents to install (the baseline trio `sr-architect`, `sr-developer`, `sr-reviewer` is always selected; optional agents like Test Writer or Security Reviewer are opt-in). Pick a model preset (Balanced / Budget / Max) and optionally override the model per agent.
+1. **Configure** — pick a model preset (Balanced / Budget / Max) and optionally override the model per agent. There are no role files to choose or install: the three pipeline roles (`sr-architect`, `sr-developer`, `sr-reviewer`) are defined by the Core engine's runtime, and their definitions, provider and model live in **Settings → Agent runtime**.
 2. **Install** — the app runs the installer (`npx --yes --prefer-online specrails-core@^5.1.0 init --yes --from-config <config>`) non-interactively and streams the output live. The version is pinned to the core release the app ships with — it never silently jumps to a new major.
-3. **Done** — a summary tells you how many agents and commands landed. Click **Continue to project**.
+3. **Done** — a summary tells you how many commands landed; its **Agents** tile counts only the project's custom roles (`custom-*`), because the baseline roles are not installed as files. Click **Continue to project**.
 
 That's the whole onboarding. No tier picker, no second wizard. You can manage agents and their per-agent models later from the **Agents** page (Profiles tab).
 

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

@@ -28,7 +28,7 @@ Innerhalb eines Durchlaufs wird Arbeit *geroutet*. Eine Aufgabe trägt Tags, und
 
 ## Eine wichtige Idee vorab
 
-Die *Definition* jedes Agents – seine Anweisungen, seine Persönlichkeit, was er darf – ist **geteilt**. Sie lebt als Datei (`.claude/agents/<id>.md`), die mit deinem Repository mitreist, sodass dein ganzes Team denselben Architekten und denselben Reviewer nutzt.
+Die *Definition* jedes Basis-Agents – seine Anweisungen, seine Persönlichkeit, was er darf – kommt aus der **Laufzeit** der Core-Engine, nicht aus einer Datei in deinem Repository. Es gibt nichts zu installieren und nichts synchron zu halten: Du liest die Definition jeder Rolle im Agents-Katalog und passt sie für alle Projekte unter **Einstellungen → Agenten-Laufzeit** an. Custom-Agents sind die Ausnahme – sie leben als Dateien (`.claude/agents/custom-*.md`), die mit deinem Repository mitreisen, sodass dein ganzes Team dieselben nutzt.
 
 Was **pro Projekt** gilt, ist die *Konfiguration* darüber: mit welchem Modell jeder Agent läuft und welche Kombination von Agents du für eine bestimmte Rail wählst. Genau dafür sind Profile da – und das ist die nächste Seite.
 

package/docs/guide/de/agents/2-profiles-and-the-balanced-default.md

@@ -12,7 +12,7 @@ Du findest Profile im Bereich **Agents** jedes Projekts (rechte Seitenleiste →
 
 Von Haus aus löst ein Projekt auf ein sinnvolles **default**-Profil auf. Es enthält das Basis-Trio – `sr-architect`, `sr-developer`, `sr-reviewer` – und routet über eine einzige Auffangregel jede Aufgabe an den Developer. Die Modelle sind für den Alltag ausgewogen: ein leistungsfähiges Modell dort, wo es zählt, ohne bei jedem Schritt zur teuersten Option zu greifen.
 
-Falls dein Projekt die Agent-Modelle bereits auf die alte Weise konfiguriert hatte (in der Frontmatter der Agent-Dateien), liest der **Migrieren**-Button diese aus und baut ein `default`-Profil, das das heutige Verhalten exakt abbildet – verlustfrei, nichts ändert sich, bis du dich entscheidest, daran zu drehen.
+Der Button **Aus aktuellen Agents migrieren** baut ein `default`-Profil aus dem Basis-Trio und den Custom-Agents, die das Projekt bereits hat – es bildet das heutige Verhalten exakt ab und braucht keine einzige Rollendatei. Trägt eine ältere Installation noch Agent-Dateien mit Modellen in der Frontmatter, bleiben diese Modelle erhalten; nichts ändert sich, bis du dich entscheidest, daran zu drehen.
 
 Die Kernaussage: **Du musst kein Profil erstellen, um Specrails zu nutzen.** Der Standard funktioniert einfach. Profile sind der Weg, weiterzugehen.
 

package/docs/guide/de/agents/3-customizing-models-per-agent.md

@@ -15,7 +15,7 @@ Wähle unter **Agents → Profile** ein Profil aus und öffne seinen Agent-Kette
 
 Die Modellwerte sind Aliasse – für Claude sind das `opus`, `sonnet` und `haiku` (am leistungsfähigsten → am schnellsten). Setze pro Agent den gewünschten Alias:
 
-- Lass das Modell eines Agents **leer**, um auf den Standard der Agent-Datei zurückzufallen.
+- Lass das Modell eines Agents **leer**, um auf den eigenen Standard der Rolle zurückzufallen – beim Basis-Trio sind das Provider und Modell aus **Einstellungen → Agenten-Laufzeit**; ein Custom-Agent fällt auf die Frontmatter seiner Datei zurück.
 - Setze es ausdrücklich, um es nur für dieses Profil zu überschreiben.
 
 Speichere, und die nächste mit diesem Profil gestartete Rail nutzt die neuen Modelle. Bereits laufende Jobs behalten ihren Snapshot.

package/docs/guide/de/agents/4-custom-agents-catalog.md

@@ -4,16 +4,16 @@ Profile entscheiden, *welche Agents mit welchen Modellen laufen*. Doch woher kom
 
 Öffne in einem beliebigen Projekt **Agents → Katalog**. Es ist eine schreibgeschützte Ansicht jedes Agents, der diesem Projekt zur Verfügung steht, in zwei Gruppen:
 
-- **Upstream-Agents** – die Agents, die mit `specrails-core` ausgeliefert werden: das Basis-Trio (`sr-architect`, `sr-developer`, `sr-reviewer`) und etwaige Spezialisten wie `sr-merge-resolver`.
+- **Upstream-Agents** – die Rollen, die die Core-Engine zur Laufzeit definiert: das Basis-Trio (`sr-architect`, `sr-developer`, `sr-reviewer`). Sie sind keine Dateien in deinem Repo; der Katalog zeigt die live geltende Definition jeder Rolle schreibgeschützt an, bearbeiten kannst du sie unter **Einstellungen → Agenten-Laufzeit**.
 - **Custom-Agents** – Agents, die du selbst hinzugefügt hast, benannt als `custom-*`.
 
-Jeder Katalogeintrag zeigt, wofür der Agent da ist und welches Standardmodell er nutzt, sodass du die vollständige Aufstellung sehen kannst, bevor du Agents in eine Profil-Kette einbindest.
+Jeder Katalogeintrag zeigt, wofür der Agent da ist; Custom-Agents zeigen zusätzlich ihr Standardmodell, während die Basis-Rollen mit Provider und Modell aus **Einstellungen → Agenten-Laufzeit** laufen. So siehst du in jedem Fall die vollständige Aufstellung, bevor du Agents in eine Profil-Kette einbindest.
 
 ## Einen Custom-Agent hinzufügen
 
 Weil sie in deinem Repo leben, sind Custom-Agents **committfähige Team-Assets**: Committe die Datei, und dein ganzes Team bekommt den Agent. Das spiegelt die Kernidee, die sich durch den gesamten Agents-Bereich zieht –
 
-> **Agent-Definitionen sind geteilt (sie leben im Repo und reisen mit `git` mit). Die Modellkonfiguration ist projektbezogen (sie lebt in Profilen).**
+> **Custom-Agent-Definitionen sind geteilt (sie leben im Repo und reisen mit `git` mit); die Basis-Rollen definiert die Core-Laufzeit. Die Modellkonfiguration ist projektbezogen (sie lebt in Profilen).**
 
 ## Einen Custom-Agent einsetzen
 

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

@@ -28,7 +28,7 @@ Within a run, work is *routed*. A task carries tags, and a profile's routing rul
 
 ## One important idea, up front
 
-The *definition* of each agent — its instructions, its personality, what it's allowed to do — is **shared**. These live as files (`.claude/agents/<id>.md`) that travel with your repository, so your whole team runs the same architect, the same reviewer.
+The *definition* of each baseline agent — its instructions, its personality, what it's allowed to do — comes from the Core engine's **runtime**, not from a file in your repository. There's nothing to install and nothing to keep in sync: read each role's definition in the Agents catalog and tune it for every project in **Settings → Agent runtime**. Custom agents are the exception — they live as files (`.claude/agents/custom-*.md`) that travel with your repository, so your whole team runs the same ones.
 
 What's **per-project** is the *configuration* on top: which model each agent runs with, and which combination of agents you pick for a given rail. That's what profiles are for — and that's the next page.
 

package/docs/guide/en/agents/2-profiles-and-the-balanced-default.md

@@ -12,7 +12,7 @@ You'll find profiles in the **Agents** section of any project (right sidebar →
 
 Out of the box, a project resolves to a sensible **default** profile. It includes the baseline trio — `sr-architect`, `sr-developer`, `sr-reviewer` — and routes every task to the developer through a single catch-all rule. The models are balanced for everyday work: a capable model where it matters, without reaching for the most expensive option on every step.
 
-If your project already had agent models configured the old way (in the agent files' frontmatter), the **Migrate** button reads those and builds a `default` profile that mirrors today's behaviour exactly — zero loss, nothing changes until you decide to tune it.
+The **Migrate from current agents** button builds a `default` profile from the baseline trio and whatever custom agents the project already has — it mirrors today's behaviour exactly and needs no role file to exist. If an older install still carries agent files with models in their frontmatter, those models are kept; nothing changes until you decide to tune it.
 
 The headline: **you don't have to create a profile to use Specrails.** The default just works. Profiles are how you go further.
 

package/docs/guide/en/agents/3-customizing-models-per-agent.md

@@ -15,7 +15,7 @@ In **Agents → Profiles**, select a profile and open its agent chain editor. Ea
 
 The model values are aliases — for Claude that's `opus`, `sonnet`, and `haiku` (most capable → fastest). Set the alias you want per agent:
 
-- Leave an agent's model **blank** to fall back to the agent file's own default.
+- Leave an agent's model **blank** to fall back to the role's own default — for the baseline trio that's the provider and model set in **Settings → Agent runtime**; a custom agent falls back to its file's frontmatter.
 - Set it explicitly to override just for this profile.
 
 Save, and the next rail launched with that profile uses the new models. Jobs already running keep their snapshot.

package/docs/guide/en/agents/4-custom-agents-catalog.md

@@ -4,16 +4,16 @@ Profiles decide *which agents run and with what models*. But where do the agents
 
 Open **Agents → Catalog** in any project. It's a read-only viewer of every agent available to that project, in two groups:
 
-- **Upstream agents** — the agents that ship with `specrails-core`: the baseline trio (`sr-architect`, `sr-developer`, `sr-reviewer`) and any specialists like `sr-merge-resolver`.
+- **Upstream agents** — the roles the Core engine defines at runtime: the baseline trio (`sr-architect`, `sr-developer`, `sr-reviewer`). They're not files in your repo; the catalog shows each role's live definition read-only, and you edit it in **Settings → Agent runtime**.
 - **Custom agents** — agents you've added yourself, named `custom-*`.
 
-Each catalog entry shows what the agent is for and its default model, so you can see the full roster before wiring agents into a profile chain.
+Each catalog entry shows what the agent is for; custom agents also show their default model, while the baseline roles run with the provider and model set in **Settings → Agent runtime**. Either way you can see the full roster before wiring agents into a profile chain.
 
 ## Adding a custom agent
 
 Because they live in your repo, custom agents are **committable team assets**: commit the file and your whole team gets the agent. This mirrors the core idea throughout the Agents section —
 
-> **Agent definitions are shared (they live in the repo and travel with `git`). Model configuration is per-project (it lives in profiles).**
+> **Custom agent definitions are shared (they live in the repo and travel with `git`); the baseline roles are defined by the Core runtime. Model configuration is per-project (it lives in profiles).**
 
 ## Putting a custom agent to work
 

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

@@ -28,7 +28,7 @@ Dentro de una ejecución, el trabajo se *enruta*. Cada tarea lleva etiquetas, y
 
 ## Una idea importante, de entrada
 
-La *definición* de cada agente — sus instrucciones, su personalidad, lo que tiene permitido hacer — es **compartida**. Vive en archivos (`.claude/agents/<id>.md`) que viajan con tu repositorio, así que todo tu equipo ejecuta el mismo architect, el mismo reviewer.
+La *definición* de cada agente base — sus instrucciones, su personalidad, lo que tiene permitido hacer — viene del **runtime** del motor Core, no de un archivo en tu repositorio. No hay nada que instalar ni que mantener sincronizado: lee la definición de cada rol en el catálogo de Agentes y ajústala para todos los proyectos en **Ajustes → Motor de agentes**. Los agentes personalizados son la excepción: viven en archivos (`.claude/agents/custom-*.md`) que viajan con tu repositorio, así que todo tu equipo ejecuta los mismos.
 
 Lo que es **por proyecto** es la *configuración* que se monta encima: con qué modelo corre cada agente y qué combinación de agentes eliges para un rail concreto. Para eso están los perfiles — y de eso trata la siguiente página.
 

package/docs/guide/es/agents/2-profiles-and-the-balanced-default.md

@@ -12,7 +12,7 @@ Encontrarás los perfiles en la sección **Agentes** de cualquier proyecto (barr
 
 Desde el primer momento, un proyecto resuelve hacia un perfil **default** sensato. Incluye el trío base — `sr-architect`, `sr-developer`, `sr-reviewer` — y enruta cada tarea al developer mediante una única regla comodín. Los modelos están equilibrados para el trabajo del día a día: un modelo capaz donde importa, sin tirar de la opción más cara en cada paso.
 
-Si tu proyecto ya tenía los modelos de los agentes configurados a la antigua usanza (en el frontmatter de los archivos de agente), el botón **Migrar** los lee y construye un perfil `default` que replica el comportamiento actual exactamente — sin pérdidas, nada cambia hasta que tú decidas ajustarlo.
+El botón **Migrar desde los agentes actuales** construye un perfil `default` a partir del trío base y de los agentes personalizados que el proyecto ya tenga — replica el comportamiento actual exactamente y no necesita que exista ningún archivo de rol. Si una instalación antigua aún conserva archivos de agente con modelos en su frontmatter, esos modelos se mantienen; nada cambia hasta que tú decidas ajustarlo.
 
 El titular: **no necesitas crear un perfil para usar Specrails.** El default simplemente funciona. Los perfiles son la forma de llegar más lejos.
 

package/docs/guide/es/agents/3-customizing-models-per-agent.md

@@ -15,7 +15,7 @@ En **Agentes → Perfiles**, selecciona un perfil y abre su editor de cadena de
 
 Los valores de modelo son alias — para Claude son `opus`, `sonnet` y `haiku` (de más capaz → más rápido). Asigna el alias que quieras por agente:
 
-- Deja el modelo de un agente **en blanco** para que recurra al default propio del archivo del agente.
+- Deja el modelo de un agente **en blanco** para que recurra al default propio del rol — en el trío base son el proveedor y el modelo configurados en **Ajustes → Motor de agentes**; un agente personalizado recurre al frontmatter de su archivo.
 - Asígnalo explícitamente para sobrescribirlo solo en este perfil.
 
 Guarda, y el próximo rail lanzado con ese perfil usará los nuevos modelos. Los jobs que ya están en marcha conservan su snapshot.

package/docs/guide/es/agents/4-custom-agents-catalog.md

@@ -4,16 +4,16 @@ Los perfiles deciden *qué agentes corren y con qué modelos*. Pero ¿de dónde
 
 Abre **Agentes → Catálogo** en cualquier proyecto. Es un visor de solo lectura de todos los agentes disponibles para ese proyecto, en dos grupos:
 
-- **Agentes upstream** — los agentes que vienen con `specrails-core`: el trío base (`sr-architect`, `sr-developer`, `sr-reviewer`) y cualquier especialista como `sr-merge-resolver`.
+- **Agentes upstream** — los roles que el motor Core define en tiempo de ejecución: el trío base (`sr-architect`, `sr-developer`, `sr-reviewer`). No son archivos de tu repo; el catálogo muestra la definición viva de cada rol en modo solo lectura, y la editas en **Ajustes → Motor de agentes**.
 - **Agentes personalizados** — agentes que has añadido tú, con el nombre `custom-*`.
 
-Cada entrada del catálogo muestra para qué sirve el agente y su modelo por defecto, así que puedes ver la plantilla completa antes de conectar agentes a la cadena de un perfil.
+Cada entrada del catálogo muestra para qué sirve el agente; los agentes personalizados muestran además su modelo por defecto, mientras que los roles base se ejecutan con el proveedor y el modelo configurados en **Ajustes → Motor de agentes**. En cualquier caso puedes ver la plantilla completa antes de conectar agentes a la cadena de un perfil.
 
 ## Añadir un agente personalizado
 
 Como viven en tu repo, los agentes personalizados son **activos de equipo commiteables**: commitea el archivo y todo tu equipo recibe el agente. Esto refleja la idea central de toda la sección Agentes —
 
-> **Las definiciones de los agentes son compartidas (viven en el repo y viajan con `git`). La configuración de modelos es por proyecto (vive en los perfiles).**
+> **Las definiciones de los agentes personalizados son compartidas (viven en el repo y viajan con `git`); los roles base los define el runtime de Core. La configuración de modelos es por proyecto (vive en los perfiles).**
 
 ## Poner a trabajar un agente personalizado
 

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

@@ -28,7 +28,7 @@ Au sein d'une exécution, le travail est *routé*. Une tâche porte des tags, et
 
 ## Une idée importante, dès le départ
 
-La *définition* de chaque agent — ses instructions, sa personnalité, ce qu'il a le droit de faire — est **partagée**. Elle vit dans des fichiers (`.claude/agents/<id>.md`) qui voyagent avec votre dépôt, si bien que toute votre équipe fait tourner le même architecte, le même relecteur.
+La *définition* de chaque agent de base — ses instructions, sa personnalité, ce qu'il a le droit de faire — vient du **runtime** du moteur Core, pas d'un fichier dans votre dépôt. Il n'y a rien à installer ni à garder synchronisé : lisez la définition de chaque rôle dans le catalogue des Agents et ajustez-la pour tous les projets dans **Paramètres → Moteur d’agents**. Les agents personnalisés sont l'exception : ils vivent dans des fichiers (`.claude/agents/custom-*.md`) qui voyagent avec votre dépôt, si bien que toute votre équipe fait tourner les mêmes.
 
 Ce qui est **propre à chaque projet**, c'est la *configuration* qui se superpose : quel modèle chaque agent utilise, et quelle combinaison d'agents vous choisissez pour un rail donné. C'est précisément à cela que servent les profils — et c'est l'objet de la page suivante.
 

package/docs/guide/fr/agents/2-profiles-and-the-balanced-default.md

@@ -12,7 +12,7 @@ Vous trouverez les profils dans la section **Agents** de n'importe quel projet (
 
 Par défaut, un projet se rabat sur un profil **default** sensé. Il inclut le trio de base — `sr-architect`, `sr-developer`, `sr-reviewer` — et route chaque tâche vers le développeur via une unique règle fourre-tout. Les modèles sont équilibrés pour le travail quotidien : un modèle compétent là où ça compte, sans dégainer l'option la plus chère à chaque étape.
 
-Si votre projet avait déjà des modèles d'agents configurés à l'ancienne (dans le frontmatter des fichiers d'agents), le bouton **Migrer** les lit et construit un profil `default` qui reproduit exactement le comportement actuel — aucune perte, rien ne change tant que vous ne décidez pas de l'ajuster.
+Le bouton **Migrer depuis les agents actuels** construit un profil `default` à partir du trio de base et des agents personnalisés que le projet possède déjà — il reproduit exactement le comportement actuel et n'a besoin d'aucun fichier de rôle. Si une installation plus ancienne contient encore des fichiers d'agents avec des modèles dans leur frontmatter, ces modèles sont conservés ; rien ne change tant que vous ne décidez pas de l'ajuster.
 
 L'essentiel à retenir : **vous n'avez pas besoin de créer un profil pour utiliser Specrails.** Le défaut fait simplement le travail. Les profils, c'est la manière d'aller plus loin.
 

package/docs/guide/fr/agents/3-customizing-models-per-agent.md

@@ -15,7 +15,7 @@ Dans **Agents → Profils**, sélectionnez un profil et ouvrez son éditeur de c
 
 Les valeurs de modèle sont des alias — pour Claude, ce sont `opus`, `sonnet` et `haiku` (du plus capable au plus rapide). Définissez l'alias souhaité par agent :
 
-- Laissez le modèle d'un agent **vide** pour revenir au défaut propre au fichier de l'agent.
+- Laissez le modèle d'un agent **vide** pour revenir au défaut propre au rôle — pour le trio de base, ce sont le fournisseur et le modèle définis dans **Paramètres → Moteur d’agents** ; un agent personnalisé revient au frontmatter de son fichier.
 - Définissez-le explicitement pour le surcharger uniquement pour ce profil.
 
 Enregistrez, et le prochain rail lancé avec ce profil utilisera les nouveaux modèles. Les jobs déjà en cours conservent leur snapshot.

package/docs/guide/fr/agents/4-custom-agents-catalog.md

@@ -4,16 +4,16 @@ Les profils décident *quels agents s'exécutent et avec quels modèles*. Mais d
 
 Ouvrez **Agents → Catalogue** dans n'importe quel projet. C'est un visualiseur en lecture seule de tous les agents disponibles pour ce projet, répartis en deux groupes :
 
-- **Agents upstream** — les agents fournis avec `specrails-core` : le trio de base (`sr-architect`, `sr-developer`, `sr-reviewer`) et d'éventuels spécialistes comme `sr-merge-resolver`.
+- **Agents upstream** — les rôles que le moteur Core définit à l'exécution : le trio de base (`sr-architect`, `sr-developer`, `sr-reviewer`). Ce ne sont pas des fichiers de votre dépôt ; le catalogue affiche la définition en vigueur de chaque rôle en lecture seule, et vous la modifiez dans **Paramètres → Moteur d’agents**.
 - **Agents personnalisés** — les agents que vous avez ajoutés vous-même, nommés `custom-*`.
 
-Chaque entrée du catalogue indique à quoi sert l'agent et son modèle par défaut, ce qui vous permet de voir l'effectif complet avant de câbler des agents dans la chaîne d'un profil.
+Chaque entrée du catalogue indique à quoi sert l'agent ; les agents personnalisés affichent aussi leur modèle par défaut, tandis que les rôles de base tournent avec le fournisseur et le modèle définis dans **Paramètres → Moteur d’agents**. Dans tous les cas, vous voyez l'effectif complet avant de câbler des agents dans la chaîne d'un profil.
 
 ## Ajouter un agent personnalisé
 
 Parce qu'ils vivent dans votre dépôt, les agents personnalisés sont des **ressources d'équipe commitables** : commitez le fichier et toute votre équipe récupère l'agent. Cela reflète l'idée centrale qui traverse toute la section Agents —
 
-> **Les définitions d'agents sont partagées (elles vivent dans le dépôt et voyagent avec `git`). La configuration des modèles est propre au projet (elle vit dans les profils).**
+> **Les définitions des agents personnalisés sont partagées (elles vivent dans le dépôt et voyagent avec `git`) ; les rôles de base sont définis par le runtime de Core. La configuration des modèles est propre au projet (elle vit dans les profils).**
 
 ## Mettre un agent personnalisé au travail
 

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

@@ -28,7 +28,7 @@ All'interno di un'esecuzione, il lavoro viene *instradato*. Un task porta con s
 
 ## Un'idea importante, da subito
 
-La *definizione* di ciascun agente — le sue istruzioni, la sua personalità, ciò che gli è consentito fare — è **condivisa**. Queste definizioni vivono come file (`.claude/agents/<id>.md`) che viaggiano insieme al tuo repository, così tutta la tua squadra usa lo stesso architect, lo stesso reviewer.
+La *definizione* di ciascun agente di base — le sue istruzioni, la sua personalità, ciò che gli è consentito fare — arriva dal **runtime** dell'engine Core, non da un file nel tuo repository. Non c'è nulla da installare né da tenere sincronizzato: leggi la definizione di ogni ruolo nel catalogo degli Agenti e la regoli per tutti i progetti in **Impostazioni → Motore degli agenti**. Gli agenti personalizzati sono l'eccezione: vivono come file (`.claude/agents/custom-*.md`) che viaggiano insieme al tuo repository, così tutta la tua squadra usa gli stessi.
 
 Ciò che invece è **per progetto** è la *configurazione* che ci sta sopra: con quale modello gira ciascun agente e quale combinazione di agenti scegli per un dato rail. È a questo che servono i profili — ed è proprio l'argomento della prossima pagina.
 

package/docs/guide/it/agents/2-profiles-and-the-balanced-default.md

@@ -12,7 +12,7 @@ Trovi i profili nella sezione **Agenti** di qualsiasi progetto (barra laterale d
 
 Fin da subito, un progetto si risolve verso un sensato profilo **default**. Include il trio di base — `sr-architect`, `sr-developer`, `sr-reviewer` — e instrada ogni task al developer tramite un'unica regola "cattura-tutto". I modelli sono bilanciati per il lavoro di tutti i giorni: un modello capace dove conta, senza ricorrere all'opzione più costosa a ogni passaggio.
 
-Se nel tuo progetto i modelli degli agenti erano già configurati alla vecchia maniera (nel frontmatter dei file agente), il pulsante **Migra** li legge e costruisce un profilo `default` che rispecchia esattamente il comportamento attuale — nessuna perdita, niente cambia finché non decidi tu di metterci mano.
+Il pulsante **Migra dagli agenti attuali** costruisce un profilo `default` a partire dal trio di base e dagli agenti personalizzati che il progetto ha già — rispecchia esattamente il comportamento attuale e non ha bisogno di alcun file di ruolo. Se un'installazione più vecchia conserva ancora file agente con i modelli nel frontmatter, quei modelli vengono mantenuti; niente cambia finché non decidi tu di metterci mano.
 
 Il punto chiave: **non sei obbligato a creare un profilo per usare Specrails.** Il default funziona e basta. I profili sono il modo per andare oltre.
 

package/docs/guide/it/agents/3-customizing-models-per-agent.md

@@ -15,7 +15,7 @@ In **Agenti → Profili**, seleziona un profilo e apri il suo editor della caten
 
 I valori dei modelli sono alias — per Claude sono `opus`, `sonnet` e `haiku` (dal più capace → al più veloce). Imposta l'alias che desideri per ogni agente:
 
-- Lascia il modello di un agente **vuoto** per ricadere sul default presente nel file dell'agente.
+- Lascia il modello di un agente **vuoto** per ricadere sul default proprio del ruolo — per il trio di base sono il provider e il modello impostati in **Impostazioni → Motore degli agenti**; un agente personalizzato ricade sul frontmatter del suo file.
 - Impostalo esplicitamente per fare l'override solo per questo profilo.
 
 Salva, e il prossimo rail avviato con quel profilo userà i nuovi modelli. I job già in esecuzione mantengono il loro snapshot.

package/docs/guide/it/agents/4-custom-agents-catalog.md

@@ -4,16 +4,16 @@ I profili decidono *quali agenti girano e con quali modelli*. Ma da dove arrivan
 
 Apri **Agenti → Catalogo** in qualsiasi progetto. È un visualizzatore in sola lettura di ogni agente disponibile per quel progetto, suddiviso in due gruppi:
 
-- **Agenti upstream** — gli agenti forniti con `specrails-core`: il trio di base (`sr-architect`, `sr-developer`, `sr-reviewer`) ed eventuali specialisti come `sr-merge-resolver`.
+- **Agenti upstream** — i ruoli che l'engine Core definisce a runtime: il trio di base (`sr-architect`, `sr-developer`, `sr-reviewer`). Non sono file nel tuo repo; il catalogo mostra in sola lettura la definizione attiva di ogni ruolo, e la modifichi in **Impostazioni → Motore degli agenti**.
 - **Agenti custom** — gli agenti che hai aggiunto tu, con nome `custom-*`.
 
-Ogni voce del catalogo mostra a cosa serve l'agente e il suo modello predefinito, così puoi vedere la rosa completa prima di collegare gli agenti a una catena di profilo.
+Ogni voce del catalogo mostra a cosa serve l'agente; gli agenti personalizzati mostrano anche il loro modello predefinito, mentre i ruoli di base girano con il provider e il modello impostati in **Impostazioni → Motore degli agenti**. In ogni caso puoi vedere la rosa completa prima di collegare gli agenti a una catena di profilo.
 
 ## Aggiungere un agente custom
 
 Poiché vivono nel tuo repo, gli agenti custom sono **asset di squadra committabili**: committi il file e tutta la tua squadra ottiene l'agente. Questo riflette l'idea centrale che attraversa l'intera sezione Agenti —
 
-> **Le definizioni degli agenti sono condivise (vivono nel repo e viaggiano con `git`). La configurazione dei modelli è per progetto (vive nei profili).**
+> **Le definizioni degli agenti personalizzati sono condivise (vivono nel repo e viaggiano con `git`); i ruoli di base li definisce il runtime di Core. La configurazione dei modelli è per progetto (vive nei profili).**
 
 ## Mettere al lavoro un agente custom
 

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

@@ -28,7 +28,7 @@
 
 ## 最初に押さえておきたい大切な考え方
 
-各エージェントの *定義* ——その指示内容、その個性、できることの範囲—— は **共有** されます。これらはファイル（`.claude/agents/<id>.md`）として存在し、リポジトリと一緒に移動します。そのため、チーム全体が同じアーキテクト、同じレビュアーを動かすことになります。
+基本エージェントの *定義* ——その指示内容、その個性、できることの範囲—— は、リポジトリ内のファイルではなく、Core エンジンの **ランタイム** から来ます。インストールするものも、同期を保つものもありません。各ロールの定義は Agents カタログで読め、**設定 → エージェント実行エンジン** ですべてのプロジェクト向けに調整できます。例外はカスタムエージェントです。こちらはファイル（`.claude/agents/custom-*.md`）として存在し、リポジトリと一緒に移動するので、チーム全体が同じものを動かすことになります。
 
 一方、**プロジェクトごと** になるのは、その上に重なる *設定* です: 各エージェントがどのモデルで動くか、そしてあるレールにどのエージェントの組み合わせを選ぶか。それこそがプロファイルの役割です —— そしてそれが次のページの話題です。
 

package/docs/guide/ja/agents/2-profiles-and-the-balanced-default.md

@@ -12,7 +12,7 @@
 
 最初の状態では、プロジェクトは適切な **default** プロファイルに解決されます。これは基本のトリオ —— `sr-architect`、`sr-developer`、`sr-reviewer` —— を含み、単一の包括ルールを通じて、すべてのタスクをデベロッパーへルーティングします。モデルは日々の作業に向けてバランスよく選ばれており、肝心なところでは有能なモデルを使いつつ、すべてのステップで最も高価な選択肢に手を伸ばすことはありません。
 
-もしプロジェクトで、すでに従来の方法（エージェントファイルのフロントマター）でエージェントのモデルを設定していた場合は、**Migrate** ボタンがそれらを読み取り、今の動作をそのまま忠実に再現する `default` プロファイルを作成します —— 損失ゼロで、あなたが調整しようと決めるまで何も変わりません。
+**現在のエージェントから移行** ボタンは、基本のトリオと、プロジェクトにすでにあるカスタムエージェントから `default` プロファイルを作成します —— 今の動作をそのまま忠実に再現し、ロールファイルは一つも必要ありません。古いインストールにフロントマターでモデルを指定したエージェントファイルがまだ残っていれば、そのモデルは引き継がれます。あなたが調整しようと決めるまで何も変わりません。
 
 要点はこうです: **Specrails を使うのにプロファイルを作る必要はありません。** デフォルトのままでちゃんと動きます。プロファイルは、そこからさらに踏み込むための手段です。
 

package/docs/guide/ja/agents/3-customizing-models-per-agent.md

@@ -15,7 +15,7 @@
 
 モデルの値はエイリアスです —— Claude の場合は `opus`、`sonnet`、`haiku`（最も有能 → 最も高速）です。エージェントごとに、使いたいエイリアスを設定してください。
 
-- エージェントのモデルを **空欄** のままにすると、そのエージェントファイル自身のデフォルトにフォールバックします。
+- エージェントのモデルを **空欄** のままにすると、そのロール自身のデフォルトにフォールバックします —— 基本のトリオなら **設定 → エージェント実行エンジン** で設定したプロバイダーとモデル、カスタムエージェントならそのファイルのフロントマターです。
 - 明示的に設定すると、このプロファイルだけで上書きします。
 
 保存すれば、そのプロファイルで次に起動されるレールは新しいモデルを使います。すでに実行中のジョブは、自分のスナップショットを保持します。

package/docs/guide/ja/agents/4-custom-agents-catalog.md

@@ -4,16 +4,16 @@
 
 どのプロジェクトでも **Agents → Catalog** を開いてください。そのプロジェクトで利用できるすべてのエージェントを、2つのグループに分けて表示する読み取り専用のビューアーです。
 
-- **アップストリームエージェント** —— `specrails-core` に付属するエージェント: 基本のトリオ（`sr-architect`、`sr-developer`、`sr-reviewer`）と、`sr-merge-resolver` のようなスペシャリストです。
+- **アップストリームエージェント** —— Core エンジンがランタイムで定義するロール: 基本のトリオ（`sr-architect`、`sr-developer`、`sr-reviewer`）です。リポジトリ内のファイルではありません。カタログは各ロールの現在の定義を読み取り専用で表示し、編集は **設定 → エージェント実行エンジン** で行います。
 - **カスタムエージェント** —— あなた自身が追加した、`custom-*` という名前のエージェントです。
 
-各カタログ項目には、そのエージェントが何のためのもので、どのデフォルトモデルを使うかが表示されるので、エージェントをプロファイルのチェーンに組み込む前に、全員の顔ぶれを確認できます。
+各カタログ項目には、そのエージェントが何のためのものかが表示されます。カスタムエージェントはデフォルトモデルも表示され、基本のロールは **設定 → エージェント実行エンジン** で設定したプロバイダーとモデルで動きます。いずれにせよ、エージェントをプロファイルのチェーンに組み込む前に、全員の顔ぶれを確認できます。
 
 ## カスタムエージェントを追加する
 
 カスタムエージェントはリポジトリの中に住んでいるので、**コミット可能なチームの資産** です: ファイルをコミットすれば、チーム全員がそのエージェントを手に入れます。これは Agents セクション全体を貫く中心的な考え方を映したものです ——
 
-> **エージェントの定義は共有されます（リポジトリの中に住み、`git` とともに移動します）。モデルの設定はプロジェクトごとです（プロファイルの中に住みます）。**
+> **カスタムエージェントの定義は共有されます（リポジトリの中に住み、`git` とともに移動します）。基本のロールは Core のランタイムが定義します。モデルの設定はプロジェクトごとです（プロファイルの中に住みます）。**
 
 ## カスタムエージェントを実際に使う
 

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

@@ -28,7 +28,7 @@ Dentro de uma execução, o trabalho é *encaminhado*. Uma tarefa traz tags, e a
 
 ## Uma ideia importante, já agora
 
-A *definição* de cada agente — as suas instruções, a sua personalidade, o que lhe é permitido fazer — é **partilhada**. Vivem como ficheiros (`.claude/agents/<id>.md`) que viajam com o seu repositório, por isso toda a equipa corre o mesmo architect, o mesmo reviewer.
+A *definição* de cada agente de base — as suas instruções, a sua personalidade, o que lhe é permitido fazer — vem do **runtime** do motor Core, não de um ficheiro no seu repositório. Não há nada para instalar nem para manter sincronizado: leia a definição de cada papel no catálogo de Agentes e afine-a para todos os projetos em **Configurações → Motor de agentes**. Os agentes personalizados são a exceção: vivem como ficheiros (`.claude/agents/custom-*.md`) que viajam com o seu repositório, por isso toda a equipa corre os mesmos.
 
 O que é **por projeto** é a *configuração* por cima: com que modelo cada agente corre, e que combinação de agentes escolhe para um dado rail. É para isso que servem os perfis — e esse é o tema da próxima página.
 

package/docs/guide/pt/agents/2-profiles-and-the-balanced-default.md

@@ -12,7 +12,7 @@ Vai encontrar os perfis na secção **Agentes** de qualquer projeto (barra later
 
 Logo à partida, um projeto resolve para um perfil **default** sensato. Inclui o trio de base — `sr-architect`, `sr-developer`, `sr-reviewer` — e encaminha todas as tarefas para o developer através de uma única regra do tipo apanha-tudo. Os modelos estão equilibrados para o trabalho do dia a dia: um modelo capaz onde importa, sem recorrer à opção mais cara em cada passo.
 
-Se o seu projeto já tinha os modelos dos agentes configurados à maneira antiga (no frontmatter dos ficheiros dos agentes), o botão **Migrar** lê esses valores e cria um perfil `default` que reflete exatamente o comportamento atual — sem perdas, nada muda até que decida afiná-lo.
+O botão **Migrar a partir dos agentes atuais** cria um perfil `default` a partir do trio de base e dos agentes personalizados que o projeto já tem — reflete exatamente o comportamento atual e não precisa de nenhum ficheiro de papel. Se uma instalação mais antiga ainda guardar ficheiros de agentes com modelos no frontmatter, esses modelos são mantidos; nada muda até que decida afiná-lo.
 
 O ponto principal: **não precisa de criar um perfil para usar o Specrails.** A predefinição simplesmente funciona. Os perfis são a forma de ir mais além.
 

package/docs/guide/pt/agents/3-customizing-models-per-agent.md

@@ -15,7 +15,7 @@ Em **Agentes → Perfis**, selecione um perfil e abra o seu editor de cadeia de
 
 Os valores de modelo são aliases — para o Claude são `opus`, `sonnet` e `haiku` (do mais capaz → ao mais rápido). Defina o alias que quiser por agente:
 
-- Deixe o modelo de um agente **em branco** para recorrer à predefinição do próprio ficheiro do agente.
+- Deixe o modelo de um agente **em branco** para recorrer à predefinição do próprio papel — no trio de base são o fornecedor e o modelo definidos em **Configurações → Motor de agentes**; um agente personalizado recorre ao frontmatter do seu ficheiro.
 - Defina-o explicitamente para o substituir apenas neste perfil.
 
 Guarde, e o próximo rail lançado com esse perfil usa os novos modelos. Os jobs já em execução mantêm o seu snapshot.

package/docs/guide/pt/agents/4-custom-agents-catalog.md

@@ -4,16 +4,16 @@ Os perfis decidem *que agentes correm e com que modelos*. Mas de onde vêm os pr
 
 Abra **Agentes → Catálogo** em qualquer projeto. É um visualizador apenas de leitura de todos os agentes disponíveis para esse projeto, em dois grupos:
 
-- **Agentes upstream** — os agentes que vêm com o `specrails-core`: o trio de base (`sr-architect`, `sr-developer`, `sr-reviewer`) e quaisquer especialistas como o `sr-merge-resolver`.
+- **Agentes upstream** — os papéis que o motor Core define em tempo de execução: o trio de base (`sr-architect`, `sr-developer`, `sr-reviewer`). Não são ficheiros do seu repositório; o catálogo mostra a definição em vigor de cada papel apenas em leitura, e edita-a em **Configurações → Motor de agentes**.
 - **Agentes personalizados** — agentes que adicionou você mesmo, com o nome `custom-*`.
 
-Cada entrada do catálogo mostra para que serve o agente e o seu modelo predefinido, para que possa ver toda a equipa antes de ligar os agentes a uma cadeia de perfil.
+Cada entrada do catálogo mostra para que serve o agente; os agentes personalizados mostram também o seu modelo predefinido, enquanto os papéis de base correm com o fornecedor e o modelo definidos em **Configurações → Motor de agentes**. Em qualquer caso, pode ver toda a equipa antes de ligar os agentes a uma cadeia de perfil.
 
 ## Adicionar um agente personalizado
 
 Como vivem no seu repositório, os agentes personalizados são **ativos de equipa que se podem committar**: faça commit do ficheiro e toda a equipa fica com o agente. Isto espelha a ideia central de toda a secção Agentes —
 
-> **As definições dos agentes são partilhadas (vivem no repositório e viajam com o `git`). A configuração dos modelos é por projeto (vive nos perfis).**
+> **As definições dos agentes personalizados são partilhadas (vivem no repositório e viajam com o `git`); os papéis de base são definidos pelo runtime do Core. A configuração dos modelos é por projeto (vive nos perfis).**
 
 ## Pôr um agente personalizado a trabalhar
 

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

@@ -28,7 +28,7 @@
 
 ## 一个需要先说清楚的重要观念
 
-每个 Agent 的*定义*——它的指令、它的性格、它被允许做什么——是**共享的**。它们以文件的形式存在（`.claude/agents/<id>.md`），随你的代码仓库一起流转，因此你的整个团队跑的是同一个 architect、同一个 reviewer。
+每个基础 Agent 的*定义*——它的指令、它的性格、它被允许做什么——来自 Core 引擎的**运行时**，而不是你仓库里的某个文件。没有东西需要安装，也没有东西需要保持同步：在 Agents 目录里可以读到每个角色的定义，并在 **设置 → 代理运行引擎** 中为所有项目统一调校。自定义 Agent 是例外——它们以文件的形式存在（`.claude/agents/custom-*.md`），随你的代码仓库一起流转，因此你的整个团队跑的是同一批自定义 Agent。
 
 而**因项目而异**的，是叠加在其上的*配置*：每个 Agent 用哪个模型运行，以及你为某条 rail 挑选了哪一组 Agent 的组合。这正是 Profile 的用武之地——也是下一页的内容。
 

package/docs/guide/zh/agents/2-profiles-and-the-balanced-default.md

@@ -12,7 +12,7 @@
 
 开箱即用时，项目会解析到一个合理的 **default** Profile。它包含基础三人组——`sr-architect`、`sr-developer`、`sr-reviewer`——并通过一条兜底规则把每个任务都路由给 developer。模型搭配在日常工作中保持均衡：在关键处用足够强的模型，而不会每一步都去动用最贵的那一个。
 
-如果你的项目此前已经用老办法配置过 Agent 模型（写在 Agent 文件的 frontmatter 里），那么 **迁移** 按钮会读取这些配置，并构建出一个完整复刻当前行为的 `default` Profile——零损失，在你决定调校它之前什么都不会变。
+**从当前 Agent 迁移** 按钮会基于基础三人组和项目里已有的自定义 Agent 构建出一个 `default` Profile——完整复刻当前行为，而且不需要任何角色文件存在。如果较旧的安装里仍留有在 frontmatter 中写了模型的 Agent 文件，这些模型会被保留；在你决定调校它之前什么都不会变。
 
 重点是：**你不必先创建 Profile 才能使用 Specrails。** 默认值就能正常工作。Profile 是你想更进一步时的手段。
 

package/docs/guide/zh/agents/3-customizing-models-per-agent.md

@@ -15,7 +15,7 @@ Profile 让你能做的最有用的一件事，就是**为每一步挑选合适
 
 模型值是一些别名——对 Claude 而言就是 `opus`、`sonnet` 和 `haiku`（从最强 → 最快）。按 Agent 设置你想要的别名：
 
-- 把某个 Agent 的模型**留空**，即回退到该 Agent 文件自带的默认值。
+- 把某个 Agent 的模型**留空**，即回退到该角色自身的默认值——基础三人组回退到 **设置 → 代理运行引擎** 中设置的提供商和模型；自定义 Agent 则回退到其文件的 frontmatter。
 - 显式设置它，则仅在此 Profile 内覆盖。
 
 保存之后，下一条用该 Profile 启动的 rail 就会使用新模型。已在运行的任务则保留它们的快照。

package/docs/guide/zh/agents/4-custom-agents-catalog.md

@@ -4,16 +4,16 @@ Profile 决定的是*哪些 Agent 运行、用什么模型*。但 Agent 本身
 
 在任意项目中打开 **Agents → 目录**。它是一个只读视图，列出该项目可用的每一个 Agent，分为两组：
 
-- **上游 Agent**——随 `specrails-core` 一起发布的 Agent：基础三人组（`sr-architect`、`sr-developer`、`sr-reviewer`）以及像 `sr-merge-resolver` 这样的任何专家型 Agent。
+- **上游 Agent**——由 Core 引擎在运行时定义的角色：基础三人组（`sr-architect`、`sr-developer`、`sr-reviewer`）。它们不是你仓库里的文件；目录以只读方式展示每个角色当前生效的定义，编辑则在 **设置 → 代理运行引擎** 中进行。
 - **自定义 Agent**——你自己添加的 Agent，命名为 `custom-*`。
 
-每个目录条目都会展示该 Agent 的用途和它的默认模型，这样在把 Agent 接入某条 Profile 链之前，你就能看清整支阵容。
+每个目录条目都会展示该 Agent 的用途；自定义 Agent 还会显示它的默认模型，而基础角色则使用 **设置 → 代理运行引擎** 中设置的提供商和模型运行。无论哪种，在把 Agent 接入某条 Profile 链之前，你都能看清整支阵容。
 
 ## 添加一个自定义 Agent
 
 由于它们就住在你的仓库里，自定义 Agent 是**可提交的团队资产**：提交这个文件，你的整个团队就都拥有了这个 Agent。这呼应了贯穿整个 Agents 区的核心观念——
 
-> **Agent 定义是共享的（它们住在仓库里，随 `git` 一起流转）。模型配置则因项目而异（它住在 Profile 里）。**
+> **自定义 Agent 的定义是共享的（它们住在仓库里，随 `git` 一起流转）；基础角色由 Core 运行时定义。模型配置则因项目而异（它住在 Profile 里）。**
 
 ## 让自定义 Agent 上岗